Skip to main content

Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
draft-ietf-ccamp-rfc4420bis-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ccamp mailing list <ccamp@ops.ietf.org>, 
    ccamp chair <ccamp-chairs@tools.ietf.org>
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

Ballot Text

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.

RFC Editor Note