draft-ietf-pce-interas-pcecp-reqs-03.txt   draft-ietf-pce-interas-pcecp-reqs-04.txt 
Network Working Group Nabil Bitar Network Working Group Nabil Bitar
Internet Draft (Editor)
Intended Status: Informational Verizon
Expires: September 2008 Raymond Zhang
(Editor) (Editor)
Verizon BT
Internet Draft Raymond Zhang Kenji Kumaki
(Editor)
BT Infonet
Intended Status: Informational Kenji Kumaki
(Editor) (Editor)
KDDI Corporation KDDI Corporation
February 2008
Inter-AS Requirements for the Path Computation Element Inter-AS Requirements for the Path Computation Element
Communication Protocol (PCECP) Communication Protocol (PCECP)
draft-ietf-pce-interas-pcecp-reqs-03.txt draft-ietf-pce-interas-pcecp-reqs-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author By submitting this Internet-Draft, each author represents that any
represents that any applicable patent or other IPR applicable patent or other IPR claims of which he or she is aware
claims of which he or she is aware have been or will have been or will be disclosed, and any of which he or she becomes
be disclosed, and any of which he or she becomes aware aware will be disclosed, in accordance with Section 6 of BCP 79.
will be disclosed, in accordance with Section 6 of BCP
79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet Engineering
Engineering Task Force (IETF), its areas, and its Task Force (IETF), its areas, and its working groups. Note that
working groups. Note that other groups may also other groups may also distribute working documents as Internet-
distribute working documents as Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in January 2008. This Internet-Draft will expire in September 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Multiprotocol Label Switching Traffic Engineered (MPLS-TE) Label Multiprotocol Label Switching Traffic Engineered (MPLS-TE) Label
Switched Paths (LSPs) may be established wholly within an Autonomous Switched Paths (LSPs) may be established wholly within an Autonomous
System (AS) or may cross AS boundaries. System (AS) or may cross AS boundaries.
The Path Computation Element (PCE) is a component that is capable of The Path Computation Element (PCE) is a component that is capable of
computing paths for MPLS-TE LSPs. The PCE Communication computing paths for MPLS-TE LSPs. The PCE Communication
Protocol(PCECP) is defined to allow communication between Path Protocol(PCECP) is defined to allow communication between Path
Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is
used to request paths and to supply computed paths in responses. used to request paths and to supply computed paths in response.
Generic requirements for the PCEP are set out in "Path Computation Generic requirements for the PCECP are set out in "Path Computation
Element(PCE) Communication Protocol Generic Requirements", RFC 4657. Element(PCE) Communication Protocol Generic Requirements", RFC 4657.
This document extends those requirements to cover the use of PCEP in This document extends those requirements to cover the use of PCECP
support of inter-AS MPLS-TE. in support of inter-AS MPLS-TE.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction....................................................3
2. Definitions......................................................3 2. Definitions.....................................................4
3. Reference Model..................................................4 3. Reference Model.................................................4
4. Detailed PCECP Requirements for Inter-AS Computation.............5 3.1. Scope of Deployment Model.....................................5
4.1. PCE Communication Protocol Requirements........................5 4. Detailed PCECP Requirements for Inter-AS Computation............6
4.1.1. Requirements for path computation requests...................5 4.1. PCE Communication Protocol Requirements.......................6
4.1.2. Requirements for path computation responses..................6 4.1.1. Requirements for path computation requests..................6
4.2. Scalability and Performance Considerations.....................7 4.1.2. Requirements for path computation responses.................7
4.3. Management Considerations......................................8 4.2. Scalability and Performance Considerations....................8
4.4. Confidentiality................................................8 4.3. Management Considerations.....................................8
4.5. Policy Controls Affecting inter-AS PCECP.......................9 4.4. Confidentiality...............................................9
4.5.1. Inter-AS PCE Peering Policy Controls.........................9 4.5. Policy Controls Affecting inter-AS PCECP.....................10
4.5.2. Inter-AS PCE Reinterpretation Policies......................10 4.5.1. Inter-AS PCE Peering Policy Controls.......................10
5. Security Considerations.........................................10 4.5.2. Inter-AS PCE Re-interpretation Policies....................11
6. IANA Considerations.............................................11 5. Security Considerations........................................11
7. Acknowledgments.................................................11 5.1. Use and Distribution of Keys.................................11
8. Authors' Addresses..............................................11 5.2. Application of Policy........................................12
9. Normative References............................................12 5.3. Confidentiality..............................................12
10. Informative References.........................................12 5.4. Falsification of Information.................................13
6. IANA Considerations............................................13
7. Acknowledgments................................................13
8. Authors' Addresses.............................................13
9. Normative References...........................................14
10. Informative References........................................14
1. Introduction 1. Introduction
[RFC4216] defines the scenarios motivating the deployment of inter- [RFC4216] defines the scenarios motivating the deployment of inter-
AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
specifies the requirements for inter-AS MPLS-TE when the ASes are specifies the requirements for inter-AS MPLS-TE when the ASes are
under the administration of one Service Provider (SP) or the under the administration of one Service Provider (SP) or the
administration of different SPs. administration of different SPs.
Three signaling options are defined for setting up an inter-AS TE Three signaling options are defined for setting up an inter-AS TE
skipping to change at page 3, line 37 skipping to change at page 3, line 38
The Path Computation Element (PCE) [RFC4655] is a component that is The Path Computation Element (PCE) [RFC4655] is a component that is
capable of computing paths for MPLS-TE LSPs. The requirements for a capable of computing paths for MPLS-TE LSPs. The requirements for a
PCE have come from Service Provider (SP) demands to compute optimum PCE have come from Service Provider (SP) demands to compute optimum
paths across multiple areas and/or domains, and to be able to paths across multiple areas and/or domains, and to be able to
separate the path computation elements from the forwarding elements. separate the path computation elements from the forwarding elements.
The PCE Communication Protocol (PCECP) is defined to allow The PCE Communication Protocol (PCECP) is defined to allow
communication between Path Computation Clients (PCCs) and PCEs, and communication between Path Computation Clients (PCCs) and PCEs, and
between PCEs. The PCECP is used to request paths and to supply between PCEs. The PCECP is used to request paths and to supply
computed paths in responses. Generic requirements for the PCECP are computed paths in response. Generic requirements for the PCECP are
discussed in [RFC4657]. This document provides a set of PCECP discussed in [RFC4657]. This document provides a set of PCECP
requirements that are specific to MPLS-TE inter-AS path computation. requirements that are specific to inter-AS (G)MPLS-TE path
computation.
2. Definitions 2. Definitions
This document adopts the definitions and acronyms defined in Section This document adopts the definitions and acronyms defined in Section
3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the
following terminology: following terminology:
PCECP: PCE Communication Protocol PCECP: PCE Communication Protocol
Inter-AS (G)MPLS-TE: MPLS or Generalized MPLS Traffic Engineering
Inter-AS (G)MPLS-TE path: An MPLS-TE or Generalized MPLS (GMPLS) Inter-AS (G)MPLS-TE path: An MPLS-TE or Generalized MPLS (GMPLS)
path that traverses two or more ASes. path that traverses two or more ASes.
Intra-AS (G)MPLS-TE path: An MPLS-TE or GMPLS path that is confined Intra-AS (G)MPLS-TE path: An MPLS-TE or GMPLS path that is confined
to a single AS. It may traverse one or more IGP areas. to a single AS. It may traverse one or more IGP areas.
Intra-AS PCE: A PCE responsible for computing MPLS-TE or GMPLS paths Intra-AS PCE: A PCE responsible for computing MPLS-TE or GMPLS paths
remaining within a single AS. remaining within a single AS.
Inter-AS PCE: A PCE responsible for computing inter-AS MPLS-TE or Inter-AS PCE: A PCE responsible for computing inter-AS MPLS-TE or
skipping to change at page 4, line 29 skipping to change at page 4, line 37
3. Reference Model 3. Reference Model
Figure 1 depicts the reference model for PCEs in an inter-AS Figure 1 depicts the reference model for PCEs in an inter-AS
application. We refer to two types of PCE functions in this application. We refer to two types of PCE functions in this
document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the
procedures needed for inter-AS MPLS-TE or GMPLS path computation procedures needed for inter-AS MPLS-TE or GMPLS path computation
while intra-AS PCEs perform the functions needed for intra-AS MPLS- while intra-AS PCEs perform the functions needed for intra-AS MPLS-
TE or GMPLS path computation. TE or GMPLS path computation.
Lets follow a scenario that illustrates the interaction among PCCs, Let's follow a scenario that illustrates the interaction among PCCs,
inter-AS PCEs and intra-AS PCEs shown Figure 1. R1 in AS1 wants to inter-AS PCEs and intra-AS PCEs as shown Figure 1. R1 in AS1 wants
setup a MPLS-TE or a GMPLS path, call LSP1, with certain constraints to setup a MPLS-TE or a GMPLS path, call it LSP1, with certain
to R7 in AS3. R1 determines using mechanisms out of the scope of constraints to R7 in AS3. R1 determines, using mechanisms out of the
this document that R7 is an inter-AS route and that it needs to scope of this document, that R7 is an inter-AS route and that it
contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a needs to contact its Inter-AS PCE1 to compute the path. R1, as a
PCECP path request to PCE1. PCE1 determines that R7 is reachable via PCC, sends a PCECP path request to PCE1. PCE1 determines that R7 is
AS2 and that PCE2 is the PCE to ask for path computation across AS2. reachable via AS2 and that PCE2 is the PCE to ask for path
PCE1 sends a PCECP path request to PCE2. Inter-AS PCE2, in turn, computation across AS2. PCE1 sends a PCECP path request to PCE2.
sends a PCECP path request to Intra-AS PCE R4 to compute a path Inter-AS PCE2, in turn, sends a PCECP path request to Intra-AS PCE
within AS2 (In certain cases, the same router such R3 can assume R4 to compute a path within AS2 (in certain cases, the same router
both inter-AS and intra-AS path computation functions). R4 returns a such as R3 can assume both inter-AS and intra-AS path computation
PCECP path response to PCE2 with ASBR3 as the entry point to AS2 functions). R4 returns a PCECP path response to PCE2 with ASBR3 as
from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a PCECP the entry point to AS2 from AS1 and ASBR7 as the exit point to AS3.
path request to PCE3 to compute the path segment across AS3, PCE2 then sends a PCECP path request to PCE3 to compute the path
starting at ASBR7 and terminating at R7. PCE3 returns a PCECP path segment across AS3, starting at ASBR7 and terminating at R7. PCE3
response to PCE2 with the path segment ASBR7-R7. PCE2 then return returns a PCECP path response to PCE2 with the path segment ASBR7-
path ASBR3-ASBR7-R7 to PCE1 which, in turn, returns path ASBR1- R7. PCE2 then return path ASBR3-ASBR5-ASBR7-R7 to PCE1 which, in
ASBR3-ASBR7-R7 to PCC R1. turn, returns path ASBR1-ASBR3-ASBR5-ASBR7-R7 to PCC R1.
As described in the above scenario, in general, a PCC may contact an As described in the above scenario, in general, a PCC may contact an
inter-AS PCE to request an inter-AS path, and that PCE may supply inter-AS PCE to request an inter-AS path, and that PCE may supply
the path itself, or may solicit the services of other PCEs which the path itself, or may solicit the services of other PCEs which
may, themselves be inter-AS PCEs, or may be intra-AS PCEs with the may, themselves be inter-AS PCEs, or may be intra-AS PCEs with the
responsibility for computing path segments within just one AS. responsibility for computing path segments within just one AS.
This document describes the PCE Communication Protocol requirements This document describes the PCE Communication Protocol requirements
for inter-AS path computation. That is, for PCCs to communicate path for inter-AS path computation. That is, for PCCs to communicate path
requests for inter-AS paths to a PCE, and for the PCE to respond. It requests for inter-AS paths to a PCE, and for the PCE to respond. It
also includes the requirements for PCEs to communicate inter-AS path also includes the requirements for PCEs to communicate inter-AS path
requests and responses. requests and responses.
Inter-AS Inter-AS Inter AS Inter-AS Inter-AS Inter-AS
PCC <->PCE1<--------->PCE2<--------------->PCE3 PCC <->PCE1<--------->PCE2<--------------->PCE3
:: :: :: :: :: :: :: ::
R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
| | | | | | | | | | | |
| | | | | | | | | | | |
R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
:: ::
Intra-AS Intra-AS
PCE PCE
<==AS1=> <====AS2======> <=====AS3===> <==AS1=> <====AS2======> <=====AS3===>
Figure 1 Inter and Intra-AS PCE Reference Model Figure 1 Inter and Intra-AS PCE Reference Model
3.1. Scope of Deployment Model
All attempts to predict future deployment scopes within the Internet
have proven fruitless. Nevertheless, it may be helpful to provide
some discussion of the scope of the inter-AS deployment model as
envisioned at the time of writing.
It is expected that most, if not all, inter-AS PCECP-based
communications will be between PCEs operating in the cooperative PCE
model described in [RFC4655]. Clearly, in this model, the requesting
PCE acts as a PCC for the purpose of issuing a path computation
request, but nevertheless, the requesting node fills the wider role
of a PCE in its own AS. It is currently considered unlikely that a
PCC (for example, a normal Label Switching Router) will make a path
computation request to a PCE outside its own AS. This means that the
PCECP relationships between ASes are limited to at most n-squared
where n is the number of peering PCEs in the various ASes
(considered to be no greater than 100 in [RFC4657]). In practice,
however, it is likely that only a few PCEs in one AS will be
designated for PCECP communications with a PCE in an adjacent AS,
and each of these will only have a few PCEs in the adjacent AS to
choose from. A deployment model might place the PCEs as co-resident
with the ASBRs, resulting in a manageable scaling of the PCE-PCE
relationships. Scaling considerations (Section 4.2), manageability
considerations (Section 4.3), and security considerations (Section
5) should be examined in the light of these deployment expectations.
4. Detailed PCECP Requirements for Inter-AS Computation 4. Detailed PCECP Requirements for Inter-AS Computation
This section discusses detailed PCECP requirements for inter-AS This section discusses detailed PCECP requirements for inter-AS
MPLS-TE and GMPLS LSPs. Depending on the deployment environment, MPLS-TE and GMPLS LSPs. Depending on the deployment environment,
some or all of the requirements described here may be utilized. some or all of the requirements described here may be utilized.
Specifically, some requirements are more applicable to inter- Specifically, some requirements are more applicable to inter-
provider inter-AS MPLS-TE and GMPLS operations than to intra- provider inter-AS MPLS-TE and GMPLS operations than to intra-
provider operations. provider operations.
4.1. PCE Communication Protocol Requirements 4.1. PCE Communication Protocol Requirements
skipping to change at page 6, line 17 skipping to change at page 7, line 9
not change that requirement, but, in addition, it MUST be possible not change that requirement, but, in addition, it MUST be possible
for an inter-AS PCE to apply local policy to vary the priority of for an inter-AS PCE to apply local policy to vary the priority of
path computation requests received across AS borders. PCECP MAY path computation requests received across AS borders. PCECP MAY
include a mechanism to inform the requesting inter-AS PCE of the include a mechanism to inform the requesting inter-AS PCE of the
change in priority that was applied. change in priority that was applied.
2. A path computation request by an inter-AS PCE or a PCC to another 2. A path computation request by an inter-AS PCE or a PCC to another
inter-AS PCE MUST be able to specify the sequence of ASes and/or inter-AS PCE MUST be able to specify the sequence of ASes and/or
ASBRs across the network by providing ASBRs and/or ASes as hops in ASBRs across the network by providing ASBRs and/or ASes as hops in
the desired path of the LSP to the destination. For instance, an the desired path of the LSP to the destination. For instance, an
inter-AS PCE MUST be be able to specify to the inter-AS PCE serving inter-AS PCE MUST be able to specify to the inter-AS PCE serving the
the neighboring AS a preferred ASBR for exiting to that AS and reach neighboring AS a preferred ASBR for exiting to that AS and reach the
the destination. That is, where multiple ASBRs exist, the requester destination. That is, where multiple ASBRs exist, the requester MUST
MUST be able to indicate a non-mandatory preference for one of them. be able to indicate a preference for one of them. The PCE must be
able to indicate whether the specified ASBR or AS as mandatory or
non-mandatory to be on the (G)MPLS-TE path.
3. PCECP MUST allow a requester to provide a list of ASes and/or 3. PCECP MUST allow a requester to provide a list of ASes and/or
ASBRs to be excluded from the computed path. ASBRs to be excluded from the computed path.
4. A PCECP path request from one inter-AS PCE to another MUST 4. A PCECP path request from one inter-AS PCE to another MUST
include the previous AS number in the path of the LSP to enable the include the previous AS number in the path of the LSP to enable the
correct application of local policy at the second inter-AS PCE. correct application of local policy at the second inter-AS PCE.
5. A path computation request from a PCC to an inter-AS PCE or an 5. A path computation request from a PCC to an inter-AS PCE or an
inter-AS PCE to another MUST be able to specify the need for inter-AS PCE to another MUST be able to specify the need for
protection against node, link, or SRLG failure using 1:1 detours or protection against node, link, or SRLG failure using 1:1 detours or
facility backup. It MUST be possible to request protection across facility backup. It MUST be possible to request protection across
all ASes or across specific ASes. all ASes or across specific ASes.
6. The disjoint path requirements specified in [RFC4657] are 6. PCECP MUST support the disjoint path requirements specified in
extended such that it MUST be possible to apply a constraint of AS- [RFC4657] and MUST further allow the specification of AS-diversity
diversity in the computation of a set of two or more paths. for the computation of a set of two or more paths.
7. A PCECP path computation request message MUST be able to identify 7. A PCECP path computation request message MUST be able to identify
the scope of diversified path computation to be end-to-end (i.e., the scope of diversified path computation to be end-to-end (i.e.,
between the endpoints of the (G)MPLS-TE tunnel) or to be limited to between the endpoints of the (G)MPLS-TE tunnel) or to be limited to
a specific AS. a specific AS.
4.1.2. Requirements for path computation responses 4.1.2. Requirements for path computation responses
The following are inter-AS specific requirements for PCECP responses The following are inter-AS specific requirements for PCECP responses
for path computation: for path computation:
1. A PCECP path computation response from one inter-AS PCE to 1. A PCECP path computation response from one inter-AS PCE to
another MUST be able to include both ASBRs and ASes in the computed another MUST be able to include both ASBRs and ASes in the computed
path while preserving path segment and topology confidentiality. path while preserving path segment and topology confidentiality.
2. A PCECP path computation response from one inter-AS PCE to the 2. A PCECP path computation response from one inter-AS PCE to the
requesting inter-AS PCE MUST be able to carry an identifier for a requesting inter-AS PCE MUST be able to carry an identifier for a path
path segment it computes to preserve path segment and topology segment it computes to preserve path segment and topology
confidentiality. The objective of the identifier is to be included confidentiality. The objective of the identifier is to be included in
in the LSP signaling, whose mechanism is out of scope of this
document, to be used for path expansion during LSP signaling. the LSP signaling, whose mechanism is out of scope of this document, to
be used for path expansion during LSP signaling.
3. If a constraint for a desired ASBR (see Section 4.1.1, 3. If a constraint for a desired ASBR (see Section 4.1.1,
requirement 3) cannot be satisfied by a PCE, PCECP SHOULD allow the requirement 2) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE
PCE to notify the requester of that fact as an error in a path to notify the requester of that fact as an error in a path computation
computation response. response.
4. A PCECP path computation from an inter-AS PCE to a requesting 4. A PCECP path computation from an inter-AS PCE to a requesting
inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS path
path cost. Path cost normalization across ASes is out of scope of cost. Path cost normalization across ASes is out of scope of this
this document. document.
5. A PCECP path computation response from an inter-AS PCE to a PCC 5. A PCECP path computation response from an inter-AS PCE to a PCC
SHOULD be able to carry the intra-AS cost of the path segment within SHOULD be able to carry the intra-AS cost of the path segment within
the PCC AS. the PCC AS.
6. A PCECP path computation response MUST be able to identify 6. A PCECP path computation response MUST be able to identify
diversified paths for the same (G)MPLS-TE LSP. End-to-end (i.e., diversified paths for the same (G)MPLS-TE LSP. End-to-end (i.e.,
between the two endpoints of the (G)MPLS-TE tunnel) disjoint paths between the two endpoints of the (G)MPLS-TE tunnel) disjoint paths are
are paths that do not share nodes, links or SRLGs except for the LSP paths that do not share nodes, links or SRLGs except for the LSP head-
head-end and tail-end. In cases where diversified path segments are end and tail-end. In cases where diversified path segments are desired
desired within one or more ASes, the disjoint path segments may within one or more ASes, the disjoint path segments may share only the
share only the ASBRs of the first AS and the ASBR of the last AS ASBRs of the first AS and the ASBR of the last AS across these ASes.
across these ASes.
4.2. Scalability and Performance Considerations 4.2. Scalability and Performance Considerations
PCECP design for use in the inter-AS case SHOULD consider the PCECP design for use in the inter-AS case SHOULD consider the following
following criteria: criteria:
- PCE message processing load. - PCE message processing load.
- Scalability as a function of the following parameters: - Scalability as a function of the following parameters:
- number of PCCs within the scope of an inter-AS PCE - number of PCCs within the scope of an inter-AS PCE
- number of intra-AS PCEs within the scope of an inter-AS PCE - number of intra-AS PCEs within the scope of an inter-AS PCE
- number of peering inter-AS PCEs per inter-AS PCE - number of peering inter-AS PCEs per inter-AS PCE
- Added complexity caused by inter-AS features. - Added complexity caused by inter-AS features.
4.3. Management Considerations 4.3. Management Considerations
[RFC4657] specifies generic requirements for PCECP management. This [RFC4657] specifies generic requirements for PCECP management. This
document addresses new requirements that apply to inter-AS document addresses new requirements that apply to inter-AS operations.
perations.
The PCECP MIB module MUST provide objects to control the behavior of The PCECP MIB module MUST provide objects to control the behavior of
PCECP in inter-AS applications. They include the ASes within the PCECP in inter-AS applications. They include the ASes within the
scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which
the requesting PCE will or will not communicate, confidentiality and the requesting PCE will or will not communicate, confidentiality and
policies, etc.. policies, etc..
The built-in diagnostic tools MUST enable failure detection and The built-in diagnostic tools MUST enable failure detection and
status checking of PCC/PCE-PCE PCECP. Diagnostic tools include status checking of PCC/PCE-PCE PCECP. Diagnostic tools include
statistics collection on the historical behavior of PCECP as statistics collection on the historical behavior of PCECP as
specified in [RFC4657], but additionally it MUST be possible to specified in [RFC4657], but additionally it MUST be possible to
analyze this statistics on a neighboring AS basis (i.e., across the analyze this statistics on a neighboring AS basis (i.e., across the
inter-AS PCEs that belong to a neighboring AS). inter-AS PCEs that belong to a neighboring AS).
The MIB module MUST support trap functions when thresholds are The MIB module MUST support trap functions when thresholds are
crossed or when important events occur as stated in [RFC4657]. These crossed or when important events occur as stated in [RFC4657]. These
thresholds SHOULD be specifiable per neighbor AS as well as per peer thresholds SHOULD be specifiable per neighbor AS as well as per peer
inter-AS PCE and traps should be accordingly generated. inter-AS PCE, and traps should be accordingly generated.
Basic liveliness detection for PCC/PCE-PCE PCECP is described in Basic liveliness detection for PCC/PCE-PCE PCECP is described in
[RFC4657]. The PCECP MIB module SHOULD allow control of liveliness [RFC4657]. The PCECP MIB module SHOULD allow control of liveliness
check behavior by providing a liveliness message frequency MIB check behavior by providing a liveliness message frequency MIB
object and this frequency object SHOULD be specified per inter-AS object and this frequency object SHOULD be specified per inter-AS
PCE peer. In addition, there SHOULD be a MIB object that specifies PCE peer. In addition, there SHOULD be a MIB object that specifies
the dead-interval as a multiplier of the liveliness message the dead-interval as a multiplier of the liveliness message
frequency so that if no liveliness message is received within that frequency so that if no liveliness message is received within that
time from an inter-A PCE, the inter-AS PCE is declared unreachable. time from an inter-AS PCE, the inter-AS PCE is declared unreachable.
4.4. Confidentiality 4.4. Confidentiality
Confidentiality mainly applies to inter-provider (inter-AS) PCE Confidentiality mainly applies to inter-provider (inter-AS) PCE
communication. It is about protecting the information exchanged communication. It is about protecting the information exchanged between
between PCEs and about protecting the topology information within PCEs and about protecting the topology information within a provider's
a provider's network. Confidentiality rules may also apply among network. Confidentiality rules may also apply among ASes under a single
ASes under a single provider. Each SP will in most cases designate provider. Each SP will in most cases designate some PCEs for inter-AS
some PCEs for inter-AS MPLS-TE or GMPLS path computation within its MPLS-TE or GMPLS path computation within its own administrative domain
own administrative domain and some other PCEs for inter-provider and some other PCEs for inter-provider inter-AS MPLS-TE or GMPLS path
inter-AS MPLS-TE or GMPLS path computation. Among the computation. Among the inter-provider-scoped inter-AS PCEs in each SP
inter-provider-scoped inter-AS PCEs in each SP domain, there may also be a subset of the PCEs specifically enabled for
domain, there may also be a subset of the PCEs specifically enabled path computation across a specific set of ASes of different peer SPs.
for path computation across a specific set of ASes of different peer
SPs.
PCECP SHOULD allow an SP to hide from other SPs the set of hops PCECP SHOULD allow an SP to hide from other SPs the set of hops
within its own ASes that are traversed by an inter-AS inter-provider within its own ASes that are traversed by an inter-AS inter-provider
LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative
domain environment, SPs may want to hide their network topologies domain environment, SPs may want to hide their network topologies
for security or commercial reasons. Thus, for each inter-AS LSP path for security or commercial reasons. Thus, for each inter-AS LSP path
segment an inter-AS PCE computes, it may return to the requesting segment an inter-AS PCE computes, it may return to the requesting
inter-AS PCE an inter-AS TE LSP path segment from its own ASes inter-AS PCE an inter-AS TE LSP path segment from its own ASes
without detailing the explicit intra-AS hops. As stated earlier, without detailing the explicit intra-AS hops. As stated earlier,
PCECP responses SHOULD be able to carry path-segment identifiers PCECP responses SHOULD be able to carry path-segment identifiers
that replace the details of that path segment. The potential use of that replace the details of that path segment. The potential use of
that identifier for path expansion, for instance, during LSP that identifier for path expansion, for instance, during LSP
signaling is out of scope of this document. signaling is out of scope of this document.
4.5. Policy Controls Affecting inter-AS PCECP 4.5. Policy Controls Affecting inter-AS PCECP
Section 5.2.2 of [RFC4216] discusses the policy control requirements Section 5.2.2 of [RFC4216] discusses the policy control requirements
for inter-AS RSVP-TE signaling at the AS boundaries for the for inter-AS RSVP-TE signaling at the AS boundaries for the enforcement
enforcement of interconnect agreements, attribute/parameter of interconnect agreements, attribute/parameter translation and
translation and security hardening. security hardening.
This section discusses those policy control requirements that are This section discusses those policy control requirements that are
similar to what are discussed in section 5.2.2 of [RFC4216] for similar to what are discussed in section 5.2.2 of [RFC4216] for
PCECP. Please note that SPs may still require policy controls during PCECP. Please note that SPs may still require policy controls during
signaling of LSPs to enforce their bilateral or multi-lateral signaling of LSPs to enforce their bilateral or multi-lateral
agreements at AS boundaries, but signaling is out of scope for this agreements at AS boundaries, but signaling is out of scope for this
document. document.
4.5.1. Inter-AS PCE Peering Policy Controls 4.5.1. Inter-AS PCE Peering Policy Controls
An inter-AS PCE sends path computation requests to its neighboring An inter-AS PCE sends path computation requests to its neighboring
inter-AS PCEs, and an inter-AS PCE that receives such a request inter-AS PCEs, and an inter-AS PCE that receives such a request
enforces policies applicable to the sender of the request. These enforces policies applicable to the sender of the request. These
policies may include rewriting some of the parameters, or rejecting policies may include rewriting some of the parameters, or rejecting
requests based on parameter values. Such policies may be applied for requests based on parameter values. Such policies may be applied for
PCEs belonging to different SPs or to PCEs responsible for ASes PCEs belonging to different SPs or to PCEs responsible for ASes within
within a single SP administrative domain. Parameters that might be a single SP administrative domain. Parameters that might be subject to
subject to policy include bandwidth, setup/holding priority, Fast policy include bandwidth, setup/holding priority, Fast Reroute request,
Reroute request, Differentiated Services Traffic Engineering (DS-TE) Differentiated Services Traffic Engineering (DS-TE) Class Type (CT),
Class Type (CT), and others as specified in section 5.2.2.1 of and others as specified in section 5.2.2.1 of [RFC4216].
[RFC4216].
For path computation requests that are not compliant with locally For path computation requests that are not compliant with locally
configured policies, PCECP SHOULD enable a PCE to send an error configured policies, PCECP SHOULD enable a PCE to send an error
message to the requesting PCC or PCE indicating that the request has message to the requesting PCC or PCE indicating that the request has
been rejected because a specific parameter did not satisfy the local been rejected because a specific parameter did not satisfy the local
policy. policy.
4.5.2. Inter-AS PCE Reinterpretation Policies 4.5.2. Inter-AS PCE Re-interpretation Policies
Each SP may have different definitions in its use of, for example, Each SP may have different definitions in its use of, for example, DS-
DS-TE TE classes. An inter-AS PCE receiving a path computation TE TE classes. An inter-AS PCE receiving a path computation request
request needs to interpret the parameters and constraints and adapt needs to interpret the parameters and constraints and adapt them to the
them to the local environment. Specifically, a request constructed local environment. Specifically, a request constructed by a PCC or PCE
by a PCC or PCE in one AS may have parameters and constraints that in one AS may have parameters and constraints that should be
should be interpreted differently by the receiving PCE that is in interpreted differently or translated by the receiving PCE that is in a
a different AS. A list of signaling parameters subject to policy different AS. A list of signaling parameters subject to policy re-
reinterpretation at AS borders can be found in section 5.2.2.2 of interpretation at AS borders can be found in section 5.2.2.2 of
[RFC4216], and the list for path computation request parameters and [RFC4216], and the list for path computation request parameters and
constraints is the same. In addition, the transit SPs along the constraints is the same. In addition, the transit SPs along the inter-
inter-AS TE path may be GMPLS transport providers which may require AS TE path may be GMPLS transport providers which may require re-
reinterpretation of MPLS specific PCECP path request objects to interpretation of MPLS specific PCECP path request objects to enable
enable path computation over a GMPLS network. path computation over a GMPLS network or vice versa.
5. Security Considerations 5. Security Considerations
Security concerns arise between any two communicating The PCECP is a communications protocol for use between potentially
PCC/PCEs especially when they belong to different administrative remote entities (PCCs and PCEs) over an IP network. Security
entities. Security concerns that need to be addressed are for concerns arise in order to protect the PCC and PCE, and the
communication among inter-AS PCEs and other PCEs in a single SP information they exchange. [RFC4758] specifies requirements on the
administrative domain as well among inter-AS PCEs under different SP PCECP to protect against spoofing, snooping, and DoS attacks. That
administrative domains. [RFC4657] specifies requirements on PCECP to document is concerned with general protocol requirements applicable
protect against spoofing, snooping and DoS attacks. These to the basic use of the PCECP. This document is specific to the
requirements become especially critical in the multi-AS case. application of the PCE architecture in an inter-AS environment, and
so it is appropriate to highlight the security considerations that
apply in that environment.
Additionally, two aspects of operations specific to inter-AS PCEs Security requirements that exist within a single administrative
require careful security considerations. There are two modes of domain become critical in the multi-AS case when the control of IP
determining peering PCEs across the AS boundary manual traffic and access to the network may leave the authority of a
configuration and auto-discovery. In the manual mode, mechanisms single administration.
for securely exchanging manually confgiured authentication key or
key sets across SP boundaries MUST be defined. For example, the
authentication key May be manually configured for each PCE peer and
PCE registration MAY be served as a mechanism for securely
exchanging authentication keys across SP boundaries. In the
auto-discovery mode, inter-as PCEs can be auto-discovered only if
it is configured to participate in that discovery scope.
An inter-AS PCE is not necessarily able to establish PCEP sessions 5.1. Use and Distribution of Keys
with the discovered PCEs in its scope(s), it MUST be able to
authenticate with the peering inter-AS PCE, therefore mechanisms How the participants in a PCECP session discover each other and the
for securely exchanging authentication keys across SP boundaries need for the session is out of scope of this document. It may be
MUST also be defined in this case. Furthermore, the auto-discovery
process itself MUST also be authenticated. through configuration or automatic discovery. However, when a PCECP
session is established, the PCECP speakers MUST have mechanisms to
authenticate each other's identities and validate the data the
exchange. They also SHOULD have mechanisms protect the data that they
exchange via encryption. Such mechanisms usually require the use of
keys, and so the PCECP MUST describe techniques for the exchange and
use of security keys. Where inter-AS PCE discovery is used, and PCECP
security is required, automated key distribution mechanisms MUST also
be used. Since such key exchange must (necessarily) operate over an AS
boundary, proper consideration needs to be given to how inter-
administration key exchanges may be carried out and how the key
exchange, itself, may be secured. Key distribution mechanisms MUST be
defined with consideration of [RFC4107]. Where a PCECP session is
configured between a pair of inter-AS PCEs, a security key may be
manually set for that session.
5.2. Application of Policy
Policy forms an important part of the operation of PCEs in an inter-AS
environment as described in Section 4.5, especially when ASes are
administrated by different Service Providers. A wider discussion of the
application of policy to the PCE architecture can be found in [PCE-
POLICY].
Policy may also form part of the security model for the PCECP and may
be particularly applicable to inter-AS path computation requests. A
fundamental element of the application of policy at a PCE is the
identity of the requesting PCC/PCE. This makes the use of
authentication described in Section 5.1 particularly important. Where
policy information is exchanged as part of the computation request
and/or response, the policy object is transparent to the PCECP being
delivered un-inspected and unmodified to the policy component of a PCE
or PCC. Therefore, the policy components are responsible for protecting
(for example, encrypting) the policy information and using additional
identification and authentication if a higher level of validation is
required than is provided by the base protocol elements of the PCECP.
5.3. Confidentiality
The PCECP SHOULD also provide mechanism to preserve the confidentiality
of path segments computed by a PCE in one AS and provided to a
computation response in another AS. Not only is it necessary for such
mechanisms to be provided in PCECP responses, but signaling messages
MUST also provide mechanisms such that an ASBR receiving an incoming
signaling request can apply policy to reject signaling messages that do
not contain the computation responses produced by the local PCE.
Furthermore, a PCE SHOULD be provided with a mechanism to mask its
identity such that its presence in the path computation chain in a
cooperative PCE model (such as described in [BRPC]) cannot be derived
from the computed path. This will help to protect the PCE from targeted
attacks. Clearly, such confidentiality does not extend to the PCECP
peer (i.e., a PCC or another PCE) that invokes the PCE with a path
computation request.
5.4. Falsification of Information
In the PCE architecture, when PCEs cooperate, one PCE may return a path
computation result that is composed of multiple path segments each
computed by a different PCE. In the inter-AS case, each PCE may belong
to a different administrative domain, and the source PCC might not know
about the downstream PCEs, nor fully trust them. Although it is
possible and RECOMMENDED to establish a chain of trust between PCEs,
this might not always be possible. In this case, it becomes necessary
to guard against a PCE changing the information provided by another
downstream PCE. Some mechanism MUST be available in the PCECP, and
echoed in the corresponding signaling, that allows an AS to verify that
the signaled path conforms to the path segment computed by the local
PCE and returned on the path computation request.
6. IANA Considerations 6. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
7. Acknowledgments 7. Acknowledgments
We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean
Jean Louis Le Roux for their useful comments and suggestions. Louis Le Roux for their useful comments and suggestions. Pasi Eronen
and Sandy Murphy provided valuable early Security Directorate reviews.
Adrian Farrel re-wrote the Security Considerations section.
8. Authors' Addresses 8. Authors' Addresses
Nabil Bitar Nabil Bitar
Verizon Verizon
40 Sylvan Road 40 Sylvan Road
Waltham, MA 02451 Waltham, MA 02451
Email: nabil.n.bitar@verizon.com Email: nabil.n.bitar@verizon.com
Kenji Kumaki Kenji Kumaki
skipping to change at page 12, line 11 skipping to change at page 14, line 32
[RFC4216] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering [RFC4216] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering
Requirements", RFC 4216, November 2005. Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, Vasseur & Ash, "A Path Computation Element (PCE)- [RFC4655] Farrel, Vasseur & Ash, "A Path Computation Element (PCE)-
Based Architecture", RFC 4755, August 2006. Based Architecture", RFC 4755, August 2006.
[RFC4657] J. Ash, J.L Le Roux et al., "PCE Communication Protocol [RFC4657] J. Ash, J.L Le Roux et al., "PCE Communication Protocol
Generic Requirements", RFC 4657, September 2006. Generic Requirements", RFC 4657, September 2006.
[RFC4107] Bellovin, S. and Housley, R., "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4758] Nystroem, "Cryptographic Token Key Initialization
Protocol (CT-KIP)", November 2006
10. Informative References 10. Informative References
[INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic [INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain- Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-
rsvp-te-06.txt, April 2006 (Work in Progress) rsvp-te-07.txt, September 2007 (Work in Progress)
[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-06.txt, Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-06.txt,
September 2005, (work in progress). April 2007, (work in progress).
[RFC4206] Kompella K., Rekhter Y., "Label switched Paths(LSP) [RFC4206] Kompella K., Rekhter Y., "Label switched Paths(LSP)
Hierarchy with Generalized MPLS TE", RFC4206, October 2005. Hierarchy with Generalized MPLS TE", RFC4206, October 2005.
[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path [INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
computation method for computing Inter-domain Traffic Engineering computation method for computing Inter-domain Traffic Engineering
(TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd- (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
path-comp-05.txt, February 2006, (Work in Progress). path-comp-06.txt, November 2007, (Work in Progress).
[PCE-POLICY] Bryskin, I., Berger, L. and Ash, J., "Policy-Enabled
Path Computation Framework", draft-ietf-pce-policy-enabled-path-
comp-03, October 2007, work in progress.
[BRPC] Vasseur,etc. "A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-domain Traffic
Engineering Label Switched Paths", draft-ietf-pce-brpc-07.txt,
February 2008 (Work in Progress)
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
skipping to change at page 13, line 21 skipping to change at page 16, line 7
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject Copyright (C) The IETF Trust (2008). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 42 change blocks. 
157 lines changed or deleted 271 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/