--- 1/draft-ietf-mpls-rsvpte-attributes-03.txt 2006-02-05 00:43:00.000000000 +0100 +++ 2/draft-ietf-mpls-rsvpte-attributes-04.txt 2006-02-05 00:43:00.000000000 +0100 @@ -1,34 +1,33 @@ Network Working Group Adrian Farrel (Editor) Internet Draft Old Dog Consulting -Category: Standards Track -Expires: July 2004 Dimitri Papadimitriou - Alcatel - +Category: Standards Track Dimitri Papadimitriou +Expires: January 2005 Alcatel Jean-Philippe Vasseur Cisco Systems, Inc. - Arthi Ayyangar Juniper Networks - March 2004 + July 2004 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE - draft-ietf-mpls-rsvpte-attributes-03.txt + draft-ietf-mpls-rsvpte-attributes-04.txt Status of this Memo - This document is an Internet-Draft and is in full conformance - with all provisions of Section 10 of RFC 2026 [RFC2026]. + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. 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." @@ -54,34 +53,39 @@ arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. 0. Change History - This section to be removed before publication. + This section to be removed before publication as an RFC. -0.1 Changes from 02 to 03 Version +0.1 Changes from 03 to 04 Version + + - New IPR and copyright text + - Update referneces + +0.2 Changes from 02 to 03 Version - Allow LSP_ATTRIBUTES object on Resv message. - Document inheritance rules. - Add table of Contents. - New IPR and Copyright boiler-plate. -0.2 Changes from 01 to 02 Version +0.3 Changes from 01 to 02 Version - Minor typographical changes. -0.3 Changes from 00 to 01 Version +0.4 Changes from 00 to 01 Version - Change Attributes Flags TLV to be variable length so that more bits can easily be added in the future. - Define default behaviors for bits absent from the TLV and for absence of the TLV. - Clarify the IANA requirements for tracking Attributes Flags bits. - Introduce RRO Attributes Subobject and describe usage. - Move Fast Reroute reference to informational. - Update security considerations to handle new RRO subobject - Remove section that explained the need for this document in @@ -98,21 +102,21 @@ 1.2 A Rejected Alternate Solution 4 2. Terminology 5 3. Attributes TLVs 5 3.1 Attributes Flags TLV 5 4. LSP_ATTRIBUTES Object 6 4.1 Format 7 4.2 Generic Processing Rules for Path Messages 7 4.3 Generic Processing Rules for Resv Messages 7 5. LSP_REQUIRED_ATTRIBUTES Object 8 5.1 Format 8 - 5.2 Generic Processing Rules 8 + 5.2 Generic Processing Rules 9 6. Inheritance Rules 9 7. Recording Attributes Per-LSP 9 7.1 Requirements 9 7.2 RRO Attributes Subobject 10 7.3 Procedures 10 7.3.1 Subobject Presence Rules 10 7.3.2 Reporting Compliance with LSP Attributes 11 7.3.3 Reporting Per-Hop Attributes 11 7.3.4 Default Behavior 11 8. Summary of Attribute Bit Allocation 11 @@ -123,21 +127,21 @@ 10.3 Attributes Flags 14 10.4 SESSION_ATTRIBUTE Flags Field 14 10.5 New Error Codes 14 10.6 New Record Route Subobject Identifier 14 11. Security Considerations 15 12. Acknowledgements 15 13. Intellectual Property Consideration 15 13.1 IPR Disclosure Acknowledgement 16 14. Normative References 16 15. Informative References 16 - 16. Authors' Addresses 17 + 16. Authors' Addresses 16 17. Full Copyright Statement 17 1. Introduction and Problem Statement Traffic Engineered Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) [RFC3031] may be set up using the Path message of the RSVP-TE signaling protocol [RFC3209]. The Path message includes the SESSION_ATTRIBUTE object which carries a flags field used to indicate desired options and attributes of the LSP. @@ -233,21 +237,21 @@ 2. 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]. 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 RFC2119 [6]. + document are to be interpreted as described in [RFC2219]. 3. Attributes TLVs Attributes carried by the new objects defined in this document are encoded within TLVs. One or more TLVs may be present in each object. There are no ordering rules for TLVs and no interpretation should be placed on the order in which TLVs are received. Each TLV is encoded as follows. @@ -417,26 +421,26 @@ an LSP where that information MUST be inspected at each transit LSR. Specifically, each transit LSR MUST examine the attributes in the LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object transparently. This object effectively extends the flags field in the SESSION_ ATTRIBUTE object and allows for the future inclusion of more complex objects through TLVs. It complements the LSP_ATTRIBUTES object. The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. - This C-Num value ensures that LSRs that do not - recognize the object reject the LSP setup effectively saying that - they do not support the attributes requested. This means that this - object SHOULD only be used for attributes that require support at - some transit LSRs and so require examination at all transit LSRs. See - Section 4 for how end-to-end and selective attributes are signaled. + This C-Num value ensures that LSRs that do not recognize the object + reject the LSP setup effectively saying that they do not support the + attributes requested. This means that this object SHOULD only be used + for attributes that require support at some transit LSRs and so + require examination at all transit LSRs. See Section 4 for how end- + to-end and selective attributes are signaled. One C-Type is defined, C-Type = 1 for LSP Required Attributes. This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP. 5.1 Format LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1 @@ -802,56 +806,49 @@ RRO may reveal information about the status of the LSP and the capabilities of individual LSRs that operators wish to keep secret. The same strategy that applies to other RRO subobjects also applies here. Note, however, that there is a tension between notifying the head end of the LSP status at transit LSRs, and hiding the existence or identity of the transit LSRs. 12. Acknowledgements Credit to the OSPF Working Group for inspiration from their solution - to a similar problem. - - Thanks to Rahul Aggarwal for his careful review and support of this - work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews, - Jim Gibson and Alan Kullberg for their input. + to a similar problem. Thanks to Rahul Aggarwal for his careful review + and support of this work. Thanks also to Raymond Zhang, Kireeti + Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their + input. As so often, thanks to John Drake for useful offline + discussions. 13. Intellectual Property Consideration 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. + 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 this standard. Please address the information to the - IETF at ietf-ipr@ietf.org. - -13.1 IPR Disclosure Acknowledgement + 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. - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. + 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. 14. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. @@ -875,38 +872,24 @@ 15. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. - [INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic - Engineering", , - Internet Draft, work in progress. - [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for - LSP Tunnels", , Internet Draft, work in progress. - [OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., - Vasseur, JP., "Extensions to OSPF for Advertising - Optional Router Capabilities", , Internet Draft, work in progress. - - [REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS - Traffic Engineering loosely routed explicit LSP path", - , Internet - Draft, work in progress. - [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress. 16. Authors' Addresses Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk @@ -923,25 +905,25 @@ USA EMail: jpv@cisco.com Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA EMail: arthi@juniper.net -17. Full Copyright Statement +17. Disclaimer of Validity - Copyright (C) The Internet Society (2004). 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. - 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. +18. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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.