Network Working Group Jun Kyun Choi (ICU) Internet Draft Dipnarayan Guha Category: Informational Expiration Date: August 2006 March 2006 Considerations of point-to-multipoint route optimization using PCEMP draft-choi-pce-p2mp-framework-03.txt Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Copyright (C) The Internet Society (2006). Abstract This draft describes the basic concepts of point-to-multipoint (p2mp) path computation on the basis of the Path Computation Element Metric Protocol (PCEMP). PCEMP, being soft-memory based, has the capability of dynamic configuration of its finite state machines (FSMs) in the participating PCEMP peers, and thus can support a wide variety of traffic engineering techniques that are needed to guarantee bandwidth demand and scalable fast protection and restoration in PCE based p2mp frameworks. To take advantage of bandwidth considerations and fast restoration mechanisms, the centralized Controller, which is the key element in a PCE node, is used for path computation in case of p2mp paths and can be used in a scenario where reliable multicasting of bandwidth-on-demand services becomes an important criteria for multiple-domain and/or inter-domain PCE based architectures. Choi, Guha Informational [Page 1] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 Table of Contents 1 Terminology ................................................. 3 2 Introduction ................................................ 4 3 p2mp Support Requirements in PCE architectures .............. 4 3.1 High-level requirements for PCE-based p2mp TE path computation and PCEMP ....................................... 5 3.2 Features of PCEMP as outlined for p2mp realizations ..... 6 3.2.1 PCEMP as a metric protocol ........................ 6 3.2.2 Protection and Restoration considerations in p2mp TE LSP computation using PCEMP .................... 7 3.2.3 p2mp Peer Discovery during Path Computation ....... 7 4 Implementation considerations of the PCEMP protocol architecture in p2mp LSP TE computations .................... 7 4.1 PCEMP State Machines Design ............................. 8 4.2 Functional Parameters for PCEMP DS processing for p2mp TE LSP computation ..................................... 8 4.3 Realization of fast path computing unit architecture using PCEMP ................................................. 9 4.4 Fundamentals of the PCEMP Algorithm as a function of CPCA 9 4.5 Protocol implementation considerations using PCEMP ...... 12 5 Considerations of operationing of p2mp in PCE ............... 14 5.1 QoS oriented p2mp path computation provisioning in PCE .. 15 6 Conclusion .................................................. 15 7 Security Considerations ..................................... 16 8 IANA Considerations ......................................... 16 9 Acknowledgements ............................................ 16 10 Intellectual Property Considerations ........................ 16 11 Normative References ........................................ 17 12 Informational References .................................... 17 13 Authors' Addresses .......................................... 18 14 Full Copyright Statement .................................... 19 Choi, Guha Informational [Page 2] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 1. Terminology This memo makes use of the following terms: 1. Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain LSPs. This entity can simultaneously act as a client and a server. Several PCEs can be deployed in a given Autonomous System (AS). 2. Path Computation Element node (PCE Node): a network processing unit comprising of a PCE unit. This can be embedded in a router or a switch. 3. Domain: Denotes an Autonomous system (AS) within the scope of this draft. 4. PCE Domain Area (PCEDA): A specific domain area within an AS that consists of PCE peers managed by a PCE node running PCEMP 5. PCE descriptor ID: a 32 bit number generated by the PCEMP FSM execution upon successful path computation and partition of the AS into PCEDAs 6. PCE p2mp ID (pp2mp ID): A set consisting of one or more PCE descriptor IDs. The scope of this ID is determined by the LSP setup and teardown dynamically, it can be within two adjacent nodes, or between different PCE peers under a common PCEDA, or just a unique one for the entire LSP. Choi, Guha Informational [Page 3] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 2. Introduction One of the key work items involving the functional specification of MPLS and GMPLS Traffic Engineering LSP path computation techniques in the proposed PCE WG charter is the case for TE LSP path computation for inter-domain areas applying to both point-to-point (p2p) and point-to-multipoint (p2mp) TE LSPs. Such path computation techniques include primary, protection and recovery paths and well as load balancing and reoptimization techniques. Most of the existing MPLS TE allows for strict QoS guarantee, resource optimization and fast failure recovery, but the scope is mostly limited to p2p applications. In the context of path computation, one of the important application areas is the reliable support of bandwidth-on-demand applications, where the QoS provisioning needs to be dynamic and robust. A scenario where a PCE node acts a server which are connected to several clients, which may or may not be PCE peers, needs a clear requirement addressal so far as p2mp TE tunneling is considered. In this draft, we consider that such p2mp TE LSP path computation is QoS triggered, and we show how PCEMP finite state machines (FSMs) might help in achieving a scalable architecture involving PCEDAs where p2mp path computation metrics are independent of the number of clients to which the PCE server is attached to. The Path Computing Element Metric Protocol (PCEMP) acts as a generic computational model for path based metrics in large multi-domain and/or multi-layer networks. This draft goes on to show some of the features of the PCEMP protocol in realizing a protocol-driven architecture, which essentially means that the topology for load balancing and reoptimization in path computation is performed on the fly with the PCEMP FSM execution on the participating PCE peers. This feature of PCEMP helps in degenerating the setup and teardown of p2mp TE LSP computation to the PCEMP protocol processing itself, thus enabling support of an arbitrary number of clients as well provisioning of guaranteed robust path protection and restoration and dynamic QoS provisioning for bandwidth-on-demand services. 3. p2mp Support Requirements in PCE architectures For the scenario involving robust and dynamic provisioning of bandwidth-on-demand services, the p2mp applications request p2mp forwarding paths in case of different topology deployments. The robustness must be thought in the context of path reoptimization, so a quick change in the topology must be accomodated with every PCEDA level optimization. The p2mp path will have several observed metrics as constraints, such as cost of path establishment and teardown, delay boundedness of the p2mp path, both delay bounded and cost optimized constraints in tandem for path computation, etc. One of the features as brought out in the PCE WG charter is the co-existence of different path computation algorithms on the PCE node, so that depending upon the data that is processed, a particular algorithm is invoked. It is also evident that for p2mp Choi, Guha Informational [Page 4] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 applications, a CPU intensive path computation is necessary, primarily because most of the bandwidth-on-demand applications tend to be resource-intensive applications like streaming multimedia, real-time videoconferencing, etc. The ideal thing would be to let the data that is under processing in the PCE node determine the path computation algorithm directly, which would mean that the constraints imposed by the QoS provisioning requirements would directly determine the path computation algorithm and path reoptimization, which in turns drives the resulting topology architecture. Thus, it is easy to see why PCEMP is a possible solution for p2mp TE LSP computation, as it drives a protocol driven architecture for topology changes in path reoptimization. The traffic engineering techniques involved with p2mp TE LSP computation involve mainly with the case of p2mp path computation over multiple domains. There are three main issues involved with this feature: 1. load sharing among paths, 2. ability to modify the p2mp paths in different PCEDAs even when the PCEDA entities lie in different multiple domains, 3. p2mp path computation for corresponding clients in muliple domains must be able to support scalability, i.e. the number of clients entering/leaving the p2mp tree at a given time. 3.1 High-level requirements for PCE-based p2mp TE path computation and PCEMP Some of the high level requirements for PCE-based p2mp TE path computation [1] are: 1. Capability to implement multiple p2mp path calculation algorithms/mechanisms and to select the appropriate algorithm/ mechanism based on computation demands. We have mentioned this independently earlier about PCEMP FSM driven architectures. 2. Reliability in LSR-PCE signaling. A good thing about PCEMP is that as the FSMs are soft-configured on the participating peers, the same protocol can be used for communicating between a LSR and a PCE, as well do the data processing and path computation on a PCE peer entity, i.e. a node. 3. Support of PCE in a centralized and distributed manner. This is automatically derived from the PCEDA partitions once the PCE peers are known. 4. Capability to calculate a p2mp path by co-ordinating multiple PCEs. PCEMP does this by assigning an IDT (input data type) associated with each TE-LSP that is set up through the corresponding PCE node entity. For path computation using PCEMP FSMs, the PCE descriptor ID is returned after every computation is complete. If the computation is successful, a random 32 bit number is generated Choi, Guha Informational [Page 5] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 which holds the path computation status at that PCE node. If the path computation fails, a value of -1 is generated in the PCE descriptor ID field which is communicated to the immediate PCE peer and automatic protection of the TE LSP begins and a reoptimization is calculated by the last stored random number for this node by the neighboring PCE peer. A pp2mp ID is a set of the corresponding PCE descriptor IDs (a -1 has a local scope to the node where the fault occurred) 5. Detection of p2mp capability (p2mp signaling/forwarding support) of LSRs. This is done using the soft-memory feature aspect of PCEMP FSMs. If the LSR does not support p2mp capability, it will just transparently pass through the PCEMP protocol messages. The soft-memory will provide a temporary "make-and-break" FSM support on the LSR before actual communications take place. 6. Support of load balancing between multiple PCEs. This is done with the help of the corresponding IDTs derived from the QoS classes in the PCEMP FSMs. 7. Capability to hold calculated p2mp path information. This is done dynamically for TE LSPs passing through a PCE peer entity through the PCE descriptor IDs. Besides, the centralized Controller of the PCE server also maintains a table containing these descriptor IDs corresponding to the PCE peers within the PCEDA for which it is responsible. 8. Capability to synchronize TEDB/LSDB between the PCE and LSR. This has been discussed using the different parts of the centralized Controller. The authors have brought out a draft on this for SRLG based end-to-end fast protection and recovery, where this synchronization aspect is mentioned in [3]. 3.2 Features of PCEMP as outlined for p2mp realizations 3.2.1 PCEMP as a metric protocol 1. PCEMP acts as a generic computational model for path based metrics in large multi-domain and/or multi-layer networks. 2. The protocol mechanism can serve as an application path computation framework for any PCE 3. Analysis of PCEMP metrics in terms of protocol cost shows the implementation considerations of PCEMP protocol state machines in p2mp TE LSP path computations. Choi, Guha Informational [Page 6] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 4. The underlying key point is that PCEMP addresses inter-domain partitioning and management issues through the concept of PCE peers drafted by PCEMP. Partitioning into PCEDAs help automatically in p2mp path computation, reoptimization and multiple PCE co-ordination. 3.2.2 Protection and Restoration considerations in p2mp TE LSP computation using PCEMP 1. PCE based backup path computation can be done using SRLGs, as in [3]. There can be any other mechanism associated with the real-time protection, restoration and recovery for p2mp TE LSP path computation, as we have mentioned earlier, using the PCE descriptor ID. Processing the PCE descriptor ID for protection and recovery is outside the scope of this draft. 2. PCEMP FSMs partition the corresponding AS into PCEDAs, which means there is an obvious segmentation of any logical topology during path computation. The network and control structure frameworks in the scenario of PCEMP guarantees a fast establishment of a disjoint backup path. This also means that there is a mechanism possible for integrated provisioning and protection for the purpose of fast backup path computation, which is an important standpoint for bandwidth-on-demand QoS provisioning in p2mp scenarios. 3.2.3 p2mp Peer Discovery during Path Computation 1. The PCE peer architecture as "seen" by the PCEMP FSM [2] helps in fast PCE peer advertisement and fast processing of PCE peer solicitations, thus improving router handling procedures on individual PCE nodes and peers. 2. The configuration of PCE peers for fast processing of solicitations is one of the key aspects of p2mp TE LSP path computation and reoptimization. This is also an important requirement for bandwidth-on-demand services involving a PCE server and the corresponding clients. 3. [4] has shown a guideline to specifications of modifying existing protocols to facilitate communication between LSRs, PCEs and PCE peers. The concept of synchronization of information between PCE nodes in case of a change in the PCEDA helps in fast default PCE peer acquisition [4]. This results from the fact that PCE peers are capable of being "soft-configured" in inter-domain PCE issues. 4. Implementation considerations of the PCEMP protocol architecture in p2mp LSP TE computations We extend the definition from [2], which contains the basic definition of PCEMP Data Structure (PCEMP DS). The PCE node essentially has three distinct functional entities: Choi, Guha Informational [Page 7] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 1. Protocol System Architecture: PCEMP DS decoder architecture and path computing core that interfaces with the network processing engines in the PCE nodes. 2. Protocol System Specifications: An efficient algorithm for running in the computing core of the PCE units, called the Combinatorial Path Computing Algorithm (CPCA). This algorithm is the fundamental block that co-ordinates the PCEMP state machines and describes the decoder that processes arbitrarily large input data sequences using SCM [2]. The memory structure of the protocol processing engine is implemented in terms of these soft decoder algorithms and the data that is being processed for p2mp applications. The method reduces hardware and path computing complexity considerably. 3. Protocol System Requirements: High Level Path Computing Transform Library 4.1 PCEMP State Machines Design Definition: A unifying concept that ties together the CPCA and protocol level processing. These mathematical programs are selected on the PCE node block structure by the PCEMP DS based on the input data sequence real-time and implemented as a dynamic data driven tree partitioning. For p2mp TE LSP computation, this tree is additionally given respective IDs for different LSPs (differentiated by LSP IDs during LSP setup) Concept: A function that is mapped onto the CPCA and PCE computation (PCEC) classes and outputs the path computation unit length. This parameter is benchmarked for performance in processing time and computational complexity of the PCE unit and invoked CC and SPC metrics. For p2mp, these individual functions might be mapped to a single centralized function in the PCE server (centralized path computation), or might co-exist with one another in terms of local function descriptors(distributed path computation) Iterator Self-Reflection of Types Design: The PCEMP DS is a general framework supporting CPCA and PCEC modes of computation in the PCE unit. Self-reflection of type instantiates two iterators that share a common constructor class. The iterator types are of type CPCA and PCEC, and called during compile-time to generate the necessary control structure output. This helps in implementing the data-driven strategy for path computing real-time and forms the basis of PCEMP State Machines design. 4.2 Functional Parameters for PCEMP DS processing for p2mp TE LSP computation The input data sequence is arranged into an ordered set called the Input Data Type (IDT) which is a subset of the input vector S and a function of the control transform to be computed T. A State Subset Choi, Guha Informational [Page 8] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 is a member of the cardinal product of S and T. It is shown to be isomorphic with the logical decoder outputs [2]. The IDTs invoke the hardware for computing across the partitioned kernel in the PCE nodes. Input: IDT Tj, State Subsets Sl and Sm, Integers l and m, Label Lb, Semi-Ring R. For p2mp support, there will be multiple state subsets, and we will pairwise consider all such states. In case where the total number of states is odd, one state will be paired with the identity state. Output: Flow metric/measure p(A,B), which maps to the PCE descriptor ID. For p2mp cases, the PCE descriptor IDs are setwise collected to form the pp2mp ID. This is again implementation dependent. 4.3 Realization of fast path computing unit architecture using PCEMP Concept: Iterative applications of the PCEMP DS. Two or more IDT encoders separated by an interleaver (respectively CC and SPC). This structure suggests a decoding strategy based on the iterative passing of soft-computing information between two decoding algorithms. This is equivalent to dynamically partitioning the path computing engine core into sub-units that are linked together real-time based on the input data and the protocol handler. This is what makes PCEMP a protocol driving architecture, and is one of the key features of realizing a NP-hard path computation for p2mp TE LSPs. Basic Computation: Configure PCEMP DS to compute soft-decisions in terms of measures. An assigned measure is given to each branch of the IDT. This algorithm makes the data intensive path computing much easier and reduces overhead and complexity and is incorporated in the computing core. It also guarantees disjoint path computation that enables fast end-to-end backup and protections. The configuration is totally dependent on the processed data and in a PCE server based bandwidth-on-demand scenario, can be triggered by the QoS service classes. The QoS classes are directly mapped onto the IDT, and thus can realize the p2mp based TE LSP path computation and reoptimization all the time based on the demanded bandwidth ensuring robustness and reliability of services. 4.4 Fundamentals of the PCEMP Algorithm as a function of CPCA for { any TE LSP passing through a PCE node P { Let A belong to Sm and B belong to Sl. A and B are thus sets of states with m and l. Initialization: For each s in Sm, r(Sj,s) = 1 when s is in A else 0 xt(0) =1, xt(m) = 0, m is not zero Loop: Choi, Guha Informational [Page 9] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 /* For Decoder i to Decoder k, CC and SPC */ /* For j = m+1, m+2,...,l, for each s2 in Si, */ /* Label branch bout with input m and three outputs (c0,c1,x1); */ // p2mp TE LSP path computation support // do { repeat for all Si's ; assign bouts for each si in Si for P ; } // p2mp TE LSP path computation support // /* c0 = common symbols between the two encoders, CC and SPC */ /* c1,x1 = PCE unit inputs */ call decoder_private; /* populates decoder specific private data*/ /* This is populated by data driven mapping of external routing information. In PCEMP, each external route is imported into the PCE domain area in separate data driven computation strategies */ u(y|c0) = load file_channel; /* populates PCE unit kernel specific data */ /* This is populated by the peer-to-peer information exchange by the functional blocks involved in the PCE node. i.e. the network processor, the domain processor and the node processor */ u(y|m) = rel (u(y|c0), u(c1,x1|c0,y); /* This is SCM specific kernel computation that involves a data-driven partitioning of the ordered graph based on iterator instantiates */ assign p = probability(c0); // p2mp TE LSP path computation support // do { repeat for all Si's; assign p for all c0's for all Si's; take the weighted arithmetic mean of the probabilities along with the branch labels; assign p1 = probability weighted (mean(c0)); } // p2mp TE LSP path computation support // /* This is the probability that the PCE computing is actually invoked for computing upon data vectors that show a significant change in the data profile sequence, else it is just buffered and tagged for decision making. This reduces computational overhead and unnecessary kernel calls for data intensive path computing */ Choi, Guha Informational [Page 10] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 // This is precisely what we use for the p2mp support in PCEMP based architectures. The path computation and reoptimization is driven by QoS demands. The algorithm processing completely depends on the data that is under processing, and the PCEMP FSM executes accordingly. Besides, this also shows that there can be other algorithms that can co-exist with PCEMP, in which case the corresponding iterators to the other protocol FSMs would just be needed to be included as a child of the PCEMP iterator // assign y = u(c0).u(y|c0).decoder_private; log p(Si, xj) = log sum (si, xj-1) + log sum (zj) over all b in Bi, y(b) = u(m).u(y|m).decoder_private; invoke Fast_Decoding_Procedure; /* This procedure has been described in the context of iterator self-reflection types in Section 4.1 */ /* This essentially means this: */ /* for m to l all the state indices, */ /* for all the branches on the corresponding graph of the PCEMP DS IDT, obtain the sum of the logarithms of the corresponding weights and optimize it for choosing the correct points on the graph. This is a continuous, cumulative and dynamic process which involves minimum computation overhead and provides a guaranteed fast crossover for path computation and backup protection */ // This is thus invoked for all the p2mp TE LSP path computations, as we see above in the algorithm// // besides, the path computation for p2mp support is independent of the number of nodes, as that parameter does not appear in our algorithm. This helps in scalability issues for p2mp TE LSP computation in PCE architectures // Stop: p(si,xj) = min log (sum (si, xj -1) /* Store the sums obtained in the Loop and then equate to the final sum */ Choi, Guha Informational [Page 11] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 /* Fast path computing procedure for large sequence input data: */ /* 1. Setup: Use the received kernel data to compute the common and private soft channel information */ /* 2. Iterate: Repeatedly update, for the outer and inner decoder, the iterative information by updating u(c0) and u(m). The computation involves a forward and backward application of the PCEMP DS with the complete branch measure. */ /* The extracted measure for the common symbol is computed based on (x,y1,z) using the private branch measure */ /* 3. Conclude: The extracted measure for the control symbol m is computed based on (x,y1,z) using the complete branch measure z */ Based on the above algorithm and analysis, we can consider two distinct finite state machine diagrams of the PCEMP protocol architecture, as in [2]: 1. The case where the PCE unit block is invoked for constantly changing data profiles within the time of test of goodness of fit (MAX_PCE_TIME_FIT) 2. The case where the PCE unit block is invoked only once for a variable data profile and then the data is tagged (tags) within the time of test of goodness of fit (MAX_PCE_TIME_FIT). max tags is an important parameter to determine the computing potential within MAX_PCE_TIME_FIT and determines the ease of p2mp path bifurcation, route reoptimization and real-time protection and restoration. 4.5 Protocol implementation considerations using PCEMP |----------- (1) ------------>| | | |<-----------(2) -------------| | | |------------(3) ------------>| | | |<-----------(4) -------------| | | |------------(5) ------------>| | | |<-----------(6) -------------| PCE1 PCE2 Figure 1: PCEMP message exchanges between PCE elements in p2mp case Choi, Guha Informational [Page 12] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 For considerations of point-to-multipoint route optimization using PCEMP, we can use PCEMP messaging for implementing such a scenario. Here is a sample sequence of messaging that helps in the PCE nodes maintain soft PCEMP status. Details about the protocol messages can be found in [2]. (1): Send a PCEMP Common Header with the COMPUTE_PATH enabled in the PCEMode field and the ACK REQUESTED enabled in the PCEFlag field. The PCEMP message MAY include a PCE SUBOBJECT to inform the responder (PCE2) about the initiator's (PCE1) PCEMP-LOCAL-INITIATOR-ADDRESS. In this way PCE2 is initialized with the soft-memory based computation for PCEMP FSMs. (2): PCE2 receives this message and is configured with the soft-memory based path computation states. It sends back an ACK message to PCE1 with the responder's (PCE2) PCEMP-LOCAL-RESPONDER-ADDRESS (3): PCE1 sends a PCEMP Common Header with the COMPUTE_LSP_TYPE enabled in the PCEMode field, the Peer-to-peer mode set to 0 in the PCEStatus field of the Common Header. For the other values set in the Peer-to-peer mode according to [2], this is still TBD. It also sends a PCEMP ESTABLISH message with the following parameters: 1. Flag field set to VARIABLE. The MAX_PCE_TIME_FIT is to be negotiated as discussed in [2]. In case this is not able to be negotiated, then the PCEMP ERROR message SHOULD be generated with the ERROR CODE field set to OUT OF TIME, and the PCE1 node MUST issue a fresh PCEMP ESTABLISH message with the Flag field set to STATIC. 2. In case of contention in the value of the MAX_PCE_TIME_FIT during negotiation, the node ID with the higher value wins. The other PCE node which has won contention must send a fresh PCEMP ESTABLISH message with the Flag field set to STATIC and its' own MAX_PCE_TIME_FIT value. It MUST also set the ACK requested flag in the PCEFlag of the corresponding outgoing PCEMP Common Header. The node which has lost contention SHOULD send out an ACK message along with a PCE SUBOBJECT with the MAX_PCE_TIME_FIT value obtained thus. 3. A BANDWIDTH OBJECT for conveying the QoS requirements of the initiator. An absence of this object SHOULD generate a PCEMP ERROR MESSAGE with the ERROR CODE field set to 3 signifying a protocol error. (4): PCE2 sends a PCEMP RESPOND message with the corresponding PCE Descriptor ID. This is matched and stored statically for the lifetime of the path computation between PCE1-PCE2 so that this ID remains static between them till the path computation is over. If the PCE Descriptor ID changes value, a PCEMP ERROR message MUST be generated with the ERROR CODE field set to PROTOCOL ERROR with its own saved PCE Descriptor ID of the wronged hop in the PCEMP NEGOTIATE OBJECT. It MUST also set the Protection mode in the PCEStatus field of the corresponding outgoing PCEMP Common Header and the BANDWIDTH OBJECT with the same field value that was received in the PCEMP ESTABLISH message. If the two values are different, a PCEMP ACK message MUST be generated with the PCE SUBOBJECT set to the newer value of the BANDWIDTH OBJECT. The responder MUST generate a PCEMP ACK message with this accepted value of the BANDWIDTH OBJECT. In case these two still do not match, a PCEMP ERROR message MUST be generated with the ERROR CODE field set to 3, a PCEMP NEGOTIATE OBJECT with the accepted QoS parameters and the same value in the BANDWIDTH OBJECT. Choi, Guha Informational [Page 13] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 (5): PCE1 issues a PCEMP TEARDOWN message with the RequestType field set to CHANGE IN COMPUTATION STYLE for PCE2 to remain PCEMP enabled and the path computation state active. (6): PCE2 sends a PCEMP Common Header with the COMPUTE_LSP_TYPE enabled in the PCEMode field. The PCEMP message MAY include a PCE SUBOBJECT to inform the responder (PCE1) about the initiator's (PCE2) PCEMP-LOCAL-INITIATOR-ADDRESS. This process is repeated for multiple PCEn, and the path computation works along the one described in Section 4.4. 5. Considerations of operationing of p2mp in PCE As said before, it is possible to obtain a protocol driven network architecture from a data driven protocol FSM. From the operationing point of view, there are two equally likely possibilities for p2mp support in PCEs: 1. The PCE descriptor ID that is obtained from the FSM execution can be carried as a separate optional object in standard OSPF/RSVP-TE extensions, irrespective of whether a routing or a signaling based solution is deployed for TE LSP path computation in p2mp scenarios. Traditionally, if an explicit-route object is used, the PCE descriptor ID can be used in conjuction with it as a sub-object. It is easy to understand that a path change will essentially mean changing the contents of the explicit-route object and/or inserting/deleting a new one for the purpose of p2mp support. The pp2mp ID, which is added on once the PCE descriptor IDs are added with the explicit route object being processed by every next hop, will be thus spanned over the entire PCEDA. At the egress side, the total pp2mp ID is recognized and the LSP contents mapped onto the corresponding client paths. 2. The other option is to have a separate messaging system for PCEMP that only has the PCEMP header and the PCE descriptor ID as the payload. The PCE nodes can maintain a local counter for these IDs, which are generated randomly but become fixed for any set of adjacent path computation. The scope of this deployment is again implementation specific. It might act as an encapsulated packet within standard routing or signaling protocols, or may be run independently before control and management information is exchanged, or may be periodically run to maintain the "soft-state" like conditions. In either case, the p2mp TE LSP path computation is independent of the number of clients (or end points) that are attached to the PCE node, resulting in clear scalability enhancements. It is also evident that the make-before-break conditions in modifying p2mp TE LSPs can be easily done without much overhead and computation intensive operations. Choi, Guha Informational [Page 14] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 5.1 QoS oriented p2mp path computation provisioning in PCE For bandwidth-on-demand services, the QoS flow classes are mapped onto individual PCE descriptor IDs using soft-memory concepts, as shown in Section 4.4, so that route optimization is guaranteed for reliable bandwidth provisioning in case of protection and restoration using the central Controller in PCE nodes [3]. The central Controller acts analogous to a bandwidth controller in this case. The algorithm tree helps in guaranteeing an optimal route path all the time, thus provisioning (as well as tree generation/bifurcation/extensions is optimal globally all the time) is guaranteed for bandwidth-on-demand applications. This is possible to do while extracting the QoS field or indicative object/TLV in the corresponding control packet and then generating the PCE FSM based on this. This also has the feature that one single PCE node that is part of multiple LSPs requesting different levels of bandwidth may support them by the corresponding FSM execution and optimized routes, ensuring real-time provisioning and path protection for multiple LSPs that may pass through it. It also has the compatibility of supporting both P2P and P2MP scenarios in either case based on what the LSP setup and teardown demands. Also, in the trivial case the p2mp support using PCEMP degenerates to what the single p2p case is so far as performance and scalability is concerned. 6. Conclusion One of the important things is that the soft-nature of the PCEMP FSM helps in supporting an arbitrary number of client nodes so far as p2mp applications are concerned. The nominal value of such nodes is a function of the deployment scenario, based on the domain that is being controlled by the service provider, or in the case where different service providers have an agreement about providing inter-domain end-to-end QoS services. The algorithm's performance is independent of the number of leaf nodes, which makes PCEMP scalable to large inter-domain and multi-domain networks considerably. Apart from this, PCEMP also helps the p2mp participating nodes to advertise their capabilities based on the set of constraints that it can support. Using PCEMP for p2mp TE LSP path computation and global reoptimization also serves the dual purpose of topology reconfiguration. The main metrics for evaluating PCEMP as a facilitator for p2mp support in PCE are 1. scalability, 2. cost of setup/teardown of the tree and/or its subtrees and branches, and 3. reliability and robustness. The intent of this draft is to provide a general framework for p2mp support in PCE architectures, and is based on a scenario where the p2mp path computation is triggered by a QoS requirement. However, the algorithm is very general for path computation and the p2mp support can be invoked by any general criterion. The PCEMP framework also supports the co-existence of other path computing algorithms, as seen in Section 4.4, and can invoke them based solely on the data (here the bandwidth-on-demand) that is being processed. This draft shows a complete bandwidth sharing scheme which might help in significant bandwidth savings for bandwidth-on-demand scenarios in PCE architectures. Choi, Guha Informational [Page 15] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 7. Security Considerations As outlined in the scope of the PCE WG charter, one of the main area for standardization is the specification of a communication protocol for use between LSRs(termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol must be capable of representing requests for path computation including a full set of constraints, must be able to return multiple paths with consideration of confidentiality and security, and must itself be secure. The impact of the use of the PCEMP architecture is relatively much secure as the PCEDA are computed and distributed internal to the PCE unit. An increase in inter-domain information flows and the facilitation of inter-domain path establishment through PCEMP does not increase the existing vulnerability to security attacks. It should be remembered that PCEMP works by an invoked logic scheme local to each participating PCE unit, and the protocol invoke is brought into play only when there is a significant change in the data profile within the time of goodness of fit. However, it is expected that the PCE solutions will address security issues mentioned in [Ash] in details using authentication and security techniques. 8. IANA Considerations This document makes no requests for IANA action. 9. Acknowledgements This work was supported by the Ministry of Information and Communications (MIC), Republic of Korea 10. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Choi, Guha Informational [Page 16] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 12. Informational References [1] Yasukawa, S. ed., "Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", Internet Draft, draft-ietf-mpls-p2mp-sig-requirement-04.txt, December 2005 [2] Choi, J.K., and Guha, D., "Path Computation Element Metric Protocol (PCEMP)", Internet Draft, draft-choi-pce-metric-protocol-04.txt, March 2006 [3] Choi, J.K., Guha, D. et al., "Fast End-to-End Restoration Mechanism with SRLG using Centralized Control", Internet Draft, draft-choi-pce-e2e-centralized-restoration-srlg-05.txt, March 2006 [4] Choi, J.K. and Guha, D., "Fast IPv6 PCE peer Advertisement using PCEMP", Internet Draft, draft-choi-pcemp-ipv6-04.txt, March 2006 [5] Mannie, E. et al., "Generalized Multi-Protocol Label Switching Architecture", Internet Draft, draft-ietf-ccamp-gmpls-architecture-07.txt, November 2003. [6] Papadimitriou, D. and Mannie, E. (Editors), "Analysis of Generalized Multi-Protocol Label Switching (GMPLS) based Recovery Mechanisms (Including Protection and Restoration)", Internet Draft, draft-ietf-ccamp-gmpls-recovery-analysis-03.txt, October 2004. Choi, Guha Informational [Page 17] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 [7] Mannie, E. and Papadimitriou, D. (Editors), "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", Internet Draft, draft-ietf-ccamp-gmpls-recovery-terminology-04.txt, October 2004. [8] Lang, P. and Rajagopalan, B. (Editors), "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", Internet Draft, draft-ietf-ccamp-gmpls-recovery-functional-02.txt, October 2004. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999. [RFC3209] Awduche, D., et. al., "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req-00.txt, March 2004 (WIP). [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-06.txt, January 2004 (work in progress). [MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for Multi-Region Networks", draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, February 2004 (WIP). Le Roux, J.L., Ed., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-03.txt, February 2006 Ash, J., and Le Roux, J.L., Ed., "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-04.txt, February 2006 13. Authors' Addresses Jun Kyun Choi Information and Communications University (ICU) 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Dipnarayan Guha Email: dg236@cornell.edu Choi, Guha Informational [Page 18] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006 14. Full Copyright Statement Copyright (C) The Internet Society (2006). All Rights Reserved. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Choi, Guha Informational [Page 19] Internet Draft draft-choi-pce-p2mp-framework-03.txt March 2006