draft-ietf-pce-interas-pcecp-reqs-00.txt   draft-ietf-pce-interas-pcecp-reqs-01.txt 
Network Working Group Nabil Bitar (Editor) Network Working Group Nabil Bitar (Editor)
Verizon Internet Draft Verizon
Internet Draft Raymond Zhang (Editor) Raymond Zhang (Editor)
BT Infonet BT Infonet
Kenji Kumaki (Editor) Intended Status: Informational Kenji Kumaki (Editor)
KDDI Corporation KDDI Corporation
Expires: January 2007 August 2006 Expires: April 2007 October 2006
Inter-AS Requirements for the Path Computation Element Communication Inter-AS Requirements for the Path Computation Element
Protocol (PCECP) Communication Protocol (PCECP)
draft-ietf-pce-interas-pcecp-reqs-00.txt draft-ietf-pce-interas-pcecp-reqs-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author
applicable patent or other IPR claims of which he or she is aware represents that any applicable patent or other IPR
have been or will be disclosed, and any of which he or she becomes claims of which he or she is aware have been or will
aware will be disclosed, in accordance with Section 6 of BCP 79. be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP
79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its
other groups may also distribute working documents as Internet- working groups. Note that other groups may also
Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than a "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 December 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document discusses requirements for the support of the Path Multiprotocol Label Switching Traffic Engineered (MPLS-TE)
Computation Element Communication Protocol (PCECP) in inter-AS LabelSwitched Paths (LSPs) may be established wholly within an
applications. Its main objective is to present a set of requirements Autonomous System (AS) or may cross AS boundaries.
which would result in guidelines for the definition, selection and
specification development for any technical solution(s) meeting these The Path Computation Element (PCE) is a component that is capable of
requirements. computing paths for MPLS-TE LSPs. The PCE Communication
Protocol(PCECP) is defined to allow communication between Path
Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is
used to request paths and to supply computed paths in responses.
Generic requirements for the PCECP are set out in "Path Computation
Element(PCE) Communication Protocol Generic Requirements", RFC 4657.
This document extends those requirements to cover the use of PCECP
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.....................................................2 1. Introduction.....................................................3
2. Definitions......................................................3 2. Definitions......................................................3
3. Reference Model..................................................4 3. Reference Model..................................................4
4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4 4. Detailed PCECP Requirements for Inter-AS Computation.............5
4.1.1. PCC/PCE-PCE Communication Protocol Requirements..............4 4.1. PCE Communication Protocol Requirements........................5
4.1.1.1. Requirements on path computation requests..................4 4.1.1. Requirements for path computation requests...................5
4.1.1.2. Requirements on path computation responses.................6 4.1.2. Requirements for path computation responses..................6
4.1.2. Scalability and Performance Requirements.....................6 4.2. Scalability and Performance Requirements.......................7
4.1.3. Management, Aliveness Detection and Recovery Requirements....7 4.3. Management, Aliveness Detection, and Recovery Requirements.....8
4.1.4. Confidentiality..............................................8 4.4. Confidentiality................................................8
4.1.5. Policy Controls Effecting inter-AS PCECP.....................8 4.5. Policy Controls Affecting inter-AS PCECP.......................9
4.1.5.1. Inter-AS PCE Peering Policy Controls.......................8 4.5.1. Inter-AS PCE Peering Policy Controls.........................9
4.1.5.2. Inter-AS PCE Reinterpretation Polices......................9 4.5.2. Inter-AS PCE Reinterpretation Policies......................10
5. Security Considerations..........................................9 5. Security Considerations.........................................10
6. IANA Considerations..............................................9 6. IANA Considerations.............................................11
7. Acknowledgments..................................................9 7. Acknowledgments.................................................11
8. Authors' Addresses...............................................9 8. Authors' Addresses..............................................11
9. Normative References............................................10 9. Normative References............................................11
10. Informative References.........................................10 10. Informative References.........................................12
1. Introduction 1. Introduction
MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ] [RFC4216] defines the scenarios motivating the deployment of inter-
defined the scenarios motivating the deployment of inter-AS MPLS AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE).
traffic engineering. [INTERAS-TE-REQ] also specified the requirements [RFC4216] specifies the requirements for inter-AS MPLS-TE when the
for inter-AS MPLS traffic engineering when the ASes are under one ASs are under the administration of one Service Provider (SP) or the
Service Provider (SP) administration or the administration of administration of different SPs.
different SPs.
Today, there are three signaling options in setting up an inter-AS Three signaling options are defined for setting up an inter-AS TE
TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2) LSP:
Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE 1) contiguous TE LSP as documented in [INTERD-TESIG];
LSP as in [LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines 2) Stitched inter-AS TE LSP discussed in [LSP-STITCHING];
mechanisms for inter-domain path computation using network elements 3) nested TE LSP as in [RFC4206].
along the signaling and data paths. The mechanisms in [INTERD-TE-
PDPC] do not provide the capability to guarantee an optimum TE path
across multiple ASes. A (G)MPLS-TE 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 adopted in each transit AS),
among all possible paths that satisfy the LSP TE-constraints.
The requirements for a PCE have risen from SP needs to compute a more [INTERD-TE-PDPC] defines mechanisms for the computation of inter-
optimum path than that can be achieved by mechanisms provided in domain TE LSPs using network elements along the signaling paths to
[INTERD-TE-PDPC], and be able to separate the path computation compute per-domain path segments. The mechanisms in [INTERD-TE-PDPC]
elements from the forwarding elements. do not guarantee an optimum path across multiple ASs where an
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
adopted in each transit AS) among all possible paths that satisfy
the LSP TE-constraints.
Generic requirements for the PCE discovery protocol (PCEDP) and The Path Computation Element (PCE) [RFC4655] is a component that is
PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP- capable of computing paths for MPLS-TE LSPs. The requirements for a
REQ] and [PCECP-REQ], respectively. Complementary to these already- PCE have come from Service Provider (SP) demands to compute optimum
defined generic requirements, this document provides a set of PCECP paths across multiple domains, and to be able to separate the path
requirements that are specific to (G)MPLS-TE inter-AS path computation elements from the forwarding elements.
computation using a PCE-based approach.
Section 2 of this document states some definitions. Section 3 defines The PCE Communication Protocol (PCECP) is defined to allow
a reference model. Section 4 states inter-AS PCECP requirements. communication between Path Computation Clients (PCCs) and PCEs, and
Section 5 discusses security issues. between PCEs. The PCECP is used to request paths and to supply
computed paths in responses. Generic requirements for the PCECP are
discussed in [RFC4657]. This document provides a set of PCECP
requirements that are specific to MPLS-TE inter-AS path computation.
2. Definitions 2. Definitions
This document adopts the definitions and acronyms defined in This document adopts the definitions and acronyms defined in Section
[INTERAS-TE-REQ] Section 3.1 and [PCE-ARCH] Section 2. In addition, 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the
we use the following terminology: following terminology:
PCECP: PCE Communication Protocol PCECP: PCE Communication Protocol
PCEDP: PCE Discovery Protocol Inter-AS (G)MPLS-TE path: An MPLS-TE or Generalized MPLS (GMPLS)
path that traverses two or more ASs.
Inter-AS (G)MPLS-TE path: A (G)MPLS-TE path that traverses two or
more ASes
Intra-AS (G)MPLS-TE path: A (G)MPLS-TE path that is confined to a
single AS. It may traverse on or more IGP areas.
Inter-area PCE: A PCE responsible for computing (G)MPLS-TE paths or Intra-AS (G)MPLS-TE path: An MPLS-TE or GMPLS path that is confined
path segments traversing across multi-IGP areas. to a single AS. It may traverse one or more IGP areas.
Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths Intra-AS PCE: A PCE responsible for computing MPLS-TE or GMPLS paths
traversing a single AS. remaining within a single AS.
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS- Inter-AS PCE: A PCE responsible for computing inter-AS MPLS-TE or
TE paths or path segments, by possibly cooperating with intra-AS GMPLS paths or path segments, possibly by cooperating with intra-AS
PCEs, across one or more ASes. 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 document: application. We refer to two types of PCE functions in this
inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the
needed for inter-AS (G)MPLS-TE path computation while intra-AS PCEs procedures needed for inter-AS MPLS-TE or GMPLS path computation
perform the functions needed for intra-AS (G)MPLS-TE path while intra-AS PCEs perform the functions needed for intra-AS MPLS-
computation. This document focuses on the PCE Communication Protocol TE or GMPLS path computation.
requirements used by inter-AS PCEs to communicate path
requests/responses to other inter-AS PCEs and by intra-AS PCEs to Following is a scenario that depicts the interaction among PCCs,
communicate path requests/responses to inter-AS PCEs and vice versa. inter-AS PCEs and intra-area PCEs based on Figure 1. R1 in AS1
wants to setup a TE-LSP or a GMPLS path with certain constraints
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
contact 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
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
a PCECP path request to Intra-AS PCE R4 to compute a path within AS2
(In certain cases, the same router such R3 can assume both inter-AS
and intra-AS path computation functions). R4 returns a PCECP path
response to PCE2 with ASBR3 as the entry point to AS2 from AS1 and
ASBR7 as the exit point to AS3. PCE2 then sends a PCECP path request
to PCE3 to compute the path segment across AS3, starting at ASBR7 and
terminating at R7. PCE3 returns a PCECP path response to PCE2 with
the path segment ASBR7-R7. PCE2 then return 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
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
may, themselves be inter-AS PCEs, or may be intra-AS PCEs with the
responsibility for computing path segments within just one AS.
This document describes the PCE Communication Protocol requirements
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
also includes the requirements for PCEs to communicate inter-AS path
requests and responses.
Inter-AS Inter-AS Inter AS Inter-AS Inter-AS Inter AS
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
4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE 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
(G)MPLS-TE applications using a PCE-based approach. Depending on the MPLS-TE and GMPLS. Depending on the deployment environment, some or
operation environment, service providers may use some or all of the all of the requirements described here may be utilized.
capabilities of a PCECP that satisfies these requirements. Specifically, some requirements are more applicable to inter-
Specifically, some requirements are more applicable to inter-AS provider inter-AS MPLS-TE and GMPLS operations than to intra-
inter-provider (G)MPLS-TE operation than intra-provider operations. provider operations.
4.1.1. PCC/PCE-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 section 4.1.1.1 and 4.1.1.2, and responses are discussed in Sections 4.1.1 and 4.1.2,
respectively. respectively.
4.1.1.1. Requirements on path computation requests 4.1.1. Requirements for path computation requests
Following are inter-AS specific requirements on PCECP requests for
path computation
- PCECP MUST allow the specification of a path computation request The following are inter-AS specific requirements for PCECP requests
priority as specified in [PCECP-REQ]. Priority-based message for path computation:
processing is a local decision to a PCE and is out of the scope of
this document. However, in inter-AS operation, a policy may be
enforced on a path computation request so that the path computation
request priority is altered when progressing the request within the
same AS or across other ASes. PCECP SHOULD allow the notification of
the requester of such a change when it happens. Such notification MAY
be suppressed by configuration action on a neighboring inter-AS PCE
basis.
- A path computation request to an inter-AS PCE MUST be able to 1. [RFC4657] states the requirement for a priority level to be
specify ASBRs and/or ASes as strict and loose nodes in the path of associated with each path computation request. This document does
the LSP to the destination. A PCE MUST also be able to specify a not change that requirement, but in addition it MUST be possible for
preferred ASBR for exiting to the next AS for reaching the an inter-AS PCE to apply local policy to vary the priority of path
destination through a neighboring AS. If such a constraint cannot computation requests received across AS borders. PCECP MAY include a
be satisfied at a PCE, PCECP SHOULD allow a PCE to notify the mechanism to inform the requesting inter-AS PCE of the change in
requestor of that fact in the path error message. priority that was applied.
- PCECP MUST enable enlisting a list of ASes and/or ASBRs to be 2. A path computation request by an inter-AS PCE or a PCC to another
excluded in the path computation. inter-AS PCE MUST be able to specify the sequence of ASs and/or
ASBRs across the network by providing ASBRs and/or ASs as hops in
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
the neighboring AS a preferred ASBR for exiting to that AS and reach
the destination. That is, where multiple ASBRs exist, the requester
MUST be able to indicate a non-mandatory preference for one of them.
- PCECP MUST enable an inter-AS PCE to specify the AS on whose behalf 3. PCECP MUST allow a requester to provide a list of Ass and/or
it is sending the request. This is specifically important when the ASBRs to be excluded from the computed path.
inter-AS PCE has identified many ASes within its scope to the other
inter-AS PCE at the other end of the communication.
- A PCC or PCE (including inter-AS PCE) MUST be able to specify in 4. A PCECP path request from one inter-AS PCE to another MUST
its PCECP path computation request the need for computing an end-to- include the previous AS number in the path of the LSP to enable the
end path with protection against node, link, and/or SRLG correct application of local policy at the second inter-AS PCE.
failure using 1:1 detours or facility backup. An inter-AS PCE may
itself ask for a similarly protected path. In addition, it may ask
for protection across all ASes the path can traverse or across
specific ASes.
- A PCC or PCE MUST be able to specify in its path request to an 5. A path computation request from a PCC to an inter-AS PCE or an
inter-AS PCE the retturn of a minimum of two diversified paths inter-AS PCE to another MUST be able to specify the need for
(i.e., paths that do not share common nodes, links and/or SRLGs). protection against node, link, or SRLG failure using 1:1 detours or
facility backup. It MUST be possible to request protection across
all ASs or across specific ASs.
- A PCECP path computation request message MUST enable the 6. The disjoint path requirements specified in [RFC4657] are
specification of AS-only diversified path computation. 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.
- 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 a between the endpoints of the (G)MPLS-TE tunnel) or to be limited to
specific AS. a specific AS.
4.1.1.2. Requirements on path computation responses 4.1.2. Requirements for path computation responses
Following are inter-AS specific requirements on PCECP responses for The following are inter-AS specific requirements for PCECresponses
path computation: for path computation:
- A path computation response MUST be able to include ASBRs and ASes 1. A PCECP path computation response from one inter-AS PCE to
on the computed path. In inter-AS intra-provider path another MUST be able to include ASBRs and ASs in the computed path to
computation, there may not be any confidentiality issues or maintain path segment and topology confidentiality.
restrictions that prevent one AS from returning a path with strict
hops and no loose hops (i.e., nodes and links) within its AS to the
requesting inter-AS PCE. In this case, the head-end of an LSP could
receive, as a result of the work of multiple cooperating intra-AS and
inter-AS PCEs, a path that contains nodes and links as strict hops
from LSP head-end to tail-end. In the inter-provider case,
confidentially and security considerations may require only the
return of AS numbers and/or ASBRs in path computation response
messages.
- A PCECP response message MUST be able to carry an identifier for a 2. A PCECP path computation response from one inter-AS PCE to the
path segment computed by the responding PCE. Such an identifier could requesting inter-AS PCE MUST be able to carry an identifier for a path
be used in a (G)MPLS-TE path setup message for path expansion at an segment it computes to preserve path segment and topology
ASBR. confidentiality. The objective of the identifier is to be included in
the LSP signaling, out of scope of this document, to be used for path
expansion during LSP signaling.
- A PCECP response message MUST be able to carry an inter-AS 3. If a constraint for a desired ASBR (see Section 4.1.1,
path cost. Path cost normalization across ASes is out requirement 3) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE
of the scope of this document and it is expected to be addressed to notify the requester of that fact in a positive path computation
in other work on path computation. response.
- A PCECP response message SHOULD be able to carry an intra-AS cost 4. A PCECP path computation request from an inter-AS PCE to a
for a path segment separately from an inter-AS path segment cost. requesting inter-AS PCE or a PCC MUST be able to carry a cumulative
Best path selection procedures based on these costs are out of the inter-AS path cost. Path cost normalization across ASs is out of the
scope of this document. scope of this document.
- A PCECP response message MUST be able to identify diversified paths 5. A PCECP path computation response from an inter-AS PCE to a PCC
for the same(G)MPLS-TE LSP when the responding PCE is requested to SHOULD be able to carry the intra-AS cost of the path segment within
compute such paths. End-to-end (i.e., between the two endpoints of the PCC AS.
the (G)MPLS-TE tunnel) disjoint diversified paths are paths that do
not share nodes, links or SRLGs except for the LSP head-end and tail-
end. In cases where diversified path segments are desired within one
or more ASes, the diversified path segments may share only the ASBRs
of the first AS and the ASBR of the last AS across these ASes.
4.1.2. Scalability and Performance Requirements 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.,
between the two endpoints of the (G)MPLS-TE tunnel) disjoint paths are
paths that do not share nodes, links or SRLGs except for the LSP head-
end and tail-end. In cases where diversified path segments are desired
within one or more ASes, the disjoint path segments may share only the
ASBRs of the first AS and the ASBR of the last AS across these ASes.
When evaluating a PCECP for the inter-AS case, the following 4.2. Scalability and Performance Requirements
scalability and performance criteria SHOULD be considered:
- Message Processing load on the inter-AS PCEs and intra-AS PCEs. PCECP design for use in the inter-AS case SHOULD consider the
- Scalability as a function of the following parameters: following criteria:
- PCE message processing load.
- 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-area 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 - number of peering inter-AS PCEs per inter-AS PCE
- Added complexity and features to the PCC/PCE-PCE communication - Added complexity caused by inter-AS features.
protocol
4.1.3. Management, Aliveness Detection and Recovery Requirements 4.3. Management, Aliveness Detection, and Recovery Requirements
[PCECP-REQ] specifies generic requirements for PCECP management. This [RFC4657] specifies generic requirements for PCECP management.
document addresses new requirements that apply to inter-AS This document addresses new requirements that apply to inter-AS
operations. operations.
The PCECP MIB module MUST provide objects to control the behavior of The PCECP MIB module MUST provide objects to control the behavior
PCECP in inter-AS applications, including the ASes within its scope, of PCECP in inter-AS applications, including the ASs within the
the ASes the PCE cannot communicate with via PCECP, the ASes that the scope of an inter-AS PCE, neighboring ASs with whose inter-AS
PCE can communicate with, confidentiality policies, and traffic PCE(s) the inter-AS PCE MUST not communicate, neighboring ASs with
engineering policies. Each of these two latter requirements SHOULD whose inter-AS PCEs the inter-AS PCE can communicate,
apply per inter-AS PCE and/or AS peer. 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. Diagnotic 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 [PCECP-REQ]. For inter-AS operations, this statistics specified in [RFC4657], but additionally it MUST be possible to
SHOULD be collected on per inter-AS PCE peer basis and per AS. For analyze this statistics on a neighboring AS basis (i.e., across
instance, the following statistics SHOULD be collected: the inter-AS PCEs that belong to a neighboring AS).
- number of successfully satisfied requests
- number of rejected requests per reason
- number of PCE requests
- number of malformed PCECP messages
- number of unauthenticated PCECP messages
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 for inter-AS PCEs. These crossed or when important events occur as stated in [RFC4657].
thresholds SHOULD be specifiable per peer AS as well as per peer These thresholds SHOULD be specifiable per neighbor AS as well as
inter-AS PCE and traps should be accordingly generated. per peer inter-AS PCE and traps should be accordingly generated.
Basic liveliness detection for PCC/PCE-PCE communication is described
in [PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to
check the liveliness of the neighboring inter-AS PCE(s) it is
communicating with for inter-AS (G)MPLS-TE path computation. The
inter-AS PCECP MIB module SHOULD allow control of liveliness check
behavior by providing a liveliness message frequency MIB object. This
frequency SHOULD be specified per inter-AS PCE peer. In addition,
there SHOULD a MIB object that specifies the dead-interval as a
multiplier of the liveliness message frequency so that if no
liveliness message is received within that time from an inter-A PCE,
the inter-AS PCE is declared unreachable.
4.1.4. Confidentiality Basic liveliness detection for PCC/PCE-PCE communication is
described in [RFC4657]. The PCECP MIB module SHOULD allow control
of liveliness check behavior by providing a liveliness message
frequency MIB object and this frequency object SHOULD be specified
per inter-AS PCE peer. In addition, there SHOULD be a MIB object
that specifies the dead-interval as a multiplier of the liveliness
message frequency so that if no liveliness message is received
within that time from an inter-AS PCE, the inter-AS PCE is declared
unreachable.
Confidentiality mainly applies to inter-provider PCE communication. 4.4. Confidentiality
However, confidentiality rules may also apply among ASes under a Confidentiality mainly applies to inter-provider (inter-AS) PCE
single provider. Each SP will in most cases designate some PCEs for communication. It is about protecting the information exchanged
inter-AS (G)MPLS-TE path computation within its own administrative between PCEs and about protecting the topology information within
domain and some other PCEs for inter-provider inter-As (G)MPLS-TE a provider's network. Confidentiality rules may also apply among
path computation. Among the inter-provider-scoped inter-AS PCEs in ASs under a single provider. Each SP will in most cases designate
each SP domain, there may also be a subset of the PCEs specifically some PCEs for inter-AS MPLS-TE or GMPLS path computation within
enabled for path computation across a specific set of ASes of its own administrative domain and some other PCEs for inter-
different peer SPs. provider inter-AS MPLS-TE or GMPLS path computation. Among the
inter-provider-scoped inter-AS PCEs in each SP domain, there may
also be a subset of the PCEs specifically enabled for path
computation across a specific set of ASs 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 AS(es,) traversed by an inter-AS inter-provider within its own ASs that are traversed by an inter-AS inter-
(G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]). In a provider LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP
multi-SP administrative domain environment, SPs want to hide their administrative domain environment, SPs may want to hide their
network topologies for security reasons. In addition, SPs do not want network topologies for security or commercial reasons. Thus, for
to reveal the path traversed by an LSP segment within their domains each inter-AS LSP path segment an inter-AS PCE computes, it may
to other SPs' domains. Thus, for each partial inter-AS LSP path a PCE return to the requesting inter-AS PCE an inter-AS TE LSP path
computes, it may return to its peering PCE in the upstream neighbor segment from its own ASs without detailing the explicit intra-AS
AS(es) an inter-AS TE LSP segment from its own AS(es) without hops. As stated earlier, PCECP responses SHOULD be able to carry
detailing the explicit intra-AS hops plus partial paths with an path-segment identifiers that replace the details of that path
aggregated TE LSP cost it receives from its downstream PCE. As stated segment. The potential use of that identifier for path expansion,
earlier, PCECP responses SHOULD be able to carry path-segment for instance, during LSP signaling is out of the scope of this
identifiers without the details of that path segment. An ASBR that document.
receives an RSVP-TE path message with an identifier object
(new object), it can use that object to contact the PCE keyed by
that identifier and extract the identified path segment as well.
4.1.5. Policy Controls Effecting inter-AS PCECP 4.5. Policy Controls Affecting inter-AS PCECP
Section 5.2.2 of [INTERAS-TE-REQ] discusses the policy control Section 5.2.2 of [RFC4216] discusses the policy control
requirements on the inter-AS RSVP-TE signaling at the AS boundaries requirements for inter-AS RSVP-TE signaling at the AS boundaries
for the enforcement of interconnect agreements, attribute/parameter for the enforcement of interconnect agreements, attribute/parameter
translation and security hardening. translation and security hardening.
This section discusses those policy control requirements for PCECP. This section discusses those policy control requirements that are
Please note that SPs may still require ingress policy controls on the similar to what are discussed in section 5.2.2 of [RFC4216], for
actual signaling paths mentioned above to enforce their bilateral or PCECP. Please note that SPs may still require policy controls
multi-lateral agreements at the AS boundaries. during signaling of LSPs to enforce their bilateral or multi-
lateral agreements at AS boundaries, but signaling is out of scope
4.1.5.1. Inter-AS PCE Peering Policy Controls for this document.
In a multi-SP administrative domain environment, each SP itself has 4.5.1. Inter-AS PCE Peering Policy Controls
some policies for a (G)MPLS-TE enabled network. An inter-AS PCE sends An inter-AS PCE sends path computation requests to its
path computation requests with some parameters to its neighboring neighboring inter-AS PCEs, and an inter-AS PCE that receives
inter-AS PCEs. An inter-AS PCE that receives such requests enforces such a request enforces policies applicable to the sender of the
some policies applied to its neighboring inter-AS PCEs. These request. These policies may include rewriting some of the
policies may include rewriting some of the parameters' values and parameters, or rejecting requests based on parameter values.
rejecting requests based on some parameters' values. Such policies Such policies may be applied for PCEs belonging to different SPs
may also be applied in the case of multiple ASes within a single SP or to PCEs responsible for ASs within a single SP administrative
administrative domain. Parameters subject to policy include domain. Parameters that might be subject to policy include
bandwidth, setup/holding priority, Fast Reroute request, bandwidth, setup/holding priority, Fast Reroute request,
Differentiated Services Traffic Engineering (DS-TE) Class Type (CT), Differentiated Services Traffic Engineering (DS-TE) Class Type
and others as specified in section 5.2.2.1 of [INTERAS-TE-REQ]. (CT), and others as specified in section 5.2.2.1 of [RFC4216].
For path computation requests that are not compliant with configured For path computation requests that are not compliant with
policies, PCECP SHOULD enable a PCE to send an error message to the locally configured policies, PCECP SHOULD enable a PCE to send
requesting PCC or PCE indicating the cause of errors. 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.1.5.2. Inter-AS PCE Reinterpretation Polices 4.5.2. Inter-AS PCE Reinterpretation Policies
Each SP may have different definitions in its use of for example, Each SP may have different definitions in its use of, for
RSVP-TE session attributes, DS-TE TE classes, etc. A PCE receiving example, DS-TE TE classes. An inter-AS PCE receiving a path
path computation requests needs to be able to reinterpret some of the computation request needs to interpret the parameters and
attributes and adapt them to the native environment in its own AS for constraints and adapt them to the local environment.
path computation. A list of such parameters subject to policy Specifically, a request constructed by a PCC or PCE in one AS
reinterpretation can be found in section 5.2.2.2 of [INTERAS-TE-REQ]. may have parameters and constraints that should be interpreted
In addition, the transit SPs along the inter-AS TE path may be GMPLS differently by the receiving PCE that is in a different AS. A
transport providers which may require reinterpretation of MPLS list of signaling parameters subject to policy reinterpretation
specific PCECP path request messages for path computation over a at AS borders can be found in section 5.2.2.2 of [RFC4216], and
GMPLS network. These interpretation policies must be specifiable on the list for patch computation request parameters and
a per-peer inter-AS PCE or AS basis as part of PCECP MIBs discussed constraints is the same. In addition, the transit SPs along the
earlier. inter-AS TE path may be GMPLS transport providers which may
require reinterpretation of MPLS specific PCECP path request
objects to enable path computation over a GMPLS network.
5. Security Considerations 5. Security Considerations
Security concerns arise between any two communicating elements Security concerns arise between any two communicating
especially when the elements belong to different administrative elements especially when the elements belong to different
entities. In this case, there are security concerns that need to be administrative entities. In this case, there are security concerns
addressed for communication among inter-AS PCEs and other PCEs in a that need to be addressed for communication among inter-AS PCEs and
single SP administrative domain as well among inter-AS PCEs under other PCEs in a single SP administrative domain as well among inter-
different SP administrative domains. [PCECP-REQ] specifies AS PCEs under different SP administrative domains. [RFC4657]
requirements on PCECP to protect against spoofing, snooping and DoS specifies requirements on PCECP to protect against spoofing,
attacks. These requirements become especially important in the multi- snooping and DoS attacks. These requirements become especially
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
inter-AS PCEs can be auto-discovered by an inter-AS PCE and peering
sessions are formed dynamically, mechanisms for securely exchanging
authentication keys across SP boundaries MUST be defined. The
autodiscovery 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, We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and
and Jean Louis Le Roux for their useful comments and suggestions. Jean Louis Le Roux for their useful comments and suggestions.
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 10, line 25 skipping to change at page 11, line 46
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Raymond Zhang Raymond Zhang
BT INFONET Services Corporation BT INFONET Services Corporation
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.infonet.com
9. Normative References 9. Normative References
[INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic [RFC4216] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering
Engineering Requirements", RFC4216, November 2005. Requirements", RFC 4216, November 2005.
[PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element [RFC4655] Farrel, A., Vasseur, J.P, & Ash, J., "A Path Computation
(PCE) Based Architecture", draft-ietf-pce-architecture-05.txt Element (PCE)-Based Architecture", RFC 4655, August 2006.
(Work in Progress).
[PCECP-REQ] J. Ash, J.L Le Roux et al., "PCE Communication Protocol [RFC4657] Ash, J., Le Roux, J.L, et al., "PCE Communication Protocol
Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs- Generic Requirements", RFC 4657, September 2006.
06.txt (work in progress).
10. Informative References 10. Informative References
[INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic [INTERD-TESIG] Ayyangar, A., and Vasseur, J.P, "Inter domain GMPLS
Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain- Traffic Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-
rsvp-te-02.txt, April 2006 (Work in Progress) domain-rsvp-te-03.txt, March 2006 (Work in Progress)
[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with [LSP-STITCHING] Ayyangar A., Vasseur J,P., "Label Switched Path
Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt, Stitching with Generalized MPLS Traffic Engineering", draft-ietf-
September 2005, (work in progress). ccamp-lsp-stitching-03.txt, March 2006, (work in progress).
[LSP-HIERARCHY] 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.
[PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation [INTERD-TE-PDPC] Vasseur,J.P, Ayyangar, A., and Zhang, R., "A Per-
Element(PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work in domain path computation method for establishing Inter-domain Traffic
progress). Engineering (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter
-domain-pd-path-comp-03.txt, August 2006, (Work in Progress).
[INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
computation method for computing Inter-domain Traffic Engineering
(TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
path-comp-02.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 to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information it has made any independent effort to identify any such rights.
on the procedures with respect to rights in RFC documents can be Information on the procedures with respect to rights in RFC
found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
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 an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject to
to the rights, licenses and restrictions contained in BCP 78, and the rights, licenses and restrictions contained in BCP 78, and except
except as set forth therein, the authors retain all their rights. as set forth therein, the authors retain all their rights.
 End of changes. 80 change blocks. 
338 lines changed or deleted 352 lines changed or added

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