draft-ietf-pce-interas-pcecp-reqs-01.txt   draft-ietf-pce-interas-pcecp-reqs-02.txt 
Network Working Group Nabil Bitar (Editor)
Internet Draft Verizon Network Working Group Nabil Bitar
Raymond Zhang (Editor) (Editor)
Verizon
Internet Draft Raymond Zhang
(Editor)
BT Infonet BT Infonet
Intended Status: Informational Kenji Kumaki (Editor) Intended Status: Informational Kenji Kumaki
(Editor)
KDDI Corporation KDDI Corporation
Expires: April 2007 October 2006
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-01.txt draft-ietf-pce-interas-pcecp-reqs-02.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 applicable patent or other IPR represents that any applicable patent or other IPR
claims of which he or she is aware have been or will claims of which he or she is aware have been or will
be disclosed, and any of which he or she becomes aware be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP will be disclosed, in accordance with Section 6 of BCP
79. 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-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 a "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 December 2006. This Internet-Draft will expire in January 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Multiprotocol Label Switching Traffic Engineered (MPLS-TE) Multiprotocol Label Switching Traffic Engineered (MPLS-TE) Label
LabelSwitched Paths (LSPs) may be established wholly within an Switched Paths (LSPs) may be established wholly within an Autonomous
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 responses.
Generic requirements for the PCECP are set out in "Path Computation Generic requirements for the PCEP 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 PCECP This document extends those requirements to cover the use of PCEP in
in support of inter-AS MPLS-TE. 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......................................................3
3. Reference Model..................................................4 3. Reference Model..................................................4
4. Detailed PCECP Requirements for Inter-AS Computation.............5 4. Detailed PCECP Requirements for Inter-AS Computation.............5
4.1. PCE Communication Protocol Requirements........................5 4.1. PCE Communication Protocol Requirements........................5
4.1.1. Requirements for path computation requests...................5 4.1.1. Requirements for path computation requests...................5
4.1.2. Requirements for path computation responses..................6 4.1.2. Requirements for path computation responses..................6
4.2. Scalability and Performance Requirements.......................7 4.2. Scalability and Performance Considerations.....................7
4.3. Management, Aliveness Detection, and Recovery Requirements.....8 4.3. Management Considerations......................................8
4.4. Confidentiality................................................8 4.4. Confidentiality................................................8
4.5. Policy Controls Affecting inter-AS PCECP.......................9 4.5. Policy Controls Affecting inter-AS PCECP.......................9
4.5.1. Inter-AS PCE Peering Policy Controls.........................9 4.5.1. Inter-AS PCE Peering Policy Controls.........................9
4.5.2. Inter-AS PCE Reinterpretation Policies......................10 4.5.2. Inter-AS PCE Reinterpretation Policies......................10
5. Security Considerations.........................................10 5. Security Considerations.........................................10
6. IANA Considerations.............................................11 6. IANA Considerations.............................................11
7. Acknowledgments.................................................11 7. Acknowledgments.................................................11
8. Authors' Addresses..............................................11 8. Authors' Addresses..............................................11
9. Normative References............................................11 9. Normative References............................................12
10. Informative References.........................................12 10. Informative References.........................................12
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). AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
[RFC4216] specifies the requirements for inter-AS MPLS-TE when the specifies the requirements for inter-AS MPLS-TE when the ASes are
ASs 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
LSP: LSP:
1) contiguous TE LSP as documented in [INTERD-TESIG]; 1) contiguous TE LSP as documented in [INTERD-TESIG];
2) Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 2) stitched inter-AS TE LSP discussed in [LSP-STITCHING];
3) nested TE LSP as in [RFC4206]. 3) nested TE LSP as in [RFC4206].
[INTERD-TE-PDPC] defines mechanisms for the computation of inter- [INTERD-TE-PDPC] defines mechanisms for the computation of inter-
domain TE LSPs using network elements along the signaling paths to domain TE LSPs using network elements along the signaling paths to
compute per-domain path segments. The mechanisms in [INTERD-TE-PDPC] compute per-domain path segments. The mechanisms in [INTERD-TE-PDPC]
do not guarantee an optimum path across multiple ASs where an do not guarantee an optimum path across multiple ASes where an
optimum path for an LSP is one that has the smallest cost, according optimum path for an LSP is one that has the smallest cost, according
to a normalized TE metric (based upon a TE-metric or IGP metric to a normalized TE metric (based upon a TE-metric or IGP metric
adopted in each transit AS) among all possible paths that satisfy adopted in each transit AS) among all possible paths that satisfy
the LSP TE-constraints. the LSP TE-constraints.
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 domains, and to be able to separate the path paths across multiple areas and/or domains, and to be able to
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 responses. 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 MPLS-TE inter-AS 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 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 ASs. 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
GMPLS paths or path segments, possibly by cooperating with intra-AS GMPLS paths or path segments, possibly by cooperating with intra-AS
PCEs. PCEs.
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.
Following is a scenario that depicts the interaction among PCCs, Lets follow a scenario that illustrates the interaction among PCCs,
inter-AS PCEs and intra-area PCEs based on Figure 1. R1 in AS1 inter-AS PCEs and intra-AS PCEs shown Figure 1. R1 in AS1 wants to
wants to setup a TE-LSP or a GMPLS path with certain constraints setup a MPLS-TE or a GMPLS path, call LSP1, with certain constraints
to R7 in AS3. R1 determines, using mechanisms out of the scope of to R7 in AS3. R1 determines using mechanisms out of the scope of
this document, that R7 is an AS-external route and that it needs to this document that R7 is an inter-AS route and that it needs to
contact Inter-AS PCE1 to compute the path. R1, as a PCC, sends a contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a
PCECP path request to PCE1. PCE1 determines that R7 is reachable via PCECP path request to PCE1. PCE1 determines that R7 is reachable via
AS2 and that PCE2 is the PCE to ask for path computation across AS2. AS2 and that PCE2 is the PCE to ask for path computation across AS2.
PCE1 sends a PCECP path request to PCE2. Inter-AS PCE2 in turn sends PCE1 sends a PCECP path request to PCE2. Inter-AS PCE2, in turn,
a PCECP path request to Intra-AS PCE R4 to compute a path within AS2 sends a PCECP path request to Intra-AS PCE R4 to compute a path
(In certain cases, the same router such R3 can assume both inter-AS within AS2 (In certain cases, the same router such R3 can assume
and intra-AS path computation functions). R4 returns a PCECP path both inter-AS and intra-AS path computation functions). R4 returns a
response to PCE2 with ASBR3 as the entry point to AS2 from AS1 and PCECP path response to PCE2 with ASBR3 as the entry point to AS2
ASBR7 as the exit point to AS3. PCE2 then sends a PCECP path request from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a PCECP
to PCE3 to compute the path segment across AS3, starting at ASBR7 and path request to PCE3 to compute the path segment across AS3,
terminating at R7. PCE3 returns a PCECP path response to PCE2 with starting at ASBR7 and terminating at R7. PCE3 returns a PCECP path
the path segment ASBR7-R7. PCE2 then return path ASBR3-ASBR7-R7 to response to PCE2 with the path segment ASBR7-R7. PCE2 then return
PCE1 which in turn returns path ASBR1-ASBR3-ASBR7-R7 to PCC R1. path ASBR3-ASBR7-R7 to PCE1 which, in turn, returns path ASBR1-
ASBR3-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
skipping to change at page 5, line 30 skipping to change at page 5, line 31
:: ::
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
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. Depending on the deployment environment, some or MPLS-TE and GMPLS LSPs. Depending on the deployment environment,
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
Requirements specific to inter-AS PCECP path computation requests Requirements specific to inter-AS PCECP path computation requests
and responses are discussed in Sections 4.1.1 and 4.1.2, and responses are discussed in the following sections.
respectively.
4.1.1. Requirements for path computation requests 4.1.1. Requirements for path computation requests
The following are inter-AS specific requirements for PCECP requests The following are inter-AS specific requirements for PCECP requests
for path computation: for path computation:
1. [RFC4657] states the requirement for a priority level to be 1. [RFC4657] states the requirement for a priority level to be
associated with each path computation request. This document does associated with each path computation request. This document does
not change that requirement, but in addition it MUST be possible for not change that requirement, but, in addition, it MUST be possible
an inter-AS PCE to apply local policy to vary the priority of path for an inter-AS PCE to apply local policy to vary the priority of
computation requests received across AS borders. PCECP MAY include a path computation requests received across AS borders. PCECP MAY
mechanism to inform the requesting inter-AS PCE of the change in include a mechanism to inform the requesting inter-AS PCE of the
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 ASs 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 ASs 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 be able to specify to the inter-AS PCE serving
the neighboring AS a preferred ASBR for exiting to that AS and reach the neighboring AS a preferred ASBR for exiting to that AS and reach
the destination. That is, where multiple ASBRs exist, the requester the destination. That is, where multiple ASBRs exist, the requester
MUST be able to indicate a non-mandatory preference for one of them. MUST be able to indicate a non-mandatory preference for one of them.
3. PCECP MUST allow a requester to provide a list of Ass 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 ASs or across specific ASs. all ASes or across specific ASes.
6. The disjoint path requirements specified in [RFC4657] are 6. The disjoint path requirements specified in [RFC4657] are
extended such that it MUST be possible to apply a constraint of AS- extended such that it MUST be possible to apply a constraint of AS-
diversity in the computation of a set of two or more paths. diversity in 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 PCECresponses 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 ASBRs and ASs in the computed path to another MUST be able to include both ASBRs and ASes in the computed
maintain 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 path requesting inter-AS PCE MUST be able to carry an identifier for a
segment it computes to preserve path segment and topology path segment it computes to preserve path segment and topology
confidentiality. The objective of the identifier is to be included in confidentiality. The objective of the identifier is to be included
the LSP signaling, out of scope of this document, to be used for path in the LSP signaling, whose mechanism is out of scope of this
expansion during LSP signaling. 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 PCE requirement 3) cannot be satisfied by a PCE, PCECP SHOULD allow the
to notify the requester of that fact in a positive path computation PCE to notify the requester of that fact as an error in a path
response. computation response.
4. A PCECP path computation request from an inter-AS PCE to a 4. A PCECP path computation from an inter-AS PCE to a requesting
requesting inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS
inter-AS path cost. Path cost normalization across ASs is out of the path cost. Path cost normalization across ASes is out of scope of
scope of this document. this 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 are between the two endpoints of the (G)MPLS-TE tunnel) disjoint paths
paths that do not share nodes, links or SRLGs except for the LSP head- are paths that do not share nodes, links or SRLGs except for the LSP
end and tail-end. In cases where diversified path segments are desired head-end and tail-end. In cases where diversified path segments are
within one or more ASes, the disjoint path segments may share only the desired within one or more ASes, the disjoint path segments may
ASBRs of the first AS and the ASBR of the last AS across these ASes. share only the ASBRs of the first AS and the ASBR of the last AS
across these ASes.
4.2. Scalability and Performance Requirements 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 criteria: following 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, Aliveness Detection, and Recovery Requirements 4.3. Management Considerations
[RFC4657] specifies generic requirements for PCECP management. [RFC4657] specifies generic requirements for PCECP management. This
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 The PCECP MIB module MUST provide objects to control the behavior of
of PCECP in inter-AS applications, including the ASs within the PCECP in inter-AS applications. They include the ASes within the
scope of an inter-AS PCE, neighboring ASs with whose inter-AS scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which
PCE(s) the inter-AS PCE MUST not communicate, neighboring ASs with the requesting PCE will or will not communicate, confidentiality and
whose inter-AS PCEs the inter-AS PCE can communicate, policies, etc..
confidentiality policies, and traffic engineering policies. Each
of these two latter requirements SHOULD be applicable on inter-AS
PCE-pair basis or neighboring AS basis (i.e., apply to all inter-
AS PCEs that belong to a neighboring AS).
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 analyze this statistics on a neighboring AS basis (i.e., across the
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]. crossed or when important events occur as stated in [RFC4657]. These
These thresholds SHOULD be specifiable per neighbor AS as well as thresholds SHOULD be specifiable per neighbor AS as well as per peer
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 communication is Basic liveliness detection for PCC/PCE-PCE PCECP is described in
described in [RFC4657]. The PCECP MIB module SHOULD allow control [RFC4657]. The PCECP MIB module SHOULD allow control of liveliness
of liveliness check behavior by providing a liveliness message check behavior by providing a liveliness message frequency MIB
frequency MIB object and this frequency object SHOULD be specified object and this frequency object SHOULD be specified per inter-AS
per inter-AS PCE peer. In addition, there SHOULD be a MIB object PCE peer. In addition, there SHOULD be a MIB object that specifies
that specifies the dead-interval as a multiplier of the liveliness the dead-interval as a multiplier of the liveliness message
message frequency so that if no liveliness message is received frequency so that if no liveliness message is received within that
within that time from an inter-AS PCE, the inter-AS PCE is declared time from an inter-A PCE, the inter-AS PCE is declared unreachable.
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 PCEs and about protecting the topology information within between PCEs and about protecting the topology information within
a provider's network. Confidentiality rules may also apply among a provider's network. Confidentiality rules may also apply among
ASs under a single provider. Each SP will in most cases designate ASes under a single provider. Each SP will in most cases designate
some PCEs for inter-AS MPLS-TE or GMPLS path computation within some PCEs for inter-AS MPLS-TE or GMPLS path computation within its
its own administrative domain and some other PCEs for inter- own administrative domain and some other PCEs for inter-provider
provider inter-AS MPLS-TE or GMPLS path computation. Among the inter-AS MPLS-TE or GMPLS path computation. Among the
inter-provider-scoped inter-AS PCEs in each SP domain, there may inter-provider-scoped inter-AS PCEs in each SP
also be a subset of the PCEs specifically enabled for path domain, there may also be a subset of the PCEs specifically enabled
computation across a specific set of ASs 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 ASs that are traversed by an inter-AS inter- within its own ASes that are traversed by an inter-AS inter-provider
provider LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative
administrative domain environment, SPs may want to hide their domain environment, SPs may want to hide their network topologies
network topologies for security or commercial reasons. Thus, for for security or commercial reasons. Thus, for each inter-AS LSP path
each inter-AS LSP path segment an inter-AS PCE computes, it may segment an inter-AS PCE computes, it may return to the requesting
return to the requesting inter-AS PCE an inter-AS TE LSP path inter-AS PCE an inter-AS TE LSP path segment from its own ASes
segment from its own ASs without detailing the explicit intra-AS without detailing the explicit intra-AS hops. As stated earlier,
hops. As stated earlier, PCECP responses SHOULD be able to carry PCECP responses SHOULD be able to carry path-segment identifiers
path-segment identifiers that replace the details of that path that replace the details of that path segment. The potential use of
segment. The potential use of that identifier for path expansion, that identifier for path expansion, for instance, during LSP
for instance, during LSP signaling is out of the scope of this signaling is out of scope of this document.
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 Section 5.2.2 of [RFC4216] discusses the policy control requirements
requirements for inter-AS RSVP-TE signaling at the AS boundaries for inter-AS RSVP-TE signaling at the AS boundaries for the
for the enforcement of interconnect agreements, attribute/parameter enforcement of interconnect agreements, attribute/parameter
translation and security hardening. translation and 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 PCECP. Please note that SPs may still require policy controls during
during signaling of LSPs to enforce their bilateral or multi- signaling of LSPs to enforce their bilateral or multi-lateral
lateral agreements at AS boundaries, but signaling is out of scope agreements at AS boundaries, but signaling is out of scope for this
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 inter-AS PCEs, and an inter-AS PCE that receives
such a request enforces policies applicable to the sender of the
request. These policies may include rewriting some of the
parameters, or rejecting requests based on parameter values.
Such policies may be applied for PCEs belonging to different SPs
or to PCEs responsible for ASs within a single SP administrative
domain. Parameters that might be subject to policy include
bandwidth, setup/holding priority, Fast Reroute request,
Differentiated Services Traffic Engineering (DS-TE) Class Type
(CT), and others as specified in section 5.2.2.1 of [RFC4216].
For path computation requests that are not compliant with An inter-AS PCE sends path computation requests to its neighboring
locally configured policies, PCECP SHOULD enable a PCE to send inter-AS PCEs, and an inter-AS PCE that receives such a request
an error message to the requesting PCC or PCE indicating that enforces policies applicable to the sender of the request. These
the request has been rejected because a specific parameter did policies may include rewriting some of the parameters, or rejecting
not satisfy the local policy. requests based on parameter values. Such policies may be applied for
PCEs belonging to different SPs or to PCEs responsible for ASes
within a single SP administrative domain. Parameters that might be
subject to policy include bandwidth, setup/holding priority, Fast
Reroute request, Differentiated Services Traffic Engineering (DS-TE)
Class Type (CT), and others as specified in section 5.2.2.1 of
[RFC4216].
For path computation requests that are not compliant with locally
configured policies, PCECP SHOULD enable a PCE to send an error
message to the requesting PCC or PCE indicating that the request has
been rejected because a specific parameter did not satisfy the local
policy.
4.5.2. Inter-AS PCE Reinterpretation Policies 4.5.2. Inter-AS PCE Reinterpretation Policies
Each SP may have different definitions in its use of, for Each SP may have different definitions in its use of, for example,
example, DS-TE TE classes. An inter-AS PCE receiving a path DS-TE TE classes. An inter-AS PCE receiving a path computation
computation request needs to interpret the parameters and request needs to interpret the parameters and constraints and adapt
constraints and adapt them to the local environment. them to the local environment. Specifically, a request constructed
Specifically, a request constructed by a PCC or PCE in one AS by a PCC or PCE in one AS may have parameters and constraints that
may have parameters and constraints that should be interpreted should be interpreted differently by the receiving PCE that is in
differently by the receiving PCE that is in a different AS. A a different AS. A list of signaling parameters subject to policy
list of signaling parameters subject to policy reinterpretation reinterpretation at AS borders can be found in section 5.2.2.2 of
at AS borders can be found in section 5.2.2.2 of [RFC4216], and [RFC4216], and the list for path computation request parameters and
the list for patch 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-AS TE path may be GMPLS transport providers which may inter-AS TE path may be GMPLS transport providers which may require
require reinterpretation of MPLS specific PCECP path request reinterpretation of MPLS specific PCECP path request objects to
objects to enable path computation over a GMPLS network. enable path computation over a GMPLS network.
5. Security Considerations 5. Security Considerations
Security concerns arise between any two communicating Security concerns arise between any two communicating
elements especially when the elements belong to different PCC/PCEs especially when they belong to different administrative
administrative entities. In this case, there are security concerns entities. Security concerns that need to be addressed are for
that need to be addressed for communication among inter-AS PCEs and communication among inter-AS PCEs and other PCEs in a single SP
other PCEs in a single SP administrative domain as well among inter- administrative domain as well among inter-AS PCEs under different SP
AS PCEs under different SP administrative domains. [RFC4657] administrative domains. [RFC4657] specifies requirements on PCECP to
specifies requirements on PCECP to protect against spoofing, protect against spoofing, snooping and DoS attacks. These
snooping and DoS attacks. These requirements become especially requirements become especially critical in the multi-AS case.
important in the multi-AS case. An inter-AS PCE MUST be able to
authenticate a peering inter-AS PCE as a legitimate peer. Since Additionally, two aspects of operations specific to inter-AS PCEs
inter-AS PCEs can be auto-discovered by an inter-AS PCE and peering require careful security considerations. There are two modes of
sessions are formed dynamically, mechanisms for securely exchanging determining peering PCEs across the AS boundary manual
authentication keys across SP boundaries MUST be defined. The configuration and auto-discovery. In the manual mode, mechanisms
autodiscovery process itself MUST also be authenticated. for securely exchanging authentication keys across SP boundaries
MUST be defined. For example, 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 with the discovered PCEs in its scope(s), it MUST be able
to authenticate with the peering inter-AS PCE, therefore mechanisms
for securely exchanging authentication keys across SP boundaries
MUST also be defined in this case. Furthermore, the auto-discovery
process itself MUST also be authenticated.
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 Louis Le Roux for their useful comments and suggestions. Jean Louis Le Roux for their useful comments and suggestions.
skipping to change at page 11, line 39 skipping to change at page 11, line 36
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
Iidabashi, Chiyoda-ku, Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103 Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Raymond Zhang Raymond Zhang
BT INFONET Services Corporation BT
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90245 USA El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com Email: Raymond_zhang@bt.com
9. Normative References 9. Normative References
[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, A., Vasseur, J.P, & Ash, J., "A Path Computation [RFC4655] Farrel, Vasseur & Ash, "A Path Computation Element (PCE)-
Element (PCE)-Based Architecture", RFC 4655, August 2006. Based Architecture", RFC 4755, August 2006.
[RFC4657] Ash, J., Le Roux, J.L, 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.
10. Informative References 10. Informative References
[INTERD-TESIG] Ayyangar, A., and Vasseur, J.P, "Inter domain GMPLS [INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
Traffic Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter- Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-
domain-rsvp-te-03.txt, March 2006 (Work in Progress) rsvp-te-06.txt, April 2006 (Work in Progress)
[LSP-STITCHING] Ayyangar A., Vasseur J,P., "Label Switched Path [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
Stitching with Generalized MPLS Traffic Engineering", draft-ietf- Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-06.txt,
ccamp-lsp-stitching-03.txt, March 2006, (work in progress). September 2005, (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,J.P, Ayyangar, A., and Zhang, R., "A Per- [INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
domain path computation method for establishing Inter-domain Traffic computation method for computing Inter-domain Traffic Engineering
Engineering (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
-domain-pd-path-comp-03.txt, August 2006, (Work in Progress). path-comp-05.txt, February 2006, (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 13 skipping to change at page 13, line 10
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided
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 AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject to Copyright (C) The IETF Trust (2007). This document is subject
the rights, licenses and restrictions contained in BCP 78, and except to the rights, licenses and restrictions contained in BCP 78, and
as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 58 change blocks. 
197 lines changed or deleted 206 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/