CCAMP Working Group J.L. Le Roux France Telecom Internet Draft D. Papadimitriou Alcatel Category: Standard Track Expires: April 2006 October 2005 Handling Path Constraints in Generalized RSVP-TE signaling draft-leroux-ccamp-rsvp-te-path-constr-00.txt Status of this Memo 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. 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 April 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In various situations, it would be useful to include path parameters such as delay, jitter, number of hops, cost, optical power, within Generalized MPLS signaling. For that purpose, this draft extends GMPLS RSVP-TE, for signaling path constraint, and accumulating path parameters. It defines protocol elements and procedures, that allow signaling path_constraints and accumulating path parameters along the signaled path. TBD Standard Track - Expires March 2006 [Page 1] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt This draft only defines generic encoding rules and procedures. Specific encoding and procedures for each path parameter such as delay, hop count, jitter will be addressed in separate documents. Table of Contents 1. Terminology 2 2. Introduction 2 3. Overview of the Mechanism 4 4. Path_Constraints TLV 5 4.1. Description 5 4.2. Format 5 4.2.1. Path Parameter sub-TLV 6 4.3. Elements of procedure 6 5. The COMPOSITION object 7 5.1. Format 7 5.2. Elements of procedure 7 6. Procedures to setup a TE-LSP with Path_Constraints 8 6.1. Procedure for the Head-End LSR 8 6.2. Procedure for a transit LSR 8 6.3. Procedure for tail-end LSRs 9 7. Bi-directional LSPs 9 8. IANA Consideration 9 8.1. New RSVP C-Num and C-Type 9 8.2. New LSP Attributes TLV 10 8.3. New Path Parameters TLV Space 10 8.4. New Error Codes 10 8.5. Security issues 10 9. Intellectual Property Considerations 10 10. Normative References 11 11. Informative References 11 12. Authors' Address 12 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 1. Terminology This document uses terminology from the MPLS architecture document [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which inherits from the RSVP specification [RFC2205]. It also makes uses of the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and [RFC3473]. 2. Introduction Leroux et al. Standard Track - Expires March 2006 [Page 2] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt GMPLS control plane (see [GMPLS-ARCH]) supports routing and signaling of TE-LSPs for various switching technologies (PSC, L2SC, TDM, LSC, FSC). Those generalized TE LSPs are routed along paths that respect a set of TE constraints. Various TE constraints can be taken into account during path computation, such as, for instance, bandwidth, delay, hop-counts, and resource affinities. There are two types of TE constraints: - Link constraints: bandwidth, affinities, etc. - Spatial Path_Constraints: delay, jitter, hop count, etc. - Spectral Path Constraints: polarization, signal power, etc. Some GMPLS Path_Constraints such as jitter apply only to statistical multiplexing layers (PSC, L2SC). Some constraints such as polarization or signal power, applies only to photonic layers. Some other constraints such as hop count apply to any switching layer. GMPLS Path parameters such as delay, hop count, signal power result from the combination of link parameters. Their composition can be a simple accumulation / reduction function but this may be a more complex function. For instance the delay of a path is simply the accumulation of hop delays. Current Generalized RSVP-TE [RFC3473] signals, and performs local admission control based on link constraints only. Path_Constraints are not signaled within RSVP-TE. However there are some cases where it would be useful to signal paths constraints, and combine link parameters values along the path, in order to perform an admission control a tail-end LSR, based on Path_Constraints. This includes the following cases: - The TE-LSP path has been computed taking into account Path_Constraints, but with incomplete information on link parameters, or estimated link parameters. In that case it is useful to signal path constraint, and combine link parameters along the path, to let the tail-end perform admission control based on signaled constraints with respect to the composition of the corresponding link parameter(s). Also it is also useful to reflect actual path parameters value back to the Head-End LSR. - In case of inter-domain LSP it may be useful to signal Path_Constraints, and accumulate link parameters, so that a border router can take them into account when doing ERO expansion (case of per-domain path computation in [INTER- DOMAIN-COMP]). This draft defines Generalized RSVP-TE protocol extensions to allow for signaling of Path_Constraints, and accumulation of link parameters along the path. Leroux et al. Standard Track - Expires March 2006 [Page 3] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt The document is built as follows: - Section 3 gives an overview of the solution. - Section 4 defines a new Path Constraint TLV, to be carried within the LSP_REQUIRED_ATTRIBUTE object, and used to encode Path Constraints. - Section 5 defines a new object called the COMPOSITION object, used to build path parameters based on a composition of link parameters along the signaled path. - Finally, section 6 defines elements of procedures for head-end, transit, and tail-end LSRs. This document only defines generic encoding and procedures. Specific encoding, procedures and accumulation rules is path parameter such as delay, hop count, jitter and LSP class specific and will be addressed in separate documents. 3. Overview of the Mechanism As mentioned in the previous section, it would be useful in various situations to signal Path_Constraints such as maximum delay or maximum hop count (in particular during for loose paths), within RSVP-TE, and to combine link parameters along the path, in order to determine path parameters such as path delay or path hop count. A new Path Constraints TLV is defined for being carried within the LSP_REQUIRED_ATTRIBUTE object [LSP-ATTR]. It is used to carry particular value such as upper or lower bounds for a set of path parameters or a value range. Values are fixed by the head-end LSR and are not modified along the path. A new COMPOSITION object is defined to compose link parameter values and determine end-to-end significant parameters along the path of the LSP. It is updated at each hop, basically each hop combines received value with its own contribution to the path parameter. The procedure to signal an LSP with Path_Constraints is as follows: - The head-end sends a Path message that includes: - A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE object, that encodes for each path constraint a set of parameters. - An COMPOSITION object that contains a set of path parameters, initially set to the least significant value. - At each transit LSR, each value included in the COMPOSITION object value is updated based on local hop contribution to each path parameter. It is assumed that the composition function is uniquely defined for each of these parameters. - The tail-end LSR performs admission control for each parameter included in the Path_Constraints TLV. For each Leroux et al. Standard Track - Expires March 2006 [Page 4] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt parameter, the composed value in the COMPOSITION object is compared with the constraint value included as part of the Path Constraints TLV. Admission control formulas are specific to each parameter and are not addressed in this document. If all constraints are acceptable by the tail-end LSR, the later sends back a Resv message, reflecting the COMPOSITION object that is passed unchanged back to the head-end LSR. - In case one (or more) constraints are violated, the tail-end LSR sends a PathErr message with the Path_State_Removed flag set [RFC3473], and with a new Error code and value that indicates the violated constraint. The PathErr message also includes the COMPOSITION object that is passed unchanged back to the head-end LSR. 4. Path_Constraints TLV 4.1. Description The Path_Constraints TLV is defined as a new Attribute TLV of the LSP REQUIRED ATTRIBUTE object. It exactly follows the processing rules defined in [LSP-ATTR]. It contains a set of Path Parameter sub-TLVs, each encoding the constraint value for a given path parameter. Path Parameter sub-TLVs are to be specified on a per QoS service basis. 4.2. Format The Path Constraints TLV is encoded 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Path Parameters sub-TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Path_Constraints IANA has been asked to manage the space of TLV types in the REQUIRED_LSP_ATTRIBUTES Object [LSP-ATTRIB]. This document suggest Type = 2 for the Path Constraints TLV. Leroux et al. Standard Track - Expires March 2006 [Page 5] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt 4.2.1. Path Parameter sub-TLV Each path parameter sub-TLV encodes constraint value of a path parameter. It has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Path Parameter Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The identifier of the path parameter. Length: The length of the value field in bytes. Thus if no value field is present the length field contains the value zero. Each value field must be zero padded at the end to take it up to a four byte boundary - the padding is not included in the length so that a one byte value would be encoded in an eight byte TLV with length field set to one. Path Parameter Value: Scalar value of the path parameter. The unit will depend on on the type of parameter and will be defined in the document that introduces the parameter. 4.3. Elements of procedure An LSR that does not recognize a parameter type in the Path Constraint TLV MUST reject the Path message using a Path Error with Error Code "Unknown Path Parameter" and Error Value set to the parameter type. To avoid high rejection rate, a break bit (X) is introduced. Moreover, as values can be correlated to deliver a given service, it is expected that the processing of this bit will be defined such that it applies to the set of the corresponding Path Parameter sub-TLVs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |X| Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Leroux et al. Standard Track - Expires March 2006 [Page 6] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt | | // Path Parameter Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. The COMPOSITION object The COMPOSITION object is used to build path parameters, by combining hop parameters along the signaled path. It is carried within a Path message and updated at each hop. This object is also be carried in Resv and PathErr message, where it is passed unchanged, with no update at any hop. 5.1. Format The COMPOSITION object contains a set of Composed Path Parameter TLVs whose encoding is defined in 2.2.1, each TLV corresponding to a given accumulated parameter along the path. Note that a given parameter must have the same type, when carried in the LSP_REQUIRED ATTRIBUTE object or in the COMPOSITION object. Class = 10bbbbbb, C-Type = Composed Path Parameter TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | // Composed Path Parameter TLVs // | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To avoid a too massive rejection break bit (X) is introduced. Moreover, as values can be correlated to deliver a given service, it is expected that the processing of this bit will be defined such that it applies to the set of the corresponding sub-TLVs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |X| Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Composed Parameter Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Elements of procedure The ACCUMLATOR object has a C-Num of form 10bbbbbb. That is, an LSR that does not recognize this object should discard it silently. Leroux et al. Standard Track - Expires March 2006 [Page 7] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt An LSR that recognize this object but does not recognize a path parameter should set the break bit X. It is upon tail-end LSR decision (and subsequently the head-end LSR) to decide whether a non- complete composition is satisfactory or not for the whole Path. 6. Procedures to setup a TE-LSP with Path_Constraints 6.1. Procedure for the Head-End LSR To signal a LSP subject to a set of path_constraints, the head-end LSR sends a Path message that contains a Path Constraints TLV included within a LSP_REQUIRED_ATTRIBUTE object. Path_constraints are encoded within Path Parameter sub-TLVs. Note that the type of constraints and constraint values may be subject to change during the life of the LSP but are under full control of the head-end LSR. The Path message sent by the head-end LSR also contains an COMPOSITION object. Values in path parameters TLVs are initialized following rules specific to each parameter. These specific rules are out of the scope of this document, and will be addressed in documents introducing the parameters. Note that all path parameters present in the Path_Constraints TLV, MUST also appear in the COMPOSITION Object. In return some path parameters not subject to admission control may be present in the COMPOSITION object, and not in the Path_Constraints TLV. On receipt of a Resv message with a COMPOSITION object, the head-end LSR will be aware of the current LSP path parameters. The processing of these values by the Head-End LSR will be addressed in documents defining the path parameters. 6.2. Procedure for a transit LSR A Transit LSR MUST update each path parameter of a COMPOSITION object received in a Path message, and forward the updated object in the Path message sent downstream. Basically, for each path parameter it should combine the received value with its own "contribution" to the parameter. Combination rule depend on the parameter type, and must be addressed in the document defining the path parameter. When its local contribution changes, a transit LSR SHOULD send a Path message downstream with an appropriately updated COMPOSITION object. A COMPOSITION object included in a Resv message MUST be forwarded transparently by a transit LSR. The Path_Constraints TLV included in a Path/Resv message MUST be forwarded transparently by a transit LSR. Leroux et al. Standard Track - Expires March 2006 [Page 8] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt 6.3. Procedure for tail-end LSRs On receipt of a Path message containing a COMPOSITION object and no Path_Constraints TLV, a tail-end LSR MUST reflect the COMPOSITION object unchanged in a Resv message upstream to the head-end LSR. On receipt of a Path message containing both a COMPOSITION object and a Path_Constraints TLV in the LSP_REQUIRED_ATTRIBUTE object, the tail-end LSR MUST perform an admission control for each path parameter constraint in the Path_Constraints TLV. Each path parameter constraint must be compared, with the accumulated parameter value. Comparison rules will be addressed in documents defining the path parameters. If no constraint is violated, the COMPOSITION object MUST be reflected unchanged in a Resv message sent upstream. If at least one constraint is violated, the LSP must be rejected, and the tail-end LSR must send a PathErr message with the Path_State_Removed flag set, and with a new Error code (path constraint violation, and error value corresponding to the violated constraint. This PathErr message MUST also reflect the COMPOSITION object unchanged. 7. Bi-directional LSPs TBD 8. IANA Consideration 8.1. New RSVP C-Num and C-Type One new RSVP C-Num is defined in this document and should be assigned by IANA. o COMPOSITION object The C-Num should be of the form 10bbbbbb so that LSRs that do not recognize the object will ignore the object and discard it silently. One C-Type is defined for this object and should be assigned by IANA. o Path Parameter TLVs Recommended C-Type value 1. Leroux et al. Standard Track - Expires March 2006 [Page 9] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt 8.2. New LSP Attributes TLV This document defines one LSP Attributes TLV type as follows: - TLV Type Suggested value = 2 - TLV Name = Path_Constraints - allowed on LSP_REQUIRED_ATTRIBUTES object. 8.3. New Path Parameters TLV Space: The COMPOSITION object and the Path Constraints TLV defined above are constructed from TLVs. Each TLV correspond to a particular path parameter. Each TLV includes a 16-bit type identifier (the T-field). The same T-field values are applicable to the COMPOSITION object and the Path Constraints TLV. IANA is requested to manage TLV type identifiers as follows: - TLV Type (T-field value) - TLV Name 8.4. New Error Codes This document defines the following new error codes and error values. Numeric values should be assigned by IANA. Error Code Error Value "Unknown Path parameter TLV" Identifies the unknown TLV type code. "Path Constraint Violaton" Identifies the TLV type of the violated constraint. 8.5. Security issues This document adds one new object to the RSVP Path/Resv message, and a new TLV to the LSP_REQUIRED_ATTRIBUTE object. It does not introduce any new direct security issues and the reader is referred to the security considerations expressed in [RFC2205], [RFC3209] and [RFC3473]. 9. 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. Leroux et al. Standard Track - Expires March 2006 [Page 10] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt 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. 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. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473, January 2003. [LSP-ATTR] A. Farrel, et. al. , "Encoding of Attributes for MPLS LSP Establishment Using RSVP-TE", Work in Progress, draft-ietf-mpls-rsvpte-attributes-05.txt, May 2005. 11. Informative References [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2005. [INTER-DOMAIN-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter- domain MPLS Traffic Engineering LSP path Leroux et al. Standard Track - Expires March 2006 [Page 11] Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt computation methods", (work in progress). 12. Authors' Address Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France jeanlouis.leroux@francetelecom.com Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel.be 13. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. Leroux et al. Standard Track - Expires March 2006 [Page 12]