Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, ccamp mailing list <firstname.lastname@example.org>, ccamp chair <email@example.com> Subject: Protocol Action: 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE' to Proposed Standard The IESG has approved the following document: - 'Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE ' <draft-ietf-ccamp-rfc4420bis-04.txt> as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-04.txt
Technical Summary This document replaces and obsoletes RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. This allows consistency with the use of TLV data structures in other related documents, and therefore essentially corrects a bug in 4420. Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of 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. Working Group Summary This document corrects a bug in RFC4220 which was found during interoperability testing. Once this bug was found, there was no controversy regarding how to fix this. Document Quality Current implementations are compatible with this document (and therefore no longer compatible with one detail in RFC4220). Personnel Deborah Brungard is the document shepherd. Ross Callon is the responsible AD. RFC Editor Note Please update section 3 as follows: OLD Length Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four- octet aligned. Value The data for the TLV padded as described above. NEW Length Indicates the total length of the TLV in octets. That is the combined length of the Type, Length, and Value fields, i.e., four plus the length of the Value field in octets. The entire TLV MUST be padded with between zero and three trailing zeros to make it four-octet aligned. The Length field does not count any padding. Value The data carried in the TLV.