Internet Engineering Task Force K. Li Internet-Draft X. Tu Intended status: Standards Track Z. Fu Expires: July 3, 2012 ZTE Corporation December 31, 2011 Hierachical PCE Extensions for Inter-Domain Point-to-Multipoint Path Computation draft-li-pce-hierarchical-pce-p2mp-path-00 Abstract The hierachical Path Computation Element (PCE) architecture defined in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the hierachical PCE (H-PCE) extensions for the purpose of implementing inter-domain P2MP Path Computation. 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 July 3, 2012. Copyright Notice 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 Li, et al. Expires July 3, 2012 [Page 1] Internet-Draft H-PCE Extensions for P2MP Path December 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Li, et al. Expires July 3, 2012 [Page 2] Internet-Draft H-PCE Extensions for P2MP Path December 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architectural Protocol Overview . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Child PCE Responsibility . . . . . . . . . . . . . . . . . 7 3.3. Parent PCE Responsibility . . . . . . . . . . . . . . . . 7 3.4. Multi-layer H-PCE . . . . . . . . . . . . . . . . . . . . 8 3.5. Inter-domain TE Link . . . . . . . . . . . . . . . . . . . 9 4. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 10 4.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 11 4.3. PCNtf Message . . . . . . . . . . . . . . . . . . . . . . 12 4.4. PCErr Message . . . . . . . . . . . . . . . . . . . . . . 13 5. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Inter-domain Capability Advertisement . . . . . . . . . . 15 5.2. Preserving Topology Confidentiality . . . . . . . . . . . 15 5.3. Extensions to END-POINTS Object . . . . . . . . . . . . . 15 5.4. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 17 5.5. Extensions to Unreach-Destination Object . . . . . . . . . 17 5.6. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6.1. OSPF PCE Capability Flag . . . . . . . . . . . . . . . . . 20 6.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Li, et al. Expires July 3, 2012 [Page 3] Internet-Draft H-PCE Extensions for P2MP Path December 2011 1. Introduction [RFC4655] describes the motivations and architecture for a Path Computation Element (PCE) based model for the computation of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). [PCE-HIERARCHY-FWK] defined a hierachical Path Computation Element (H-PCE) architecture allows the optimum sequence of domains to be selected, and the optimum end-to-end inter-domain path to be derived through the use of a hierarchical relationship between domains. This document specifies the inter-domain P2MP path computation methods. Inter-domain P2MP is comprised of multiple source-to-leaf sub-LSPs. These S2L sub-LSPS are set up between the ingress and egress LSRs, and may located in different domain or autonomous system. Li, et al. Expires July 3, 2012 [Page 4] Internet-Draft H-PCE Extensions for P2MP Path December 2011 2. Terminology AS: Autonomous System, A collection of connected routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet. ASBR: Autonomous System Border Router. Routers used to connect together ASes of the same or different service providers via one or more inter-AS links. BN: Boundary Node, 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. Child PCE: A PCE responsible for computing the path across one or more specific (child) domains. A child PCE maintains a relationship with at least one parent PCE. Parent PCE: A PCE responsible for selecting a path across a parent domain and any number of child domains by coordinating with child PCEs and examining a topology map that shows domain inter- connectivity. PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element. An entity that is capable of computing a network path or route based on a network graph and applying computational constraints. H-PCE: Hierarchical PCE. A parent PCE maintains a domain topology map that contains the child domains and their interconnections (links in the topology). Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a path. Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a path. Li, et al. Expires July 3, 2012 [Page 5] Internet-Draft H-PCE Extensions for P2MP Path December 2011 3. Architectural Protocol Overview 3.1. Overview This docment provids a method which uses H-PCE to compute an optimal P2MP path. The parent PCE floods path computation requests from the ingress domain which contains the ingress node to adjacent domains, child PCE which serves the domain receives the path computation requests, finishes the computation and replys the results to the parent PCE. After computation of all domains, the parent PCE completes the path computation of the whole P2MP tree. Procedure is as follows: 1. PCC sends P2MP path computation request to child PCE. The request message must contain information of leaf nodes, type and other attributes of the P2MP tree. 2. Child PCE find that the message is a inter-domain P2MP path computation request, and transmits it to its parent PCE. 3. The parent PCE treats the ingress domain which contains the ingress node of the inter-domain P2MP tree as currently processing domain, and treats the ingress node as root node, the BNs of this domain and leaf nodes in this domain as leaf nodes, then the parent PCE sents a path computation request to a child PCE which serves the domain. 4. The child PCE which receives the path computation request from the parent PCE will select a optimal path computation request to compute path to every leaf nodes and finally reply optimized computation results to the parent PCE. 5. The parent PCE receives path segments computation results, combines these results into a P2MP path tree, this P2MP tree's root is ingress node and leaf nodes are BNs of the domain and leaf nodes of this trees that have been computed. Then the parent PCE decides next domains need to be flooded and sends path computation requests to them. 6. The corresponding child PCEs that receive the path computation requests from the parent PCE process as step 4. 7. If the path segments computation results is null, or if there isn't any next domain need to be flooded, then current path computation is completed, the parent PCE should repond the completed inter-domain P2MP path to its child PCE. Otherwise, the parent PCE should send path computation requests to child PCEs in next domains, just as process in step 5. Li, et al. Expires July 3, 2012 [Page 6] Internet-Draft H-PCE Extensions for P2MP Path December 2011 8. Child PCEs reply the ultimately path computation result to PCC. 3.2. Child PCE Responsibility Each child PCE is responsible for one domain, computing path segment in the domain and replying computation result to its parent PCE. Child PCE's main work is detailed as follows. Child PCE should receive path computation request which is sent by PCC, and decide the path computation request, if the path is inter- domain type, then child PCE should transmit the path computation request to its parent PCE. Child PCE then receive path segment computation request, according to content of the request message, compute path segment in the domain, and reply optimal result to its parent PCE. Child PCE should receive path computation result from its parent PCE, and transmit it to PCC. In the actual network application scenario, the connection among domains may be very complex, especially when the connection among domains is full mesh. So child PCE may receive more than one path computation requests. When child PCE receives more than one requests, it should process those requests according to following rules. If child PCE receives more than one path computation requests for a number of different root nodes in the same flooding process, the child PCE should compute path for each request, then decide all the computation results and give an optimal sub-S2L LSP for each leaf node, reply those results to its parent PCE. If child PCE receives more than one path computation requests for a number of different root nodes in different flooding processes, the child PCE only need to process latest request and reply computation result to its parent PCE. If child PCE receives more than one path computation requests for the same root node in the same flooding process, the child PCE only need to process the request which has the smallest cost to root node, and reply computation result to its parent PCE. If child PCE receives more than one path computation requests for the same root node in different flooding processes, the child PCE should decide cost to root node in the later received path computation request is smaller; if yes, the child PCE should re-compute path to each leaf node and reply computation result to its parent PCE. 3.3. Parent PCE Responsibility Parent PCE is mainly responsible for flooding path computation requests to neighbor domains, summarizing path computation results from its child PCEs, and deciding the whole computation process. First, parent PCE receives inter-domain path computation request Li, et al. Expires July 3, 2012 [Page 7] Internet-Draft H-PCE Extensions for P2MP Path December 2011 which is sent by its child PCE, finds the domain that has ingress node of the P2MP tree that to be computed, finds ingress nodes(BNs) and leaf nodes of this domain, then sends path segment computation request to this child PCE. After sending the computation request, parent PCE should wait for computation result from child PCE, and decide next neighbor domains that should be flooded, find ingress nodes and leaf nodes of those domains, send path segment computation requests to them. If parent PCE decides the path computation is complete, it should end the computation process and send result to the child PCE which request inter-domain path computation. In complex scenario, parent PCE maybe receive different computation results from the same child PCE, then parent PCE should process those results according to following rules. For each BN, parent PCE should decide if the cost to the BN in the later received computation result is better than cost value exists in parent PCE; if so, parent PCE should flood the BN's neighgor domains in next flooding process; otherwise, parent PCE should desert the later received computation result without any further process. In each flooding process to next domains, parent PCE should first estimate the entry BN of next domains haven't been flooded; if so, parent PCE continue to send computation requests to next domains; otherwise, parent PCE shouldn't send any request to next domains, and parent PCE only need to update corresponed cost values in parent PCE. After that, parent PCE should decide again that if is there need to send computation requests to the next domain's next domains. If every possible path of each domains has been computed, or if there isn't better result given by child PCE, parent CPE can decide the path computation is complete. 3.4. Multi-layer H-PCE H-PCE may have more than two layers in actual scenario, it could nest more layers, neighbor layers are parent and child, such as Figure 1. Li, et al. Expires July 3, 2012 [Page 8] Internet-Draft H-PCE Extensions for P2MP Path December 2011 +----+ --|PCE3| / +----+ +----+ / -- |PCE2|-- / +----+ +----+ / -- |PCE1|-- / +----+ +---+ / |PCC|-- +---+ Figure 1: Multi-Layer H-PCE Example In Figure 1, there are three layers. For one PCE layer, it treats its up PCE as parent PCE and treats its down layer as PCC. it only has communication with its up layer. For PCE1 in Figure 1, PCE2 is parent PCE, when PCE1 receives path computation request from PCC, it will transmit the request to parent PCE(i.e. PCE2). For PCE2 in Figure 1, it treats PCE1 as PCC, and treats PCE3 as parent PCE, when it receives path computation request from PCE1, it will transmit the request to parent PCE(i.e. PCE3).If PCE3 receives path computation request, it will send intra-domain path computation request to PCE2(PCE3's child PCE), and PCE2 will break down the request and send new request to PCE1(PCE2's child PCE). Then, PCE1 will compute path and reply to PCE2. 3.5. Inter-domain TE Link BNs of different domains are connected through TE link, such as: --------- Transit --------- |Domain1|---------|Domain2| --------- Link --------- Figure 2: TE Link Example When PCE computes path of a P2MP tree, parent PCE should consider attributes of TE link as constraints. Li, et al. Expires July 3, 2012 [Page 9] Internet-Draft H-PCE Extensions for P2MP Path December 2011 4. Messages Format 4.1. PCReq Message The PCEP Path Computation Request message (PCReq Message) is a PCEP message sent by a PCC or PCE to request a path computation. A PCReq message may carry more than one path computation request. As in inter-domain scene, the overlap of addressing space should be considered, and it should use the newly defined END-POINTS object as in section 5.3. Also, the request message must contain the cost which the ingress node(or what we called root node of the P2MP path) associated, so there is a METRIC-LIST object followed each END-POINTS object. PCReq Message format defined as follows: ::= [] where: ::=[] ::=[] For supporting of PATH-KEY, defined as follows: ::= | ::= [] [] [] [] [] [] ::= where: ::= [][] [] ::= [][] ::= [] Li, et al. Expires July 3, 2012 [Page 10] Internet-Draft H-PCE Extensions for P2MP Path December 2011 Extension to [PCE-HIERARCHY-FWK], PCReq Message can be send by PCC to child PCE to initialize a inter-domain p2mp path computation, and can be transfered by child PCE to parent PCE, and parent PCE can also send PCReq message to child PCE for the inner domain sub path result. For supporting of preserving topology confidentiality between each domain, request object is extended to support Path-Key mechanism. The usage is specified in [RFC5520] 4.2. PCRep Message The PCEP Path Computation Reply message (PCRep Message) is a PCEP message in response to a previously received PCReq message. A PCRep message may contain a set of computed paths corresponding to either a single path computation request or multiple path computation requests, each computed path must followed by a METRIC object to indicate the path's cost. Because of it should preserving topology information leak into other domain, when child PCE reply P2MP path segment to parent PCE, the PATH object should use loose hops, or Path-Key described in [RFC5520] The PCRep message format defined as follows: Li, et al. Expires July 3, 2012 [Page 11] Internet-Draft H-PCE Extensions for P2MP Path December 2011 ::= where: ::= [] ::= [] [] [] where: ::= [] | [] ::= (|) [] ::= [] ::=[] [] [] [] [] Note that we add Metric object after each ERO/SERO and PATH-KEY object. At least one instance of Metric MUST BE present in each path or path-key-expansion. 4.3. PCNtf Message The PCNtf Message is send by a PCC or a PCE to notify of a specific event. The PCNtf Message MUST carry at least one NOTIFICATION object. The format of NOTIFICATION object is as follows: Li, et al. Expires July 3, 2012 [Page 12] Internet-Draft H-PCE Extensions for P2MP Path December 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | NT | NV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: NOTIFICATION Object Body Format We need to add new notification types in inter-domain scene, which defined as follows: Notification-type=3, Notification-value=1: Parent PCE update request metric to child PCE. It indicates that parent PCE wants to inform a child PCE that the path computation request before should update the metric contains in the message. Such an event could be triggered when the parent PCE request child PCE to computate a P2MP path segment, but have not return the result yet, parent PCE can use this NOTIFICATION object to renew the child PCE's metric, when child PCE reply the last result, it can do the path computation according to newest metric. 4.4. PCErr Message The PCErr message is sent by a PCC or a PCE in response to a request or in an unsolicited manner. A PCErr message MUST contain a PCEP- ERROR object specifying the PCEP error condition. The PCEP-ERROR object is defined as follows (defined in [RFC5440]): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | Error-Type | Error-value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PCEP-ERROR Object Body Format For each PCEP error, an Error-Type and an Error-value are defined. Li, et al. Expires July 3, 2012 [Page 13] Internet-Draft H-PCE Extensions for P2MP Path December 2011 We need to add new error type as follows: When Error-Type=5, Error-value=3, reception of messages where K bit in RP object is setted, but not supported When Error-Type=6, Error-value=3, reception of messages with no metric object Li, et al. Expires July 3, 2012 [Page 14] Internet-Draft H-PCE Extensions for P2MP Path December 2011 5. Object Format 5.1. Inter-domain Capability Advertisement [RFC6006] use the OSPF PCE capability Flags in PCE Discovery TLV to indicate the capability of P2MP computation. This document will use the same method, defines a new flag in the OSPF PCE Capability Flags to indicate the capability of inter-domain P2MP computation. PCEs wishing to advertise that they support inter-domain path computation will set this bit, as to inter-domain P2MP ,PCEs would set this bit and the bit 10 ([RFC6006]) accordingly. PCCs that do not understand those bit will ignore it. PCEs that do not support inter-domain will leave the bit clear (per the default behavior defined in [RFC5088] and [RFC5089]). 5.2. Preserving Topology Confidentiality A important element of inter-domain is that topology information is not shared between domains for scalability and confidentiality reasons. So the cooperating PCEs cann!_t exchange the actual path segments between each other in PCRep Messages. We can use loose hops described in [RFC3209]] to satisfy this requirement, or we can use PATH-KEY described in [RFC6006]. If loose hops are used, the TE LSPs are signaled as normal ([RFC3209]), and when a loose hop is encountered in the explicit route, it is resolved by performing a secondary path computation to reach the resource or set of resources identified by the loose hop. A Path-Key is a token that replaces a path segment in an explicit route. The Path-Key is encoded as a Path-Key Subobject (PKS) returned in the PCEP Path Computation Reply message (PCRep) ([RFC5440]). when a PATH-KEY is encountered in the signaling process, corresponding PCE will return the actural path segment continuing to set up the LSP, thus avoid the secondary path computation. After parent PCE computated the finally path and reply PCRep Message, the ERO and RRO contain in messge will only represented in loose hops or PATH-KEY format. 5.3. Extensions to END-POINTS Object P2MP END-POINT object is mainly used in PCReq Messages to specify path!_s source and destination. When using in inter-domain scene, there may be overlap in address space, so END-POINT object should expand to inter-domain mode, the object type should be newly defined. Li, et al. Expires July 3, 2012 [Page 15] Internet-Draft H-PCE Extensions for P2MP Path December 2011 END-POINTS Object-Class is 4. P2MP END-POINTS Object-Type is 3 for IPv4 and 4 for IPv6. And it should add type code for inter-domain IPV4 and inter-domain IPV6. We assume that 5 for inter-domain IPV4, and 6 for inter-domain IPV6. The format of the new inter-domian END-POINTS object body for IPv4 (Object-Type 5) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source domain | | Source IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain | | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain | | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Inter-domain P2MP END-POINTS Object Body Format for IPv4 The format of the new inter-domian END-POINTS object body for IPv6 (Object-Type 6) is as follows: Li, et al. Expires July 3, 2012 [Page 16] Internet-Draft H-PCE Extensions for P2MP Path December 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source domain | | | | Source IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domian | | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain | | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Inter-domain P2MP END-POINTS Object Body Format for IPv6 5.4. PCEP NO-PATH Indicator [RFC6006] defined No-Path Object used in PCRep Messages to communicate the reasons for not being able to find P2MP path, we need to defined one new bit in the NO-PATH-VECTOR TLV carried in it: Bit 25GBPo when set, the PCE indicateds that there is a reachability problem with subset of the inter-domain P2MP destinations. Optionally, the PCE can specify the destination or list of destinations that are not reachable using the UNREACH-DESTINATION object. 5.5. Extensions to Unreach-Destination Object [RFC6006] defined UNREACH-DESTINATION object to specify the list of unreachable destinations or has no-better path destinations. This object can present in PCRep messages, and the Object-Class is 28, Object-Type for IPV4 is 1, for IPV6 is2. We need to add Object-Type for inter-domain options, the type added list below: Li, et al. Expires July 3, 2012 [Page 17] Internet-Draft H-PCE Extensions for P2MP Path December 2011 UNREACH-DESTINATION Object-Class is 28. UNREACH-DESTINATION Object-Type for inter-domain IPv4 is 3. UNREACH-DESTINATION Object-Type for inter-domain IPv6 is 4. The format of the UNREACH-DESTIONATION object body for inter-domain IPV4 is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain | | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain | | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: UNREACH-DESTINATION Object Body for IPv4 The format of the UNREACH-DESTINATION object body for inter-domain IPV6 is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain (4 bytes) | | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination domain (4 bytes) | | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li, et al. Expires July 3, 2012 [Page 18] Internet-Draft H-PCE Extensions for P2MP Path December 2011 Figure 8: UNREACH-DESTINATION Object Body for IPv6 5.6. OPEN Object When a PCE does not advertise its inter-domain P2MP capability during discovery, it should be done during the Open Message exchange when the PCEP session is established. To satisfy this requirement, we need to extend the PCEP OPEN object by add a new optional TLV to indicate the PCE!_s capability to perform inter-domain P2MP path computations. OPEN object format defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Keepalive | DeadTimer | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: OPEN Object Body Format In optional TLVs, we add a new TLV type 0x07, to indicate the inter- domain P2MP path computation. Li, et al. Expires July 3, 2012 [Page 19] Internet-Draft H-PCE Extensions for P2MP Path December 2011 6. IANA Considerations 6.1. OSPF PCE Capability Flag As discussed in Section 5.1, a new OSPF Capability Flag is defined to indicate inter-domain path computation capability. IANA is requested to make the following allocation form the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry: Bit Description Reference 11 inter-domain path computation This I-D 6.2. PCEP TLV Type Indicators As discussed in Section 5.5, a new inter-domain P2MP capability TLV allows the PCE to advertise its inter-domain P2MP path computation capability. IANA is requested to make the following allocation from the "PCEP TLV Type Indicators" sub-registry: Value Description Reference 7 inter-domain P2MP capable This I-D Li, et al. Expires July 3, 2012 [Page 20] Internet-Draft H-PCE Extensions for P2MP Path December 2011 7. References 7.1. Normative References [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 and GMPLS", October 2011. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 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. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010. 7.2. Informative References [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010. Li, et al. Expires July 3, 2012 [Page 21] Internet-Draft H-PCE Extensions for P2MP Path December 2011 Authors' Addresses KeJun Li ZTE Corporation 6F, RD Building 3, ZTE Industrical Park, XiLi LiuXian Road Nanshan District, Shenzhen 518055 P.R.China Phone: +86 755 26773611 Email: li.kejun@zte.com.cn XiaoPing Tu ZTE Corporation 6F, RD Building 3, ZTE Industrical Park, XiLi LiuXian Road Nanshan District, Shenzhen 518055 P.R.China Phone: +86 755 26773624 Email: tu.xiaoping@zte.com.cn ZhenTao Fu ZTE Corporation No.50, RuanJian Avenue Yuhuatai District, Nanjing, Jiangsu P.R.China Phone: +86 25 88014227 Email: fu.zhentao@zte.com.cn Li, et al. Expires July 3, 2012 [Page 22]