summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5376.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5376.txt')
-rw-r--r--doc/rfc/rfc5376.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5376.txt b/doc/rfc/rfc5376.txt
new file mode 100644
index 0000000..dba74cf
--- /dev/null
+++ b/doc/rfc/rfc5376.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group N. Bitar
+Request for Comments: 5376 Verizon
+Category: Informational R. Zhang
+ BT
+ K. Kumaki
+ KDDI R&D Labs
+ November 2008
+
+
+ Inter-AS Requirements for the
+ Path Computation Element Communication Protocol (PCECP)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2008 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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
+
+ Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label
+ Switched Paths (LSPs) may be established wholly within an Autonomous
+ System (AS) or may cross AS boundaries.
+
+ The Path Computation Element (PCE) is a component that is capable of
+ computing constrained paths for (G)MPLS TE LSPs. The PCE
+ Communication Protocol (PCECP) is defined to allow communication
+ between Path Computation Clients (PCCs) and PCEs, as well as between
+ PCEs. The PCECP is used to request constrained paths and to supply
+ computed paths in response. 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.
+
+
+
+
+
+Bitar, et al. Informational [Page 1]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Reference Model .................................................4
+ 3.1. Scope of Deployment Model ..................................5
+ 4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
+ Computation .....................................................6
+ 4.1. PCE Communication Protocol Requirements ....................6
+ 4.1.1. Requirements for Path Computation Requests ..........6
+ 4.1.2. Requirements for Path Computation Responses .........7
+ 4.2. Scalability and Performance Considerations .................8
+ 4.3. Management Considerations ..................................8
+ 4.4. Confidentiality ............................................9
+ 4.5. Policy Controls Affecting Inter-AS PCECP ...................9
+ 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.1. Use and Distribution of Keys ..............................11
+ 5.2. Application of Policy .....................................11
+ 5.3. Confidentiality ...........................................12
+ 5.4. Falsification of Information ..............................12
+ 6. Acknowledgments ................................................12
+ 7. Normative References ...........................................13
+ 8. Informative References .........................................13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al. Informational [Page 2]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+1. Introduction
+
+ [RFC4216] defines the scenarios motivating the deployment of inter-AS
+ Multiprotocol Label Switching Traffic Engineering (MPLS TE) and
+ specifies the requirements for inter-AS MPLS TE when the ASes are
+ under the administration of one Service Provider (SP) or the
+ administration of different SPs.
+
+ Three signaling options are defined for setting up an inter-AS TE
+ Label Switched Path (LSP):
+
+ 1) contiguous TE LSP as documented in [RFC5151];
+ 2) stitched inter-AS TE LSP discussed in [RFC5150];
+ 3) nested TE LSP as in [RFC4206].
+
+ [RFC5152] defines mechanisms for the computation of inter-domain TE
+ LSPs using network elements along the signaling paths to compute
+ per-domain constrained path segments. The mechanisms in [RFC5152] do
+ not guarantee an optimum constrained path across multiple ASes where
+ an optimum path for a TE LSP is one that has the smallest cost,
+ according to a normalized TE metric (based upon a TE metric or
+ Interior Gateway Protocol (IGP) metric adopted in each transit AS)
+ among all possible paths that satisfy the LSP TE constraints.
+
+ The Path Computation Element (PCE) [RFC4655] is a component that is
+ capable of computing paths for MPLS TE and Generalized Multiprotocol
+ Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a
+ PCE have come from SP demands to compute optimum constrained paths
+ across multiple areas and/or domains, and to be able to separate the
+ path computation elements from the forwarding elements.
+
+ 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 (G)MPLS TE paths and to
+ supply computed paths in response. Generic requirements for the
+ PCECP are discussed in [RFC4657]. This document provides a set of
+ PCECP requirements that are specific to inter-AS (G)MPLS TE path
+ computation.
+
+2. Terminology
+
+ This document adopts the definitions and acronyms defined in Section
+ 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the
+ following terminology:
+
+ ASBR: Autonomous System Border Router (see section 3 of RFC 4216)
+
+ PCECP: PCE Communication Protocol
+
+
+
+Bitar, et al. Informational [Page 3]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ (G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering
+
+ Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) path
+ that traverses two or more ASes.
+
+ 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.
+
+ Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths
+ remaining within a single AS.
+
+ Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths
+ 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
+
+ Figure 1 depicts the reference model for PCEs in an inter-AS
+ application. We refer to two types of PCE functions in this
+ document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the
+ procedures needed for inter-AS (G)MPLS TE path computation while
+ intra-AS PCEs perform the functions needed for intra-AS (G)MPLS TE
+ path computation.
+
+ Inter-AS Inter-AS Inter-AS
+ PCC <-->PCE1<--------->PCE2<---------------->PCE3
+ :: :: :: ::
+ :: :: :: ::
+ R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
+ | | | | | |
+ | | | | | |
+ R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
+ ::
+ ::
+ Intra-AS
+ PCE
+
+ <==AS1==> <=====AS2=====> <====AS3====>
+
+ 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
+
+
+
+Bitar, et al. Informational [Page 4]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ 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
+
+ All attempts to predict future deployment scopes within the Internet
+ have proven fruitless. Nevertheless, it may be helpful to provide
+ some discussion of the scope of the inter-AS deployment model as
+ envisioned at the time of writing.
+
+ It is expected that most, if not all, inter-AS PCECP-based
+ communications will be between PCEs operating in the cooperative PCE
+ model described in [RFC4655]. Clearly, in this model, the requesting
+ PCE acts as a PCC for the purpose of issuing a path computation
+ request, but nevertheless, the requesting node fills the wider role
+ of a PCE in its own AS. It is currently considered unlikely that a
+ PCC (for example, a normal Label Switching Router) will make a path
+ computation request to a PCE outside its own AS. This means that the
+ PCECP relationships between ASes are limited to at most n squared
+ (n^2), where n is the number of peering PCEs in the various ASes
+
+
+
+Bitar, et al. Informational [Page 5]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ (considered to be no greater than 100 in [RFC4657]). In practice,
+ however, it is likely that only a few PCEs in one AS will be
+ designated for PCECP communications with a PCE in an adjacent AS, and
+ each of these will only have a few PCEs in the adjacent AS to choose
+ from. A deployment model might place the PCEs as co-resident with
+ the ASBRs, resulting in a manageable scaling of the PCE-PCE
+ relationships. Scaling considerations (Section 4.2), manageability
+ considerations (Section 4.3), and security considerations (Section 5)
+ should be examined in the light of these deployment expectations.
+
+4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path Computation
+
+ This section discusses detailed PCECP requirements for inter-AS
+ (G)MPLS TE LSPs. Depending on the deployment environment, some or
+ all of the requirements described here may be utilized.
+ Specifically, some requirements are more applicable to inter-
+ provider inter-AS (G)MPLS TE operations than to intra-provider
+ operations.
+
+4.1. PCE Communication Protocol Requirements
+
+ Requirements specific to inter-AS PCECP path computation requests and
+ responses are discussed in the following sections.
+
+4.1.1. Requirements for Path Computation Requests
+
+ The following are inter-AS specific requirements for PCECP requests
+ for path computation:
+
+ 1. [RFC4657] states the requirement for a priority level to be
+ associated with each path computation request. This document does
+ not change that requirement. However, PCECP should include a
+ mechanism that enables an inter-AS PCE to inform the requesting
+ inter-AS PCE of a change in the request priority level that may
+ have resulted from the application of a local policy.
+
+ 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
+ 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,
+ 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
+ and reach the destination. That is, where multiple ASBRs exist,
+ the requester MUST be able to indicate a preference for one of
+ them. The PCE must be able to indicate whether the specified ASBR
+ or AS is mandatory or non-mandatory on the (G)MPLS TE path.
+
+
+
+
+
+Bitar, et al. Informational [Page 6]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ 3. PCECP MUST allow a requester to provide a list of ASes and/or
+ ASBRs to be excluded from the computed path.
+
+ 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
+ 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
+ inter-AS PCE to another MUST be able to specify the need for
+ protection against node, link, or Shared Risk Link Group (SRLG)
+ failure using 1:1 detours or facility backup. It MUST be possible
+ to request protection across all ASes or across specific ASes.
+
+ 6. PCECP MUST support the disjoint path requirements as specified in
+ [RFC4657]. In addition, it MUST allow the specification of AS-
+ diversity for the computation of a set of two or more paths.
+
+ 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.,
+ between the endpoints of the (G)MPLS TE tunnel) or to be limited
+ to a specific AS.
+
+4.1.2. Requirements for Path Computation Responses
+
+ The following are inter-AS specific requirements for PCECP responses
+ for path computation:
+
+ 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
+ while preserving path segment and topology confidentiality.
+
+ 2. A PCECP path computation response from one inter-AS PCE to the
+ requesting inter-AS PCE MUST be able to carry an identifier for a
+ path segment it computes to preserve path segment and topology
+ confidentiality. The objective of the identifier is to be
+ included in the TE LSP signaling, whose mechanism is out of scope
+ of this document, to be used for path expansion during LSP
+ signaling.
+
+ 3. If a constraint for a desired ASBR (see Section 4.1.1, requirement
+ 2) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE to
+ notify the requester of that fact as an error in a path
+ computation response.
+
+ 4. A PCECP path computation response from an inter-AS PCE to a
+ requesting inter-AS PCE or a PCC MUST be able to carry a
+ cumulative inter-AS path cost. Path cost normalization across
+ ASes is out of scope of this document.
+
+
+
+Bitar, et al. Informational [Page 7]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ 5. A PCECP path computation response from an inter-AS PCE to a PCC
+ SHOULD be able to carry the intra-AS cost of the path segment
+ within the PCC AS.
+
+ 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.
+
+4.2. Scalability and Performance Considerations
+
+ PCECP design for use in the inter-AS case SHOULD consider the
+ following criteria:
+
+ - PCE message processing load.
+ - Scalability as a function of the following parameters:
+ o number of PCCs within the scope of an inter-AS PCE
+ o number of intra-AS PCEs within the scope of an inter-AS PCE
+ o number of peering inter-AS PCEs per inter-AS PCE
+ - Added complexity caused by inter-AS features.
+
+4.3. Management Considerations
+
+ [RFC4657] specifies generic requirements for PCECP management. This
+ document specifies new requirements that apply to inter-AS
+ operations.
+
+ The PCECP MIB module MUST provide objects to control the behavior of
+ PCECP in inter-AS applications. These objects include the ASes
+ within the scope of an inter-AS PCE, inter-AS PCEs in neighboring
+ ASes to which the requesting PCE will or will not communicate,
+ confidentiality, and policies.
+
+ The built-in diagnostic tools MUST enable failure detection and
+ status checking of PCC/PCE-PCE PCECP. Diagnostic tools include
+ statistics collection on the historical behavior of PCECP as
+ specified in [RFC4657], but additionally it MUST be possible to
+ analyze these statistics on a neighboring AS basis (i.e., across the
+ inter-AS PCEs that belong to a neighboring AS).
+
+ The MIB module MUST support trap functions when thresholds are
+ crossed or when important events occur as stated in [RFC4657]. These
+ thresholds SHOULD be specifiable per neighbor AS as well as per peer
+ inter-AS PCE, and traps should be accordingly generated.
+
+
+
+Bitar, et al. Informational [Page 8]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ Basic liveliness detection for PCC/PCE-PCE PCECP 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.
+
+4.4. Confidentiality
+
+ Confidentiality mainly applies to inter-provider (inter-AS) PCE
+ communication. It is about protecting the information exchanged
+ between PCEs and about protecting the topology information within an
+ 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
+ inter-AS (G)MPLS TE path computation within its own administrative
+ domain and some other PCEs for inter-provider inter-AS (G)MPLS TE
+ 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 ASes of
+ different peer SPs.
+
+ 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
+ (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative
+ domain environment, SPs may want to hide their network topologies for
+ security or commercial reasons. Thus, for each inter-AS TE LSP path
+ segment an inter-AS PCE computes, it may return to the requesting
+ inter-AS PCE an inter-AS TE LSP path segment from its own ASes
+ without detailing the explicit intra-AS hops. As stated earlier,
+ PCECP responses SHOULD be able to carry path-segment identifiers that
+ replace the details of that path segment. The potential use of that
+ identifier for path expansion, for instance, during LSP signaling is
+ out of scope of this document.
+
+4.5. Policy Controls Affecting Inter-AS PCECP
+
+ Section 5.2.2 of [RFC4216] discusses the policy control requirements
+ for inter-AS RSVP-TE signaling at the AS boundaries for the
+ enforcement of interconnect agreements, attribute/parameter
+ translation and security hardening.
+
+ This section discusses those policy control requirements that are
+ similar to what are discussed in section 5.2.2 of [RFC4216] for
+ PCECP. Please note that SPs may still require policy controls during
+
+
+
+
+
+Bitar, et al. Informational [Page 9]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ signaling of TE LSPs to enforce their bilateral or multilateral
+ agreements at AS boundaries, but signaling is out of scope for this
+ document.
+
+4.5.1. Inter-AS PCE Peering Policy Controls
+
+ An inter-AS PCE sends path computation requests to its neighboring
+ inter-AS PCEs, and an inter-AS PCE that receives such a request
+ enforces policies applicable to the sender of the request. These
+ policies may include rewriting some of the parameters or rejecting
+ requests based on parameter values. Such policies may be applied for
+ PCEs belonging to different SPs or to PCEs responsible for ASes
+ within a single SP administrative domain. Parameters that might be
+ subject to policy include bandwidth, setup/holding priority, Fast
+ Reroute request, Differentiated Services Traffic Engineering (DS-TE)
+ Class Type (CT), and others as specified in section 5.2.2.1 of
+ [RFC4216].
+
+ For path computation requests that are not compliant with locally
+ configured policies, PCECP SHOULD enable a PCE to send an error
+ message to the requesting PCC or PCE indicating that the request has
+ been rejected because a specific parameter did not satisfy the local
+ policy.
+
+4.5.2. Inter-AS PCE Re-Interpretation Policies
+
+ Each SP may have different definitions in its use of, for example,
+ DS-TE TE classes. An inter-AS PCE receiving a path computation
+ request needs to interpret the parameters and constraints and adapt
+ them to the local environment. Specifically, a request constructed
+ by a PCC or PCE in one AS may have parameters and constraints that
+ should be interpreted differently or translated by the receiving PCE
+ that is in a different AS. A list of signaling parameters subject to
+ policy re-interpretation at AS borders can be found in section
+ 5.2.2.2 of [RFC4216], and the list for path computation request
+ parameters and constraints is the same. In addition, the transit SPs
+ along the inter-AS TE path may be GMPLS transport providers, which
+ may require re-interpretation of MPLS-specific PCECP path computation
+ request objects in order to enable path computation over a GMPLS
+ network or vice versa.
+
+5. Security Considerations
+
+ The PCECP is a communications protocol for use between potentially
+ remote entities (PCCs and PCEs) over an IP network. Security
+ concerns arise in order to protect the PCC, PCE, and the information
+ they exchange. [RFC4758] specifies requirements on the PCECP to
+ protect against spoofing, snooping, and DoS attacks. That document
+
+
+
+Bitar, et al. Informational [Page 10]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ is concerned with general protocol requirements applicable to the
+ basic use of the PCECP. This document is specific to the application
+ of the PCE architecture in an inter-AS environment, and so it is
+ appropriate to highlight the security considerations that apply in
+ that environment.
+
+ Security requirements that exist within a single administrative
+ 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 single
+ administration.
+
+5.1. Use and Distribution of Keys
+
+ 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
+ through configuration or automatic discovery. However, when a PCECP
+ session is established, the PCECP speakers MUST have mechanisms to
+ authenticate each other's identities and validate the data they
+ exchange. They also SHOULD have mechanisms to protect the data that
+ they exchange via encryption. Such mechanisms usually require the
+ use of keys, and so the PCECP MUST describe techniques for the
+ exchange and use of security keys. Where inter-AS PCE discovery is
+ used, and PCECP security is required, automated key distribution
+ mechanisms MUST also be used. Since such key exchange must
+ (necessarily) operate over an AS boundary, proper consideration needs
+ to be given to how inter-AS key exchanges may be carried out and how
+ the key exchange, itself, may be secured. Key distribution
+ mechanisms MUST be defined with consideration of [RFC4107]. Where a
+ PCECP session is configured between a pair of inter-AS PCEs, a
+ security key may be manually set for that session.
+
+5.2. Application of Policy
+
+ Policy forms an important part of the operation of PCEs in an inter-
+ AS environment as described in Section 4.5, especially when ASes are
+ administrated by different SPs. A wider discussion of the
+ application of policy to the PCE architecture can be found in
+ [PCE-POLICY].
+
+ Policy may also form part of the security model for the PCECP and may
+ be particularly applicable to inter-AS path computation requests. A
+ fundamental element of the application of policy at a PCE is the
+ identity of the requesting PCC/PCE. This makes the use of
+ authentication described in Section 5.1 particularly important.
+ Where policy information is exchanged as part of the computation
+ request and/or response, the policy object is transparent to the
+ PCECP being delivered un-inspected and unmodified to the policy
+ component of a PCE or PCC. Therefore, the policy components are
+
+
+
+Bitar, et al. Informational [Page 11]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ responsible for protecting (for example, encrypting) the policy
+ information and using additional identification and authentication if
+ a higher level of validation is required than is provided by the base
+ protocol elements of the PCECP.
+
+5.3. Confidentiality
+
+ The PCECP MUST provide a mechanism to preserve the confidentiality of
+ path segments computed by a PCE in one AS and provided in a
+ computation response to another AS.
+
+ Furthermore, a PCE SHOULD be provided with a mechanism to mask its
+ identity such that its presence in the path computation chain in a
+ cooperative PCE model (such as described in [BRPC]) cannot be derived
+ from the computed path. This will help to protect the PCE from
+ targeted attacks. Clearly, such confidentiality does not extend to
+ the PCECP peer (i.e., a PCC or another PCE) that invokes the PCE with
+ a path computation request.
+
+5.4. Falsification of Information
+
+ In the PCE architecture, when PCEs cooperate, one PCE may return a
+ path computation result that is composed of multiple path segments,
+ each computed by a different PCE. In the inter-AS case, each PCE may
+ belong to a different administrative domain, and the source PCC might
+ not know about the downstream PCEs, nor fully trust them. Although
+ it is possible and RECOMMENDED to establish a chain of trust between
+ PCEs, this might not always be possible. In this case, it becomes
+ necessary to guard against a PCE changing the information provided by
+ another downstream PCE. Some mechanism MUST be available in the
+ PCECP, and echoed in the corresponding signaling, that allows an AS
+ to verify that the signaled path conforms to the path segment
+ computed by the local PCE and returned on the path computation
+ request.
+
+6. Acknowledgments
+
+ We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean
+ Louis Le Roux for their useful comments and suggestions. Pasi Eronen
+ and Sandy Murphy provided valuable early Security Directorate
+ reviews. Adrian Farrel re-wrote the Security Considerations section.
+
+
+
+
+
+
+
+
+
+
+Bitar, et al. Informational [Page 12]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+7. Normative References
+
+ [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
+ Cryptographic Key Management", BCP 107, RFC 4107, June
+ 2005.
+
+ [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
+ Autonomous System (AS) Traffic Engineering (TE)
+ Requirements", RFC 4216, November 2005.
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC 4655,
+ August 2006.
+
+ [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol Generic
+ Requirements", RFC 4657, September 2006.
+
+8. Informative References
+
+ [BRPC] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
+ Backward Recursive PCE-based Computation (BRPC)
+ Procedure To Compute Shortest Constrained Inter-domain
+ Traffic Engineering Label Switched paths", Work in
+ Progress, April 2008.
+
+ [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+ Hierarchy with Generalized Multi-Protocol Label
+ Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
+ October 2005.
+
+ [RFC4758] Nystroem, M., "Cryptographic Token Key Initialization
+ Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758,
+ November 2006.
+
+ [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+ "Label Switched Path Stitching with Generalized
+ Multiprotocol Label Switching Traffic Engineering (GMPLS
+ TE)", RFC 5150, February 2008.
+
+ [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
+ Domain MPLS and GMPLS Traffic Engineering -- Resource
+ Reservation Protocol-Traffic Engineering (RSVP-TE)
+ Extensions", RFC 5151, February 2008.
+
+
+
+
+
+
+
+Bitar, et al. Informational [Page 13]
+
+RFC 5376 Inter-AS Requirements for PCECP November 2008
+
+
+ [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "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., Papadimitriou, D., Berger, L., and J. Ash,
+ "Policy-Enabled Path Computation Framework", Work in
+ Progress, October 2007.
+
+Authors' Addresses
+
+ Nabil Bitar
+ Verizon
+ 117 West Street
+ Waltham, MA 02451 USA
+ EMail: nabil.n.bitar@verizon.com
+
+ Kenji Kumaki
+ KDDI R&D Laboratories, Inc.
+ 2-1-15 Ohara Fujimino
+ Saitama 356-8502, JAPAN
+ EMail: ke-kumaki@kddi.com
+
+ Raymond Zhang
+ BT
+ 2160 E. Grand Ave.
+ El Segundo, CA 90245 USA
+ EMail: Raymond.zhang@bt.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al. Informational [Page 14]
+