Network Working Group XH. Fu Internet-Draft YL. Bao Intended status: Informational ZTE Corporation Expires: March 2, 2011 YL. Zhao J. Zhang BUPT August 29, 2010 A Dual-end Recursive PCE-based Computation (DRPC) Procedure to Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths draft-fuxh-pce-drpc-01 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 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Fu, et al. Expires March 2, 2011 [Page 1] Internet-Draft DRPC Procedure August 2010 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. Mode of Operation in Stitching PCE Selection by PCE Designation . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Mode of Operation in Stitching PCE Selection via PCEP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 5. PCEP Protocol Extension Requirements . . . . . . . . . . . . . 14 6. VSPG Encoding . . . . . . . . . . . . . . . . . . . . . . . . 15 7. DRPC Procedure Failures . . . . . . . . . . . . . . . . . . . 16 8. Path Computation Failures . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 17 10.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 17 10.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 17 10.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Fu, et al. Expires March 2, 2011 [Page 2] Internet-Draft DRPC Procedure August 2010 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 shortest path [RFC5441]. During the procedure of BRPC, a PCE sequence should be pre-determined. Recently, a hierarchical PCE architecture is designed to determine the PCE sequence needed in BRPC procedure [I-D.ietf-pce-hierarchy- fwk]. However, when there is a large number of PCEs in the predetermined PCE sequence, the path computation time may be long for the customer, and the long PCE chain is more vulnerable. A dual-end recursive PCE-based computation procedure (DRPC) is proposed to compute shortest constrained inter-domain traffic engineering label switched paths. 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. Boundary Node (BN): a boundary node is either an ABR in the context Fu, et al. Expires March 2, 2011 [Page 3] Internet-Draft DRPC Procedure August 2010 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 in the PCE sequence which is neither Source PCE nor 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. Upstream: In backward direction, from Destination PCE to Source PCE. Fu, et al. Expires March 2, 2011 [Page 4] Internet-Draft DRPC Procedure August 2010 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 PCE sequence has to be predetermined before DRPC procedure is launched, which corresponds to domain path selection. The PCE/domain path may be either administratively predetermined or discovered by some means outside of the scope of this document. A hierarchical PCE architecture is highly recommended which is proposed in [I-D.ietf-pce-hierarchy-fwk]. In the hierarchical PCE Fu, et al. Expires March 2, 2011 [Page 5] Internet-Draft DRPC Procedure August 2010 architecture, a Parent (hierarchical) PCE maintains a domain topology map. The domain topology map contains the domains and their interconnections, but has no information about the contents of the domains. Each domain has a PCE responsible for computing paths across it. These PCEs are known as Child PCEs and have a relationship with the Parent PCE. Each Child PCE also knows the identity of the border nodes and links of its adjacent domains The Parent PCE learns from configuration or from each Child PCE how the domains are interconnected including the traffic engineering (TE) capabilities of domain interconnections, but does not know the contents of the domains. When the ingress PCE receives a path computation request from the source node, and the destination is outside of the ingress domain, the ingress PCE will send a path computation request(PCReq Message) to the parent PCE. The parent PCE computes a domain path based on the current domain topology. The Parent PCE selects candidate domain paths; it then sends computation requests and the PCE sequence information to the source PCE and the destination PCE on the PCE sequence. 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. 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): Fu, et al. Expires March 2, 2011 [Page 6] Internet-Draft DRPC Procedure August 2010 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 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, affinities, 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 that of VSPT(1,i). VSPT(0,i): P2MP (point-to-multipoint) tree returned by PCE(i) to PCE(i+1): Root (TE LSP source) / | \ 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 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) and the TE LSP source that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.). These are path segments to reach BN-en(j,i) from the TE LSP source. Different from BRPC, when there is a path computation request arriving and the PCE sequence which will take part in the path computation has been fixed, 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 directons. 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 Fu, et al. Expires March 2, 2011 [Page 7] Internet-Draft DRPC Procedure August 2010 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, a pre-determined PCE sequence should also be designated before DRPC. 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. VSPT(0, i-1) is 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 stitched by the two directional shortest path tree gained above. The former represents the directional shortest path graph computed from source node to the Entry BN of the middle domain, and the later represents the directional shortest path graph computed from destination PCE to the Entry BN of the middle domain. Or the former represents the directional shortest path graph computed from source node to the Entry BN of the domain next to the middle domain, and the later represents the directional shortest path graph computed from destination PCE to the Entry BN of the domain next to the middle domain. In the first case, the middle PCE completes the VSPG(0,i) including the path computation in the local domain, and then stitched the two directional shortest path graphs together. In the second case, the middle PCE completes the VSPG(1,i) including the path computation in the local domain, and then stitched the two directional shortest path graphs together. 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 either be designated by (1) Parent PCE/Source PCE before DRPC procedure or by (2) automatic selection in PCEP signaling procedure. Fu, et al. Expires March 2, 2011 [Page 8] Internet-Draft DRPC Procedure August 2010 4.3. Mode of Operation in Stitching PCE Selection by PCE Designation In the case of (1), the following steps are described as follows. Denote that PCE(1) is the Source PCE, PCE(m) the Stitching PCE, and PCE(n) 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,1) 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)(PCReq transferred PCE-by-PCE upstream from the Source PCE), or PCE(1) directly. 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(0,i) to PCE(i+1). Step m: 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+1) and VSPT(1,m+1) which is returned from PCE(m+1) into a VSPG. Two strategies are permitted to return the shortest path back to PCC. Fu, et al. Expires March 2, 2011 [Page 9] Internet-Draft DRPC Procedure August 2010 o PCE(m) transfers the newly stitched directional shortest path graph to the Source PCE. Source PCE generates the shortest path and returns it back to PCC. The non-shortest paths are deleted at the Source PCE. o PCE(m) transfers the computed shortest path to the Source PCE in PCReq message and the Source PCE returns it back to PCC. The non- shortest paths are deleted at the Stitching PCE. The PCReq message can be either transferred from the Stitching PCE to the Source PCE upstream PCE-by-PCE, or to the Source PCE directly via TCP connection. If n=2, the source domain and the destination domain are directly interconnected each other. The Stitching PCE MUST be specified as the Source PCE where step i is omitted. 4.4. Mode of Operation in Stitching PCE Selection via PCEP Signaling Denote that PCE(1) is the Source PCE and PCE(n) the Destination PCE. In the case of (2), every PCE transfers VSPT to the next PCE without knowing a fixed Stitching PCE. So, the Stitching PCE is selected automatically in PCEP signaling procedure where PCReq messages upstream and downstream meet each other and there are three scenarios. Scenario (1): PCE(i) and PCE(i+1) receive PCReq messages with 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, as is shown in Fig.4. Fu, et al. Expires March 2, 2011 [Page 10] Internet-Draft DRPC Procedure August 2010 PCE(i-1) PCE(i+2) \ / PCReq \ / PCReq \ / PCE(i) PCE(i+1) \ / {Compute VSPT(0,i)} {Compute VSPT(1,i+1)} \ / \ / PCReq \ / \ / X / \ PCRep / \ / \ PCE(i) PCE(i+1) {Discard} / {Stitch into VSPG(i)} / / PCRep / / PCE(i-1) or PCE(1) Figure 4: Scenario(1) of Case(2) Scenario (2): PCE(i) receives a PCReq message with VSPT(1,i+1) after it has received a PCReq message with 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), as is shown in Fig.5. Fu, et al. Expires March 2, 2011 [Page 11] Internet-Draft DRPC Procedure August 2010 PCE(i+2) / / PCReq / PCE(i-1) PCE(i+1) \ / PCReq \ / \ {Compute VSPT(1,i+1)} PCE(i) / | / {Compute VSPT(0,i)}/ PCReq | / K | \ | \ | \ PCReq {Stitch into VSPG(i)}\ / \ / PCE(i+1){Discard} PCRep / / PCE(i-1) or PCE(1) Figure 5: Scenario(2) of Case(2) Scenario (3): PCE(i+1) receives a PCReq message with VSPT(0,i) after it has received a PCReq message with VSPT(1,i+2), and it is unable to stop sending PCReq with 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), as is shown in Fig.6. Fu, et al. Expires March 2, 2011 [Page 12] Internet-Draft DRPC Procedure August 2010 PCE(i-1) \ PCReq \ PCE(i+2) \ / PCE(i) / PCReq \ / {Compute VSPT(0,i)} PCE(i+1) \ | \ | \ {Compute VSPT(1,i+1)} PCReq \ | \ | {Discard} / / PCReq / / / PCE(i) {Stitch into VSPG(i)} / / PCRep / / PCE(i-1) or PCE(1) Figure 6: Scenario(3) of Case(2) The following steps are described as follows to deal with these three situations in a uniform procedure. Denote that PCE(m) is the intersection representing the Stitching PCE. Step i: (Downstream) For i=1 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 PCReq from PCE(i+1) which contains 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). Step i: (Upstream) For i=n to m: 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 Fu, et al. Expires March 2, 2011 [Page 13] Internet-Draft DRPC Procedure August 2010 VSPT(1,i+1) and its own TED. PCE(i) returns the computed VSPT(0,i) to PCE(i+1). If PCE(i) has already received a valid PCReq from PCE(i-1) which contains VSPT(0,i), it computes VSPT(0,i+1) and transfer the VSPT(0,i+1) to PCE(i+1). Once a valid PCReq message received from PCE(i+1) upstream after receiving PCReq from PCE(i-1), PCE(i) stitches these two VSPTs into a VSPG(i). Two strategies are permitted to return the shortest path back to PCC. o PCE(i) transfers the newly stitched directional shortest path graph in PCRep message to the Source PCE. Source PCE generates the shortest path and returns it back to PCC. The non-shortest paths are deleted at the Source PCE. o PCE(i) transfers the computed shortest path to the Source PCE in PCRep message and the Source PCE returns it back to PCC. The non- shortest paths are deleted at the Stitching PCE. The PCRep message can be either transferred from the Stitching PCE to the Source PCE upstream PCE-by-PCE, or to the Source PCE directly via TCP connection. These are identical with case (1). 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. The following new flags of the RP object is defined: VSPG Flags Bit Number Name Flag 23 VSPG 24 0: from source PCE to middle PCE 1: from destination PCE to middle PCE Bit 24 is valid under the assumption that bit 23 is valid When set, the VSPG Flags indicates that the PCC requests the Fu, et al. Expires March 2, 2011 [Page 14] Internet-Draft DRPC Procedure August 2010 computation of an inter-domain TE LSP using the DRPC procedure defined in this document. 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 VSPG encoding objects must be contained in the PCRep request messages, which consist of a non-ordered list of EROs where each ERO represents a path segment from a BN to the destination node or the source node specified in the END-POINT object of the corresponding PCReq message. Different from VSPT encoding in RFC5441, there are two kinds of objects in VSPG encoding, which are the path segment object from the BNs to the source, and the path segment object from the BNs to the destination. Besides, some nodes can appear twice in the two objects. As shown in Fig.7, along the direction from the source node to the destination node, when PCE1 completes the path computation in the local domain, three forward non-ordered EROs are transferred to PCE2. The three EROs are as follows: o ERO_F1: S(TE Router ID)-A(Interface IP address)-B(Interface IP address)-ABRen2-1(TE Router ID) o ERO_F2: S(TE Router ID)-C(Interface IP address)-ABRen2-2(TE Router ID) o ERO_F3: S(TE Router ID)-ABRen2-3(TE Router ID) PCE1 PCE2 PCE3 -------area1-------|------area2-------|-----area3------ ---A---B---ABRen2-1 ABRen3-1---E--- | | | | S----C-----ABRen2-2 ABRen3-2------D | | | | -----------ABRen2-3 ABRen3-3--F-G-- Figure 7: An Example of VSPG Encoding Using a Set of EROs Along the direction from the destination node to the source node, Fu, et al. Expires March 2, 2011 [Page 15] Internet-Draft DRPC Procedure August 2010 when PCE3 completes the path computation in the local domain, three backward non-ordered EROs are transferred to PCE2. The three EROs are as follows: o ERO_B1: ABRen3-1 (TE Router ID)-E(Interface IP address)-D(TE Router ID) o ERO_B2: ABRen3-2 (TE Router ID)-D(TE Router ID) o ERO_B3: ABRen3-3 (TE Router ID)-F(Interface IP address)- G(Interface IP address)-D(TE Router ID) 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 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 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 parent 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- Fu, et al. Expires March 2, 2011 [Page 16] Internet-Draft DRPC Procedure August 2010 PATH object MUST carry a NO-PATH-VECTOR TLV with the newly defined bit named "DRPC Path Computation chain unavailable" set. Different from BRPC, bit 5 is defined here. Bit number Name Flag 5 DRPC Path computation chain unavailable 9. Security Considerations TBD. 10. IANA Consideration 10.1. New Flags Of The RP Object A new flag of the RP object is defined in this document, which contains 2 bits. VSPG Flags Bit Number Name Flag Reference 23 VSPG 24 0: from source PCE to middle PCE this document 1: from destination PCE to middle PCE Bit 24 is valid under the assumption that bit 23 is valid 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 Reference 14 DRPC procedure completion failure this document Error-value 1: DRPC procedure not supported by one or more PCEs along the domain path Fu, et al. Expires March 2, 2011 [Page 17] Internet-Draft DRPC Procedure August 2010 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 number Name Flag Reference 5 DRPC Path computation chain unavailable this document 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. 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 2, 2011 [Page 18] Internet-Draft DRPC Procedure August 2010 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/ Fu, et al. Expires March 2, 2011 [Page 19]