Network 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-01.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). Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 1] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt Abstract In various situations, it would be useful to include aggregated path parameters such as, e.g., delay, hop-count or optical power, within Generalized MPLS signaling. For that purpose, this draft extends GMPLS RSVP-TE, for signaling end-to-end path constraint, and aggregating path parameters along the path. This draft only defines generic encoding rules and procedures. Specific encoding and procedures for each path parameter will be addressed in separate documents. Table of Contents 1. Terminology.................................................3 2. Introduction................................................3 3. Overview of the mechanism...................................4 4. The 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 AGGREGATION 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/tail-end LSR........................8 7. Procedures for Bidirectional LSPs..........................10 8. Procedures for inter-domain LSPs...........................10 9. IANA Consideration.........................................10 9.1. New RSVP C-Num and C-Type..................................10 9.2. New LSP Attributes TLV.....................................10 9.3. New Path Parameters TLV Space:.............................10 9.4. New Error Codes............................................11 9.5. Security issues............................................11 10. Normative References.......................................11 11. Informative References.....................................12 12. Authors' Address:..........................................12 13. Intellectual Property Statement............................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. Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 2] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt 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 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 actually two types of TE LSP constraints: - Link constraints: bandwidth, affinities, etc. - Path_Constraints: delay, hop count, power loss, etc. Some path constraints such as delay or hop count apply to any switching capability. Some other path constraints apply only to a subset of switching capabilities, such as power loss for instance. GMPLS Path parameters such as delay, hop count, power loss result from the aggregation of link parameters. Such aggregation is actually an addition of link parameters along the path. For instance the delay of a path is the sum 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 in some situations, it would be useful to signal Paths Constraints, and aggregate link parameters values along the path, in order to perform an admission control based also on Path_Constraints. This includes the following situations: - 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 Constraints, and to aggregate link parameters along the path, so as to let LSRs perform admission control based on signaled constraints and aggregated link parameter(s). Also it is useful to reflect actual aggregated path parameters value back to the Head-End LSR. - In an inter-domain domain context (inter-area, inter-AS) it may be useful to signal Path_Constraints, and to aggregate link parameters, so that a border router can take them into account when doing ERO expansion (case of per-domain path Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 3] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt computation in [PD-PATH-COMP]). Also it may be useful to indicate to the head-end LSR the actual values of path parameters, as they cannot be deduced from the RRO. This draft defines Generalized RSVP-TE protocol extensions to allow for signaling of Path_Constraints, and for aggregation of link parameters along the path. The document is built as follows: - Section 3 gives an overview of the solution. - Section 4 defines a new Path Constraints TLV, to be carried within the LSP_REQUIRED_ATTRIBUTE object, and used to encode Path Constraints. - Section 5 defines a new object called the AGGREGATION object, used to build path parameters based on an aggregation 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 and procedures depend on each path parameter and will be addressed in separate documents. Note that procedures specific to the inter-domain case (inter-area or inter-AS) will be addressed in a future revision. 3. Overview of the mechanism As mentioned in the previous section, it would be useful in various situations (e.g. loose paths), to signal Path_Constraints such as maximum delay or maximum hop count within RSVP-TE, and to aggregate associated link parameters along the path, in order to determine actual path parameters such as path delay or path hop count, and perform admission control on these parameters. A new Path Constraints TLV is defined for being carried within the LSP_REQUIRED_ATTRIBUTE object [LSP-ATTR]. It is used to carry upper bounds for a set of path parameters. These values are fixed by the head-end LSR and are not modified along the path. A new RSVP AGGREGATION object is defined so as to aggregate link parameter values along the path and determine end-to-end path parameters. It is updated at each hop, basically each hop combines received value with its own contribution to the path parameter. The procedures to signal an LSP with Path_Constraints are as follows: - The head-end sends a Path message that includes: Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 4] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt - A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE object, that carries a set of path constraints. - An AGGREGATION object that contains a set of path parameters, initially set to the least significant value. - On each LSR along the path, each value included in the AGGREGATION object is updated based on local hop contribution to each path parameter. Admission control is then performed for each parameter included in the Path_Constraints TLV. The aggregate value in the AGGREGATION object is compared with the path constraint value included as part of the Path Constraints TLV. - If all constraints are respected then if the LSR is at transit the Path message is propagated downstream and if the LSR is at tail-end, the AGGREGATION object is reflected in a Resv message and passed unchanged back to the head-end LSR. . - In case one (or more) constraints are violated, the LSR sends back 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 AGGREGATION object that is passed unchanged back to the head-end LSR. 4. The 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. 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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 5] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt 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. Value: A set of one or more Path Parameter sub-TLVs 4.2.1. Path Parameter sub-TLV A path parameter sub-TLV encodes the value of a path parameter. It can be carried within a Path Constraints TLV of an LSP_REQUIRED_ATTRIBUTE object, or an AGGREGATION object. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Path Parameter Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X: Break bit, used to indicate that at least one LSR on the path did not recognize and proceed the parameter. Type: 15 bits 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 Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 6] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt An LSR that does not recognize the Path Constraints TLV or recoginze it but does not support it MUST reject the Path message using an Error code "Unknown Attributes TLV" and an error value identifying the unknown TLV type code. An LSR that does not recognize a parameter type in the Path Constraint TLV MUST set the break bit for this parameter. 5. The AGGREGATION object The AGGREGATION object is used to build path parameters, by cumulating 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. 5.1. Format The AGGREGATION object contains a set of Path Parameter TLVs whose encoding is defined in 4.2.1. Each TLV corresponds to a given accumulated parameter along the path. Note that a given parameter must have the same TLV type, when carried in the LSP_REQUIRED ATTRIBUTE object or in the AGGREGATION object. Class = 0bbbbbbb, C-Type = Path Parameter TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | // Path Parameter TLVs // | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Elements of procedure The AGGREGATION object has a C-Num of form 0bbbbbbb. That is, an LSR that does not recognize this object should reject the LSP and send back a PathErr with the appropriate error code. An LSR that does not recognize a parameter type in AGGREGATION object MUST set the break bit for this parameter. Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 7] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt 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 AGGREGATION 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 AGGREGATION Object. In return some path parameters not subject to admission control may be present in the AGGREGATION object, and not in the Path_Constraints TLV. Note that the break bit of all parameters in the AGGREGATION object and the Path Constraints TLV MUST be initially cleared. On receipt of a Resv message with a AGGREGATION 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/tail-end LSR On receipt of a Path message with an AGGREGATION object and no Path Constraint TLV, an LSR MUST update each recognized and supported path parameter of the AGGREGATION object. For each path parameter it has to accumulate the received value with its own "contribution" to the parameter. If the LSR does not recognize or recognize but does not support a given path parameter it should set the break bit of this parameter to 1. If the LSR is at transit it MUST forward the Path message downstream with the updated AGGREGATION object. If the LSR is at tail-end it MUST reflect the updated AGGREGATION object in a Resv message sent back to the head-end LSR. On receipt of a Path message with an AGGREGATION object and a Path Constraint TLV in the LSP_REQUIRED_ATTRIBUTE object, an LSR MUST firstly update each path parameter of the AGGREGATION object. If a parameter is not recognized it should set the break bit of this parameter to 1. Then it MUST perform local admission control for each recognized and supported path parameter included in the Path Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 8] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt Constraints TLV, by verifying that aggregated path parameters does not exceed path constraints. - If all constraints are respected and all break bit are cleared then if the LSR is at transit the Path message is forwarded downstream with the updated AGGREGATION object and if the LSR is at tail-end the updated AGGREGATION object is included in a Resv message sent back to the head-end LSR. - If at least one constraint is violated, then the LSP MUST be rejected, whatever the break bit value and a PathErr is sent back to the Head-End LSR with the Path_State_Removed flag set and a new Error code ("path constraint violation"), and error value corresponding to the TLV type of the violated constraint. This PathErr message MUST also reflect the AGGREGATION object unchanged. - If at least one locally supported parameter has the break bit set and the constraint is respected, then the LSP may be rejected or not depending on local policy decision. If it is rejected a PAthErr message with the error code "Unsupported Path Parameter" and error value corresponding to the unsupported TLV type MUST be generated. This PathErr message MUST also reflect the AGGREGATION object unchanged. - If there is at least one locally unsupported parameter then the LSP may be rejected or not depending on local policy decision. If it is rejected a PAthErr message with the error code "Unsupported Path Parameter" and error value corresponding to the unsupported TLV type MUST be generated. This PathErr message MUST also reflect the AGGREGATION object unchanged. Note that path parameters included in the AGGREGATION object, but not in the Path Constraints TLV are not subject to a local admission control. When its local contribution changes, a transit LSR SHOULD perform admission control and send a Path message downstream with an updated AGGREGATION object. An AGGREGATION 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. The Break bit of a parameter TLV MUST never be cleared by any LSR. Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 9] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt 7. Procedures for Bidirectional LSPs TBD 8. Procedures for inter-domain LSPs TBD 9. IANA Consideration 9.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 AGGREGATION object The C-Num should be of the form 0bbbbbbb so that LSRs that do not recognize the object reject the LSP. One C-Type is defined for this object and should be assigned by IANA. o Path Parameter TLVs Recommended C-Type value = 1. 9.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. 9.3. New Path Parameters TLV Space: The AGGREGATION object and the Path Constraints TLV defined above are constructed from TLVs. Each TLV correspond to a particular path parameter. Each TLV includes a 15-bit type identifier (the T-field). The same T-field values are applicable to the AGGREGATION object and the Path Constraints TLV. IANA is requested to manage Path Parameter TLV type identifiers as follows: - TLV Type (T-field value) - TLV Name: Name of the Path Parameter - RFC: Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 10] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt 9.4. New Error Codes This document defines the following new RSVP 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 Violation" Identifies the TLV type of the violated constraint. 9.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]. 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" draft-ietf-mpls-rsvpte- attributes, work in progress. Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 11] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt 11. Informative References [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-architecture- 07.txt, May 2003. [PD-PATH-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., " A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-path-comp, 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. Intellectual Property Statement 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. 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 Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 12] Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. 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. Le Roux, Papadimitriou Standard Track - Expires April 2006 [Page 13]