Internet Engineering Task Force Q. Zhao, Ed. Internet-Draft Huawei Technology Intended Status: Standards Track Daniel King, Ed. Created: December 30, 2009 Old Dog Consulting Expires: May 1, 2010 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths draft-ietf-pce-pcep-p2mp-extensions-06.txt Abstract Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on May 1, 2010. Zhao and King [Page 1] Internet-Draft December 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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. 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]. Zhao and King [Page 2] Internet-Draft December 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 3.2. Efficient Presentation of P2MP TE LSPs . . . . . . . . . . 3.3. P2MP Path Computation Request/Reply Message Extensions . . 3.3.1. The Extension of the RP Object . . . . . . . . . . . . 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 3.4. Request Message Format . . . . . . . . . . . . . . . . . . 3.5. Reply Message Format . . . . . . . . . . . . . . . . . . . 3.6. P2MP Objective Functions and Metric Types . . . . . . . . 3.6.1. New Object Functions . . . . . . . . . . . . . . . . . 3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 3.8. Non-Support by Back-Level PCE Implementations. . . . . . . 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . . 3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . . 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . . 3.12. Synchronization of P2MP TE Path Computation Requests . . . 3.13. Request and Response Fragmentation . . . . . . . . . . . . 3.13.1 Request Fragmentation Procedure . . . . . . . . . . . . 3.13.2 Response Fragmentation Procedure . . . . . . . . . . . 3.13.3 Fragmentation Examples . . . . . . . . . . . . . . . . 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . . 3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 4. Manageability Considerations . . . . . . . . . . . . . . . . . 4.1. Control of Function and Policy . . . . . . . . . . . . . . 4.2. Information and Data Models . . . . . . . . . . . . . . . 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 4.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . . 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . . 6.3. Object Function . . . . . . . . . . . . . . . . . . . . . 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . . 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . . 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . Zhao and King [Page 3] Internet-Draft December 2009 7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . . 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8.2. Informative References . . . . . . . . . . . . . . . . . . 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . . 1. Introduction 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 point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671]. The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. However, that specification does not provide a mechanism to request path computation of P2MP TE LSPs. This document presents extensions to PCEP to support P2MP path computation satisfying the set of requirements described in [PCE- P2MP-REQ]. This document relies on the mechanisms of PCEP for requesting path computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between ingress and egress LSRs and are appropriately combined by the branch LSRs using computation results from the PCE to determine the path of a P2MP TE LSP. One request message from a PCC may signal one or more S2L sub-LSP path computation requests to the PCE for a single P2MP LSP with certain constraints. Hence the S2L sub-LSPs belonging to a P2MP LSP can use one path computation request message or be split across multiple path computation messages. Zhao and King [Page 4] Internet-Draft December 2009 1.1 Terminology Terminology used in this document. TE LSP: Traffic Engineered Label Switched Path. LSR: Label Switch Router. OF: Objective Function: A set of one or more optimization criterion (criteria) used for the computation of a single path (e.g. path cost minimization), or the synchronized computation of a set of paths (e.g. aggregate bandwidth consumption minimization, etc.). P2MP: Point-to-Multipoint. P2P: Point-to-Point. This document also uses the terminology defined in [RFC4655], [RFC4875], and [RFC5440]. 2. Requirements This section summarizes the PCC-PCE Communication Requirements for P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]: 1. Indication of P2MP Path Computation Request 2. Indication of P2MP Objective Functions 3. Non-Support of P2MP Path Computation. 4. Non-Support by Back-Level PCE Implementations. 5. Specification of Destinations 6. Indication of P2MP Paths 7. Multi-Message Requests and Responses 8. Non-Specification of Per-Destination Constraints and Parameters 9. Path Modification and Path Diversity 10. Reoptimization of P2MP TE LSPs 11. Addition and Removal of Destinations from Existing Paths 12. Specification of Applicable Branch Nodes Zhao and King [Page 5] Internet-Draft December 2009 13. Capabilities Exchange 14. Path-Tree Diversity 3. Protocol Procedures and Extensions The following section describes the protocol extensions required to satisfy the requirements specified in the Requirements section (Section 2) of this document. 3.1. P2MP Capability Advertisement 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol Since [RFC5088] has specified that we cannot add an additional sub-TLV (type-length-value) to the PCEP TLV, we will define a new bit to go in the existing 32 bit PCE capabilities flags to indicate the capability of P2MP computation. 3.1.2. Open Message Extension Based on the Capabilities Exchange requirement described in [PCE-P2MP-REQ], if a PCE does not advertise its P2MP capability during discovery, PCEP should be used to allow a PCC to discover which PCEs are capable of supporting P2MP path computation. To satisfy this requirement, we extend the OPEN object format by including a new defined TLV for the capability of P2MP in the optional field. The new defined capability TLV allows the PCE to advertise its P2MP path computation capability. The TLV type number will be assigned by IANA and is requested in the IANA Considerations section (Section 6) of this document. The length value is 2 bytes. The value field is set to default value 0. Note that the capability TLV is meaningful only for a PCE so it will typically appear only in one of the two Open messages during PCE session establishment. However, in case of PCE cooperation (e.g., inter-domain), when a PCE behaving as a PCC initiates a PCE session it SHOULD also indicate its path computation capabilities. 3.2. Efficient Presentation of P2MP LSPs When specifying additional leaves, or optimizing existing P2MP TE LSPs as specified in [PCE-P2MP-REQ], it may be necessary to pass existing P2MP LSP route information between the PCC and PCE in the request and reply message. In each of these scenarios, we need new path objects for efficiently passing the existing P2MP LSP between the PCE and PCC. Zhao and King [Page 6] Internet-Draft December 2009 We specify the use of the Explicit Route Object (ERO) to encode the explicit route of a TE LSP through the network. The Secondary Explicit Route Object (SERO) is used to specify the explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and Secondary Reported Route Object (SERO) are used to report the routes of an existing TE LSP for which a reoptimization is desired. The format and contents of the ERO and RRO are defined in [RFC5440]. The format and contents of the SERO and SRRO are defined in [RFC4875]. A new class and type are requested for SERO and SRRO in the IANA Considerations section of this document. 3.3. P2MP Path Computation Request/Reply Message Extensions The existing P2P RP (Request Parameters) object has been extended so that a PCC can signal a P2MP path computation request to the PCE receiving the PCEP request. The END-POINT object is also extended to improve the efficiency of the message exchange between PCC and PCE in the case of P2MP path computation. 3.3.1. The Extension of the RP Object The PCE path computation request and reply message will need the following additional parameters to allow a receiving PCE to identify that the request and reply message has been fragmented across multiple messages, has been requested for a P2MP path and to specify if the route is represented in the compressed or uncompressed format. The F bit is added to the flag bits of the RP object to indicate to the receiver that the request is part of a fragmented request, or is not a fragmented request. The N 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 P2MP or not. The E bit is added in the flag bits field of the RP object to signal the receiver of the message that the route is in the compressed format or not. By default, the path returned by the PCE will use the compressed format. The extended format of the RP object body to include the F bit, N bit and the E bit is as follows: Zhao and King [Page 7] Internet-Draft December 2009 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 |F|N|E| |O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RP Object Body Format The following flags are added in this draft: o F ( RP fragmentation bit - 1 bit): 0: This indicates that the RP is not fragmented or it is the last piece of the fragmented RP. 1: This indicates that the RP is fragmented and this is not the last piece of the fragmented RP and the receiver needs to wait until it receives an RP with the same RP-ID and with the F bit is set to 0. o N ( P2MP bit - 1 bit): 0: This indicates that this is not PCReq/PCRep for P2MP. 1: This indicates that this is PCReq or PCRep message for P2MP. o E ( ERO-compression bit - 1 bit): 0: This indicates that the route is not in the compressed format. 1: This indicates that the route is in the compressed format. 3.3.2. The New P2MP END-POINTS Object To represent the end points for a P2MP path efficiently, we define a new type of end-points object for the P2MP path. With the new END-POINTS object, the PCE path computation request message is expanded in a way which allows a single request message to list multiple destinations. Zhao and King [Page 8] Internet-Draft December 2009 There are 4 types of leaves in a P2MP request: o New leaves to add; o Old leaves to remove; o Old leaves whose path can be modified/reoptimized; o Old leaves whose path must be left unchanged. A given END-POINTS object gathers the leaves of a given type. The type of leaf in a given END-POINTS object is identified by the END- POINTS object leaf type field. Four values are possible for the leaf type field: 1. New leaves to add; 2. Old leaves to remove; 3. Old leaves whose path can be modified/reoptimized; 4. Old leaves whose path must be left unchanged. With the new END-POINTS object, the END-POINTS portion of a request message for the multiple destinations can be reduced by up to 50% for a P2MP path where a single source address has a very large number of destinations. Note that a P2MP path computation request can mix the different types of leaves by including several END-POINTS object per RP object as shown in the PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format in following Request Message Formats section (Section 3.4). The format of the new END-POINTS object body 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The New P2MP END-POINTS Object Body Format for IPv4 Zhao and King [Page 9] Internet-Draft December 2009 The format of the END-POINTS object body for IPv6 (Object-Type 4) 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 IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The New P2MP END-POINTS Object Body Format for IPv6 The END-POINTS object body has a variable length. These are multiples of 4 bytes for IPv4, and multiples of 16 bytes for IPv6. 3.4. Request Message Format As per [RFC5511] the RBNF format of the PCReq message is as follows: Below is the message format for the request message: ::= where: ::= [] [] [] [] [] [] Zhao and King [Page 10] Internet-Draft December 2009 where: ::= [][] [] ::=[][] ::=[] Figure 4: The Message Format for the Request Message Note we preserve compatibility with the [RFC5440] definition of . At least one instance of must be present in this definition. Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license. 3.5. Reply Message Format As per [RFC5511] the RBNF format of the PCRep message is as follows: Below is the message format for the reply message: ::= ::= [] [] [] where: ::= [][] ::=(ERO)|(SERO)|] ::=[] [] [] [] [] Figure 5: The Message Format for the Reply Message The optional END-POINTS in the reply message is used to specify which paths are removed, changed, not changed, or added for the request. The path is only needed for the end points which are added or changed. Zhao and King [Page 11] Internet-Draft December 2009 If the E bit (ERO-Compress bit) was set to 1 in the request then the path will be formed by an ERO followed by a list of SEROs. Note that we preserve compatibility with the [RFC5440] definition of and the optional and . Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license. 3.6. P2MP Objective Functions and Metric Types 3.6.1. New Object Functions Six objective functions have been defined in [RFC5541] for P2P path computation. This document defines two additional objective functions, namely SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP path computation. Hence two new objective function codes have to be defined. The description of the two new objective functions is as follows. Objective Function Code: 7 (suggested value, to be assigned by IANA) Name: Shortest Path Tree (SPT) Description: Minimize the maximum source-to-leaf cost with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified. (e.g. TE or IGP metric) Objective Function Code: 8 (suggested value, to be assigned by IANA) Name: Minimum Cost Tree (MCT) Description: Minimize the total cost of the tree, that is the sum of the costs of tree links, with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified. Processing these two new objective functions is subject to the rules defined in [RFC5541]. 3.6.2. New Metric Object Types There are three types defined for the object in [RFC5440], namely, the IGP metric, the TE metric and the Hop Count metric. This document defines three additional types for the object: the P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. They encode the sum of the metrics of all links of the tree. We propose the following values for these new metric types: Zhao and King [Page 12] Internet-Draft December 2009 o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA) o P2MP TE metric: T=9 (suggested value, to be assigned by IANA) o P2MP hop count metric: T=10 (suggested value, to be assigned by IANA) 3.7. Non-Support of P2MP Path Computation. o If a PCE receives a P2MP path request and it understands the P2MP flag in the RP object, but the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object and corresponding Error-Value. The original P2MP path computation request MUST then be cancelled. New Error-Types and Error-Values are requested in the IANA Considerations section of this document. o If the PCE does not understand the P2MP flag in the RP object, then the PCE MUST send a PCErr message with a new error type "Unknown RP flag". 3.8. Non-Support by Back-Level PCE Implementations. If a PCC inadvertently sends a P2MP request to a PCE which does not support P2MP path computation and therefore the PCEP P2MP extensions, then the PCE SHOULD reject the request. 3.9. P2MP TE Path Reoptimization Request A reoptimization request for a P2MP TE path is specified by the use of the R bit within the RP object as defined in [RFC5440] and is similar to the reoptimization request for a P2P TE path. The only difference is that the user must insert the list of RROs and SRROs after each type of END-POINTS in the PCReq message, as described in the Request Message Format section (Section 3.4) of this document. An example of a reoptimization request and subsequent PCReq message is described below: Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 3 RRO list OF (optional) Figure 6: PCReq Message Example 1 for Optimization Zhao and King [Page 13] Internet-Draft December 2009 In this example, we request reoptimization of the path to all leaves without adding or pruning leaves. The reoptimization request would use an END-POINT type 3. The RRO list would represent the P2MP LSP before the optimization and the modifiable path leaves would be indicated in the END-POINTS object. It is also possible to specify specific leaves whose path cannot be modified. An example of the PCReq message in this scenario would be: Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 7: PCReq Message Example 2 for Optimization A P2MP reoptimization request could contain a parameter that allows the PCC to express a cost-benefit reoptimization threshold for the whole LSP as well as per destination. This function would be set by the local PCC and subject to the PCE policy [RFC5394]. This specification does not provide a mechanism to address this threshold function. The function may be addressed in a future document. 3.10. Adding and Pruning Leaves to the P2MP Tree When adding new leaves or removing old leaves to the existing P2MP tree, by supplying a list of existing leaves, it SHOULD be possible to optimize the existing P2MP tree. This section explains the methods to add new leaves or remove old leaves to the existing P2MP tree. To add new leaves the user must build a P2MP request using END-POINTS with leaf type 1. To remove old leaves the user must build a P2MP request using END-POINTS with leaf type 2. The PCC must also provide the list of old leaves and indicate if they should be reoptimized or not by including END-POINTS with leaf type 3, leaf type 4 or both. The error values when the conditions are not satisfied (i.e., when there is no END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 or 2), are documented in the IANA Considerations section (Section 6) of this document. Zhao and King [Page 14] Internet-Draft December 2009 For old leaves the user must provide the old path as a list of RROs that immediately follows each END-POINTS object. This document specifies error values when specific conditions are not satisfied. The following examples demonstrate full and partial reoptimization of existing P2MP LSPs: Case 1: Adding leaves with full reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 1 RRO list END-POINTS for leaf type 3 RRO list OF (optional) Figure 8: Adding Leaves with Full Reoptimization Case 2: Adding leaves with partial reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 1 END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 9: Adding Leaves with Partial Reoptimization Case 3: Adding leaves without reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 1 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 10: Adding Leaves without Reoptimization Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list OF (optional) Figure 11: Pruning Leaves with Full Reoptimization Zhao and King [Page 15] Internet-Draft December 2009 Case 5: Pruning leaves with partial reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 12: Pruning Leaves with Partial Reoptimization Case 6: Pruning leaves without reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 13: Pruning Leaves without Reoptimization Case 7: Adding and pruning leaves full reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list OF (optional) Figure 14: Adding and Pruning Leaves full Reoptimization Zhao and King [Page 16] Internet-Draft December 2009 Case 8: Adding and pruning leaves with partial reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 3 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 15: Adding and Pruning Leaves with Partial Reoptimization Case 9: Adding and pruning leaves without reoptimization of existing paths Common Header RP with P2MP flag/R bits set END-POINTS for leaf type 1 END-POINTS for leaf type 2 RRO list END-POINTS for leaf type 4 RRO list OF (optional) Figure 16: Adding and Pruning Leaves without Reoptimization 3.11. Discovering Branch Nodes Before computing the P2MP path, a PCE must be provided means to know which nodes in the network are capable of acting as branch LSRs. A PCE can discover such capabilities by using the mechanisms defined in [RFC5073]. 3.11.1 Branch Node Object The PCC can specify a list of nodes that can be used as branch nodes or a list of nodes that cannot be used as branch nodes by using the a BRANCH NODE Capability (BNC) Object. The BNC Object has the same format as the IRO object defined in [RFC5440] except that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- types are also defined: Zhao and King [Page 17] Internet-Draft December 2009 o Branch node list: List of nodes that can be used as branch nodes. o Non-branch node list: List of nodes that cannot be used as branch nodes. The object can only be carried in a PCReq message. A Path Request may carry at most one BRANCH NODE Object. The Object-Class and Object-types will need to allocated by IANA. The IANA request is documented in Section 6.5. 3.12. Synchronization of P2MP TE Path Computation Requests There are cases when multiple P2MP LSPs computations need to be synchronized. For example, one P2MP LSP is the designated backup of another P2MP LSP. In this case, path diversity for these dependent LSPs may need to be considered during the path computation. The synchronization can be done by just using the existing SVEC functionality. An example of synchronizing two P2MP LSPs, each has two leaves for Path Computation Request Messages is illustrated as below: Common Header SVEC for sync of LSP1 and LSP2 OF (optional) END-POINTS1 for P2MP RRO1 list END-POINTS2 for P2MP RRO2 list Figure 17: PCReq Message Example for Synchronization This specification also defines two new flags to the SVEC object for P2MP path dependent computation requests. The first new flag is to allow the PCC to request that the PCE should compute a secondary P2MP pathtree with partial path diversity for specific leaves or a specific S2L sub-path to the primary P2MP path tree. The second flag, would allow the PCC to request that partial paths should be link direction diverse. Zhao and King [Page 18] Internet-Draft December 2009 The format of the SVEC object body 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |S|N|L|P|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number #1 | // // | Request-ID-number #M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: SVEC Body Object Format with Additional Flags The following flags are added to the SVEC object body in this draft: o P ( Partial Path Diversity bit - 1 bit): When set this would indicate a request for path diversity for a specific leaf, a set of leaves or all leaves. o D ( Link Direction Diverse bit - 1 bit): When set this would indicate a request that a partial path or paths should be link direction diverse. 3.13. Request and Response Fragmentation In certain scenarios the P2MP computation request may not fit into a single request or response message. For example, if a tree has many hundreds or thousands of leaves. Then the request or response may need to be fragmented into multiple messages. The F bit has been outlined in the Extension of the RP Object section (Section 3.3.1) of this document. The F bit is used in the RP object header to signal that the initial request or response was too large to fit into a single message and will be fragmented into multiple messages. In order to indentify the single request or response, each message will use the same request ID. 3.13.1 Request Fragmentation Procedure If the initial request is too large to fit into a single request message the PCC will split the request over multiple messages. Each message sent to the PCE, except the last one, will have the F bit set in the RP object to signify that the request has been fragmented into multiple messages. In order to indentify that a series of request messages represents a single request, each message will use the same request ID. Zhao and King [Page 19] Internet-Draft December 2009 The assumption is that request messages are reliably delivered and in sequence since PCEP relies on TCP. 3.13.2 Response Fragmentation Procedure Once the PCE computes a path based on the initial request, a response is sent back to the PCC. If the response is too large to fit into a single response message the PCE will split the request over multiple messages. Each message sent to the PCE, except the last one, will have the F bit set in the RP object to signify that the response has been fragmented into multiple messages. In order to identify that a series of response messages represents a single request, each message will use the same request ID. Again, the assumption is that response messages are reliably delivered and in sequence since PCEP relies on TCP. 3.13.3 Fragmentation Examples The following example illustrates the PCC sending a request message with Req-ID1 to the PCE, in order to add one leaf to an existing tree with 1200 leaves. The assumption is that the one request message can hold up to 800 leaves. In this scenario, the original single message needs to be fragmented and sent using two smaller messages, which have the Req-ID1 specified in the RP object, and with the F bit set on the first message. Common Header RP1 with Req-ID1 and P2MP flag and F bit set OF (optional) END-POINTS1 for P2MP RRO1 list Common Header RP2 with Req-ID1 and P2MP flag and F bit cleared OF (optional) END-POINTS1 for P2MP RRO1 list To handle the scenario that the last fragmented message piece is lost, the receiver side of the fragmented message may start a timer once it receives the first piece of the fragmented message. When the timer expires and it has not received the last piece of the fragmented message, it should send an error message to the sender to signal that it has received an incomplete message. 3.14. UNREACH-DESTINATION Object The PCE path computation request may fail because all or a subset of the destinations are unreachable. Zhao and King [Page 20] Internet-Draft December 2009 In such a case, the UNREACH-DESTINATION object allows the PCE to optionally specify the list of unreachable destinations. This object can be present in PCRep messages. There can be up to one such object per RP. The following UNREACH-DESTINATION objects will be required: UNREACH-DESTINATION Object-Class is to be assigned by IANA. UNREACH-DESTINATION Object-Type for IPv4 is to be assigned by IANA UNREACH-DESTINATION Object-Type for IPv6 is to be assigned by IANA. The format of the UNREACH-DESTINATION object body for IPv4 (Object- Type=1) 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 IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: UNREACH-DESTINATION Object Body for IPv4 The format of the UNREACH-DESTINATION object body for IPv6 (Object- Type=2) 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 IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: UNREACH-DESTINATION Object Body for IPv6 Zhao and King [Page 21] Internet-Draft December 2009 3.15. P2MP PCEP Error Objects and Types To indicate errors associated with the P2MP path request, a new Error-Type (16) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object: Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path request and the PCE is not capable to satisfy the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP ERROR object (Error-Type=16) and an Error-Value(Error-Value=1). The corresponding P2MP path computation request MUST also be cancelled. Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request and the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error- Value (Error-Value=2). The corresponding P2MP path computation request MUST be also cancelled. To indicate an error associated with policy violation, a new error value "P2MP Path computation not allowed" should be added to the existing error code for policy violation (Error-Type=5) as defined in [RFC5440]: Error-Type=5; Error-Value=6: if a PCE receives a P2MP path computation request which is not compliant with administrative privileges (i.e., "The PCE policy does not support P2MP path computation"), the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=5) and an Error-Value (Error-Value=6). The corresponding P2MP path computation request MUST also be cancelled. 3.16. PCEP NO-PATH Indicator To communicate the reasons for not being able to find P2MP path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Nature of Issue|C| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: The Format of the NO-PATH Object Body One new bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH Object: Zhao and King [Page 22] Internet-Draft December 2009 0x24: when set, the PCE indicates that there is a reachability problem with all or a subset of the P2MP destinations. Optionally the PCE can specify the destination or list of destinations that are not reachable using the new UNREACH-DESTINATION object defined in section 3.6. 4. Manageability Considerations [PCE-P2MP-REQ] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how manageability requirements mentioned in [PCE-P2MP-REQ] 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 P2MP] are already covered there. 4.1. 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). 4.2. Information and Data Models As described in [PCE-P2MP-REQ], MIB objects MUST be supported for PCEP extensions specified in this document. 4.3. Liveness Detection and Monitoring There are no additional considerations beyond those expressed in [RFC5440], since [PCE-P2MP-REQ] does not address any additional requirements. 4.4. Verifying Correct Operation There are no additional considerations beyond those expressed in [RFC5440], since [PCE-P2MP-REQ] does not address any additional requirements. 4.5. Requirements on Other Protocols and Functional Components As described in [PCE-P2MP-REQ], the PCE MUST obtain information about the P2MP signaling and branching capabilities of each LSR in the network. Zhao and King [Page 23] Internet-Draft December 2009 Protocol extensions specified in this document does not provide such capability. Other mechanisms MUST be present. The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) can be used to advertise capabilities to PCCs. A new flag (value=10) could be defined in PCE-CAP-FLAGs Sub-TLV to indicate P2MP path computation capability. Extensions for PCE discovery are out of scope of this document. 4.6. Impact on Network Operation It is expected that use of PCEP extensions specified in this document does not have significant impact on network operations. 5. Security Considerations As described in [PCE-P2MP-REQ], 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. 6. IANA Considerations IANA maintains a registry of PCEP parameters. A number of IANA considerations have been highlighted in previous sections of this document. IANA is requested to make the following allocations. 6.1 P2MP Capability TLV As described in Section 3.1.2, the newly defined P2MP capability TLV allows the PCE to advertize its P2MP path computation capability. IANA is requested to make the following allocation from the "PCEP TLV Type Indicators" sub-registry. Value Description Reference 6 P2MP capability This.I-D 6.2 Request Parameter Bit Flags As described in Section 3.3.1., three new RP Object Flags have been defined. IANA is requested to make the following allocations from the "RP Object Flag Field" Sub-Registry: Zhao and King [Page 24] Internet-Draft December 2009 Bit Description Reference 18 Fragmentation(F-bit) This.I-D 19 P2MP (N-bit) This.I-D 20 ERO-compression (E-bit) This.I-D 6.3 Objective Function As described in Section 3.6.1., two new Objective Funtions have been defined. IANA is requested to make the following allocations from the "Objective Function" sub-registry: Code Point Name Reference 7 SPT This.I-D 8 MCT This.I-D 6.4 Metric Object Types As described in Section 3.6.2., three new metric object T fields have been defined. IANA is requested to make the following allocations from the "METRIC Object T Field" sub-registry: Value Description Reference 8 P2MP IGP metric This.I-D 9 P2MP TE metric This.I-D 10 P2MP hop count metric This.I-D 6.5 PCEP Objects As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects have been defined. IANA is requested to make the following allocations from the "PCEP Objects" sub-registry Object-Class Value 25 Name UNREACH-DESTINATION Object-Type 1: IPv4 2: IPv6 3-15: Unassigned Reference This.I-D Object-Class Value 26 Name SERO Object-Type 1: SERO 2-15: Unassigned Reference This.I-D Zhao and King [Page 25] Internet-Draft December 2009 Object-Class Value 27 Name SRRO Object-Type 1: SRRO 2-15: Unassigned Reference This.I-D Object-Class Value 28 Name Branch Node Capability Object Object-Type 1: Branch node list 2: Non-branch node list 3-15: Unassigned Reference This.I-D 6.6 PCEP Error Objects and Types As described in Section 3.15., a number of new PCEP-ERROR Object Error Types and Values have been defined. IANA is requested to make the following allocations from the "PCEP-ERROR Object Error Type and Value" sub-registry: Error Type Meaning Reference 5 Policy violation Error-value=6: This.I-D P2MP Path computation is not allowed 16 P2MP Error This.I-D Error-Value=0: Unassigned Error-Value=1: This.I-D The PCE is not capable to satisfy the request due to insufficient memory Error-Value=2: This.I-D The PCE is not capable of P2MP computation 17 P2MP Error This.I-D Error-Value=0: Unassigned Error-Value=1: This.I-D The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 2 Error-Value=2: This.I-D The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 3 Error-Value=3: This.I-D The PCE is not capable to satisfy the request due to no END-POINTS with leaf type 4 Zhao and King [Page 26] Internet-Draft December 2009 6.7 PCEP NO-PATH Indicator As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field has been defined. IANA is requested to make the following allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry: Bit Description Reference 24 P2MP Reachability Problem This.I-D 7. Acknowledgements The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal and Vishwas Manral for their valuable comments and input on this draft. 8. References 8.1. Normative References [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5073] Vasseur, JP., Le Roux, JL., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007. [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. [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., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. Zhao and King [Page 27] Internet-Draft December 2009 [RFC5511] Farrel, F., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC5541] Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC5541, December 2008. 8.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)" RFC 5671, October 2009. [PCE-P2MP-REQ] Yasukawa, S. and A. Farrel, "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", draft-ietf-pce-p2mp-req-04 (work in progress), December 2009. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, J., "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. 9. Authors' Addresses Quintin Zhao (editor) Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Daniel King (editor) Old Dog Consulting UK Email: daniel@olddog.co.uk Fabien Verhaeghe Thales Communication France 160 Bd Valmy 92700 Colombes France Email: fabien.verhaeghe@gmail.com Zhao and King [Page 28] Internet-Draft December 2009 Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email: takeda.tomonori@lab.ntt.co.jp Zafar Ali Cisco systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: zali@cisco.com Julien Meuric France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, julien.meuric@orange-ftgroup.com 9.1 Contributors Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: jeanlouis.leroux@orange-ftgroup.com Mohamad Chaitou France Email: mohamad.chaitou@gmail.com Appendix A. RBNF Code Fragments This appendix contains the full set of code fragments defined in this document. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Zhao and King [Page 29] Internet-Draft December 2009 o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Below is the message format for the request message: ::= where: ::= [] [] [] [] [] [] where: ::= [][] [] ::=[][] ::=[] Below is the message format for the reply message: Below is the message format for the reply message: ::= ::= [] [] [] Zhao and King [Page 30] Internet-Draft December 2009 where: ::= [][] ::=(ERO)|(SERO)|] ::=[] [] [] [] [] Zhao and King [Page 31] Internet-Draft December 2009