path: root/doc/rfc/rfc6510.txt

Internet Engineering Task Force (IETF)                         L. Berger
Request for Comments: 6510                                          LabN
Updates: 4875, 5420                                           G. Swallow
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                            February 2012


        Resource Reservation Protocol (RSVP) Message Formats for
              Label Switched Path (LSP) Attributes Objects

Abstract

   Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
   established using the Resource Reservation Protocol Traffic
   Engineering (RSVP-TE) extensions may be signaled with a set of LSP-
   specific attributes.  These attributes may be carried in both Path
   and Resv messages.  This document specifies how LSP attributes are to
   be carried in RSVP Path and Resv messages using the Routing Backus-
   Naur Form and clarifies related Resv message formats.  This document
   updates RFC 4875 and RFC 5420.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6510.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must





Berger & Swallow             Standards Track                    [Page 1]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Path Messages ...................................................3
      2.1. Path Message Format ........................................3
   3. Resv Messages ...................................................4
      3.1. Resv Message Format -- Per LSP Operational Status ..........5
      3.2. Resv Message Format -- Per S2L Operational Status ..........6
           3.2.1. Compatibility .......................................6
   4. Security Considerations .........................................6
   5. Acknowledgments .................................................7
   6. References ......................................................7
      6.1. Normative References .......................................7
      6.2. Informative References .....................................7

1.  Introduction

   Signaling in support of Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs)
   is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling
   support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs.

   Two LSP Attributes objects are defined in [RFC5420].  These objects
   may be used to provide additional information related to how an LSP
   should be set up when carried in a Path message and, when carried in
   a Resv message, how an LSP has been established.  The definition of
   the objects includes a narrative description of related message
   formats (see Section 9 of [RFC5420]).  This definition does not
   provide the related Routing Backus-Naur Form (BNF) [RFC5511] that is
   typically used to define how messages are to be constructed using
   RSVP objects.  The current message format description has led to the
   open question of how the LSP Attributes objects are to be processed
   in Resv messages of P2MP LSPs (which are defined in [RFC4875]).

   This document provides the BNF for Path and Resv messages carrying
   the LSP Attributes object.  The definition clarifies how the objects
   are to be carried for all LSP types.  Both Path and Resv message BNF
   is provided for completeness.








Berger & Swallow             Standards Track                    [Page 2]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


   This document presents the related RSVP message formats as modified
   by [RFC5420].  This document modifies formats defined in [RFC3209],
   [RFC3473], and [RFC4875].  See [RFC5511] for the syntax used by RSVP.
   Unmodified formats are not listed.  An example of a case where the
   modified formats are applicable is described in [RFC6511].

1.1.  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 [RFC2119].

2.  Path Messages

   This section updates [RFC4875].  Path message formatting is
   unmodified from the narrative description provided in Section 9 of
   [RFC5420]:

      The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object
      MAY be carried in a Path message....

      The order of objects in RSVP-TE messages is recommended, but
      implementations must be capable of receiving the objects in any
      meaningful order.

      On a Path message, the LSP_ATTRIBUTES object and
      LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed
      immediately after the SESSION_ATTRIBUTE object if it is present,
      or otherwise immediately after the LABEL_REQUEST object.

      If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
      object are present, the LSP_REQUIRED_ATTRIBUTES object is
      RECOMMENDED to be placed first.

      LSRs MUST be prepared to receive these objects in any order in any
      position within a Path message.  Subsequent instances of these
      objects within a Path message SHOULD be ignored and MUST be
      forwarded unchanged.

2.1.  Path Message Format

   This section presents the Path message format as modified by
   [RFC5420].  Unmodified formats are not listed.

   <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
                          [ <MESSAGE_ID> ]
                          <SESSION> <RSVP_HOP>



Berger & Swallow             Standards Track                    [Page 3]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


                          <TIME_VALUES>
                          [ <EXPLICIT_ROUTE> ]
                          <LABEL_REQUEST>
                          [ <PROTECTION> ]
                          [ <LABEL_SET> ... ]
                          [ <SESSION_ATTRIBUTE> ]
                          [ <LSP_REQUIRED_ATTRIBUTES> ... ]
                          [ <LSP_ATTRIBUTES> ... ]
                          [ <NOTIFY_REQUEST> ]
                          [ <ADMIN_STATUS> ]
                          [ <POLICY_DATA> ... ]
                          <sender descriptor>
                          [<S2L sub-LSP descriptor list>]

   Note that PathErr and PathTear messages are not impacted by the
   introduction of the LSP Attributes objects.

3.  Resv Messages

   This section updates [RFC4875] and [RFC5420].  Section 9 of [RFC5420]
   contains the following text regarding Resv messages:

      The LSP_ATTRIBUTES object MAY be carried in a Resv message.

      The order of objects in RSVP-TE messages is recommended, but
      implementations must be capable of receiving the objects in any
      meaningful order.

      ...

      On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
      descriptor and is associated with the FILTER_SPEC object that
      precedes it.  It is RECOMMENDED that the LSP_ATTRIBUTES object be
      placed immediately after the LABEL object.

      LSRs MUST be prepared to receive this object in any order in any
      position within a Resv message, subject to the previous note.
      Only one instance of the LSP_ATTRIBUTES object is meaningful
      within the context of a FILTER_SPEC object.  Subsequent instances
      of the object SHOULD be ignored and MUST be forwarded unchanged.

   This means that LSP attributes may be present per sender (LSP) and
   allows for the LSP Attributes object to be modified using make-
   before-break (see [RFC3209]).  This definition is sufficient for
   point-to-point ([RFC3209] and [RFC3473]) LSPs and the special case
   where all point-to-multipoint source-to-leaf (S2L) sub-LSPs
   ([RFC4875]) report the same operational status (as used in
   [RFC5420]).  However, this definition does not allow for different



Berger & Swallow             Standards Track                    [Page 4]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


   egress Label Switching Routers (LSRs) to report different operational
   statuses.  In order to allow such reporting, this document adds the
   following definition:

      An LSR that wishes to report the operational status of a (point-
      to-multipoint) S2L sub-LSP may include the LSP Attributes object
      in a Resv message or update the object that is already carried in
      a Resv message.  LSP Attributes objects representing S2L sub-LSP
      status MUST follow a S2L_SUB_LSP object.  Only the first instance
      of the LSP Attributes object is meaningful within the context of a
      S2L_SUB_LSP object.  Subsequent instances of the object SHOULD be
      ignored and MUST be forwarded unchanged.

      When an LSP Attributes object is present before the first
      S2L_SUB_LSP object, the LSP Attributes object represents the
      operational status of all S2L sub-LSPs identified in the message.
      Subsequent instances of the object (e.g., in the filter spec or
      the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be
      forwarded unchanged.  When a branch node is combining Resv state
      from multiple receivers into a single Resv message and an LSP
      Attributes object is present before the first S2L_SUB_LSP object
      in a received Resv message, the received LSP Attributes object
      SHOULD be moved to follow the first received S2L_SUB_LSP object
      and then SHOULD be duplicated for, and placed after, each
      subsequent S2L_SUB_LSP object.

3.1.  Resv Message Format -- Per LSP Operational Status

   This section presents the Resv message format for LSPs as modified by
   [RFC5420] and can be used to report operational status per LSP.
   Unmodified formats are not listed.  The following is based on
   [RFC4875].

   <FF flow descriptor list> ::= <FF flow descriptor>
                                 [ <FF flow descriptor list> ]

   <FF flow descriptor>      ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                                 [ <LSP_ATTRIBUTES> ... ]
                                 [ <RECORD_ROUTE> ]
                                 [ <S2L sub-LSP flow descriptor list> ]

   <SE flow descriptor>      ::= <FLOWSPEC> <SE filter spec list>

   <SE filter spec list>     ::= <SE filter spec>
                                 [ <SE filter spec list> ]






Berger & Swallow             Standards Track                    [Page 5]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


   <SE filter spec>          ::= <FILTER_SPEC> <LABEL>
                                 [ <LSP_ATTRIBUTES> ... ]
                                 [ <RECORD_ROUTE> ]
                                 [ <S2L sub-LSP flow descriptor list> ]

3.2.  Resv Message Format -- Per S2L Operational Status

   This section presents the Resv message format for LSPs as modified by
   this document and [RFC5420], and can be used to report operational
   status per S2L sub-LSP.  Unmodified formats are not listed.  The
   following is based on [RFC4875].

   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                            [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <SE filter spec>     ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor list> ::=
                               <S2L sub-LSP flow descriptor>
                               [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor>      ::= <S2L_SUB_LSP>
                               [ <LSP_ATTRIBUTES> ... ]
                               [ <P2MP_SECONDARY_RECORD_ROUTE> ]

3.2.1.  Compatibility

   A node that supports [RFC4875] and [RFC5420], but not this document,
   will interpret the first LSP Attributes object present in a received
   message, which is formatted as described in this document, as
   representing LSP operational status rather than S2L sub-LSP status.
   It is unclear if this is a significant issue as the LSP Attributes
   object is currently considered to be an unsuitable mechanism for
   reporting operational status of P2MP LSPs, for example, see Section
   2.1 of [RFC6511].  The intent of this document is to correct this
   limitation; it is expected that networks that wish to make use of
   such operational reporting will deploy this extension.

4.  Security Considerations

   This document clarifies usage of objects defined in [RFC5420].  No
   new information is conveyed; therefore, no additional security
   considerations are included here.  For a general discussion on MPLS-
   and GMPLS-related security issues, see the MPLS/GMPLS security
   framework [RFC5920].




Berger & Swallow             Standards Track                    [Page 6]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


5.  Acknowledgments

   The authors would like to acknowledge the contributions of Adrian
   Farrel.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 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.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              January 2003.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
              2007.

   [RFC5420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, February 2009.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

6.2.  Informative References

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6511]  Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
              Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
              Label Switched Paths", RFC 6511, February 2012.







Berger & Swallow             Standards Track                    [Page 7]
^L
RFC 6510         RSVP Message Formats for LSP Attributes   February 2012


Authors' Addresses

   Lou Berger
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   EMail: lberger@labn.net

   George Swallow
   Cisco Systems, Inc.
   EMail: swallow@cisco.com









































Berger & Swallow             Standards Track                    [Page 8]
^L