Internet Draft                                         Lou Berger (LabN)
Updates: 4875, 5420
Category: Standards Track                         George Swallow (Cisco)
Expiration Date: February 19, 2012

                                                         August 19, 2011

            LSP Attributes Related Routing Backus-Naur Form

                 draft-ietf-ccamp-attribute-bnf-02.txt

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 attribute 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on February 19, 2012









Berger & Swallow             Standards Track                    [Page 1]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


Copyright and License Notice

   Copyright (c) 2011 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
   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  ....................................   4
    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  ................................   7
    5      IANA Considerations  ....................................   7
    6      Acknowledgments  ........................................   7
    7      References  .............................................   7
    7.1    Normative References  ...................................   7
    7.2    Informative References  .................................   8
    8      Authors' Addresses  .....................................   8



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) TE LSPs.

   Two LSP Attributes related objects are defined in [RFC5420].  These
   objects may be used to provide additional information related to how
   an LSP should be setup 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],



Berger & Swallow             Standards Track                    [Page 2]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


   that is typically used to define how messages are to be constructed
   using RSVP objects.  The current message format description has led
   to an issue in how the LSP Attributes related objects are to be
   processed in Resv messages of P2MP LSPs.

   This document provides the BNF for Path and Resv messages carrying
   the LSP Attributes related 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.

   This document presents the RSVP message related 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 [NO-PHP-OOB].


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].  As stated in [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.



Berger & Swallow             Standards Track                    [Page 3]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


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>
                          <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 attributed related objects.


3. Resv Messages

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

      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 LSP attributes object to be modified using make-before-



Berger & Swallow             Standards Track                    [Page 4]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


   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]).  But, this definition
   does not allow for different egress LSRs to report different
   operational status.  In order to allow such reporting, this document
   adds the following definition:

      An LSR that wishes to report operational status of a (point-to-
      multipoint) S2L sub-LSP, it 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.  This 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]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


   <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.  This
   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 does not support the LSP Attribute object formatting as
   defined in this section will interpret the first present LSP
   Attribute object as representing LSP operational status even when it
   is intended to represent S2L sub-LSP status.  It is unclear if this
   is a significant issue as the LSP Attribute object is currently
   considered to be an unsuitable mechanism for reporting operational
   status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB].
   The intent of this document is to correct this limitation and it is
   expected that networks that wish to make use of such operational
   reporting will deploy this extension.













Berger & Swallow             Standards Track                    [Page 6]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


4. Security Considerations

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


5. IANA Considerations

   There are no new IANA considerations introduced by this document.


6. Acknowledgments

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


7. References

7.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",
             January 2003.

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

   [RFC5420] Farrel, A., Ed. "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






Berger & Swallow             Standards Track                    [Page 7]

Internet-Draft    draft-ietf-ccamp-attribute-bnf-02.txt   August 19, 2011


7.2. Informative References

   [NO-PHP-OOB] Ali, Z., Swallow, G., "Non PHP Behavior and
                out-of-band mapping for RSVP-TE LSPs", work in
                progress, draft-ietf-mpls-rsvp-te-no-php-oob-mapping.

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


8. 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]

Generated on: Fri, Aug 19, 2011 10:14:59 AM
