Internet DRAFT - draft-fuxh-pce-drpc

draft-fuxh-pce-drpc






Network Working Group                                             XH. Fu
Internet-Draft                                                   YL. Bao
Intended status: Informational                           ZTE Corporation
Expires: March 3, 2012                                          YL. Zhao
                                                                J. Zhang
                                                                    Y. G
                                                                    BUPT
                                                         August 31, 2011


 A Dual-end Recursive PCE-Based Computation (DRPC) Procedure to Compute
  Shortest Constrained Inter-domain Traffic Engineering Label Switched
                                 Paths
                         draft-fuxh-pce-drpc-03

Abstract

   A dual-end recursive PCE-based computation procedure (DRPC) is
   proposed to compute shortest constrained inter-domain traffic
   engineering label switched paths based on BRPC in Multi-protocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.  By
   recursively performing shortest path algorithm and transferring the
   segmental path computation result from both ends bi-directionally,
   they meet at one of the Middle PCEs, generating a directional
   shortest path graph into which the two shortest path trees are
   stitched together.  Therefore, the end-to-end constrained inter-
   domain traffic engineering label switched path, even k shortest paths
   can be gained from the directional shortest path graph directly.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 3, 2012.

Copyright Notice




Fu, et al.                Expires March 3, 2012                 [Page 1]

Internet-Draft               DRPC Procedure                  August 2011


   Copyright (c) 2011 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Terminologies  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  General Assumptions  . . . . . . . . . . . . . . . . . . . . .  5
   4.  DRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  PCE Sequence Selection Approaches  . . . . . . . . . . . .  5
     4.2.  DRPC Procedure . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Stitching PCE Selection  . . . . . . . . . . . . . . . . . 10
       4.3.1.  Case(1): Mode of Operation in PCE Designation  . . . . 10
       4.3.2.  Case(2): Mode of Operation in PCEP Signaling
               Procedure  . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  An Example of PCE Collaboration  . . . . . . . . . . . . . 13
   5.  PCEP Protocol Extension Requirements . . . . . . . . . . . . . 15
   6.  VSPG Encoding  . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  DRPC Procedure Failures  . . . . . . . . . . . . . . . . . . . 17
   8.  Path Computation Failures  . . . . . . . . . . . . . . . . . . 18
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 19
     10.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 19
     10.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 19
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20











Fu, et al.                Expires March 3, 2012                 [Page 2]

Internet-Draft               DRPC Procedure                  August 2011


1.  Introduction

   With regards to the constraint-based shortest path computation in
   Multi-protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   multi-layer and multi-domain networks, IETF groups propose the
   architecture of Path Computation Element (PCE) [RFC4655].  As an
   important approach of path computation in PCE architecture, backward
   recursive PCE-based computation (BRPC) procedure can gain a shortest
   path tree along the direction from the destination node to the source
   node, and then get an end-to-end optimal path [RFC5441].  During the
   procedure of BRPC, a sequence of PCEs should be pre-determined.
   However, when the number of PCEs in the predetermined PCE sequence
   are very large, the path computation time may be long for the
   customer, and the long PCE chain will be vulnerable.  A dual-end
   recursive PCE-based computation (DRPC) procedure is proposed to
   compute shortest constrained inter-domain traffic engineering label
   switched paths.  DRPC procedure aims to provide a further improvement
   of the existing BRPC procedure by computing and transferring the
   shortest path tree bi-directionally, which doubles the pace of inter-
   domain path computation.In DRPC procedure, path computation is
   launched at the source PCE and the destination PCE simultaneously.
   By recursively performing shortest path algorithm and transferring
   the segmental path computation result from both ends bi-
   directionally, they meet at one of the Middle PCEs, generating a
   directional shortest path graph into which the two shortest path
   trees are stitched together.  Therefore, the end-to-end constrained
   inter-domain traffic engineering label switched path, even the k
   shortest paths can be gained from the directional shortest path graph
   directly.  Only the differences from [RFC5441] are listed here, the
   overlapped comments all inherit the corresponding terms in [RFC5441],
   such as section 7, 8, 10, 11, 13, 14, 16, and so on.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Terminologies

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




Fu, et al.                Expires March 3, 2012                 [Page 3]

Internet-Draft               DRPC Procedure                  August 2011


   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 TE LSP: A TE LSP that crosses an AS boundary.  Inter-area TE
   LSP: A TE LSP that crosses an IGP area boundary.

   LSR: Label Switching Router.

   LSP: Label Switched Path.

   PCC: Path Computation Client.  Any client application requesting a
   path computation to be performed by the 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): a PCE with the scope of domain (i).

   TED: Traffic Engineering Database.

   VSPT: Virtual Shortest Path Tree.

   VSPG: Virtual Shortest Path Graph.

   Source PCE: the PCE in the source domain to launch the DRPC procedure
   and transfer the calculated VSPT forward.

   Destination PCE: the PCE in the destination domain to launch the DRPC
   procedure and transfer the calculated VSPT backward.

   Middle PCE: a PCE which is a relative concept ,that is one of the
   PCEs in the PCE sequence(the direction from the Destination PCE to
   the Source PCE or from the Source PCE to the Destination PCE
   relatively).And the Middle PCE must not be the source PCE or the
   destination PCE.

   Stitching PCE: a PCE which is determined to stitch the two VSPTs from
   both source and destination sides of PCEs into a VSPG.

   Downstream: In forward direction, from Source PCE to Destination PCE.



Fu, et al.                Expires March 3, 2012                 [Page 4]

Internet-Draft               DRPC Procedure                  August 2011


   Upstream: In backward direction, from Destination PCE to Source PCE.


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, which are same
   to the assumptions of [RFC 5441].

   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 resource affinity,
      color, metric, etc. as listed in 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 DRPC procedure described in this document,
      recursively.

   o  The domain path (set of domains traversed to reach the destination
      domain) is either administratively pre-determined or discovered by
      some means that is outside of the scope of this document.


4.  DRPC Procedure

4.1.  PCE Sequence Selection Approaches

   A PCE sequence has to be predetermined before DRPC procedure is
   launched, which corresponds to the domain path selection.  The PCE/
   domain path may be either administratively predetermined or
   discovered by some means outside of the scope of this document.



Fu, et al.                Expires March 3, 2012                 [Page 5]

Internet-Draft               DRPC Procedure                  August 2011


   A hierarchical PCE architecture is highly recommended which is
   proposed in [I-D.ietf-pce-hierarchy-fwk].  In the hierarchical PCE
   architecture, there are concepts of Parent (hierarchical) PCE and
   child PCE.

   The Parent PCE is responsible for selecting a PCE/domian path across
   its domain map.The Parent PCE maintains the domain topology map that
   contains the child domains and their interconnections and the traffic
   engineering (TE) capabilities of domain interconnections.  But The
   Parent PCE has no information about the contents of the child
   domains.And it learns those from configuration or information
   received from each Child PCE.

   Each domain has has at least one PCE capable of computing paths
   across it.  These PCEs are known as Child PCEs and have a
   relationship with the Parent PCE.  A child PCE is responsible for
   computing the path across one or more specific (child) domains.  Each
   Child PCE knows the identity of the border nodes and links of its own
   adjacent domains.  But a child PCE only knows the topology of the
   domain it serves and does not know the topology of other domains.And
   it is also not aware of the general domain mesh connectivity beyond
   the connectivity to the immediate neighbordomains of the domain it
   serves.

   When the ingress PCE responsible for the ingress domain receives a
   path computation request from the source node, and the destination is
   outside of this domain, the ingress PCE will send a path computation
   request(PCReq Message) to the parent PCE.  The parent PCE determines
   which domian the destination node belongs to.And then the parent PCE
   selects the sequence of candidate domain PCEs based on its domain
   topology map.  It then sends the selected candidate PCE sequence
   within the computation requests (PCRep Message) to the ingress PCE .

   Each selected candidate PCE that in the selected sequence computes a
   set of candidate path segments across its own domain and then use
   some methods(e.g.  BRPC, etc.) to gain an optimal end-to-end optimal
   path from the source node to the destination node.

   The communication with Parent PCE is unnecessary within the context
   of non-hierarchical PCE architecture and PCE/domain path can be
   obtained by other means.

4.2.  DRPC Procedure

   Definition of VSPG(i), VSPT(0,i) and VSPT(1,i):

   VSPG(i) consists of multi shortest paths from the same node to other
   multi nodes.



Fu, et al.                Expires March 3, 2012                 [Page 6]

Internet-Draft               DRPC Procedure                  August 2011


   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).

   The definition of VSPT(1,i) is the same as that of VSPT(i) in BRPC
   (see [RFC5441]).

   VSPT(1,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 is no larger than [X-en(i)]


           Figure 1: VSPT(1,i) Backward Shortest Path MP2P Tree

   Each link of tree VSPT(1,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, resource affinity,
   metrics, etc.).  These are path segments to reach the TE LSP
   destination from BN-en(j,i).

   The definition of VSPT(0,i) is vary similar to the VSPT(1,i).

   VSPT(0,i): P2MP (point-to-multipoint) tree returned by PCE(i) to
   PCE(i+1):







Fu, et al.                Expires March 3, 2012                 [Page 7]

Internet-Draft               DRPC Procedure                  August 2011


           -----------------------------------------------------
          |                                                      |
          |               ---------------------                  |
          |              | Root (TE LSP source)|                 |
          |               ---------------------                  |
          |              /          |          \                 |
          |             /           |           \                |
          |            /            |            \               |
          |   ------------     ------------       ------------   |
          |  |BN-en(1,i+1)|   |BN-en(2,i+1)| ... |BN-en(j,i+1)|  |
          |   ------------     ------------       ------------   |
          |                                                      |
           -----------------------------------------------------
          where [X-en(i)] is the number of entry BNs in
          domain (i), and j is no larger than [X-en(i)]


            Figure 2: VSPT(0,i) Forward Shortest Path P2MP Tree

   Each link of tree VSPT(0,i) represents the shortest constrained path
   between BN-en(j,i+1) and the TE LSP source that satisfies the set of
   required constraints for the TE LSP (bandwidth, resource affinity,
   metrics, etc.).  These are path segments to reach BN-en(j,i+1) from
   the TE LSP source.

   Different from BRPC, when a path computation request arriving and the
   PCE sequence to be traversed has been predetermined, DRPC will launch
   the path computation from dual-end PCEs to the Middle PCEs bi-
   directionally.  It is worth noting that the Middle PCE may not be the
   PCE in the middle of the PCE sequence but the PCE receiving the two
   path computation requests from two directions.  And the domian that
   servered by the Middle PCE is called as Stitching Domain,and this
   Middle PCE is also called as stitching PCE.  According to the path
   computation request, the source PCE sparks the path computaion to the
   Entry BN of the stitching domain.  While, the destination PCE sparks
   the path computation to the the Entry BN of the domain next to the
   stitching domain.  When the stitching PCE receives the two messages
   which contain the two virtual shortest path trees (VSPT) at the root
   of the source node and the destination node respectively, the
   stitching PCE will stitch the two VSPTs into one complete directional
   shortest path graph.  At last, the shortest path or k shortest paths
   will be selected from the directional shortest path graph by the
   stitching PCE according to some strategies and transferred to the
   source node through the Source PCE.  Similar with BRPC procedure, a
   predetermined PCE sequence should also be designated before DRPC
   procedure.

   PCE(i+1) computes VSPT(1,i+1) by using its own topology map without



Fu, et al.                Expires March 3, 2012                 [Page 8]

Internet-Draft               DRPC Procedure                  August 2011


   considerating any cross-domain links.  VSPT(1,i+1) is returned by
   PCE(i+1) to PCE(i) along the direction from the Destination PCE to
   the Source PCE, which consists of multi shortest paths from the multi
   BN-en(j,i+1)s to the destination node, as is shown in Fig.1.

   PCE(i-1) computes VSPT(0,i-1) by using its own topology map together
   with the cross-domain links between domain(i-1) and domain(i).
   VSPT(0, i-1) is returned by PCE(i-1) to PCE (i) along the direction
   from the Source PCE to the Destination PCE, which consists of multi
   shortest paths from the source node to multi BN-en(j,i), as is shown
   in Fig.2.

   VSPG(i)=VSPT(0,i)+VSPT(1,i+1) is the directional shortest path graph
   from the source node to the destination node which is stitched by the
   two directional shortest path trees that gained above.  As the
   Stitching PCE, PCE(i) computes VSPT(0,i) and then stitches the two
   directional shortest path graphs together where VSPT(0,i) represents
   the directional shortest path tree computed from source node to the
   Entry BN of domain(i+1) and VSPT(1,i+1) represents the directional
   shortest path graph computed from destination node to the Entry BN of
   domain(i+1).  At last, the directional shortest path graph from the
   source node to the destination node is generated as shown in Fig.3.


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


                   Figure 3: VSPG(i) Shortest Path Graph

   The Stitching PCE can be either designated before DRPC procedure or
   dynamic selected in PCEP signaling procedure automatically.




Fu, et al.                Expires March 3, 2012                 [Page 9]

Internet-Draft               DRPC Procedure                  August 2011


   Two path selection strategies are permitted to return the shortest
   path back to PCC.

   o  The Stitching PCE transfers the computed optimal end-to-end path
      to the Source PCE through PCReq message and the Source PCE returns
      the path back to PCC.  The non-optimal paths are deleted at the
      Stitching PCE.

   o  The Stitching PCE transfers the newly stitched directional
      shortest path graph to the Source PCE through PCRep message.
      Source PCE generates the shortest path and returns it back to PCC.
      The non-shortest paths are deleted at the Source PCE.

4.3.  Stitching PCE Selection

   The Stitching PCE is an ordinary PCE.  It acts as the role of
   stitching the two VSPTs from both source and destination sides of
   PCEs into a VSPG.  The Stitching PCE can be designated by several
   means before DRPC procedure, such as Parent PCE computation, Network
   Management System(NMS) designation, administrative configuration and
   etc.  These can be regarded as Designation Case and Section 4.3.1
   describes the DRPC operation in this case.  By utilizing the
   characteristics of the PCEP signaling, the stitching role can be
   dynamically determined.  Section 4.3.2 elaborates the details of PCEP
   signaling procedure in Stitching PCE Selection.

4.3.1.  Case(1): Mode of Operation in PCE Designation

   Denoting that PCE(1) is the Source PCE, PCE(m) is the Stitching PCE,
   and PCE(n) is the Destination PCE.

   Step 1:

   PCE(1) computes VSPT(0,1), the tree made of the list of shortest
   constrained paths between the TE LSP source and every BN-en(j,2) by
   using a suitable path computation algorithm (e.g.  CSPF, etc.) and
   returns the computed VSPT(0,1) to PCE(2).  This can be triggered by
   Parent PCE, PCC or spontaneously.

   Simultaneously, PCE(n) computes VSPT(1,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,
   etc.) and returns the computed VSPT(n) to PCE(n-1).  This can be
   triggered by Parent PCE, PCE(n-1) or PCE(1) directly.  It is highly
   recommended to drive PCE(n) to compute VSPT(1,n) by PCE chain and to
   relay PCReq message PCE-by-PCE downstream from PCE(1).  An example of
   specific PCEP message flow is shown in section 4.4.




Fu, et al.                Expires March 3, 2012                [Page 10]

Internet-Draft               DRPC Procedure                  August 2011


   Step i: (Downstream)

   For i=2 to m-1: PCE(i) computes VSPT(0,i), the tree made of the
   shortest constrained paths between the TE LSP source and each BN-
   en(j,i+1).  It does this by considering the information in
   VSPT(0,i-1) and its own TED including the links that provide
   connectivity from domain(i) to domain(i+1).  PCE(i) returns the
   computed VSPT(0,i) to PCE(i+1).

   Step i: (Upstream)

   For i=n-1 to m+1: PCE(i) computes VSPT(1,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 the information in
   VSPT(1,i+1) and its own TED.  PCE(i) returns the computed VSPT(1,i)
   to PCE(i-1).

   Step m:

   The Stitching PCE(m) computes VSPT(0,m), the tree made of the
   shortest constrained paths between the TE LSP source and each BN-
   en(j,m+1).  It does this by considering the information in
   VSPT(0,m-1) and its own TED including the links that provide
   connectivity from domain(m) to domain(m+1).  PCE(m) stitches the
   computed VSPT(0,m) and VSPT(1,m+1) which is returned from PCE(m+1)
   into a VSPG.

   If n=2, the source domain and the destination domain are directly
   interconnected with each other.  The Stitching PCE is recommended to
   be specified as the Source PCE where step i is omitted.

   The PCRep message which carries VSPG(m) or final Explicit Route
   Objects (EROs) should be relayed from PCE(m) to PCE(1) upstream PCE-
   by-PCE.  PCE(1) returns the final path computation result to PCC.
   The optimal path can be selected from VSPG(m) either by PCE(m) or
   PCE(1).  For the sake of topology confidentialality, PCE(m) is
   recommended to select the final explicit route rather than PCE(1).

4.3.2.  Case(2): Mode of Operation in PCEP Signaling Procedure

   Denoting that PCE(1) is the Source PCE and PCE(n) is the Destination
   PCE.  In case(2), every PCE transfers VSPT to the next PCE without
   knowing a predefined Stitching PCE.  So, the Stitching PCE is
   selected automatically in PCEP signaling procedure where VSPT request
   messages upstream and downstream meet each other and there are three
   scenarios.

   Scenario (1): PCE(i) and PCE(i+1) receive messages request for



Fu, et al.                Expires March 3, 2012                [Page 11]

Internet-Draft               DRPC Procedure                  August 2011


   VSPT(1,i+1) and VSPT(0,i) respectively after these two messages have
   been sent.  Thus, PCE(i) stitches VSPT(0,i) and VSPT(1,i+1) into
   VSPG(i), whereas PCE(i+1) discards the message.

   Scenario (2): PCE(i) receives a message carrying VSPT(1,i+1) after it
   has received a message carrying VSPT(0,i), and it is unable to stop
   sending PCReq with computed VSPT(0,i) to PCE(i+1) immediately or the
   message has already been sent.  Thus, PCE(i) stitches VSPT(0,i) and
   VSPT(1,i+1) into VSPG(i), whereas PCE(i+1) discards VSPT(0,i).

   Scenario (3): PCE(i+1) receives a message carrying VSPT(0,i) after it
   has received a message carrying VSPT(1,i+2), and it is unable to stop
   sending message carrying a computed VSPT(1,i+1) to PCE(i)
   immediately.  Thus, PCE(i) stitches VSPT(0,i) and VSPT(1,i+1) into
   VSPG(i), whereas PCE(i+1) discards VSPT(0,i).

   The following steps are described to deal with these three situations
   in a uniform procedure.  Denoting that PCE(m) is the Stitching PCE
   and it is the intersection of the two VSPTs.

   Step 1:

   PCE(1) computes VSPT(0,1), the tree made of the list of shortest
   constrained paths between the TE LSP source and every BN-en(j,2) by
   using a suitable path computation algorithm (e.g., CSPF) and returns
   the computed VSPT(0,1) to PCE(2).  This can be triggered by Parent
   PCE, PCC or spontaneously.

   Simultaneously, PCE(n) computes VSPT(1,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).  This can be triggered
   by Parent PCE, PCE(n-1) or PCE(1) directly.  It is highly recommended
   to drive PCE(n) to compute VSPT(1,n) by PCE chain and to relay PCReq
   message PCE-by-PCE downstream from PCE(1).  This step is identical
   with that of Case (1).

   Step i: (Downstream)

   For i=2 to m: PCE(i) computes VSPT(0,i), the tree made of the
   shortest constrained paths between the TE LSP source and each BN-
   en(j,i+1).  It does this by considering the information in
   VSPT(0,i-1) and its own TED including the links that provide
   connectivity from domain(i) to domain(i+1).  If PCE(i) has already
   received a valid message request for VSPT(0,i) from PCE(i+1) which
   carries VSPT(1,i+1), it ignores the message once received from
   PCE(i-1) downstream.  Otherwise PCE(i) returns the computed VSPT(0,i)
   to PCE(i+1).



Fu, et al.                Expires March 3, 2012                [Page 12]

Internet-Draft               DRPC Procedure                  August 2011


   Step i: (Upstream)

   For i=n to m+1: PCE(i) computes VSPT(1,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 the information in
   VSPT(1,i+1) and its own TED.  PCE(i) returns the computed VSPT(1,i)
   to PCE(i-1).  If PCE(i) has already received a valid message request
   for VSPT(1,i-1) from PCE(i-1) which carries VSPT(0,i-1), it computes
   VSPT(0,i+1) and transfers the VSPT(0,i) to PCE(i+1).  Once a valid
   message carrying VSPT(1, i+1) received from PCE(i+1) after receiving
   VSPT(0, i-1) from PCE(i-1), PCE(i) stitches these two VSPTs into a
   VSPG(i).

   Both PCReq and PCRep message are permitted to trigger VSPT
   computation.  It is recommended to use PCRep message to trigger the
   VSPT computation on the Middle PCE, and PCReq on the Source and
   Destination PCE.  VSPT(0, i), VSPT(1, i) and VSPG(i) MUST be encoded
   in ERO, IRO, RRO, or XRO Objects (see [RFC5440] and [RFC5521]).

   The PCRep message which carries VSPG(m) or final ERO should be
   relayed from PCE(m) to PCE(1) upstream PCE-by-PCE.  PCE(1) returns
   the final path computation result to PCC.  The shortest path can be
   selected from VSPG(m) either by PCE(m) or PCE(1).  These are
   identical with case (1).

4.4.  An Example of PCE Collaboration

   The following example is used for demonstrating PCE collaboration of
   DRPC procedure in this document.  It uses the recommended PCEP
   message flow.

   Notes:

      - Only three domains are depicted in the diagram below for the
      sake of simplicity.

      - We assume that the Stitching PCE is in the middle of the PCE
      sequence, which may be determined by either of the two cases
      described in Section 4.3.












Fu, et al.                Expires March 3, 2012                [Page 13]

Internet-Draft               DRPC Procedure                  August 2011


                 (1.1)PCReq      ------------
             +----------------->| Parent PCE |
             |   (1.2)PCRep      ------------
             |
        -----+------             ------------             ------------
       |     |      |           |  Domain 2  |           |  Domain 3  |
       |     v      |           | (Stitcher) |           |            |
       |   ------   | (2a)PCReq |   ------   | (3a)PCReq |   ------   |
       |  | PCE1 |<-+-----------+->| PCE2 |<-+-----------+->| PCE3 |  |
       |   ------   | (2b)PCRep |   ------   | (3b)PCRep |   ------   |
       |     ^      | (4)PCRep  |            |           |            |
       |  (1)|PCReq |            ------------             ------------
       |  (5)|PCRep |
       |     v      |
       |   -----    |
       |  | PCC |   |
       |   -----    |
       |            |
       |  Domain 1  |
        ------------



                  Figure 4: An Example of DRPC Procedure

   Workflows:

      (1) PCC sends a PCReq message to the Source PCE, requesting an
      end-to-end explicit route.

      (1.1) Source PCE sends a PCReq message to Parent PCE, requesting a
      PCE Sequence.

      (1.2) Parent PCE sends a PCReq message to Source PCE, replying the
      PCE Sequence.

      (2a) Once PCE(1) obtained the PCE Sequence by some means, it sends
      a PCReq message to PCE(2), asking for PCE(2) to relay this message
      to the Destination PCE.  It expects the Destination PCE to compute
      VSPT(1, 3).

      (2b) Once PCE(1) obtained the PCE Sequence by some means, it
      computes VSPT(0, 1) and encapsulate this VSPT into a PCRep
      message.  Then it sends this PCRep message to PCE(2) to launch a
      VSPT(0, 2) computation.






Fu, et al.                Expires March 3, 2012                [Page 14]

Internet-Draft               DRPC Procedure                  August 2011


      (3a) Having received a PCReq message from PCE(1), PCE(2) sends a
      PCReq message to PCE(3), asking for PCE(3) to relay this message
      to the Destination PCE.

      (3b) Having received a PCReq message from PCE(2) and checked that
      the Destination PCE is itself, PCE(3) computes VSPT(1, 3) and
      encapsulate this VSPT into a PCRep message.  Then it sends this
      PCRep message to PCE(2) to launch a VSPT(1, 2) computation.

      (4) The Stiching PCE stitches VSPT(0, 2) and VSPT(1, 2) into a
      VSPG(2).  It may either select a shortest path from this VSPG and
      encapsulate it into a PCRep message or it may encapsulate the VSPG
      into a PCRep message.  No matter which strategy is chosen, it
      sends back the PCRep message to PCE(1), the neighbor PCE along the
      upstream direction, expecting that PCE to relay this PCReq message
      to the Source PCE.

      (5) Having received a PCRep message from PCE(2) and checked that
      the Source PCE is itself, PCE(1) returns the final ERO to PCC by
      sending a PCRep message.  If the received PCRep message contains a
      VSPG, PCE(1) selects the shortest path from the VSPG, or else
      PCE(1) relays the received PCRep message to PCC directly.

   If the parent PCE which maintains the domain topology map of the
   child domains and their interconnectivity does not exist, the PCE
   sequence can be predetermined by other means such as administrative
   configuration, Network Management System(NMS)designated, non-shortest
   path computation without regard to detailed TE attributes, and etc.
   This way, the (1.1) and (1.2) steps are skipped.


5.  PCEP Protocol Extension Requirements

   The two different DRPC procedures require the specification of new
   flags of the RP object carried within the PCReq message to specify
   that the shortest paths satisfying the constraints from the
   destination to the set of entry boundary nodes or from the source to
   the set of entry boundary nodes are requested.

   Note that IANA has already defined Bit 25 of the flags in RP Object
   for VSPT.

   The following new flags of the RP object is defined:








Fu, et al.                Expires March 3, 2012                [Page 15]

Internet-Draft               DRPC Procedure                  August 2011


   Bit Number       Name Flag

   16               VSPG

   When Bit 16 is set, it enables VSPG encoding in ERO, IRO, RRO, or XRO
   Object.  In PCReq message, when Bit 16 is set, it indicates that the
   Source PCE is response for path selection from VSPG rather than the
   Stitching PCE, which is defined in this document.  Bit 16 is valid
   under the assumption that bit 17 is valid.

   Bit Number       Name Flag

   17               DRPC VSPT Extension

   In PCReq Message:

   17               1: Request for DRPC Procedure

   In PCRep Message:

   17               0: from source PCE to Middle PCE for VSPT Extension

                    1: from destination PCE to Middle PCE for VSPT
                    Extension

   In PCReq message, when Bit 17 is set, it indicates that the PCC
   requests the computation of an inter-domain TE LSP using the DRPC
   procedure defined in this document.  In PCRep message Bit 17 is valid
   under the assumption that bit 25 is valid.

   Because path segments computed by the two end PCEs in the context of
   the DRPC 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.  VSPG Encoding

   The VSPG encoding objects must be returned within a PCRep message.
   The encoding consists of a non-ordered list of Explicit Route Objects
   (EROs) where each ERO represents a path from the source node to the
   destination node specified in the END-POINT object of the
   corresponding PCReq message from PCC to Source PCE.

   Example:





Fu, et al.                Expires March 3, 2012                [Page 16]

Internet-Draft               DRPC Procedure                  August 2011


     <---- area 1 -----><-------- area 2 ---------><----- area 3 ------>
      +--A--B---BNex1-1--BNen2-1---E---F---BNex2-1--BNen3-1---K----L--+
      |                                                               |
      |                                                               |
      S----C----BNex1-2--BNen2-2---G---H---BNex2-2--BNen3-2-----M-----D
                                   |                                  |
                                   |                                  |
                                   +---J---BNex2-3--BNen3-3---N----P--+
                                             |                     |
                                             |                     |
                                             +------BNen3-4---Q----+




         Figure 5: An Example of VSPG Encoding Using a Set of EROs

   In the example shown in Figure 5, along the direction from the source
   node S to the destination node D, when the Stitching PCE completes
   the path computation and the Source PCE expects a VSPG to select the
   optimal path in it, four non-ordered EROs are transferred to PCE(1).
   The four EROs are as follows:

   ERO[1]:  S---A---B---BN-ex(1,1)---BN-en(2,1)---E---F---BN-ex(2,1)---
            BN-en(3,1)---K---L---D

   ERO[2]:  S---C---BN-ex(1,2)---BN-en(2,2)---G---H---BN-ex(2,2)---BN-
            en(3,2)---M---D

   ERO[3]:  S---C---BN-ex(1,2)---BN-en(2,2)---G---J---BN-ex(2,3)---BN-
            en(3,3)---N---P---D

   ERO[4]:  S---C---BN-ex(1,2)---BN-en(2,2)---G---J---BN-ex(2,3)---BN-
            en(3,4)---Q---P---D

   Note that the (BN-ex, BN-en) pair can either be a pair of interfaces
   on a single ABR or two detached TE-Routers in different domains.  In
   both cases they should be encoded to ERO sub-object specified in
   [RFC3209].


7.  DRPC Procedure Failures

   If the DRPC procedure cannot be completed because a PCE along the
   domain does not recognize the procedure (VSPG flag of the RP object),
   the PCE sends a PCErr message to the parent PCE with an Error-Type=4
   (not supported object), Error-value-4 (Unsupported parameter).  Then
   the parent PCE sends the failure message to the other PCEs along the



Fu, et al.                Expires March 3, 2012                [Page 17]

Internet-Draft               DRPC Procedure                  August 2011


   PCE chain.  The corresponding path computation request is then
   cancelled by the PCE without further notification.  The PCErr message
   must be relayed to the requesting PCC by the source PCE.

   PCEP-ERROR objects are used to report a PCEP protocol error and are
   characterized by an Error-Type which 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.
   A new Error-Type and the corresponding error value are defined here.

   Error-type       Meaning

   14               DRPC procedure completion failure

   Error-value      Meaning

   1                DRPC procedure not supported by one or more PCEs
                    along the domain path


8.  Path Computation Failures

   If a PCE requires to relay a path computation request according to
   the DRPC procedure defined in this document to a downstream PCE and
   no such PCE is available, the PCE MUST cancel all the procedures of
   path computation on all the other PCEs along the PCE chain through
   the Source PCE, and send a path computation reply to the PCC using a
   PCRep message that contains a NO-PATH object.  In such case, the NO-
   PATH object MUST carry a NO-PATH-VECTOR TLV with the newly defined
   bit named "DRPC Path Computation chain unavailable" set.

   Different from BRPC using bit 28, Bit 23 is defined here.

   Bit Number       Name Flag

   23               DRPC Path computation chain unavailable


9.  Security Considerations

   TBD.


10.  IANA Consideration







Fu, et al.                Expires March 3, 2012                [Page 18]

Internet-Draft               DRPC Procedure                  August 2011


10.1.  New Flags Of The RP Object

   New flags Of The RP Object is defined in this document (VSPG and
   VSPT-DRPC-Extension to be assigned by IANA).

   Bit Number       Name Flag

   16               VSPG

   17               DRPC VSPT Extension

   In PCReq Message:

   17               1: Request for DRPC Procedure

   In PCRep Message:

   17               0: from source PCE to Middle PCE for VSPT Extension

                    1: from destination PCE to Middle PCE for VSPT
                    Extension

   Bit 16 is valid under the assumption that bit 17 is valid.

   Bit 17 is valid under the assumption that bit 25 is valid in PCRep
   message.

10.2.  New Error-Type and Error-Value

   A new Error-Type is defined in this document (Error-Type and Error-
   value to be assigned by IANA).

   Error-type       Meaning

   14               DRPC procedure completion failure

   Error-value      Meaning

   1                DRPC procedure not supported by one or more PCEs
                    along the domain path

10.3.  New Flag Of The NO-PATH-VECTOR TLV

   A new flag of the NO-PATH-VECTOR TLV defined in is specified in this
   document.(Bit 23 to be assigned by IANA)






Fu, et al.                Expires March 3, 2012                [Page 19]

Internet-Draft               DRPC Procedure                  August 2011


   Bit number       Name Flag

   23               DRPC Path computation chain unavailable


11.  Acknowledgments

   The RFC text was produced using Marshall Rose's xml2rfc tool.


12.  Normative References

   [I-D.ietf-pce-hierarchy-fwk]
              King, D. and A. Farrel, "The Application of the Path
              Computation Element Architecture to the Determination of a
              Sequence of Domains in MPLS & GMPLS", December 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFC's to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC4665]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5441]  Vasseur, J., Zhang, R., Bitar, N., and JL. Le Roux, "A
              Path Computation Element (PCE)-Based Architecture",
              RFC 5441, April 2009.

   [RFC5521]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
              Path Computation Element Communication Protocol (PCEP) for
              Route Exclusions", RFC 5521, April 2009.


Authors' Addresses

   Xihua Fu
   ZTE Corporation
   West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
   Xi'an  710065
   P.R.China

   Phone: +8613798412242
   Email: fu.xihua@zte.com.cn
   URI:   http://www.zte.com.cn/








Fu, et al.                Expires March 3, 2012                [Page 20]

Internet-Draft               DRPC Procedure                  August 2011


   Yuanlin Bao
   ZTE Corporation
   5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road
   Nanshan District
   Shen Zhen  518055
   P.R.China

   Phone: +86 755 26773731
   Email: bao.yuanlin@zte.com.cn
   URI:   http://www.zte.com.cn/


   Yongli Zhao
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8613811761857
   Email: yonglizhao@bupt.edu.cn
   URI:   http://www.bupt.edu.cn/


   Jie Zhang
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8613911060930
   Email: lgr24@bupt.edu.cn
   URI:   http://www.bupt.edu.cn/


   Yuan Gu
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8613466734941
   Email: josephstrauss@yahoo.com.cn
   URI:   http://www.bupt.edu.cn/








Fu, et al.                Expires March 3, 2012                [Page 21]