draft-ietf-pce-interas-pcecp-reqs-06.txt   rfc5376.txt 
Network Working Group Nabil Bitar
Internet Draft Verizon
Intended Status: Informational Raymond Zhang
Created: May 7, 2008 BT
Expires: October 7, 2008 Kenji Kumaki
KDDI Corporation
Inter-AS Requirements for the Path Computation Element
Communication Protocol (PCEP)
draft-ietf-pce-interas-pcecp-reqs-06.txt
Status of this Memo Network Working Group N. Bitar
Request for Comments: 5376 Verizon
Category: Informational R. Zhang
BT
K. Kumaki
KDDI R&D Labs
November 2008
By submitting this Internet-Draft, each author represents that any Inter-AS Requirements for the
applicable patent or other IPR claims of which he or she is aware Path Computation Element Communication Protocol (PCECP)
have been or will 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 Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2008 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire in October 2008. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label
Switched Paths (LSPs) may be established wholly within an Autonomous Switched Paths (LSPs) may be established wholly within an Autonomous
System (AS) or may cross AS boundaries. System (AS) or may cross AS boundaries.
The Path Computation Element (PCE) is a component that is capable of The Path Computation Element (PCE) is a component that is capable of
computing constrained paths for (G)MPLS TE LSPs. The PCE computing constrained paths for (G)MPLS TE LSPs. The PCE
Communication Protocol(PCEP) is defined to allow communication Communication Protocol (PCECP) is defined to allow communication
between Path Computation Clients (PCCs) and PCEs, and between PCEs. between Path Computation Clients (PCCs) and PCEs, as well as between
The PCEP is used to request constrained paths and to supply computed PCEs. The PCECP is used to request constrained paths and to supply
paths in response. Generic requirements for the PCEP are set out in computed paths in response. Generic requirements for the PCECP are
"Path Computation Element (PCE) Communication Protocol Generic set out in "Path Computation Element (PCE) Communication Protocol
Requirements", RFC 4657. This document extends those requirements to Generic Requirements", RFC 4657. This document extends those
cover the use of PCEP in support of inter-AS MPLS TE. requirements to cover the use of PCECP in support of inter-AS MPLS
TE.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction ....................................................3
2. Terminology.....................................................3 2. Terminology.....................................................3
3. Reference Model.................................................4 3. Reference Model.................................................4
3.1 Scope of Deployment Model......................................5 3.1. Scope of Deployment Model ..................................5
4. Detailed PCEP Requirements for Inter-AS Computation.............6 4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
4.1 PCE Communication Protocol Requirements........................6 Computation .....................................................6
4.1.1 Requirements for Path Computation Requests...................6 4.1. PCE Communication Protocol Requirements ....................6
4.1.2 Requirements for Path Computation Responses..................7 4.1.1. Requirements for Path Computation Requests ..........6
4.2 Scalability and Performance Considerations.....................8 4.1.2. Requirements for Path Computation Responses .........7
4.3 Management Considerations......................................8 4.2. Scalability and Performance Considerations .................8
4.4 Confidentiality................................................9 4.3. Management Considerations ..................................8
4.5 Policy Controls Affecting Inter-AS PCEP........................9 4.4. Confidentiality ............................................9
4.5.1 Inter-AS PCE Peering Policy Controls.........................9 4.5. Policy Controls Affecting Inter-AS PCECP ...................9
4.5.2 Inter-AS PCE Re-interpretation Policies.....................10 4.5.1. Inter-AS PCE Peering Policy Controls ...............10
4.5.2. Inter-AS PCE Re-Interpretation Policies ............10
5. Security Considerations........................................10 5. Security Considerations........................................10
5.1 Use and Distribution of Keys..................................11 5.1. Use and Distribution of Keys ..............................11
5.2 Application of Policy.........................................11 5.2. Application of Policy .....................................11
5.3 Confidentiality...............................................11 5.3. Confidentiality ...........................................12
5.4 Falsification of Information..................................12 5.4. Falsification of Information ..............................12
6. IANA Considerations............................................12 6. Acknowledgments ................................................12
7. Acknowledgments................................................12 7. Normative References ...........................................13
8. Authors' Addresses.............................................12 8. Informative References .........................................13
9. Normative References...........................................13
10. Informative References........................................13
1. Introduction 1. Introduction
[RFC4216] defines the scenarios motivating the deployment of inter-AS [RFC4216] defines the scenarios motivating the deployment of inter-AS
Multiprotocol Label Switching Traffic Engineering (MPLS TE) and Multiprotocol Label Switching Traffic Engineering (MPLS TE) and
specifies the requirements for inter-AS MPLS TE when the ASes are specifies the requirements for inter-AS MPLS TE when the ASes are
under the administration of one Service Provider (SP) or the under the administration of one Service Provider (SP) or the
administration of different SPs. administration of different SPs.
Three signaling options are defined for setting up an inter-AS TE Three signaling options are defined for setting up an inter-AS TE
LSP: Label Switched Path (LSP):
1) contiguous TE LSP as documented in [RFC5151]; 1) contiguous TE LSP as documented in [RFC5151];
2) stitched inter-AS TE LSP discussed in [RFC5150]; 2) stitched inter-AS TE LSP discussed in [RFC5150];
3) nested TE LSP as in [RFC4206]. 3) nested TE LSP as in [RFC4206].
[RFC5152] defines mechanisms for the computation of inter-domain TE [RFC5152] defines mechanisms for the computation of inter-domain TE
Label Switched Paths (LSPs) using network elements along the LSPs using network elements along the signaling paths to compute
signaling paths to compute per-domain constrained path segments. The per-domain constrained path segments. The mechanisms in [RFC5152] do
mechanisms in [RFC5152] do not guarantee an optimum constrained path not guarantee an optimum constrained path across multiple ASes where
across multiple ASes where an optimum path for an TE LSP is one that an optimum path for a TE LSP is one that has the smallest cost,
has the smallest cost, according to a normalized TE metric (based according to a normalized TE metric (based upon a TE metric or
upon a TE metric or Interior Gateway Protocol (IGP) metric adopted Interior Gateway Protocol (IGP) metric adopted in each transit AS)
in each transit AS) among all possible paths that satisfy the LSP TE among all possible paths that satisfy the LSP TE constraints.
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 and Generalized Multiprotcol capable of computing paths for MPLS TE and Generalized Multiprotocol
Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a
PCE have come from SP demands to compute optimum constrained paths PCE have come from SP demands to compute optimum constrained paths
across multiple areas and/or domains, and to be able to separate the across multiple areas and/or domains, and to be able to separate the
path computation elements from the forwarding elements. path computation elements from the forwarding elements.
The PCE Communication Protocol (PCEP) 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 PCEP is used to request (G)MPLS TE paths and to between PCEs. The PCECP is used to request (G)MPLS TE paths and to
supply computed paths in response. Generic requirements for the supply computed paths in response. Generic requirements for the
PCEP are discussed in [RFC4657]. This document provides a set of PCECP are discussed in [RFC4657]. This document provides a set of
PCEP requirements that are specific to inter-AS (G)MPLS TE path PCECP requirements that are specific to inter-AS (G)MPLS TE path
computation. computation.
2. Terminology 2. Terminology
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:
PCEP: PCE Communication Protocol ASBR: Autonomous System Border Router (see section 3 of RFC 4216)
Inter-AS (G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering PCECP: PCE Communication Protocol
(G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering
Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) path
path that traverses two or more ASes. 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 (G)MPLS TE paths Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths
remaining within a single AS. remaining within a single AS.
Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths
or path segments, possibly by cooperating with intra-AS PCEs. or path segments, possibly by cooperating with intra-AS PCEs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
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 (G)MPLS TE path computation while procedures needed for inter-AS (G)MPLS TE path computation while
intra-AS PCEs perform the functions needed for intra-AS (G)MPLS TE intra-AS PCEs perform the functions needed for intra-AS (G)MPLS TE
path computation. path computation.
Let's follow a scenario that illustrates the interaction among PCCs,
inter-AS PCEs and intra-AS PCEs as shown Figure 1. R1 in AS1 wants
to setup a (G)MPLS TE path, call it LSP1, with certain constraints
to R7 in AS3. R1 determines, using mechanisms out of the scope of
this document, that R7 is an inter-AS route and that it needs to
contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a
PCEP path computation 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 PCEP path computation request
to PCE2. Inter-AS PCE2, in turn, sends a PCEP path computation
request to Intra-AS PCE R4 to compute a path within AS2 (in certain
cases, the same router such as R3 can assume both inter-AS and
intra-AS path computation functions). R4 may for instance return a
PCEP path computation 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 PCEP path computation request to PCE3 to compute the path
segment across AS3, starting at ASBR7 and terminating at R7. PCE3
returns a PCEP path computation response to PCE2 with the path
segment ASBR7-R7. PCE2 then return path ASBR3-ASBR5-ASBR7-R7 to PCE1
which, in turn, returns path ASBR1-ASBR3-ASBR5-ASBR7-R7 to PCC R1.
As described in the above scenario, in general, a PCC may contact an
inter-AS PCE to request the computation of 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
computation requests for inter-AS (G)MPLS TE path to a PCE, and for
the PCE to respond. It also includes the requirements for PCEs to
communicate inter-AS path computation requests and responses.
Inter-AS Inter-AS Inter-AS Inter-AS Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2<---------------->PCE3 PCC <-->PCE1<--------->PCE2<---------------->PCE3
:: :: :: :: :: :: :: ::
:: :: :: :: :: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
| | | | | | | | | | | |
| | | | | | | | | | | |
R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
:: ::
:: ::
Intra-AS Intra-AS
PCE PCE
<==AS1==> <=====AS2=====> <====AS3====> <==AS1==> <=====AS2=====> <====AS3====>
Figure 1 Inter and Intra-AS PCE Reference Model Figure 1: Inter- and Intra-AS PCE Reference Model
Let's follow a scenario that illustrates the interaction among PCCs,
inter-AS PCEs, and intra-AS PCEs, as shown in Figure 1. R1 in AS1
wants to setup a (G)MPLS TE path, call it LSP1, with certain
constraints to R7 in AS3. R1 determines, using mechanisms out of the
scope of this document, that R7 is an inter-AS route and that R1
(itself) needs to contact its Inter-AS PCE1 to compute the path. R1,
as a PCC, sends a PCECP path computation 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
computation request to PCE2. Inter-AS PCE2, in turn, sends a PCECP
path computation request to Intra-AS PCE R4 to compute a path within
AS2 (in certain cases, the same router such as R3 can assume both
inter-AS and intra-AS path computation functions). R4 may for
instance return a PCECP path computation 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 computation request to PCE3 to
compute the path segment across AS3, starting at ASBR7 and
terminating at R7. PCE3 returns a PCECP path computation response to
PCE2 with the path segment ASBR7-R7. PCE2 then returns path ASBR3-
ASBR5-ASBR7-R7 to PCE1, which, in turn, returns path ASBR1-ASBR3-
ASBR5-ASBR7-R7 to PCC R1.
As described in the above scenario, in general, a PCC may contact an
inter-AS PCE to request the computation of an inter-AS path. 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, i.e., for PCCs to communicate path
computation requests for inter-AS (G)MPLS TE paths to PCEs, and for
the PCEs to respond. It also includes the requirements for PCEs to
communicate inter-AS path computation requests and responses.
3.1. Scope of Deployment Model 3.1. Scope of Deployment Model
All attempts to predict future deployment scopes within the Internet All attempts to predict future deployment scopes within the Internet
have proven fruitless. Nevertheless, it may be helpful to provide have proven fruitless. Nevertheless, it may be helpful to provide
some discussion of the scope of the inter-AS deployment model as some discussion of the scope of the inter-AS deployment model as
envisioned at the time of writing. envisioned at the time of writing.
It is expected that most, if not all, inter-AS PCEP-based It is expected that most, if not all, inter-AS PCECP-based
communications will be between PCEs operating in the cooperative PCE communications will be between PCEs operating in the cooperative PCE
model described in [RFC4655]. Clearly, in this model, the requesting model described in [RFC4655]. Clearly, in this model, the requesting
PCE acts as a PCC for the purpose of issuing a path computation PCE acts as a PCC for the purpose of issuing a path computation
request, but nevertheless, the requesting node fills the wider role request, but nevertheless, the requesting node fills the wider role
of a PCE in its own AS. It is currently considered unlikely that a of a PCE in its own AS. It is currently considered unlikely that a
PCC (for example, a normal Label Switching Router) will make a path PCC (for example, a normal Label Switching Router) will make a path
computation request to a PCE outside its own AS. This means that the computation request to a PCE outside its own AS. This means that the
PCEP relationships between ASes are limited to at most n-squared PCECP relationships between ASes are limited to at most n squared
where n is the number of peering PCEs in the various ASes (n^2), where n is the number of peering PCEs in the various ASes
(considered to be no greater than 100 in [RFC4657]). In practice, (considered to be no greater than 100 in [RFC4657]). In practice,
however, it is likely that only a few PCEs in one AS will be however, it is likely that only a few PCEs in one AS will be
designated for PCEP communications with a PCE in an adjacent AS, designated for PCECP communications with a PCE in an adjacent AS, and
and each of these will only have a few PCEs in the adjacent AS to each of these will only have a few PCEs in the adjacent AS to choose
choose from. A deployment model might place the PCEs as co-resident from. A deployment model might place the PCEs as co-resident with
with the ASBRs, resulting in a manageable scaling of the PCE-PCE the ASBRs, resulting in a manageable scaling of the PCE-PCE
relationships. Scaling considerations (Section 4.2), manageability relationships. Scaling considerations (Section 4.2), manageability
considerations (Section 4.3), and security considerations (Section considerations (Section 4.3), and security considerations (Section 5)
5) should be examined in the light of these deployment expectations. should be examined in the light of these deployment expectations.
4. Detailed PCEP Requirements for Inter-AS Computation 4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path Computation
This section discusses detailed PCEP requirements for inter-AS This section discusses detailed PCECP requirements for inter-AS
(G)MPLS TE LSPs. Depending on the deployment environment, some or (G)MPLS TE LSPs. Depending on the deployment environment, some or
all of the requirements described here may be utilized. 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 (G)MPLS TE perations than to intra-provider provider inter-AS (G)MPLS TE operations than to intra-provider
operations. operations.
4.1. PCE Communication Protocol Requirements 4.1. PCE Communication Protocol Requirements
Requirements specific to inter-AS PCEP path computation requests Requirements specific to inter-AS PCECP path computation requests and
and responses are discussed in the following sections. responses are discussed in the following sections.
4.1.1. Requirements for Path Computation Requests 4.1.1. Requirements for Path Computation Requests
The following are inter-AS specific requirements for PCEP 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. However, PCEP should include a not change that requirement. However, PCECP should include a
mechanism that enables an inter-AS PCE to inform the requesting mechanism that enables an inter-AS PCE to inform the requesting
inter-AS PCE of a change in the request priority level that may inter-AS PCE of a change in the request priority level that may
have resulted from the application of a local policy. have resulted from the application of a local policy.
2. A path computation request by an inter-AS PCE or a PCC to another 2. A path computation request by an inter-AS PCE or a PCC to another
inter-AS PCE MUST be able to specify the sequence of ASes and/or inter-AS PCE MUST be able to specify the sequence of ASes and/or
ASBRs across the network by providing ASBRs and/or ASes as hops in ASBRs across the network by providing ASBRs and/or ASes as hops in
the desired path of the TE LSP to the destination. For instance, the desired path of the TE LSP to the destination. For instance,
an inter-AS PCE MUST be able to specify to the inter-AS PCE an inter-AS PCE MUST be able to specify to the inter-AS PCE
serving the neighboring AS a preferred ASBR for exiting to that AS serving the neighboring AS a preferred ASBR for exiting to that AS
and reach the destination. That is, where multiple ASBRs exist, and reach the destination. That is, where multiple ASBRs exist,
the requester MUST be able to indicate a preference for one of the requester MUST be able to indicate a preference for one of
them. The PCE must be able to indicate whether the specified ASBR them. The PCE must be able to indicate whether the specified ASBR
or AS as mandatory or non-mandatory to be on the (G)MPLS TE path. or AS is mandatory or non-mandatory on the (G)MPLS TE path.
3. PCEP MUST allow a requester to provide a list of ASes and/or 3. PCECP MUST allow a requester to provide a list of ASes and/or
ASBRs to be excluded from the computed path. ASBRs to be excluded from the computed path.
4. A PCEP path computation request from one inter-AS PCE to another 4. A PCECP path computation request from one inter-AS PCE to another
MUST include the AS number of the requesting AS to enable the MUST include the AS number of the requesting AS 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 protection against node, link, or Shared Risk Link Group (SRLG)
or facility backup. It MUST be possible to request protection failure using 1:1 detours or facility backup. It MUST be possible
across all ASes or across specific ASes. to request protection across all ASes or across specific ASes.
6. PCEP MUST support the disjoint path requirements as specified in 6. PCECP MUST support the disjoint path requirements as specified in
[RFC4657]. In addition, it MUST allow the specification of AS- [RFC4657]. In addition, it MUST allow the specification of AS-
diversity for the computation of a set of two or more paths. diversity for the computation of a set of two or more paths.
7. A PCEP 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 between the endpoints of the (G)MPLS TE tunnel) or to be limited
to a specific AS. to 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 PCEP responses The following are inter-AS specific requirements for PCECP responses
for path computation: for path computation:
1. A PCEP path computation response from one inter-AS PCE to another 1. A PCECP path computation response from one inter-AS PCE to another
MUST be able to include both ASBRs and ASes in the computed path MUST be able to include both ASBRs and ASes in the computed path
while preserving path segment and topology confidentiality. while preserving path segment and topology confidentiality.
2. A PCEP path computation response from one inter-AS PCE to the 2. A PCECP path computation response from one inter-AS PCE to the
requesting inter-AS PCE MUST be able to carry an identifier for a requesting inter-AS PCE MUST be able to carry an identifier for a
path 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 confidentiality. The objective of the identifier is to be
in the TE LSP signaling, whose mechanism is out of scope of this included in the TE LSP signaling, whose mechanism is out of scope
document, to be used for path expansion during LSP signaling. of this document, to be used for path expansion during LSP
signaling.
3. If a constraint for a desired ASBR (see Section 4.1.1, 3. If a constraint for a desired ASBR (see Section 4.1.1, requirement
requirement 2) cannot be satisfied by a PCE, PCEP SHOULD allow the 2) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE to
PCE to notify the requester of that fact as an error in a path notify the requester of that fact as an error in a path
computation response. computation response.
4. A PCEP path computation from an inter-AS PCE to a requesting 4. A PCECP path computation response from an inter-AS PCE to a
inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS requesting inter-AS PCE or a PCC MUST be able to carry a
path cost. Path cost normalization across ASes is out of scope of cumulative inter-AS path cost. Path cost normalization across
this document. ASes is out of scope of this document.
5. A PCEP 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 SHOULD be able to carry the intra-AS cost of the path segment
within the PCC AS. within the PCC AS.
6. A PCEP path computation response MUST be able to identify 6. A PCECP path computation response MUST be able to identify
diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e., diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e.,
between the two endpoints of the (G)MPLS TE tunnel) disjoint paths between the two endpoints of the (G)MPLS TE tunnel) disjoint paths
are paths that do not share nodes, links or SRLGs except for the are paths that do not share nodes, links, or SRLGs except for the
LSP head-end and tail-end. In cases where diversified path LSP head-end and tail-end. In cases where diversified path
segments are desired within one or more ASes, the disjoint 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 segments may share only the ASBRs of the first AS and the ASBR of
the last AS across these ASes. the last AS across these ASes.
4.2. Scalability and Performance Considerations 4.2. Scalability and Performance Considerations
PCEP 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 o number of PCCs within the scope of an inter-AS PCE
- number of intra-AS PCEs within the scope of an inter-AS PCE o number of intra-AS PCEs within the scope of an inter-AS PCE
- number of peering inter-AS PCEs per inter-AS PCE o number of peering inter-AS PCEs per inter-AS PCE
- Added complexity caused by inter-AS features. - Added complexity caused by inter-AS features.
4.3. Management Considerations 4.3. Management Considerations
[RFC4657] specifies generic requirements for PCEP management. This [RFC4657] specifies generic requirements for PCECP management. This
document addresses new requirements that apply to inter-AS document specifies new requirements that apply to inter-AS
operations. operations.
The PCEP MIB module MUST provide objects to control the behavior of The PCECP MIB module MUST provide objects to control the behavior of
PCEP in inter-AS applications. They include the ASes within the PCECP in inter-AS applications. These objects include the ASes
scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which within the scope of an inter-AS PCE, inter-AS PCEs in neighboring
the requesting PCE will or will not communicate, confidentiality and ASes to which the requesting PCE will or will not communicate,
policies. confidentiality, and policies.
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 PCEP. Diagnostic tools include status checking of PCC/PCE-PCE PCECP. Diagnostic tools include
statistics collection on the historical behavior of PCEP as statistics collection on the historical behavior of PCECP as
specified in [RFC4657], but additionally it MUST be possible to specified in [RFC4657], but additionally it MUST be possible to
analyze this statistics on a neighboring AS basis (i.e., across the analyze these statistics on a neighboring AS basis (i.e., across the
inter-AS PCEs that belong to a neighboring AS). inter-AS PCEs that belong to a neighboring AS).
The MIB module MUST support trap functions when thresholds are The MIB module MUST support trap functions when thresholds are
crossed or when important events occur as stated in [RFC4657]. These crossed or when important events occur as stated in [RFC4657]. These
thresholds SHOULD be specifiable per neighbor AS as well as per peer thresholds SHOULD be specifiable per neighbor AS as well as per peer
inter-AS PCE, and traps should be accordingly generated. inter-AS PCE, and traps should be accordingly generated.
Basic liveliness detection for PCC/PCE-PCE PCEP is described in Basic liveliness detection for PCC/PCE-PCE PCECP is described in
[RFC4657]. The PCEP MIB module SHOULD allow control of liveliness [RFC4657]. The PCECP MIB module SHOULD allow control of liveliness
check behavior by providing a liveliness message frequency MIB check behavior by providing a liveliness message frequency MIB
object and this frequency object SHOULD be specified per inter-AS object, and this frequency object SHOULD be specified per inter-AS
PCE peer. In addition, there SHOULD be a MIB object that specifies PCE peer. In addition, there SHOULD be a MIB object that specifies
the dead-interval as a multiplier of the liveliness message the dead-interval as a multiplier of the liveliness message frequency
frequency so that if no liveliness message is received within that so that if no liveliness message is received within that time from an
time from an inter-AS PCE, the inter-AS PCE is declared unreachable. inter-AS PCE, the inter-AS PCE is declared unreachable.
4.4. Confidentiality 4.4. Confidentiality
Confidentiality mainly applies to inter-provider (inter-AS) PCE Confidentiality mainly applies to inter-provider (inter-AS) PCE
communication. It is about protecting the information exchanged communication. It is about protecting the information exchanged
between PCEs and about protecting the topology information within an between PCEs and about protecting the topology information within an
SP's network. Confidentiality rules may also apply among ASes owned SP's network. Confidentiality rules may also apply among ASes owned
by a single SP. Each SP will in most cases designate some PCEs for by a single SP. Each SP will in most cases designate some PCEs for
inter-AS (G)MPLS TE path computation within its own administrative inter-AS (G)MPLS TE path computation within its own administrative
domain and some other PCEs for inter-provider inter-AS (G)MPLS TE domain and some other PCEs for inter-provider inter-AS (G)MPLS TE
path computation. Among the inter-provider-scoped inter-AS PCEs in path computation. Among the inter-provider-scoped inter-AS PCEs in
each SP domain, there may also be a subset of the PCEs specifically each SP domain, there may also be a subset of the PCEs specifically
enabled for path computation across a specific set of ASes of enabled for path computation across a specific set of ASes of
different peer SPs. different peer SPs.
PCEP MUST allow an SP to hide from other SPs the set of hops within PCECP MUST allow an SP to hide from other SPs the set of hops within
its own ASes that are traversed by an inter-AS inter-provider TE LSP its own ASes that are traversed by an inter-AS inter-provider TE LSP
(c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative
domain environment, SPs may want to hide their network topologies domain environment, SPs may want to hide their network topologies for
for security or commercial reasons. Thus, for each inter-AS TE LSP security or commercial reasons. Thus, for each inter-AS TE LSP path
path segment an inter-AS PCE computes, it may return to the segment an inter-AS PCE computes, it may return to the requesting
requesting inter-AS PCE an inter-AS TE LSP path segment from its own inter-AS PCE an inter-AS TE LSP path segment from its own ASes
ASes without detailing the explicit intra-AS hops. As stated without detailing the explicit intra-AS hops. As stated earlier,
earlier, PCEP responses SHOULD be able to carry path-segment PCECP responses SHOULD be able to carry path-segment identifiers that
identifiers that replace the details of that path segment. The replace the details of that path segment. The potential use of that
potential use of that identifier for path expansion, for instance, identifier for path expansion, for instance, during LSP signaling is
during LSP signaling is out of scope of this document. out of scope of this document.
4.5. Policy Controls Affecting Inter-AS PCEP 4.5. Policy Controls Affecting Inter-AS PCECP
Section 5.2.2 of [RFC4216] discusses the policy control requirements Section 5.2.2 of [RFC4216] discusses the policy control requirements
for inter-AS RSVP-TE signaling at the AS boundaries for the for inter-AS RSVP-TE signaling at the AS boundaries for the
enforcement 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
PCEP. Please note that SPs may still require policy controls during PCECP. Please note that SPs may still require policy controls during
signaling of TE LSPs to enforce their bilateral or multi-lateral signaling of TE LSPs to enforce their bilateral or multilateral
agreements at AS boundaries, but signaling is out of scope for this agreements at AS boundaries, but signaling is out of scope for this
document. document.
4.5.1. Inter-AS PCE Peering Policy Controls 4.5.1. Inter-AS PCE Peering Policy Controls
An inter-AS PCE sends path computation requests to its neighboring An inter-AS PCE sends path computation requests to its neighboring
inter-AS PCEs, and an inter-AS PCE that receives such a request inter-AS PCEs, and an inter-AS PCE that receives such a request
enforces policies applicable to the sender of the request. These enforces policies applicable to the sender of the request. These
policies may include rewriting some of the parameters, or rejecting policies may include rewriting some of the parameters or rejecting
requests based on parameter values. Such policies may be applied for requests based on parameter values. Such policies may be applied for
PCEs belonging to different SPs or to PCEs responsible for ASes PCEs belonging to different SPs or to PCEs responsible for ASes
within a single SP administrative domain. Parameters that might be within a single SP administrative domain. Parameters that might be
subject to policy include bandwidth, setup/holding priority, Fast subject to policy include bandwidth, setup/holding priority, Fast
Reroute request, Differentiated Services Traffic Engineering (DS-TE) Reroute request, Differentiated Services Traffic Engineering (DS-TE)
Class Type (CT), and others as specified in section 5.2.2.1 of Class Type (CT), and others as specified in section 5.2.2.1 of
[RFC4216]. [RFC4216].
For path computation requests that are not compliant with locally For path computation requests that are not compliant with locally
configured policies, PCEP SHOULD enable a PCE to send an error configured policies, PCECP SHOULD enable a PCE to send an error
message to the requesting PCC or PCE indicating that the request has message to the requesting PCC or PCE indicating that the request has
been rejected because a specific parameter did not satisfy the local been rejected because a specific parameter did not satisfy the local
policy. policy.
4.5.2. Inter-AS PCE Re-interpretation Policies 4.5.2. Inter-AS PCE Re-Interpretation Policies
Each SP may have different definitions in its use of, for example, Each SP may have different definitions in its use of, for example,
DS-TE TE classes. An inter-AS PCE receiving a path computation DS-TE TE classes. An inter-AS PCE receiving a path computation
request needs to interpret the parameters and constraints and adapt request needs to interpret the parameters and constraints and adapt
them to the local environment. Specifically, a request constructed them to the local environment. Specifically, a request constructed
by a PCC or PCE in one AS may have parameters and constraints that by a PCC or PCE in one AS may have parameters and constraints that
should be interpreted differently or translated by the receiving PCE should be interpreted differently or translated by the receiving PCE
that is in a different AS. A list of signaling parameters subject that is in a different AS. A list of signaling parameters subject to
to policy re-interpretation at AS borders can be found in section policy re-interpretation at AS borders can be found in section
5.2.2.2 of [RFC4216], and the list for path computation request 5.2.2.2 of [RFC4216], and the list for path computation request
parameters and constraints is the same. In addition, the transit SPs parameters and constraints is the same. In addition, the transit SPs
along the inter-AS TE path may be GMPLS transport providers which along the inter-AS TE path may be GMPLS transport providers, which
may require re-interpretation of MPLS specific PCEP path computation may require re-interpretation of MPLS-specific PCECP path computation
request objects to enable path computation over a GMPLS network or request objects in order to enable path computation over a GMPLS
vice versa. network or vice versa.
5. Security Considerations 5. Security Considerations
The PCEP is a communications protocol for use between potentially The PCECP is a communications protocol for use between potentially
remote entities (PCCs and PCEs) over an IP network. Security remote entities (PCCs and PCEs) over an IP network. Security
concerns arise in order to protect the PCC and PCE, and the concerns arise in order to protect the PCC, PCE, and the information
information they exchange. [RFC4758] specifies requirements on the they exchange. [RFC4758] specifies requirements on the PCECP to
PCEP to protect against spoofing, snooping, and DoS attacks. That protect against spoofing, snooping, and DoS attacks. That document
document is concerned with general protocol requirements applicable is concerned with general protocol requirements applicable to the
to the basic use of the PCEP. This document is specific to the basic use of the PCECP. This document is specific to the application
application of the PCE architecture in an inter-AS environment, and of the PCE architecture in an inter-AS environment, and so it is
so it is appropriate to highlight the security considerations that appropriate to highlight the security considerations that apply in
apply in that environment. that environment.
Security requirements that exist within a single administrative Security requirements that exist within a single administrative
domain become critical in the multi-AS case when the control of IP domain become critical in the multi-AS case when the control of IP
traffic and access to the network may leave the authority of a traffic and access to the network may leave the authority of a single
single administration. administration.
5.1. Use and Distribution of Keys 5.1. Use and Distribution of Keys
How the participants in a PCEP session discover each other and the How the participants in a PCECP session discover each other and the
need for the session is out of scope of this document. It may be need for the session is out of scope of this document. It may be
through configuration or automatic discovery. However, when a PCEP through configuration or automatic discovery. However, when a PCECP
session is established, the PCEP speakers MUST have mechanisms to session is established, the PCECP speakers MUST have mechanisms to
authenticate each other's identities and validate the data the authenticate each other's identities and validate the data they
exchange. They also SHOULD have mechanisms protect the data that exchange. They also SHOULD have mechanisms to protect the data that
they exchange via encryption. Such mechanisms usually require the they exchange via encryption. Such mechanisms usually require the
use of keys, and so the PCEP MUST describe techniques for the use of keys, and so the PCECP MUST describe techniques for the
exchange and use of security keys. Where inter-AS PCE discovery is exchange and use of security keys. Where inter-AS PCE discovery is
used, and PCEP security is required, automated key distribution used, and PCECP security is required, automated key distribution
mechanisms MUST also be used. Since such key exchange must mechanisms MUST also be used. Since such key exchange must
(necessarily) operate over an AS boundary, proper consideration needs (necessarily) operate over an AS boundary, proper consideration needs
to be given to how inter-AS key exchanges may be carried out and how to be given to how inter-AS key exchanges may be carried out and how
the key exchange, itself, may be secured. Key distribution mechanisms the key exchange, itself, may be secured. Key distribution
MUST be defined with consideration of [RFC4107]. Where a PCEP mechanisms MUST be defined with consideration of [RFC4107]. Where a
session is configured between a pair of inter-AS PCEs, a security key PCECP session is configured between a pair of inter-AS PCEs, a
may be manually set for that session. security key may be manually set for that session.
5.2. Application of Policy 5.2. Application of Policy
Policy forms an important part of the operation of PCEs in an Policy forms an important part of the operation of PCEs in an inter-
inter-AS environment as described in Section 4.5, especially when AS environment as described in Section 4.5, especially when ASes are
ASes are administrated by different SPs. A wider discussion of the administrated by different SPs. A wider discussion of the
application of policy to the PCE architecture can be found in application of policy to the PCE architecture can be found in
[PCE-POLICY]. [PCE-POLICY].
Policy may also form part of the security model for the PCEP and may Policy may also form part of the security model for the PCECP and may
be particularly applicable to inter-AS path computation requests. A be particularly applicable to inter-AS path computation requests. A
fundamental element of the application of policy at a PCE is the fundamental element of the application of policy at a PCE is the
identity of the requesting PCC/PCE. This makes the use of identity of the requesting PCC/PCE. This makes the use of
authentication described in Section 5.1 particularly important. authentication described in Section 5.1 particularly important.
Where policy information is exchanged as part of the computation Where policy information is exchanged as part of the computation
request and/or response, the policy object is transparent to the request and/or response, the policy object is transparent to the
PCEP being delivered un-inspected and unmodified to the policy PCECP being delivered un-inspected and unmodified to the policy
component of a PCE or PCC. Therefore, the policy components are component of a PCE or PCC. Therefore, the policy components are
responsible for protecting (for example, encrypting) the policy responsible for protecting (for example, encrypting) the policy
information and using additional identification and authentication information and using additional identification and authentication if
if a higher level of validation is required than is provided by the a higher level of validation is required than is provided by the base
base protocol elements of the PCEP. protocol elements of the PCECP.
5.3. Confidentiality 5.3. Confidentiality
The PCEP MUST provide a mechanism to preserve the confidentiality of The PCECP MUST provide a mechanism to preserve the confidentiality of
path segments computed by a PCE in one AS and provided in a path segments computed by a PCE in one AS and provided in a
computation response to another AS. computation response to another AS.
Furthermore, a PCE SHOULD be provided with a mechanism to mask its Furthermore, a PCE SHOULD be provided with a mechanism to mask its
identity such that its presence in the path computation chain in a identity such that its presence in the path computation chain in a
cooperative PCE model (such as described in [BRPC]) cannot be cooperative PCE model (such as described in [BRPC]) cannot be derived
derived from the computed path. This will help to protect the PCE from the computed path. This will help to protect the PCE from
from targeted attacks. Clearly, such confidentiality does not extend targeted attacks. Clearly, such confidentiality does not extend to
to the PCEP peer (i.e., a PCC or another PCE) that invokes the PCE the PCECP peer (i.e., a PCC or another PCE) that invokes the PCE with
with a path computation request. a path computation request.
5.4. Falsification of Information 5.4. Falsification of Information
In the PCE architecture, when PCEs cooperate, one PCE may return a In the PCE architecture, when PCEs cooperate, one PCE may return a
path computation result that is composed of multiple path segments path computation result that is composed of multiple path segments,
each computed by a different PCE. In the inter-AS case, each PCE may each computed by a different PCE. In the inter-AS case, each PCE may
belong to a different administrative domain, and the source PCC might belong to a different administrative domain, and the source PCC might
not know about the downstream PCEs, nor fully trust them. Although it not know about the downstream PCEs, nor fully trust them. Although
is possible and RECOMMENDED to establish a chain of trust between it is possible and RECOMMENDED to establish a chain of trust between
PCEs, this might not always be possible. In this case, it becomes PCEs, this might not always be possible. In this case, it becomes
necessary to guard against a PCE changing the information provided by necessary to guard against a PCE changing the information provided by
another downstream PCE. Some mechanism MUST be available in the another downstream PCE. Some mechanism MUST be available in the
PCEP, and echoed in the corresponding signaling, that allows an AS PCECP, and echoed in the corresponding signaling, that allows an AS
to verify that the signaled path conforms to the path segment to verify that the signaled path conforms to the path segment
computed by the local PCE and returned on the path computation computed by the local PCE and returned on the path computation
request. request.
6. IANA Considerations 6. Acknowledgments
This document makes no requests for IANA action.
7. Acknowledgments
We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean
Louis Le Roux for their useful comments and suggestions. Pasi Eronen Louis Le Roux for their useful comments and suggestions. Pasi Eronen
and Sandy Murphy provided valuable early Security Directorate and Sandy Murphy provided valuable early Security Directorate
reviews. Adrian Farrel re-wrote the Security Considerations section. reviews. Adrian Farrel re-wrote the Security Considerations section.
8. Authors' Addresses 7. Normative References
Nabil Bitar
Verizon
117 West Street
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com
Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.com
9. Normative References
[RFC4107] Bellovin, S., and Housley, R., "Guidelines for [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107, Cryptographic Key Management", BCP 107, RFC 4107, June
June 2005. 2005.
[RFC4216] Zhang. R., and Vasseur, JP., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Engineering Requirements", RFC 4216, November 2005. Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A.. Vasseur, JP., and Ash, J., "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4755, August 2006. Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4657] Ash, J., Le Roux, JL., et al., "PCE Communication Protocol [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Generic Requirements", RFC 4657, September 2006. Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
10. Informative References 8. Informative References
[BRPC] Vasseur, JP., et. al, "A Backward Recursive PCE-based [BRPC] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Computation (BRPC) Procedure To Compute Shortest Backward Recursive PCE-based Computation (BRPC)
Constrained Inter-domain Traffic Engineering Label Switched Procedure To Compute Shortest Constrained Inter-domain
paths", draft-ietf-pce-brpc, work in progress. Traffic Engineering Label Switched paths", Work in
Progress, April 2008.
[RFC4206] Kompella, K., and Rekhter, Y., "Label switched Paths(LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized MPLS TE", RFC4206, October 2005. Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4758] Mystroem, M., "Cryptographic Token Key Initialization [RFC4758] Nystroem, M., "Cryptographic Token Key Initialization
Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758,
November 2006. November 2006.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and Farrel, A., [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized MPLS "Label Switched Path Stitching with Generalized
Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.
[RFC5151] Farrel, A., Ayyangar, A., and Vasseur, JP., "Inter domain
MPLS and GMPLS Traffic Engineering Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) extensions", RFC
5151, February 2008.
[RFC5152] Vasseur, JP., Ayyangar, A., and Zhang, R., "A Per-domain
path computation method for Establishing Inter-domain
Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC
5152, February 2008.
[PCE-POLICY] Bryskin, I., Berger, L. and Ash, J., "Policy-Enabled
Path Computation Framework", draft-ietf-pce-policy-enabled-
path-comp, work in progress.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Intellectual Property Rights or other rights that might be claimed Domain MPLS and GMPLS Traffic Engineering -- Resource
to pertain to the implementation or use of the technology described Reservation Protocol-Traffic Engineering (RSVP-TE)
in this document or the extent to which any license under such Extensions", RFC 5151, February 2008.
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
assurances of licenses to be made available, or the result of an Per-Domain Path Computation Method for Establishing
attempt made to obtain a general license or permission for the use Inter-Domain Traffic Engineering (TE) Label Switched
of such proprietary rights by implementers or users of this Paths (LSPs)", RFC 5152, February 2008.
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any [PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
copyrights, patents or patent applications, or other proprietary "Policy-Enabled Path Computation Framework", Work in
rights that may cover technology that may be required to implement Progress, October 2007.
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity Authors' Addresses
This document and the information contained herein are provided Nabil Bitar
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Verizon
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 117 West Street
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL Waltham, MA 02451 USA
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY EMail: nabil.n.bitar@verizon.com
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Kenji Kumaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama 356-8502, JAPAN
EMail: ke-kumaki@kddi.com
Copyright (C) The IETF Trust (2008). This document is subject Raymond Zhang
to the rights, licenses and restrictions contained in BCP 78, and BT
except as set forth therein, the authors retain all their rights. 2160 E. Grand Ave.
El Segundo, CA 90245 USA
EMail: Raymond.zhang@bt.com
 End of changes. 102 change blocks. 
330 lines changed or deleted 283 lines changed or added

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