Internet Engineering Task Force Q. Zhao Internet-Draft Huawei Technology Intended status: Standards Track Z. Ali Expires: April 25, 2011 T. Saad S. Sivabalan Cisco Systems D. King Old Dog Consulting R. Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya October 25, 2010 PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths draft-zhao-pce-pcep-inter-domain-p2mp-procedures-06 Abstract The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. 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 April 25, 2011. Zhao, et al. Expires April 11, 2011 [Page 1] Internet-Draft PCEP P2MP Procedures October 2010 Copyright Notice Copyright (c) 2010 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Objective Functions . . . . . . . . . . . . . . . . . . . . . 9 7. P2MP Path Computation Procedures . . . . . . . . . . . . . . . 9 7.1. Core Trees . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Core Tree Computation Procedures . . . . . . . . . . . . . 11 7.3. Sub Tree Computation Procedures . . . . . . . . . . . . . 12 7.4. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . 12 7.4.1. The Extension of RP Object . . . . . . . . . . . . . . 13 7.4.2. The PCE Sequence Object . . . . . . . . . . . . . . . 13 7.5. Relationship with Hierarchical PCE . . . . . . . . . . . . 15 7.6. Parallelism . . . . . . . . . . . . . . . . . . . . . . . 15 8. Manageability Considerations . . . . . . . . . . . . . . . . . 15 9. Control of Function and Policy . . . . . . . . . . . . . . . . 16 10. Information and Data Models . . . . . . . . . . . . . . . . . 16 11. Liveness Detection and Monitoring . . . . . . . . . . . . . . 16 12. Verifying Correct Operation . . . . . . . . . . . . . . . . . 16 13. Requirements on Other Protocols and Functional Components . . 16 14. Impact on Network Operation . . . . . . . . . . . . . . . . . 16 15. Security Considerations . . . . . . . . . . . . . . . . . . . 17 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18.1. Normative References . . . . . . . . . . . . . . . . . . . 17 18.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Zhao, et al. Expires April 25, 2011 [Page 2] Internet-Draft PCEP P2MP Procedures October 2010 1. Introduction Multicast services are increasingly in demand for high-capacity applications such as multicast Virtual Private Networks (VPNs), IP- television (IPTV) which may be on-demand or streamed, and content- rich media distribution (for example, software distribution, financial streaming, or data-sharing). The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. A domain can be defined as a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. The applicability of the Path Computation Element (PCE) [RFC4655] for the computation of such paths is discussed in [RFC5671], and the requirements placed on the PCE communications Protocol (PCEP) for this are given in [RFC5862]. This document describes how multiple PCE techniques can be combined to address the requirements. These mechanisms include the use of the per-domain path computation technique specified in [RFC5152], extensions to the backward recursive path computation (BRPC) technique specified in [RFC5441] for P2MP LSP path computation in an inter-domain environment, and a new procedure for core-tree based path computation defined in this document. These three mechanisms are suitable for different environments (topologies, administrative domains, policies, service requirements, etc.) and can also be effectively combined. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology Terminology used in this document is consistent with the related MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875], [RFC5376], [RFC5440], [RFC5441]. [RFC5671], and [RFC5862]. ABR: Area Border Router. Router used to connect two IGP domains (areas in OSPF or levels in IS-IS). ASBR: Autonomous System Border Router. Router used to connect together ASes of the same or different Service Providers via one or more Inter-AS links. Boundary Node (BN): a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter-AS Traffic Engineering. Zhao, et al. Expires April 25, 2011 [Page 3] Internet-Draft PCEP P2MP Procedures October 2010 Core Tree: the core tree is a P2MP tree where the root is the ingress LSR, the transit nodes and branch nodes are the BNs of the transit domains and the leaf nodes are the leaf BNs of the leaf domains. Destination: The lead Nodes can be in Root Domain, Transit Domain and Leaf Domain. 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. Leaf Domain: a domain that does not have a downstream neighbor domain. Note that, with this definition, a domain with one or more leaf nodes is not necessarily a leaf domain. Leaf Boundary Nodes: the entry boundary node in the leaf domain. Leaf Nodes: the LSR which is the P2MP LSP's final. LSR: Label Switching Router. LSP: Label Switched Path. OF: Objective Function. A set of one or more optimization criterion (criteria) used for the computation of paths either for single or for synchronized requests (e.g. path cost minimization), or the synchronized computation of a set of paths (e.g. aggregate bandwidth consumption minimization, etc.). See [RFC4655] and [RFC5441]. P2MP LSP Path Tree: A set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. Path Domain Sequence: The known sequence of domains for a path between root and leaf. Path Domain Tree: The tree formed by the domains that the P2MP path crosses, where the source (ingress) domain is the root domain. 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 Zhao, et al. Expires April 25, 2011 [Page 4] Internet-Draft PCEP P2MP Procedures October 2010 network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. P2MP LSP Path Tree: A set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. Path Domain Sequence: the known sequence of domains for a path between the root node and a leaf node. PCE Sequence: the known sequence of PCEs for calculating a path between the root node and a leaf node. PCE Topology Tree: a list of PCE Sequences which has all the PCE Sequence for each path of the P2MP LSP path tree. PCE(i): a PCE that performs path computations for domain(i). Root Boundary Node: the egress LSR from the root domain on the path of the P2MP LSP. Root Domain: the domain that includes the ingress (root) LSR. TED: Traffic Engineering Database. Transit/branch Domain: a domain that has an upstream and one or more downstream neighbour domain. VSPT: Virtual Shortest Path Tree [RFC5441]. 3. Problem Statement The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. [RFC4875] describes how to set up P2MP TE LSPs for use in MPLS and GMPLS networks. The PCE is identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671]. [RFC5441] specifies a procedure relying on the use of multiple PCEs to compute (P2P) inter-domain constrained shortest paths across a predetermined sequence of domains, using a backward recursive path computation technique. The technique can be combined with the use of path keys [RFC5520] to preserve confidentiality across domains, which is sometimes required when domains are managed by different Service Zhao, et al. Expires April 25, 2011 [Page 5] Internet-Draft PCEP P2MP Procedures October 2010 Providers. The PCE communication Protocol (PCEP) [RFC5440] is extended for point-to-multipoint(P2MP) path computation requests and in [RFC6006]. However, that specification does not provide all the necessary mechanisms to request the computation of inter-domain P2MP TE LSPs. As discussed in [RFC4461], a P2MP tree is a graphical representation of all TE links that are committed for a particular P2MP LSP. In other words, a P2MP tree is a representation of the corresponding P2MP tunnel on the TE network topology. A sub-tree is a part of the P2MP tree describing how the root or an intermediate P2MP LSPs minimizes packet duplication when P2P TE sub-LSPs traverse common links. As described in [RFC5671] the computation of a P2MP tree requires three major pieces of information. The first is the path from the ingress LSR of a P2MP LSP to each of the egress LSRs, the second is the traffic engineering related parameters, and the third is the branch capability information. Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source and at least one destination residing in different domains) is particularly difficult to compute even for a distributed PCE architecture. For instance, while the BRPC recursive path computation may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to the multiple destinations. As such, inter-domain P2MP path computation may result in a plurality of per-domain path options that may be difficult to coordinate efficiently and effectively between domains. That is, when one or more domains have multiple ingress and/or egress border nodes, there is currently no known technique for one domain to determine which border routers another domain will utilize for the inter-domain P2MP tree, and no way to limit the computation of the P2MP tree to those utilized border nodes. A trivial solution to the computation of inter-domain P2MP tree would be to compute shortest inter-domain P2P paths from source to each destination and then combine them to generate an inter-domain, shortest-path-to-destination P2MP tree. This solution, however, cannot be used to trade cost to destination for overall tree cost (i.e., it cannot produce a MCT tree) and in the context of inter- domain P2MP LSPs it cannot be used to reduce the number of domain border nodes that are transited. Computing P2P LSPs individually is not an acceptable solution for computing a P2MP tree. Even per domain path computation [RFC5152] can be used to compute P2P multi-domain paths, but it does not guarantee to find the optimal path which crosses multiple domains. Furthermore, constructing a P2MP tree from individual source to leaf Zhao, et al. Expires April 25, 2011 [Page 6] Internet-Draft PCEP P2MP Procedures October 2010 P2P LSPs does not guarantee to produce a least-cost tree. This approach may also be considered to have scaling issues during LSP setup. That is, the LSP to each leaf is signaled separately, and each border node must perform path computation for each leaf. P2MP Minimum Cost Tree (MCT), i.e. one which guarantees the least cost resulting tree, is an NP-complete problem. Moreover, adding and/or removing a single destination to/from the tree may result in an entirely different tree. In this case, frequent MCT path computation requests may prove computationally intensive, and the resulting frequent tunnel reconfiguration may even cause network destabilization. There are several heuristic algorithms presented in the literature that approximate the result within polynomial time that are applicable within the context of a single-domain. This document presents a solution, and procedures and extensions to PCEP to support P2MP inter-domain path computation. 4. Assumptions It is assumed that, due to deployment and commercial limitations (e.g., inter-AS peering agreements), the sequence of domains for a path (the path domain tree) will be known in advance. In the figure below, the P2MP tree spans 6 domains, with D1 being the root domain. The corresponding domain sequences which are assumed known would be: D1-D3-D6, D1-D3-D5 and D1-D2-D4. D1 / \ D2 D3 / / \ D4 D5 D6 Figure 1: Domain Sequence Tree The examples and scenarios used in this document are also based on the following assumptions: o The PCE that serves each domain in the path domain tree is known, and the set of PCEs and their relationships is propagated to each PCE during the first exchange of path computation requests; [Editors note - this assumption needs to be more explicit. o Each PCE knows about any leaf LSRs in the domain it serves; Zhao, et al. Expires April 25, 2011 [Page 7] Internet-Draft PCEP P2MP Procedures October 2010 o The boundary nodes to use on the LSP are pre-determined and are part of the path domain tree. [Editors Note - In this version of the document we do not consider multi-homed domains.] Additional assumptions are documented in [RFC5441] and will not be repeated here. 5. Requirements This section summarizes the requirements specific to computing inter- domain P2MP paths. In these requirements we note that the actual computation times by any PCE implementation are outside the scope of this document, but we observe that reducing the complexity of the required computations has a beneficial effect on the computation time regardless of implementation. Additionally, reducing the number of message exchanges and the amount of information exchanged will reduce the overall computation time for the entire P2MP tree. We refer to the "Complexity of the computation" as the impact on these aspects of path computation time as various parameters of the topology and the P2MP LSP are changed. Its also important that the solution preserves confidentiality across domains, which is required when domains are managed by different Service Providers. Other than the requirements specified in [RFC5376], a number of requirements specific to P2MP are detailed below: 1. The computed P2MP LSP should be optimal when only considering the paths among the BNs. 2. Grafting and pruning of multicast destinations in a domain should have no impact on other domains and on the paths among BNs. 3. The complexity of the computation for each sub-tree within each domain should be dependent only on the topology of the domain and it should be independent of the domain sequence. 4. The number of PCEP request and reply messages should be independent of the number of multicast destinations in each domain. 5. Specifying the domain entry and exit nodes. 6. Specifying which nodes should be used as branch nodes. Zhao, et al. Expires April 25, 2011 [Page 8] Internet-Draft PCEP P2MP Procedures October 2010 7. Reoptimization of existing sub-trees. 8. Computation of P2MP paths that need to be diverse from existing P2MP paths. 6. Objective Functions For the computation of a single or a set of P2MP TE LSPs, a request to meet specific optimization criteria, called an Objective Function (OF) may be indicated. The computation of one or more P2MP TE-LSPs may be subject to an OF in order to select the "best" candidate paths. A variety of objective functions have been identified as being important during the computation of inter-domain P2MP LSPs. These include: 1. The sub-tree within each domain should be optimized, which can be either the Minimum cost tree [RFC5862] or Shortest path tree [RFC5862]. 2. The P2MP LSP path, formed by considering only the entry and exit nodes of the domains (the Core Tree) shold be optimal. 3. It should be possible to limit the number of entry points to a domain. 4. It should be possible to force the branches for all leaves within a domain to be in that domain. 7. P2MP Path Computation Procedures The following sections describe the Core Tree based procedures to satisfy the requirements specified in the previous section. A core tree based solution provides an optimal inter-domain P2MP TE LSP. 7.1. Core Trees A Core Tree is defined as a node tree, with nodes from the domains corresponding to the domain tree PCE topology, which satisfies the following conditions: o The root of the core tree is the ingress LSR in the root domain; o The leaves of the core tree are the entry nodes in the leaf domains; Zhao, et al. Expires April 25, 2011 [Page 9] Internet-Draft PCEP P2MP Procedures October 2010 o The transit and branch nodes of the core tree are from the entry and exit nodes from the transit and branch domains. For example, consider the Domain Tree from the figure below, representing a domain tree of 5 domains, and part of the resulting Core Tree which satisfies the aforementioned conditions. RN: Root Node EN: Entry Border Node (domain, index) XN: Exit Border Node (domain, index) +----------------------+ | Domain1 | | (RN) | | | | | +--(XN1_1)---(XN1_2) --+ / \ / \ / \ +-------(EN2_1) -----+ +----(EN3_1)-------+ | Domain2 | | Domain3 | | | | | | | | | | | | | +----(XN2_1)---------+ +-(XN3_1)-(XN3_2)--+ / \ / \ +--------(EN4_1)-------+ +---------(EN5_1)-----+ | Domain4 | | Domain5 | | | | | | | | | | | | | +----------------------+ +---------------------+ Figure 2: Domain Tree Example (RN) / \ (XN1_1) (XN3_1) / \ (EN2_1) (EN3_1) / \ (XN2_1) (XN3_1) / \ (EN4_1) (EN5_1) Zhao, et al. Expires April 25, 2011 [Page 10] Internet-Draft PCEP P2MP Procedures October 2010 Figure 3: Core Tree 7.2. Core Tree Computation Procedures Computing the complete P2MP LSP path tree is done in two phases: The algorithms to compute the optimal large core tree are outside scope of this document. The following extended BRPC based procedure can be used to compute the core tree. BRPC Based Core Tree Path Computation Procedure: 1. Using the BRPC procedures to compute the VSPT(i) for each leaf BN(i), i=1 to n, where n is the total number of entry nodes for all the leaf domains. In each VSPT(i), there are a number of P(i) paths. 2. When the root PCE has computed all the VSPT(i), i=1 to n, take one path from each VSPT and form a set of paths, we call it a PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n); 3. For each PathSet(j), there are n S2L (Source to Leaf BN) paths and form these n paths into a Core Tree(j); 4. There will be M number of Core Trees computed from step3. Apply the OF to each of these M Core Trees and find the optimal Core Tree. Note that the application of BRPC in the aforementioned procedure differs from the typical one since paths returned from a downstream PCE are not necessary prunned from the solution set by intermediate PCEs. The reason for this is that if the PCE in a downstream domain does the prunning and returns the single optimal sub-path to its parent PCE, BRPC insures that the ingress PCE will get all the best optimal sub-paths for each LN (Leaf Border Nodes), but the combination of these single optimal sub-paths into a P2MP tree is not necessarily optimal even each S2L (Source-to-Leaf) sub-path is optimal. Without trimming, the ingress PCE will get all the possible S2L sub- paths set for LN, and eventually by looking through all the combinations, and taking one sub-path from each set to built one p2mp tree it finds the optimal tree. The proposed method may present a scalability problem for the dynamic computation of the Core Tree (by iterative checking of all combinations of the solution space), specially with dense/meshed Zhao, et al. Expires April 25, 2011 [Page 11] Internet-Draft PCEP P2MP Procedures October 2010 domains. Considering a domain sequence D1, D2, D3, D4, where the Leaf border node is at domain D4, PCE(4) will return 1 path. PCE(3) will return N paths, where N is E(3) x X(3), where E(k) x X(k) denotes the number of entry nodes times the number of exit nodes for that domain. PCE(2) will return M paths, where M = E(2) x X(2) x N = E(2) x X(2) x E(3) x X(3) x 1, etc. Generally speaking the number of potential paths at the ingress PCE Q = \prod E(k) x X(k). Consequently, it is expected that the Core Path will be typically computed offline, without precluding the use of dynamic, online mechanisms such as the one presented here, in which case it SHOULD be possible to configure transit PCEs to control the number of paths sent upstream during BRPC (trading trimming for optimality at the point of trimming and downwards). 7.3. Sub Tree Computation Procedures Once the core tree is built, the grafting of all the leaf nodes from each domain to the core tree can be achieved by a number of algorithms. One algorithm for doing this phase is that the root PCE will send the request with C bit set for the path computation to the destination(s) directly to the PCE where the destination(s) belong(s) along with the core tree computed from the phase 1. This approach requires that the root PCE manage a potentially large number of adjacencies (either in persistent or non-persistent mode), including PCEP adjacencies to PCEs that are not within neighboring domains. A first alternative would involve establishing PCEP adjacencies that correspond to the PCE domain tree. This would require that branch PCEs forward requests and responses from the root PCE towards the leaf PCEs and vice-versa. Finally, another alternative would use a hierarchical PCE (H-PCE) architecture. The "hierarchically" parent would request sub tree path computations. The algorithms to compute the optimal large sub tree are outside scope of this document. In the case that the number of destinations and the number of BNs within a domain are not big, the incremental procedure based on p2p path computation using the OSPF can be used. 7.4. PCEP Protocol Extensions Zhao, et al. Expires April 25, 2011 [Page 12] Internet-Draft PCEP P2MP Procedures October 2010 7.4.1. The Extension of RP Object The extended format of the RP object body to include the C bit is as follows: The C bit is added in the flag bits field of the RP object to signal the receiver of the message that the request/reply is for inter- domain P2MP Core Tree or not. 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 |C|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: RP Object Body Format The following flag is added in this draft: C bit ( P2MP Core Tree bit - 1 bit): 0: This indicates that this is normal PCReq/PCRrep for P2MP. 1: This indicates that this is PCReq or PCRep message for inter- domain Core Tree P2MP. When the C bit is set, then the request message should have the Core Tree passed along with the destinations which and then graphed to the tree. 7.4.2. The PCE Sequence Object The PCE Sequence Object is added to the existing PCE protocol. A list of this objects will represent the PCE topology tree. A list of Sequence Objects can be exchanged between PCEs during the PCE capability exchange or on the first path computation request message between PCEs. In this case, the request message format needs to be changed to include the list of PCE Sequence Objects for the PCE inter-domain P2MP calculation request. Each PCE Sequence can be obtained from the domain sequence for a Zhao, et al. Expires April 25, 2011 [Page 13] Internet-Draft PCEP P2MP Procedures October 2010 specific path. All the PCE sequences for all the paths of P2MP inter-domain form the PCE Topology Tree of the P2MP LSP. The format of the new PCE Sequence Object for IPv4 (Object-Type 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | OT |Res|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for root PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for the downstream PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for the downstream PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | !! | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for the PCE corresponding to the leafDomain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The New PCE Sequence Object Body Format for IPv4 The format of the new PCE Sequence Object for IPv6 (Object-Type 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | OT |Res|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address for root PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address for the downstream PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address for the downstream PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | !! | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address for the PCE corresponding to the leafDomain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhao, et al. Expires April 25, 2011 [Page 14] Internet-Draft PCEP P2MP Procedures October 2010 Figure 6: The New PCE Sequence Object Body Format for IPv6 7.5. Relationship with Hierarchical PCE The actual grafting of subtrees into the Multi-Domain tree needs to be carried out by the source node. This means that the source node needs to get the computed sub-paths from all the involved domains. This requires that the source node either has a PCEP session with all the PCEs, or PCEP messages are routed via the PCEP sessions. This may mean an excessive number of sessions or an added complexity in implementations. Alternatively, one may use an architecture based on the concept of hierarchical PCE [H-PCE]. The parent PCE would be responsible to request Intra-domain subtrees to the PCEs, combine them and return the overall P2MP tree. 7.6. Parallelism In order to minimize latency in path computation in multi-domain networks, intra-domain path segments and intra-domain sub-trees SHOULD be computed in parallel when possible. The proposed procedures in this draft present opportunities for parallelism: 1. The BRPC procedure for each leaf node can be launched in parallel by the ingress/root PCE if the dynamic computation of the Core Tree is enabled. 2. Intra-domain P2MP paths can also be computed in parallel by the PCEs once the entry and exit nodes within a domain are known One of the potential issues of paralellism is that the ingress PCE would require a potentially high number of PCEP adjacencies to "remote" PCEs and that may not be desirable, but a given PCE would only receive requests for the destinations that are in its domain (+ the core nodes), without PCEs forwarding requests. 8. Manageability Considerations [RFC5862] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how manageability requirements mentioned in [RFC5862] are supported in the context of PCEP extensions specified in this document. Note that [RFC5440] describes various manageability considerations in PCEP, and most of manageability requirements mentioned in [PCE-P2MP Zhao, et al. Expires April 25, 2011 [Page 15] Internet-Draft PCEP P2MP Procedures October 2010 P2MP] are already covered there. 9. Control of Function and Policy In addition to configuration parameters listed in [RFC5440], the following parameters MAY be required. o P2MP path computations enabled or disabled. o Advertisement of P2MP path computation capability enabled or disabled (discovery protocol, capability exchange). 10. Information and Data Models As described in [RFC5862], MIB objects MUST be supported for PCEP extensions specified in this document. 11. Liveness Detection and Monitoring There are no additional considerations beyond those expressed in [RFC5440], since [RFC5862] does not address any additional requirements. 12. Verifying Correct Operation There are no additional considerations beyond those expressed in [RFC5440], since [RFC5862] does not address any additional requirements. 13. Requirements on Other Protocols and Functional Components As described in [RFC5862], the PCE MUST obtain information about the P2MP signaling and branching capabilities of each LSR in the network. Protocol extensions specified in this document do not provide such capability. Other mechanisms MUST be present. 14. Impact on Network Operation It is expected that use of PCEP extensions specified in this document will not have a significant impact on network operations. Zhao, et al. Expires April 25, 2011 [Page 16] Internet-Draft PCEP P2MP Procedures October 2010 15. Security Considerations As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also use more link bandwidth. Therefore, it may be more vulnerable to denial of service attacks. Therefore, it is more important that implementations conform to security requirements of [RFC5440], and the implementer utilize those security features. 16. IANA Considerations A new flag of the RP object (specified in [RFC5440]) is defined in this document. TBD. 17. Acknowledgements The authors would like to thank Adrian Farrel, Dan Tappan and Olufemi Komolafe for their valuable comments on this draft. 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z., Zhao, Q., King, D., "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC6006, September 2010. 18.2. Informative References [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Zhao, et al. Expires April 25, 2011 [Page 17] Internet-Draft PCEP P2MP Procedures October 2010 [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. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. [RFC5441] Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5441, June 2009. [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE)", RFC 5671, August 2009. [RFC5862] Yasukawa, S. and A. Farrel, "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", RFC 5862, June 2010. [H-PCE] King, D. and A. Farrel, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS", July 2010. Authors' Addresses Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Zhao, et al. Expires April 25, 2011 [Page 18] Internet-Draft PCEP P2MP Procedures October 2010 Zafar Ali Cisco Systems US Email: zali@cisco.com Tarek Saad Cisco Systems US Email: tsaad@cisco.com Siva Sivabalan Cisco Systems Canada Email: msiva@cisco.com Daniel King Old Dog Consulting UK Email: daniel@olddog.co.uk Ramon Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya Spain Email: ramon.casellas@cttc.es Zhao, et al. Expires April 25, 2011 [Page 19]