Networking
Network Working Group                                   JP. Vasseur, Ed.
Internet-Draft
Request for Comments: 5441                            Cisco Systems, Inc
Intended status:
Category: Standards Track                                       R. Zhang
Expires: October 16, 2008
                                                              BT Infonet
                                                                N. Bitar
                                                                 Verizon
                                                             JL. Le Roux
                                                          France Telecom
                                                              April 14, 2008 2009

 A Backward Recursive PCE-based Backward-Recursive PCE-Based Computation (BRPC) Procedure To to Compute
         Shortest Constrained Inter-domain Inter-Domain Traffic Engineering
                          Label Switched Paths

                       draft-ietf-pce-brpc-09.txt

Status of this This Memo

   By submitting

   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 Internet-Draft, each author represents that any
   applicable patent or other IPR claims protocol.  Distribution of which he or she this memo is aware
   have been or will be disclosed, unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and any 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 which he
   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 she becomes
   aware will be disclosed, IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in accordance with Section 6 some of BCP 79.

   Internet-Drafts are working documents this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate created outside the IETF Standards Process, except to use Internet-Drafts format
   it for publication as reference
   material an RFC or to cite them translate it into languages other
   than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 16, 2008. English.

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 (where 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) has been identified as a key
   requirement. Systems.  This document specifies a procedure
   relying on the use of multiple Path Computation Elements (PCEs) to
   compute such inter-
   domain inter-domain shortest constrained paths across a
   predetermined sequence of domains, using a backward recursive backward-recursive path
   computation technique.  This technique preserves confidentiality
   across domains, which is sometimes required when domains are managed
   by different Service
   Providers.

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]. service providers.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   3.  General Assumptions  . . . . . . . . . . . . . . . . . . . . .  5  4
   4.  BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . .  6  5
     4.1.  Domain Path Selection  . . . . . . . . . . . . . . . . . .  7  6
     4.2.  Mode of Operation  . . . . . . . . . . . . . . . . . . . .  7  6
   5.  PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . .  9  8
   6.  VSPT Encoding  . . . . . . . . . . . . . . . . . . . . . . . . 10  9
   7.  Inter-AS TE Links  . . . . . . . . . . . . . . . . . . . . . . 10  9
   8.  Usage In in Conjunction With Per-domain with Per-Domain Path Computation  . . . . 11 10
   9.  BRPC Procedure Completion Failure  . . . . . . . . . . . . . . 11 10
   10. Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 12 10
     10.1. Diverse end-to-end path computation End-to-End Path Computation  . . . . . . . . . . . 12 11
     10.2. Path Optimality  . . . . . . . . . . . . . . . . . . . . . 12 11
   11. Reoptimization Of An Inter-domain of an Inter-Domain TE LSP . . . . . . . . . . . 13 11
   12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 13 12
   13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 13 12
   14. Manageability Considerations . . . . . . . . . . . . . . . . . 14 12
     14.1. Control of Function And and Policy . . . . . . . . . . . . . . 14 12
     14.2. Information And and Data Models  . . . . . . . . . . . . . . . 14 13
     14.3. Liveness Detection and Monitoring  . . . . . . . . . . . . 14 13
     14.4. Verifying Correct Operation  . . . . . . . . . . . . . . . 14 13
     14.5. Requirements on Other Protocols and Functional
           Components . . . . . . . . . . . . . . . . . . . . . . . . 15 13
     14.6. Impact on Network Operation  . . . . . . . . . . . . . . . 15 13
     14.7. Path Computation Chain Monitoring  . . . . . . . . . . . . 15 14
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15 14
     15.1. New Flag Of The of the RP Object  . . . . . . . . . . . . . . . . 15 14
     15.2. New Error-Type And and Error-Value . . . . . . . . . . . . . . 15 14
     15.3. New Flag Of The of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 16 15
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   18. References . . . . . . . . . . . 15
   17. Acknowledgments  . . . . . . . . . . . . . . . 16
     18.1. Normative References . . . . . . . . 15
   18. References . . . . . . . . . . . 16
     18.2. Informative References . . . . . . . . . . . . . . . 16
     18.1. Normative References . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . 16
     18.2. Informative References . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20 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 signalling 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 to the use of
   consistent metric schemes in each domain (see section Section 13).

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 Routers.  Routers Router.  Router used to connect
   together ASes of the same or different Service Providers service providers via one or
   more Inter-AS 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-AS

   Inter-area TE LSP: A TE LSP that crosses an AS IGP area boundary.

   Inter-area

   Inter-AS TE LSP: A TE LSP that crosses an IGP area AS boundary.

   LSR: Label Switching Router.

   LSP: Label Switched Path.

   LSR: Label Switching Router.

   PCC: Path Computation Client.  Any client application requesting a
   path computation to be performed by the a Path Computation Element.

   PCE (Path

   PCE: Path Computation Element): an Element.  An entity (component, application 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 stitched, and nested TE LSPs is defined in
   [RFC4726] and will not be repeated here.

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 like (such as resource
      affinity, color, metric, etc. as listed in [RFC2702] [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 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 inter-AS TE LSP spanning
      multiple ASes ASes, where some of those ASes are themselves made of
      multiple IGP areas areas, can be easily derived from this case by
      applying the BRPC procedure described in this document,
      recursively.

   o  The domain path (set (the set of domains traversed to reach the
      destination domain) is either administratively pre-determined 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 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) 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 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
   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 it 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 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 CSPF Constrained
   Shortest Path First (CSPF) or an algorithm based on linear-programming 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 pre-determined 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 IRO
   Include Route Object (IRO) defined in [I-D.ietf-pce-pcep] [RFC5440] so that it is
   available to all PCEs.  Note also that a sequence of PCEs MAY be
   enforced by policy on the
   PCC PCC, and this constraint can be carried in
   the PCEP path computation request (as defined in [I-D.ietf-pce-monitoring]). [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)
      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)
      BN-ex(k,i) is the kth exit BN of domain(i).

   VSPT(i): MP2P (MultiPoint To Point) (multipoint-to-point) tree returned by PCE(i) to
   PCE(i-1):

                     Root (TE LSP destination)
                     /         I         |            \
               BN-en(1,i)   BN-en(2,i) ... BN-en(j,i).

   Where

   where [X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)]

              Figure 1 - 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).
   BN-en(j,i).

   Note that PCE(i) only considers the entry BNs of domain(i).  That is domain(i), i.e.,
   only the BNs that provide connectivity from domain(i-1).  That is,  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 first determine the PCE capable of serving its path
   computation request (this can be done thanks to 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 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) 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. (e.g., CSPF) and returns
   the computed VSPT(n) to PCE(n-1).

   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 inter-AS TE LSP computation, this requires to also add requires adding
   the inter-AS TE links connecting that connect the domain(i) to the domain(i+1).

   Step n

   Finally 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
   [I-D.ietf-pce-pcep].
   [RFC5440].

   Each branch of the VSPT tree (path) may be returned in the form of an
   explicit path (in which case case, all the hops along the path segment are
   listed) or a loose path (in which case case, only the BN is specified) so
   as to preserve confidentiality along with the respective cost.  In
   the later latter case, various techniques can be used in order to retrieve
   the computed explicit paths on a per domain per-domain basis during the
   signaling process process, thanks to the use of path keys as described in
   [I-D.ietf-pce-path-key].
   [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 ECMP Equal Cost Multi-Path (ECMP) paths, more
   than one path could be returned to the requesting LSR. 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
   [I-D.ietf-pce-pcep]) [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).

   The following new flag of the RP object is defined:

   VSPT Flag

   Bit Number      Name Flag
     7
      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 lists list of EROs 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 - 2: An Example of VPST VSPT Encoding Using a Set of EROs

   In the simple example shown in figure 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 adress)-D(TE address)-D(TE Router ID)

   The PCReq message, PCRep message, PCEP END-POINT object, and ERO objects
   object are defined in [I-D.ietf-pce-pcep] [RFC5440].

7.  Inter-AS TE Links

   In the case of Inter-AS inter-AS TE LSP path computation, the BRPC procedure
   requires the knowledge of the traffic engineering attributes of the
   Inter-AS
   inter-AS TE links: the 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
   [I-D.ietf-ccamp-isis-interas-te-extension] [RFC5316] and
   [I-D.ietf-ccamp-ospf-interas-te-extension]). [RFC5392]).

8.  Usage In in Conjunction With Per-domain 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 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 [I-D.ietf-pce-pcep], [RFC5440], the PCE sends a PCErr message to the upstream
   PCE with an Error-Type=4 (not (Not supported object), Error-
   value-4 Error-value=4
   (Unsupported paramater). 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 recognises 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 which 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 Error-value are managed by IANA.
   A new Error-Type is defined that relates to the BRPC procedure.

  Error-type

  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 providing 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 End-to-End Path Computation

   PCEP (see [I-D.ietf-pce-pcep]) [RFC5440]) allows a PCC to request the computation of a set
   of diverse TE LSPs thanks to the SVEC object by setting the SVEC object's flags L, N N, or S to
   request link, node node, or SRLG diversity (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 paths 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). etc.).

   By constrast, contrast, with a 2-step approach consisting of computing the first
   path followed by the computation of 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
   paths' costs, bounding the path delays of both paths paths, and so on.
   Finally, it must be noted that such a 2-step path computation
   approach is usually less efficient in term terms of
   signalling signaling delays since
   it requires that two serialized TE LSP LSPs be set up.

10.2.  Path Optimality

   BRPC guarantees that the optimal (shortest) constrained inter-domain
   path will always be found found, subject to policy constraints.  When
   combined with other  Both in
   the case where local path computation techniques (e.g. in the
   case of stitched/nested are used (such as to
   build stitched or nested TE LSP) 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 can only be guaranteed by re-
   executing
   completely re-executing the BRPC procedure.

11.  Reoptimization Of An Inter-domain 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 [I-D.ietf-pce-pcep] [RFC5440] applies where when the path in use (if
   available on the head-end) is provided as part of the path
   computation request in order for so that the PCEs involved in the reoptimization
   request to 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 [I-D.ietf-pce-pcep] [RFC5440] that contains a NO-PATH object.  In such case, the
   NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in
   [I-D.ietf-pce-pcep]) [RFC5440])
   with the newly defined bit named "BRPC Path
   Computation path computation chain
   unavailable" set.

   Bit number     Name Flag
      4
      28           BRPC Path 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 delay, or some other combination of link attributes).
   Hence, the proposed set of mechanisms always computes the shortest
   path across multiple areas obeying that obey the required set of constraints
   with respect to a specified objective function.  Conversely, in the
   case of Inter-AS 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 service
   providers to agree on a TE metric normalization scheme and use the TE
   metric for TE LSP path computation (in that case, this the use of the TE
   metric must be requested in the PCEP Path path computation request) using
   the METRIC object (defined in [I-D.ietf-pce-pcep]). [RFC5440]).

14.  Manageability Considerations

   This section follows the guidance of
   [I-D.ietf-pce-manageability-requirements]. [PCE-MANAGE].

14.1.  Control of Function And 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 to 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 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 multiple-PCE path computation technique and and,
   as such 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
   Section Sections
   9 and Section 12 12, respectively.  Furthermore, a built-in diagnostic tool to
   check the availability and performances of a PCE chain is defined in [I-D.ietf-pce-monitoring].
   [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 procedure completions on a per PCE peer
   basis, per-PCE-peer
      basis

   o  Number of BRPC procedure completion failures because the VSPT flag
      was not recognized (on a per PCE peer basis), per-PCE-peer basis)

   o  Number of BRPC procedure completetion completion failures because the BRPC
      procedure was not supported (on a per PCE peer basis), per-PCE-peer basis)

14.5.  Requirements on Other Protocols and Functional Components

   The BRPC procedure does not put any new requirements on other
   protocol.
   protocols.  That said, since the BRPC procedure relies on the PCEP
   protocol, there is a dependency between BRPC and PCEP; consequently 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 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

   [I-D.ietf-pce-monitoring]

   [PCE-MONITOR] specifies a set of mechanisms that can be used to
   gather PCE state metrics.  Because BRPC is a Multiple-PCE multiple-PCE path
   computation techniques, technique, such mechanism 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 performance, and so on.

15.  IANA Considerations

15.1.  New Flag Of The of the RP Object

   A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) [RFC5440]) is defined in
   this document.

   VSPT  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 Number      Name Flag      Description              Reference
     7

       25       VSPT                     This document

15.2.  New Error-Type And 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.

   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 (Error-Type and Error-
   value to be assigned by IANA).

    Error-type as follows:

   Error-Type     Meaning                                  Reference

     13           BRPC procedure completion failure        This document
                     Error-value
                      1:

                  Error-value=1: BRPC procedure not        This document
                  supported by one a PCE or more PCEs along
                  the domain path

15.3.  New Flag Of The of the NO-PATH-VECTOR TLV

   A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) [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 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 11 Section 10 of
   [I-D.ietf-pce-pcep].
   [RFC5440].  In addition to the security mechanisms described in [I-D.ietf-pce-pcep]
   [RFC5440] with regards to spoofing, snooping,
   falsification falsification, and Denial
   denial of Service, service, an implementation MAY support a policy module
   governing the conditions under which a PCE should participate to 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].

17.  Acknowledgements  Acknowledgments

   The authors would like to thank Arthi Ayyangar, Dimitri
   Papadimitriou, Siva Sivabalan, Meral Shirazipour Shirazipour, and Mach Chen for
   their useful comments.  A special thank thanks to Adrian Farrel for his
   useful comments and suggestions.

18.  References

18.1.  Normative References

   [I-D.ietf-pce-pcep]
              Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri,
              Y., Kumaki, K., Vasseur, J., and J. Roux, "Path
              Computation Element (PCE) Communication Protocol (PCEP)",
              draft-ietf-pce-pcep-12 (work in progress), March 2008.

   [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

   [I-D.ietf-ccamp-isis-interas-te-extension]
              Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
              Support of Inter-AS Multiprotocol Label Switching (MPLS)
              and Generalized MPLS (GMPLS) Traffic Engineering",
              draft-ietf-ccamp-isis-interas-te-extension-02 (work in
              progress), April 2008.

   [I-D.ietf-ccamp-ospf-interas-te-extension]
              Chen, M., Zhang,

   [PATH-KEY]     Bradford, R., and X. Duan, "OSPF Extensions in
              Support of Inter-AS Multiprotocol Label Switching (MPLS)
              and Generalized MPLS (GMPLS) Traffic Engineering",
              draft-ietf-ccamp-ospf-interas-te-extension-05 (work Vasseur, J., and A. Farrel, "Preserving
                  Topology Confidentiality in
              progress), April Inter-Domain Path
                  Computation Using a Key-Based Mechanism", Work in
                  Progress, November 2008.

   [I-D.ietf-pce-manageability-requirements]

   [PCE-MANAGE]   Farrel, A., "Inclusion of Manageability Sections in
                  PCE Working Group Drafts",
              draft-ietf-pce-manageability-requirements-03 (work Work in
              progress), February 2008.

   [I-D.ietf-pce-monitoring] Progress,
                  January 2009.

   [PCE-MONITOR]  Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
                  monitoring tools for Path Computation Element based
                  Architecture", draft-ietf-pce-monitoring-01 (work in
              progress), February 2008.

   [I-D.ietf-pce-path-key]
              Bradford, R. and J. Vasseur, "Preserving Topology
              Confidentiality Work in Inter-Domain Path Computation Using a
              Key-Based Mechanism", draft-ietf-pce-path-key-02 (work in
              progress), February 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.

   [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 Per-
                  Domain Path Computation Method for Establishing Inter-Domain 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.

Authors' Addresses

   JP Vasseur (editor)
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Email:

   EMail: jpv@cisco.com

   Raymond Zhang
   BT Infonet
   2160 E. Grand Ave.
   El Segundo, CA  90025
   USA

   Email: raymond_zhang@bt.infonet.com

   EMail: raymond.zhang@bt.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   117 West Street
   Waltham, MA  02145  02451
   USA

   Email: nabil.bitar@verizon.com

   EMail: nabil.n.bitar@verizon.com
   JL Le Roux
   France Telecom
   2, Avenue Pierre-Marzin
   Lannion,   22307
   FRANCE

   Email: jeanlouis.leroux@orange-ft.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such 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
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   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
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

   EMail: jeanlouis.leroux@orange-ftgroup.com