draft-ietf-mpls-rsvpte-attributes-03.txt   draft-ietf-mpls-rsvpte-attributes-04.txt 
Network Working Group Adrian Farrel (Editor) Network Working Group Adrian Farrel (Editor)
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Category: Standards Track Category: Standards Track Dimitri Papadimitriou
Expires: July 2004 Dimitri Papadimitriou Expires: January 2005 Alcatel
Alcatel
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
March 2004 July 2004
Encoding of Attributes for Multiprotocol Label Switching (MPLS) Encoding of Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE 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 Status of this Memo
This document is an Internet-Draft and is in full conformance By submitting this Internet-Draft, I certify that any applicable
with all provisions of Section 10 of RFC 2026 [RFC2026]. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at line 64 skipping to change at line 63
arbitrary attribute parameters to make RSVP-TE easily extensible to arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements. Additionally, this document defines a way support new requirements. Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis. to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable The object mechanisms defined in this document are equally applicable
to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to
GMPLS non-PSC LSPs. GMPLS non-PSC LSPs.
0. Change History 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. - Allow LSP_ATTRIBUTES object on Resv message.
- Document inheritance rules. - Document inheritance rules.
- Add table of Contents. - Add table of Contents.
- New IPR and Copyright boiler-plate. - 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. - 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 - Change Attributes Flags TLV to be variable length so that more bits
can easily be added in the future. can easily be added in the future.
- Define default behaviors for bits absent from the TLV and for - Define default behaviors for bits absent from the TLV and for
absence of the TLV. absence of the TLV.
- Clarify the IANA requirements for tracking Attributes Flags bits. - Clarify the IANA requirements for tracking Attributes Flags bits.
- Introduce RRO Attributes Subobject and describe usage. - Introduce RRO Attributes Subobject and describe usage.
- Move Fast Reroute reference to informational. - Move Fast Reroute reference to informational.
- Update security considerations to handle new RRO subobject - Update security considerations to handle new RRO subobject
- Remove section that explained the need for this document in - Remove section that explained the need for this document in
skipping to change at line 108 skipping to change at line 112
1.2 A Rejected Alternate Solution 4 1.2 A Rejected Alternate Solution 4
2. Terminology 5 2. Terminology 5
3. Attributes TLVs 5 3. Attributes TLVs 5
3.1 Attributes Flags TLV 5 3.1 Attributes Flags TLV 5
4. LSP_ATTRIBUTES Object 6 4. LSP_ATTRIBUTES Object 6
4.1 Format 7 4.1 Format 7
4.2 Generic Processing Rules for Path Messages 7 4.2 Generic Processing Rules for Path Messages 7
4.3 Generic Processing Rules for Resv Messages 7 4.3 Generic Processing Rules for Resv Messages 7
5. LSP_REQUIRED_ATTRIBUTES Object 8 5. LSP_REQUIRED_ATTRIBUTES Object 8
5.1 Format 8 5.1 Format 8
5.2 Generic Processing Rules 8 5.2 Generic Processing Rules 9
6. Inheritance Rules 9 6. Inheritance Rules 9
7. Recording Attributes Per-LSP 9 7. Recording Attributes Per-LSP 9
7.1 Requirements 9 7.1 Requirements 9
7.2 RRO Attributes Subobject 10 7.2 RRO Attributes Subobject 10
7.3 Procedures 10 7.3 Procedures 10
7.3.1 Subobject Presence Rules 10 7.3.1 Subobject Presence Rules 10
7.3.2 Reporting Compliance with LSP Attributes 11 7.3.2 Reporting Compliance with LSP Attributes 11
7.3.3 Reporting Per-Hop Attributes 11 7.3.3 Reporting Per-Hop Attributes 11
7.3.4 Default Behavior 11 7.3.4 Default Behavior 11
8. Summary of Attribute Bit Allocation 11 8. Summary of Attribute Bit Allocation 11
skipping to change at line 133 skipping to change at line 137
10.3 Attributes Flags 14 10.3 Attributes Flags 14
10.4 SESSION_ATTRIBUTE Flags Field 14 10.4 SESSION_ATTRIBUTE Flags Field 14
10.5 New Error Codes 14 10.5 New Error Codes 14
10.6 New Record Route Subobject Identifier 14 10.6 New Record Route Subobject Identifier 14
11. Security Considerations 15 11. Security Considerations 15
12. Acknowledgements 15 12. Acknowledgements 15
13. Intellectual Property Consideration 15 13. Intellectual Property Consideration 15
13.1 IPR Disclosure Acknowledgement 16 13.1 IPR Disclosure Acknowledgement 16
14. Normative References 16 14. Normative References 16
15. Informative References 16 15. Informative References 16
16. Authors' Addresses 17 16. Authors' Addresses 16
17. Full Copyright Statement 17 17. Full Copyright Statement 17
1. Introduction and Problem Statement 1. Introduction and Problem Statement
Traffic Engineered Multiprotocol Label Switching (MPLS) Label Traffic Engineered Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) [RFC3031] may be set up using the Path message Switched Paths (LSPs) [RFC3031] may be set up using the Path message
of the RSVP-TE signaling protocol [RFC3209]. The Path message of the RSVP-TE signaling protocol [RFC3209]. The Path message
includes the SESSION_ATTRIBUTE object which carries a flags field includes the SESSION_ATTRIBUTE object which carries a flags field
used to indicate desired options and attributes of the LSP. used to indicate desired options and attributes of the LSP.
skipping to change at line 243 skipping to change at line 247
2. Terminology 2. Terminology
This document uses terminology from the MPLS architecture document This document uses terminology from the MPLS architecture document
[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
inherits from the RSVP specification [RFC2205]. It also makes uses of inherits from the RSVP specification [RFC2205]. It also makes uses of
the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and
[RFC3473]. [RFC3473].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "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 3. Attributes TLVs
Attributes carried by the new objects defined in this document are Attributes carried by the new objects defined in this document are
encoded within TLVs. One or more TLVs may be present in each object. 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 There are no ordering rules for TLVs and no interpretation should be
placed on the order in which TLVs are received. placed on the order in which TLVs are received.
Each TLV is encoded as follows. Each TLV is encoded as follows.
skipping to change at line 427 skipping to change at line 431
an LSP where that information MUST be inspected at each transit LSR. an LSP where that information MUST be inspected at each transit LSR.
Specifically, each transit LSR MUST examine the attributes in the Specifically, each transit LSR MUST examine the attributes in the
LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
transparently. transparently.
This object effectively extends the flags field in the SESSION_ This object effectively extends the flags field in the SESSION_
ATTRIBUTE object and allows for the future inclusion of more complex ATTRIBUTE object and allows for the future inclusion of more complex
objects through TLVs. It complements the LSP_ATTRIBUTES object. objects through TLVs. It complements the LSP_ATTRIBUTES object.
The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb.
This C-Num value ensures that LSRs that do not This C-Num value ensures that LSRs that do not recognize the object
recognize the object reject the LSP setup effectively saying that reject the LSP setup effectively saying that they do not support the
they do not support the attributes requested. This means that this attributes requested. This means that this object SHOULD only be used
object SHOULD only be used for attributes that require support at for attributes that require support at some transit LSRs and so
some transit LSRs and so require examination at all transit LSRs. See require examination at all transit LSRs. See Section 4 for how end-
Section 4 for how end-to-end and selective attributes are signaled. to-end and selective attributes are signaled.
One C-Type is defined, C-Type = 1 for LSP Required Attributes. 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 This object is optional and may be placed on Path messages to convey
additional information about the desired attributes of the LSP. additional information about the desired attributes of the LSP.
5.1 Format 5.1 Format
LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1 LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1
skipping to change at line 812 skipping to change at line 816
RRO may reveal information about the status of the LSP and the RRO may reveal information about the status of the LSP and the
capabilities of individual LSRs that operators wish to keep secret. capabilities of individual LSRs that operators wish to keep secret.
The same strategy that applies to other RRO subobjects also applies The same strategy that applies to other RRO subobjects also applies
here. Note, however, that there is a tension between notifying the here. Note, however, that there is a tension between notifying the
head end of the LSP status at transit LSRs, and hiding the existence head end of the LSP status at transit LSRs, and hiding the existence
or identity of the transit LSRs. or identity of the transit LSRs.
12. Acknowledgements 12. Acknowledgements
Credit to the OSPF Working Group for inspiration from their solution Credit to the OSPF Working Group for inspiration from their solution
to a similar problem. to a similar problem. Thanks to Rahul Aggarwal for his careful review
and support of this work. Thanks also to Raymond Zhang, Kireeti
Thanks to Rahul Aggarwal for his careful review and support of this Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their
work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews, input. As so often, thanks to John Drake for useful offline
Jim Gibson and Alan Kullberg for their input. discussions.
13. Intellectual Property Consideration 13. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology pertain to the implementation or use of the technology described in
described in this document or the extent to which any license this document or the extent to which any license under such rights
under such rights might or might not be available; nor does it might or might not be available; nor does it represent that it has
represent that it has made any independent effort to identify any made any independent effort to identify any such rights. Information
such rights. Information on the procedures with respect to rights on the procedures with respect to rights in RFC documents can be
in RFC documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. 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
By submitting this Internet-Draft, I certify that any applicable The IETF invites any interested party to bring to its attention any
patent or other IPR claims of which I am aware have been disclosed, copyrights, patents or patent applications, or other proprietary
and any of which I become aware will be disclosed, in accordance with rights that may cover technology that may be required to implement
RFC 3668. this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
14. Normative References 14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReserVation Protocol -- and S. Jamin, "Resource ReserVation Protocol --
Version 1 Functional Specification", RFC 2205, Version 1 Functional Specification", RFC 2205,
September 1997. September 1997.
skipping to change at line 885 skipping to change at line 882
15. Informative References 15. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process [RFC2026] Bradner, S., "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996. -- Revision 3", RFC 2026, October 1996.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., [RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,
"Multiprotocol Label Switching "Multiprotocol Label Switching
Architecture", RFC 3031, January 2001. Architecture", RFC 3031, January 2001.
[INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic
Engineering", <draft-vasseur-inter-as-te-03.txt>,
Internet Draft, work in progress.
[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03 LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-06
.txt>, Internet Draft, work in progress. .txt>, 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", <draft-ietf-ospf-cap-
00.txt>, Internet Draft, work in progress.
[REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS
Traffic Engineering loosely routed explicit LSP path",
<draft-vasseur-mpls-loose-path-reopt-02.txt>, Internet
Draft, work in progress.
[MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress. MPLS TE", Work in Progress.
16. Authors' Addresses 16. Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
skipping to change at line 933 skipping to change at line 915
USA USA
EMail: jpv@cisco.com EMail: jpv@cisco.com
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
EMail: arthi@juniper.net EMail: arthi@juniper.net
17. Full Copyright Statement 17. Disclaimer of Validity
Copyright (C) The Internet Society (2004). This document is This document and the information contained herein are provided on an
subject to the rights, licenses and restrictions contained in BCP "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
78, and except as set forth therein, the authors retain all their OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
rights. 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 18. Full Copyright Statement
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND Copyright (C) The Internet Society (2004). This document is subject
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, to the rights, licenses and restrictions contained in BCP 78, and
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT except as set forth therein, the authors retain all their rights.
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/