doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5441.txt b/doc/rfc/rfc5441.txt
new file mode 100644
index 0000000..4bb8df4
--- /dev/null
+++ b/doc/rfc/rfc5441.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                   JP. Vasseur, Ed.
+Request for Comments: 5441                            Cisco Systems, Inc
+Category: Standards Track                                       R. Zhang
+                                                              BT Infonet
+                                                                N. Bitar
+                                                                 Verizon
+                                                             JL. Le Roux
+                                                          France Telecom
+                                                              April 2009
+
+
+ A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute
+         Shortest Constrained Inter-Domain Traffic Engineering
+                          Label Switched Paths
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 1]
+
+RFC 5441                          BRPC                        April 2009
+
+
+Abstract
+
+   The ability to compute shortest constrained Traffic Engineering Label
+   Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
+   Generalized MPLS (GMPLS) networks across multiple domains has been
+   identified as a key requirement.  In this context, a domain is a
+   collection of network elements within a common sphere of address
+   management or path computational responsibility such as an IGP area
+   or an Autonomous Systems.  This document specifies a procedure
+   relying on the use of multiple Path Computation Elements (PCEs) to
+   compute such inter-domain shortest constrained paths across a
+   predetermined sequence of domains, using a backward-recursive path
+   computation technique.  This technique preserves confidentiality
+   across domains, which is sometimes required when domains are managed
+   by different service providers.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  General Assumptions  . . . . . . . . . . . . . . . . . . . . .  5
+   4.  BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Domain Path Selection  . . . . . . . . . . . . . . . . . .  6
+     4.2.  Mode of Operation  . . . . . . . . . . . . . . . . . . . .  6
+   5.  PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . .  8
+   6.  VSPT Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Inter-AS TE Links  . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  Usage in Conjunction with Per-Domain Path Computation  . . . . 10
+   9.  BRPC Procedure Completion Failure  . . . . . . . . . . . . . . 10
+   10. Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 11
+     10.1. Diverse End-to-End Path Computation  . . . . . . . . . . . 11
+     10.2. Path Optimality  . . . . . . . . . . . . . . . . . . . . . 12
+   11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12
+   12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12
+   13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12
+   14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
+     14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
+     14.2. Information and Data Models  . . . . . . . . . . . . . . . 13
+     14.3. Liveness Detection and Monitoring  . . . . . . . . . . . . 13
+     14.4. Verifying Correct Operation  . . . . . . . . . . . . . . . 13
+     14.5. Requirements on Other Protocols and Functional
+           Components . . . . . . . . . . . . . . . . . . . . . . . . 14
+     14.6. Impact on Network Operation  . . . . . . . . . . . . . . . 14
+     14.7. Path Computation Chain Monitoring  . . . . . . . . . . . . 14
+   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
+     15.1. New Flag of the RP Object  . . . . . . . . . . . . . . . . 14
+     15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14
+
+
+
+Vasseur, et al.             Standards Track                     [Page 2]
+
+RFC 5441                          BRPC                        April 2009
+
+
+     15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
+   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   17. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
+   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     18.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+     18.2. Informative References . . . . . . . . . . . . . . . . . . 16
+
+1.  Introduction
+
+   The requirements for inter-area and inter-AS MPLS Traffic Engineering
+   (TE) have been developed by the Traffic Engineering Working Group (TE
+   WG) and have been stated in [RFC4105] and [RFC4216], respectively.
+
+   The framework for inter-domain Multiprotocol Label Switching (MPLS)
+   Traffic Engineering (TE) has been provided in [RFC4726].
+
+   [RFC5152] defines a technique for establishing an inter-domain
+   Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the
+   path is computed during the signaling process on a per-domain basis
+   by the entry boundary node of each domain (each node responsible for
+   triggering the computation of a section of an inter-domain TE LSP
+   path is always along the path of such TE LSP).  This path computation
+   technique fulfills some of the requirements stated in [RFC4105] and
+   [RFC4216] but not all of them.  In particular, it cannot guarantee to
+   find an optimal (shortest) inter-domain constrained path.
+   Furthermore, it cannot be efficiently used to compute a set of inter-
+   domain diversely routed TE LSPs.
+
+   The Path Computation Element (PCE) architecture is defined in
+   [RFC4655].  The aim of this document is to describe a PCE-based path
+   computation procedure to compute optimal inter-domain constrained
+   (G)MPLS TE LSPs.
+
+   Qualifying a path as optimal requires some clarification.  Indeed, a
+   globally optimal TE LSP placement usually refers to a set of TE LSPs
+   whose placements optimize the network resources with regards to a
+   specified objective function (e.g., a placement that reduces the
+   maximum or average network load while satisfying the TE LSP
+   constraints).  In this document, an optimal inter-domain constrained
+   TE LSP is defined as the shortest path satisfying the set of required
+   constraints that would be obtained in the absence of multiple domains
+   (in other words, in a totally flat IGP network between the source and
+   destination of the TE LSP).  Note that this requires the use of
+   consistent metric schemes in each domain (see Section 13).
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 3]
+
+RFC 5441                          BRPC                        April 2009
+
+
+1.1.  Requirements Language
+
+   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 [RFC2119].
+
+2.  Terminology
+
+   ABR: Area Border Routers.  Routers used to connect two IGP areas
+   (areas in OSPF or levels in IS-IS).
+
+   ASBR: Autonomous System Border Router.  Router used to connect
+   together ASes of the same or different service providers via one or
+   more inter-AS links.
+
+   Boundary Node (BN): a boundary node is either an ABR in the context
+   of inter-area Traffic Engineering or an ASBR in the context of
+   inter-AS Traffic Engineering.
+
+   Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
+   a determined sequence of domains.
+
+   Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
+   a determined sequence of domains.
+
+   Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
+
+   Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
+
+   LSP: Label Switched Path.
+
+   LSR: Label Switching Router.
+
+   PCC: Path Computation Client.  Any client application requesting a
+   path computation to be performed by a Path Computation Element.
+
+   PCE: Path Computation Element.  An entity (component, application, or
+   network node) that is capable of computing a network path or route
+   based on a network graph and applying computational constraints.
+
+   PCE(i) is a PCE with the scope of domain(i).
+
+   TED: Traffic Engineering Database.
+
+   VSPT: Virtual Shortest Path Tree.
+
+   The notion of contiguous, stitched, and nested TE LSPs is defined in
+   [RFC4726] and will not be repeated here.
+
+
+
+Vasseur, et al.             Standards Track                     [Page 4]
+
+RFC 5441                          BRPC                        April 2009
+
+
+3.  General Assumptions
+
+   In the rest of this document, we make the following set of
+   assumptions common to inter-area and inter-AS MPLS TE:
+
+   o  Each IGP area or Autonomous System (AS) is assumed to be Traffic
+      Engineering enabled.
+
+   o  No topology or resource information is distributed between domains
+      (as mandated per [RFC4105] and [RFC4216]), which is critical to
+      preserve IGP/BGP scalability and confidentiality.
+
+   o  While certain constraints like bandwidth can be used across
+      different domains, other TE constraints (such as resource
+      affinity, color, metric, etc. [RFC2702]) could be translated at
+      domain boundaries.  If required, it is assumed that, at the domain
+      boundary nodes, there will exist some sort of local mapping based
+      on policy agreement, in order to translate such constraints across
+      domain boundaries during the inter-PCE communication process.
+
+   o  Each AS can be made of several IGP areas.  The path computation
+      procedure described in this document applies to the case of a
+      single AS made of multiple IGP areas, multiple ASes made of a
+      single IGP area, or any combination of the above.  For the sake of
+      simplicity, each AS will be considered to be made of a single area
+      in this document.  The case of an inter-AS TE LSP spanning
+      multiple ASes, where some of those ASes are themselves made of
+      multiple IGP areas, can be easily derived from this case by
+      applying the BRPC procedure described in this document,
+      recursively.
+
+   o  The domain path (the set of domains traversed to reach the
+      destination domain) is either administratively predetermined or
+      discovered by some means that is outside of the scope of this
+      document.
+
+4.  BRPC Procedure
+
+   The BRPC procedure is a multiple-PCE path computation technique as
+   described in [RFC4655].  A possible model consists of hosting the PCE
+   function on boundary nodes (e.g., ABR or ASBR), but this is not
+   mandated by the BRPC procedure.
+
+   The BRPC procedure relies on communication between cooperating PCEs.
+   In particular, the PCC sends a PCReq to a PCE in its domain.  The
+   request is forwarded between PCEs, domain-by-domain, until the PCE
+   responsible for the domain containing the LSP destination is reached.
+   The PCE in the destination domain creates a tree of potential paths
+
+
+
+Vasseur, et al.             Standards Track                     [Page 5]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   to the destination (the Virtual Shortest Path Tree - VSPT) and passes
+   this back to the previous PCE in a PCRep.  Each PCE in turn adds to
+   the VSPT and passes it back until the PCE in the source domain uses
+   the VSPT to select an end-to-end path that the PCE sends to the PCC.
+
+   The BRPC procedure does not make any assumption with regards to the
+   nature of the inter-domain TE LSP that could be contiguous, nested,
+   or stitched.
+
+   Furthermore, no assumption is made on the actual path computation
+   algorithm in use by a PCE (e.g., it can be any variant of Constrained
+   Shortest Path First (CSPF) or an algorithm based on linear
+   programming to solve multi-constraint optimization problems).
+
+4.1.  Domain Path Selection
+
+   The PCE-based BRPC procedure applies to the computation of an optimal
+   constrained inter-domain TE LSP.  The sequence of domains to be
+   traversed is either administratively predetermined or discovered by
+   some means that is outside of the scope of this document.  The PCC
+   MAY indicate the sequence of domains to be traversed using the
+   Include Route Object (IRO) defined in [RFC5440] so that it is
+   available to all PCEs.  Note also that a sequence of PCEs MAY be
+   enforced by policy on the PCC, and this constraint can be carried in
+   the PCEP path computation request (as defined in [PCE-MONITOR]).
+
+   The BRPC procedure guarantees to compute the optimal path across a
+   specific sequence of traversed domains (which constitutes an
+   additional constraint).  In the case of an arbitrary set of meshed
+   domains, the BRPC procedure can be used to compute the optimal path
+   across each domain set in order to get the optimal constrained path
+   between the source and the destination of the TE LSP.  The BRPC
+   procedure can also be used across a subset of all domain sequences,
+   and the best path among these sequences can then be selected.
+
+4.2.  Mode of Operation
+
+   Definition of VSPT(i)
+
+   In each domain i:
+
+   o  There is a set of X-en(i) entry BNs noted BN-en(k,i) where
+      BN-en(k,i) is the kth entry BN of domain(i).
+
+   o  There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where
+      BN-ex(k,i) is the kth exit BN of domain(i).
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 6]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to
+   PCE(i-1):
+
+                        Root (TE LSP destination)
+                        /         |            \
+                  BN-en(1,i)   BN-en(2,i) ... BN-en(j,i).
+
+                   where [X-en(i)] is the number of
+                entry BNs in domain i and j<= [X-en(i)]
+
+                         Figure 1: MP2P Tree
+
+   Each link of tree VSPT(i) represents the shortest constrained path
+   between BN-en(j,i) and the TE LSP destination that satisfies the set
+   of required constraints for the TE LSP (bandwidth, affinities, etc.).
+   These are path segments to reach the TE LSP destination from
+   BN-en(j,i).
+
+   Note that PCE(i) only considers the entry BNs of domain(i), i.e.,
+   only the BNs that provide connectivity from domain(i-1).  In other
+   words, the set BN-en(k,i) is only made of those BNs that provide
+   connectivity from domain (i-1) to domain(i).  Furthermore, some BNs
+   may be excluded according to policy constraints (either due to local
+   policy or policies signaled in the path computation request).
+
+   Step 1:
+   First, the PCC needs to determine the PCE capable of serving its path
+   computation request (this can be done with local configuration or via
+   IGP discovery (see [RFC5088] and [RFC5089])).  The path computation
+   request is then relayed until reaching a PCE(n) such that the TE LSP
+   destination resides in the domain(n).  At each step of the process,
+   the next PCE can either be statically configured or dynamically
+   discovered via IGP/BGP extensions.  If no next PCE can be found or
+   the next-hop PCE of choice is unavailable, the procedure stops and a
+   path computation error is returned (see Section 9).  If PCE(i-1)
+   discovers multiple PCEs for the adjacent domain(i), PCE(i) may select
+   a subset of these PCEs based on some local policies or heuristics.
+   The PCE selection process is outside of the scope of this document.
+
+   Step 2:
+   PCE(n) computes VSPT(n), the tree made of the list of shortest
+   constrained paths between every BN-en(j,n) and the TE LSP destination
+   using a suitable path computation algorithm (e.g., CSPF) and returns
+   the computed VSPT(n) to PCE(n-1).
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 7]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   Step i:
+   For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the
+   shortest constrained paths between each BN-en(j,i) and the TE LSP
+   destination.  It does this by considering its own TED and the
+   information in VSPT(i+1).
+
+   In the case of inter-AS TE LSP computation, this also requires adding
+   the inter-AS TE links that connect the domain(i) to the domain(i+1).
+
+   Step n:
+   Finally, PCE(1) computes the end-to-end shortest constrained path
+   from the source to the destination and returns the corresponding path
+   to the requesting PCC in the form of a PCRep message as defined in
+   [RFC5440].
+
+   Each branch of the VSPT tree (path) may be returned in the form of an
+   explicit path (in which case, all the hops along the path segment are
+   listed) or a loose path (in which case, only the BN is specified) so
+   as to preserve confidentiality along with the respective cost.  In
+   the latter case, various techniques can be used in order to retrieve
+   the computed explicit paths on a per-domain basis during the
+   signaling process, thanks to the use of path keys as described in
+   [PATH-KEY].
+
+   A PCE that can compute the requested path for more than one
+   consecutive domain on the path SHOULD perform this computation for
+   all such domains before passing the PCRep to the previous PCE in the
+   sequence.
+
+   BRPC guarantees to find the optimal (shortest) constrained inter-
+   domain TE LSP according to a set of defined domains to be traversed.
+   Note that other variants of the BRPC procedure relying on the same
+   principles are also possible.
+
+   Note also that in case of Equal Cost Multi-Path (ECMP) paths, more
+   than one path could be returned to the requesting PCC.
+
+5.  PCEP Protocol Extensions
+
+   The BRPC procedure requires the specification of a new flag of the RP
+   object carried within the PCReq message (defined in [RFC5440]) to
+   specify that the shortest paths satisfying the constraints from the
+   destination to the set of entry boundary nodes are requested (such a
+   set of paths forms the downstream VSPT as specified in Section 4.2).
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                     [Page 8]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   The following new flag of the RP object is defined:
+
+   VSPT Flag
+
+   Bit Number      Name Flag
+      25           VSPT
+
+   When set, the VSPT Flag indicates that the PCC requests the
+   computation of an inter-domain TE LSP using the BRPC procedure
+   defined in this document.
+
+   Because path segments computed by a downstream PCE in the context of
+   the BRPC procedure MUST be provided along with their respective path
+   costs, the C flag of the METRIC object carried within the PCReq
+   message MUST be set.  It is the choice of the requester to
+   appropriately set the O bit of the RP object.
+
+6.  VSPT Encoding
+
+   The VSPT is returned within a PCRep message.  The encoding consists
+   of a non-ordered list of Explicit Route Objects (EROs) where each ERO
+   represents a path segment from a BN to the destination specified in
+   the END-POINT object of the corresponding PCReq message.
+
+   Example:
+   <---- area 1 ----><---- area 0 -----><------ area 2 ------>
+                                       ABR1-A-B-+
+                                        |       |
+                                       ABR2-----D
+                                        |       |
+                                       ABR3--C--+
+
+    Figure 2: An Example of VSPT Encoding Using a Set of EROs
+
+   In the simple example shown in Figure 2, if we make the assumption
+   that a constrained path exists between each ABR and the destination
+   D, the VSPT computed by a PCE serving area 2 consists of the
+   following non-ordered set of EROs:
+
+   o  ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP
+      address)-D(TE Router ID)
+
+   o  ERO2: ABR2(TE Router ID)-D(TE Router ID)
+
+   o  ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID)
+
+   The PCReq message, PCRep message, PCEP END-POINT object, and ERO
+   object are defined in [RFC5440].
+
+
+
+Vasseur, et al.             Standards Track                     [Page 9]
+
+RFC 5441                          BRPC                        April 2009
+
+
+7.  Inter-AS TE Links
+
+   In the case of inter-AS TE LSP path computation, the BRPC procedure
+   requires the knowledge of the traffic engineering attributes of the
+   inter-AS TE links.  The process by which the PCE acquires this
+   information is out of the scope of the BRPC procedure, which is
+   compliant with the PCE architecture defined in [RFC4655].
+
+   That said, a straightforward solution consists of allowing the ASBRs
+   to flood the TE information related to the inter-ASBR links although
+   no IGP TE is enabled over those links (there is no IGP adjacency over
+   the inter-ASBR links).  This allows the PCE of a domain to get entire
+   TE visibility up to the set of entry ASBRs in the downstream domain
+   (see the IGP extensions defined in [RFC5316] and [RFC5392]).
+
+8.  Usage in Conjunction with Per-Domain Path Computation
+
+   The BRPC procedure may be used to compute path segments in
+   conjunction with other path computation techniques (such as the per-
+   domain path computation technique defined in [RFC5152]) to compute
+   the end-to-end path.  In this case, end-to-end path optimality can no
+   longer be guaranteed.
+
+9.  BRPC Procedure Completion Failure
+
+   If the BRPC procedure cannot be completed because a PCE along the
+   domain does not recognize the procedure (VSPT flag of the RP object),
+   as stated in [RFC5440], the PCE sends a PCErr message to the upstream
+   PCE with an Error-Type=4 (Not supported object), Error-value=4
+   (Unsupported parameter).  The PCE may include the parent object (RP
+   object) up to and including (but no further than) the unknown or
+   unsupported parameter.  In this case where the unknown or unsupported
+   parameter is a bit flag (VSPT flag), the included RP object should
+   contain the whole bit flag field with all bits after the parameter at
+   issue set to zero.  The corresponding path computation request is
+   then cancelled by the PCE without further notification.
+
+   If the BRPC procedure cannot be completed because a PCE along the
+   domain path recognizes but does not support the procedure, it MUST
+   return a PCErr message to the upstream PCE with an Error-Type "BRPC
+   procedure completion failure".
+
+   The PCErr message MUST be relayed to the requesting PCC.
+
+   PCEP-ERROR objects are used to report a PCEP protocol error and are
+   characterized by an Error-Type that specifies the type of error and
+   an Error-value that provides additional information about the error
+   type.  Both the Error-Type and the Error-value are managed by IANA.
+
+
+
+Vasseur, et al.             Standards Track                    [Page 10]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   A new Error-Type is defined that relates to the BRPC procedure.
+
+  Error-Type       Meaning
+      13           BRPC procedure completion failure
+                   Error-value
+                     1: BRPC procedure not supported by one or more PCEs
+                        along the domain path
+
+10.  Applicability
+
+   As discussed in Section 3, the requirements for inter-area and
+   inter-AS MPLS Traffic Engineering have been developed by the Traffic
+   Engineering Working Group (TE WG) and have been stated in [RFC4105]
+   and [RFC4216], respectively.  Among the set of requirements, both
+   documents indicate the need for some solution that provides the
+   ability to compute an optimal (shortest) constrained inter-domain TE
+   LSP and to compute a set of diverse inter-domain TE LSPs.
+
+10.1.  Diverse End-to-End Path Computation
+
+   PCEP (see [RFC5440]) allows a PCC to request the computation of a set
+   of diverse TE LSPs by setting the SVEC object's flags L, N, or S to
+   request link, node, or SRLG (Shared Risk Link Group) diversity,
+   respectively.  Such requests MUST be taken into account by each PCE
+   along the path computation chain during the VSPT computation.  In the
+   context of the BRPC procedure, a set of diversely routed TE LSPs
+   between two LSRs can be computed since the path segments of the VSPT
+   are simultaneously computed by a given PCE.  The BRPC procedure
+   allows for the computation of diverse paths under various objective
+   functions (such as minimizing the sum of the costs of the N diverse
+   paths, etc.).
+
+   By contrast, with a 2-step approach consisting of computing the first
+   path followed by computing the second path after having removed the
+   set of network elements traversed by the first path (if that does not
+   violate confidentiality preservation), one cannot guarantee that a
+   solution will be found even if such solution exists.  Furthermore,
+   even if a solution is found, it may not be the most optimal one with
+   respect to an objective function such as minimizing the sum of the
+   paths' costs, bounding the path delays of both paths, and so on.
+   Finally, it must be noted that such a 2-step path computation
+   approach is usually less efficient in terms of signaling delays since
+   it requires that two serialized TE LSPs be set up.
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 11]
+
+RFC 5441                          BRPC                        April 2009
+
+
+10.2.  Path Optimality
+
+   BRPC guarantees that the optimal (shortest) constrained inter-domain
+   path will always be found, subject to policy constraints.  Both in
+   the case where local path computation techniques are used (such as to
+   build stitched or nested TE LSPs), and in the case where a domain has
+   more than one BN-en or more than one BN-ex, it is only possible to
+   guarantee optimality after some network change within the domain by
+   completely re-executing the BRPC procedure.
+
+11.  Reoptimization of an Inter-Domain TE LSP
+
+   The ability to reoptimize an existing inter-domain TE LSP path has
+   been explicitly listed as a requirement in [RFC4105] and [RFC4216].
+   In the case of a TE LSP reoptimization request, the reoptimization
+   procedure defined in [RFC5440] applies when the path in use (if
+   available on the head-end) is provided as part of the path
+   computation request so that the PCEs involved in the reoptimization
+   request can avoid double bandwidth accounting.
+
+12.  Path Computation Failure
+
+   If a PCE requires to relay a path computation request according to
+   the BRPC procedure defined in this document to a downstream PCE and
+   no such PCE is available, the PCE MUST send a negative path
+   computation reply to the requester using a PCReq message as specified
+   in [RFC5440] that contains a NO-PATH object.  In such case, the
+   NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440])
+   with the newly defined bit named "BRPC path computation chain
+   unavailable" set.
+
+   Bit number     Name Flag
+      28           BRPC path computation chain unavailable
+
+13.  Metric Normalization
+
+   In the case of inter-area TE, the same IGP/TE metric scheme is
+   usually adopted for all the IGP areas (e.g., based on the link-speed,
+   propagation delay, or some other combination of link attributes).
+   Hence, the proposed set of mechanisms always computes the shortest
+   path across multiple areas that obey the required set of constraints
+   with respect to a specified objective function.  Conversely, in the
+   case of inter-AS TE, in order for this path computation to be
+   meaningful, metric normalization between ASes may be required.  One
+   solution to avoid IGP metric modification would be for the service
+   providers to agree on a TE metric normalization scheme and use the TE
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 12]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   metric for TE LSP path computation (in that case, the use of the TE
+   metric must be requested in the PCEP path computation request) using
+   the METRIC object (defined in [RFC5440]).
+
+14.  Manageability Considerations
+
+   This section follows the guidance of [PCE-MANAGE].
+
+14.1.  Control of Function and Policy
+
+   The only configurable item is the support of the BRPC procedure on a
+   PCE.  The support of the BRPC procedure by the PCE MAY be controlled
+   by a policy module governing the conditions under which a PCE should
+   participate in the BRPC procedure (origin of the requests, number of
+   requests per second, etc.).  If the BRPC is not supported/allowed on
+   a PCE, it MUST send a PCErr message as specified in Section 9.
+
+14.2.  Information and Data Models
+
+   A BRPC MIB module will be specified in a separate document.
+
+14.3.  Liveness Detection and Monitoring
+
+   The BRPC procedure is a multiple-PCE path computation technique and,
+   as such, a set of PCEs are involved in the path computation chain.
+   If the path computation chain is not operational either because at
+   least one PCE does not support the BRPC procedure or because one of
+   the PCEs that must be involved in the path computation chain is not
+   available, procedures are defined to report such failures in Sections
+   9 and 12, respectively.  Furthermore, a built-in diagnostic tool to
+   check the availability and performances of a PCE chain is defined in
+   [PCE-MONITOR].
+
+14.4.  Verifying Correct Operation
+
+   Verifying the correct operation of BRPC can be performed by
+   monitoring a set of parameters.  A BRPC implementation SHOULD provide
+   the following parameters:
+
+   o  Number of successful BRPC procedure completions on a per-PCE-peer
+      basis
+
+   o  Number of BRPC procedure completion failures because the VSPT flag
+      was not recognized (on a per-PCE-peer basis)
+
+   o  Number of BRPC procedure completion failures because the BRPC
+      procedure was not supported (on a per-PCE-peer basis)
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 13]
+
+RFC 5441                          BRPC                        April 2009
+
+
+14.5.  Requirements on Other Protocols and Functional Components
+
+   The BRPC procedure does not put any new requirements on other
+   protocols.  That said, since the BRPC procedure relies on the PCEP
+   protocol, there is a dependency between BRPC and PCEP; consequently,
+   the BRPC procedure inherently makes use of the management functions
+   developed for PCEP.
+
+14.6.  Impact on Network Operation
+
+   The BRPC procedure does not have any significant impact on network
+   operation: indeed, BRPC is a multiple-PCE path computation scheme as
+   defined in [RFC4655] and does not differ from any other path
+   computation request.
+
+14.7.  Path Computation Chain Monitoring
+
+   [PCE-MONITOR] specifies a set of mechanisms that can be used to
+   gather PCE state metrics.  Because BRPC is a multiple-PCE path
+   computation technique, such mechanisms could be advantageously used
+   in the context of the BRPC procedure to check the liveness of the
+   path computation chain, locate a faulty component, monitor the
+   overall performance, and so on.
+
+15.  IANA Considerations
+
+15.1.  New Flag of the RP Object
+
+   A new flag of the RP object (specified in [RFC5440]) is defined in
+   this document.  IANA maintains a registry of RP object flags in the
+   "RP Object Flag Field" sub-registry of the "Path Computation Element
+   Protocol (PCEP) Numbers" registry.
+
+   IANA has allocated the following value:
+
+       Bit      Description              Reference
+       25       VSPT                     This document
+
+15.2.  New Error-Type and Error-Value
+
+   IANA maintains a registry of Error-Types and Error-values for use in
+   PCEP messages.  This is maintained as the "PCEP-ERROR Object Error
+   Types and Values" sub-registry of the "Path Computation Element
+   Protocol (PCEP) Numbers" registry.
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 14]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   A new Error-value is defined for the Error-Type "Not supported
+   object" (type 4).
+
+   Error-Type     Meaning and error values                 Reference
+      4           Not supported object
+
+                  Error-value=4: Unsupported parameter     This document
+
+   A new Error-Type is defined in this document as follows:
+
+   Error-Type     Meaning                                  Reference
+     13           BRPC procedure completion failure        This document
+
+                  Error-value=1: BRPC procedure not        This document
+                  supported by one or more PCEs along
+                  the domain path
+
+15.3.  New Flag of the NO-PATH-VECTOR TLV
+
+   A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is
+   specified in this document.
+
+   IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the
+   "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
+   Element Protocol (PCEP) Numbers" registry.
+
+   IANA has allocated the following allocation value:
+
+      Bit number  Meaning                  Reference
+         4        BRPC path computation    This document
+                  chain unavailable
+
+16.  Security Considerations
+
+   The BRPC procedure relies on the use of the PCEP protocol and as such
+   is subjected to the potential attacks listed in Section 10 of
+   [RFC5440].  In addition to the security mechanisms described in
+   [RFC5440] with regards to spoofing, snooping, falsification, and
+   denial of service, an implementation MAY support a policy module
+   governing the conditions under which a PCE should participate in the
+   BRPC procedure.
+
+   The BRPC procedure does not increase the information exchanged
+   between ASes and preserves topology confidentiality, in compliance
+   with [RFC4105] and [RFC4216].
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 15]
+
+RFC 5441                          BRPC                        April 2009
+
+
+17.  Acknowledgments
+
+   The authors would like to thank Arthi Ayyangar, Dimitri
+   Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for
+   their useful comments.  A special thanks to Adrian Farrel for his
+   useful comments and suggestions.
+
+18.  References
+
+18.1.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5440]      Vasseur, J., Ed. and J. Roux, Ed., "Path Computation
+                  Element (PCE) Communication Protocol (PCEP)",
+                  RFC 5440, April 2009.
+
+18.2.  Informative References
+
+   [PATH-KEY]     Bradford, R., Vasseur, J., and A. Farrel, "Preserving
+                  Topology Confidentiality in Inter-Domain Path
+                  Computation Using a Key-Based Mechanism", Work in
+                  Progress, November 2008.
+
+   [PCE-MANAGE]   Farrel, A., "Inclusion of Manageability Sections in
+                  PCE Working Group Drafts", Work in Progress,
+                  January 2009.
+
+   [PCE-MONITOR]  Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
+                  monitoring tools for Path Computation Element based
+                  Architecture", Work in Progress, November 2008.
+
+   [RFC2702]      Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
+                  J. McManus, "Requirements for Traffic Engineering Over
+                  MPLS", RFC 2702, September 1999.
+
+   [RFC4105]      Le Roux, J., Vasseur, J., and J. Boyle, "Requirements
+                  for Inter-Area MPLS Traffic Engineering", RFC 4105,
+                  June 2005.
+
+   [RFC4216]      Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
+                  System (AS) Traffic Engineering (TE) Requirements",
+                  RFC 4216, November 2005.
+
+   [RFC4655]      Farrel, A., Vasseur, J., and J. Ash, "A Path
+                  Computation Element (PCE)-Based Architecture",
+                  RFC 4655, August 2006.
+
+
+
+Vasseur, et al.             Standards Track                    [Page 16]
+
+RFC 5441                          BRPC                        April 2009
+
+
+   [RFC4726]      Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
+                  for Inter-Domain Multiprotocol Label Switching Traffic
+                  Engineering", RFC 4726, November 2006.
+
+   [RFC5088]      Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
+                  "OSPF Protocol Extensions for Path Computation Element
+                  (PCE) Discovery", RFC 5088, January 2008.
+
+   [RFC5089]      Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
+                  "IS-IS Protocol Extensions for Path Computation
+                  Element (PCE) Discovery", RFC 5089, January 2008.
+
+   [RFC5152]      Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-
+                  Domain Path Computation Method for Establishing Inter-
+                  Domain Traffic Engineering (TE) Label Switched Paths
+                  (LSPs)", RFC 5152, February 2008.
+
+   [RFC5316]      Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
+                  Support of Inter-Autonomous System (AS) MPLS and GMPLS
+                  Traffic Engineering", RFC 5316, December 2008.
+
+   [RFC5392]      Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
+                  Support of Inter-Autonomous System (AS) MPLS and GMPLS
+                  Traffic Engineering", RFC 5392, January 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 17]
+
+RFC 5441                          BRPC                        April 2009
+
+
+Authors' Addresses
+
+   JP Vasseur (editor)
+   Cisco Systems, Inc
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   USA
+
+   EMail: jpv@cisco.com
+
+
+   Raymond Zhang
+   BT Infonet
+   2160 E. Grand Ave.
+   El Segundo, CA  90025
+   USA
+
+   EMail: raymond.zhang@bt.com
+
+
+   Nabil Bitar
+   Verizon
+   117 West Street
+   Waltham, MA  02451
+   USA
+
+   EMail: nabil.n.bitar@verizon.com
+
+
+   JL Le Roux
+   France Telecom
+   2, Avenue Pierre-Marzin
+   Lannion,   22307
+   FRANCE
+
+   EMail: jeanlouis.leroux@orange-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur, et al.             Standards Track                    [Page 18]
+