Internet DRAFT - draft-hartley-ccamp-rro-editing


CCAMP Working Group                                        Matt Hartley
Internet Draft                                                Zafar Ali
Intended status: Standards Track                          Cisco Systems
Expires: August 13, 2014                            O. Gonzalez de Dios
                                                   Telefonica Global CTO
                                                             C. Margaria
                                                        Coriant R&D GmbH
                                                              Xian Zhang
                                                       February 14, 2014

                    RSVP-TE Extensions for RRO Editing

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on August 13, 2014.

Copyright Notice

   Copyright (c) 2014 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
   ( 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

Hartley, Ali, Swallow  Expires August 14, 2014                 [Page 1]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

   Provisions and are provided without warranty as described in the
   Simplified BSD License.


   This document provides extensions for the Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) to allow the communication of
   changes made by a node to the information provided by other nodes in
   a ROUTE_RECORD Object (RRO) in Path and Resv messages, or to
   indicate that it has itself provided incomplete information.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC-2119].

Table of Contents

   1. Introduction...................................................2
      1.1. Use Cases.................................................3
         1.1.1. Overlay and Multi-domain Networks....................3
         1.1.2. RRO Reduction........................................3
   2. RSVP-TE Signaling Extensions...................................3
      2.1. RRO-edit LSP_ATTRIBUTES TLV...............................3
      2.2. RRO-edit TLV Processing Rules.............................5
   3. Security Considerations........................................6
   4. IANA Considerations............................................6
      4.1. LSP_ATTRIBUTES Object.....................................6
   5. Acknowledgments................................................7
   6. References.....................................................7
      6.1. Normative References......................................7
      6.2. Informative References....................................7
   Author's Addresses................................................8
   Disclaimer of Validity............................................8

1. Introduction

   The signaling process of a Label-Switched Path (LSP) may require
   gathering information of the actual path traversed by the LSP. The
   procedure for collecting this information includes the hop-by-hop
   construction of a Record Route Object (RRO) in the Path and Resv
   messages, containing information about the path traversed by the LSP
   ([RFC-3209], [RFC-3473], [RFC-4873], [RFC-5420], [RFC-5553], [DRAFT-
   SRLG], [DRAFT-METRIC]). There are cases, described in this document,
   in which one or more nodes on the path of an LSP may require that
   the data contained in the RRO in the Path and/or Resv be removed or

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 2]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

   summarized. However, it is important for the ingress or egress nodes
   to know which RRO subobjects have been edited by intermediate nodes.
   This document addresses this requirement.

1.1. Use Cases

1.1.1. Overlay and Multi-domain Networks

   In the GMPLS overlay model there is a client-server relationship
   [RFC4208]. The GMPLS User-Network Interface (UNI) is the reference
   point where policies may be applied. In this case, policy at the
   server network boundary may require that some or all information
   related to the server network be edited, summarized or removed when
   communicating with the client nodes. Similar policy requirements
   exist for inter-domain LSPs and in E-NNI use case.

1.1.2. RRO Reduction

   If an LSP with many hops is signaled and a great deal of information
   is collected at each hop, it is possible that the RRO may grow to
   the point where it reaches its maximum possible size or is too large
   to fit in the Path or Resv message. In this case a node may
   summarize or remove information from the RRO to reduce its size,
   rather than dropping it entirely as specified by [RFC-3209].

2. RSVP-TE Signaling Extensions

   This section describes the signaling extensions required to address
   the aforementioned requirements. Specifically, the requirements are
   addressed by defining a new LSP_ATTRIBUTES TLV that can be used to
   reference what information in RRO has been edited.


   A new LSP_ATTRIBUTES TLV is defined in order to indicate that RRO
   sub-object(s) of a specified type have been edited.

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 3]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


   |             Type              |              Length           |


   // Edited type  |     Flags     |  Edited type  |    Flags     //


   |  Edited type  |     Flags     |            Padding            |


   The sub-object fields are defined as follows:

   Type (2 bytes): The sub-object type, to be assigned by IANA
   (suggested value: 3).

   Length (2 bytes): the total length of the TLV, in bytes. It MUST be
   a multiple of 4, and at least 8.

   The following fields are repeated for each edited type:

     Edited type (1 byte): the type of the RRO sub-object to which the
     immediately following flags in this sub-object apply.

     Flags (1 byte): the flags that apply to the preceding Edited Type,
     numbered from 0 as the most significant bit in the field. Three
     flags are defined by this document:

       . Bit position 0: P (Partial) bit. When set, this bit indicates
          that the data contained in RRO sub-objects of the immediately
          preceding type is incomplete. This may be because some
          information was withheld by a node (i.e. never placed into
          the RRO) or because information provided by one node has been
          removed by another.
       . Bit position 1: S (Summary) bit. When set, this bit indicates
          that the data contained in the specified RRO sub-object has
          been summarized.

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 4]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

       . Bit position 2: R (Removed) bit. When set, this bit indicates
          that the specified RRO sub-object has been removed entirely.

     The remaining bits of the Flags field are undefined. They MUST be
     set to 0 on transmission and MUST be ignored when received.

   Padding: This field is present only if an odd number of edited
   type/flags pairs is present in the TLV. It is used to ensure the TLV
   length is always a multiple of 4 bytes.

2.2. RRO-edit TLV Processing Rules

   The processing rules in this section apply to the processing of both
   Path and Resv RROs.

   The RRO-edit TLV provides information on the changes made to RRO
   sub-objects. It MAY be present in the LSP_ATTRIBUTES object in a
   Path or Resv message. It MUST NOT be added to the

   The LSP_ATTRIBUTES object SHOULD contain no more than one RRO-edit
   TLV. If a received LSP_ATTRIBUTES object contains multiple RRO-edit
   TLVs, the second and subsequent RRO-edit TLVs MUST be ignored.

   The RRO-edit TLVs contains pairs of RRO subobject types and flags
   relating to that type. Any RRO subobject type MAY be present in the
   RRO-edit TLV. Each RRO subobject type SHOULD appear only once; if a
   RRO subobject type occurs more than once then only the first
   occurrence is meaningful, and subsequent occurrences MUST be

   Normal RRO processing involves a node simply adding data related to
   the local hop to the RRO received from the prior node to RRO, and
   placing the new RRO in the message to be transmitted. In this case
   the transmitted RRO contains all data that was present in the
   received RRO and no further processing is required.

   If a node edits the data in the received RRO such that the same data
   is not present in the transmitted RRO, or if it is supplying
   incomplete or summarized data on its own behalf, then the following
   rules apply at the processing node.

     . The node MAY choose not to add or amend the RRO-edit TLV if its
        local policy prevents this.
     . For each RRO subobject type that the processing node has
        edited, a RRO-edit type/flags pair SHOULD be added to the RRO-
        edit TLV if it does not already exist. If a RRO-edit type/flags

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 5]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

        pair for the edited subobject type is already present in the
        RRO-edit TLV, the node SHOULD set additional flags in that
        subobject if appropriate.
     . The node SHOULD set the appropriate P/S/R bits for the RRO
        subobject in the RRO-edit TLV to indicate the changes that have
        been made to RRO subobjects of that type.
     . A node SHOULD NOT insert a RRO-edit type/flags pair with all
        flags set to zero.
     . A node SHOULD NOT unset any P/S/R bit that is set in a received
        RRO-edit TLV.
     . A node SHOULD NOT remove any RRO-edit type/flags pair from the
        RRO-edit TLV.
     . A RRO-edit TLV with no RRO-edit type/flags pairs (i.e. one of
        length 4) is considered invalid. It MUST be ignored on receipt
        and MUST NOT be added to a LSP_ATTRIBUTES object.
     . Unassigned flag bits are considered reserved. They MUST be set
        to zero.
     . The RRO-edit TLV length MUST be a multiple of 4. If an odd
        number of RRO-subobject/flags pairs is present on transmission,
        a 16-bit Padding field MUST be added to the TLV. If an even
        number of RRO-subobject/flags pairs is present on transmission,
        the Padding MUST NOT be added. If present, the Padding bytes
        MUST be set to zero on transmission and MUST be ignored on
     . Any set flag whose meaning is either unassigned or not
        understood SHOULD be ignored, and MUST be included unchanged in
        the transmitted RRO-edit TLV.
     . A RRO-edit type/flags pair with an unknown RRO subobject type
        SHOULD be ignored and MUST passed unchanged in the transmitted
        RRO-edit TLV.

3. Security Considerations

   There are no new security considerations introduced by this

4. IANA Considerations


IANA has made the following assignments in the "Attributes TLV Space"
section of the "RSVP-TE PARAMETERS" registry located at

   This document introduces a new LSP_ATTRIBUTES sub-object:

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 6]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

     Type                       Name             Reference

     ------------------------   ------------     ---------

     TBD (suggested value: 3)   RRO-edited TLV   This I-D

     This TLV is allowed on LSP_ATTRIBUTES, and not allowed on

5. Acknowledgments

   The authors would like to thank Lou Berger for suggesting the core
   idea described in this draft. The authors would also like to thank
   George Swallow for his input.

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.

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

6.2. Informative References

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

   [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
             "GMPLS Segment Recovery", RFC 4873, May 2007.

   [RFC5553] Farrel, A., Ed., Bradford, R., Vasseur, JP., "Resource
             Reservation Protocol (RSVP) Extensions for Path Key
             Support", RFC 5553, May 2009.

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 7]
Internet-Draft    draft-hartley-ccamp-rro-editing-01      February 2014

   [DRAFT-SRLG] Zhang, F., Li, D., Gonzalez de Dios, O., Margaria, C.,
             Hartley, M., "RSVP-TE Extensions for Collecting SRLG
             Information", draft-ietf-ccamp-rsvp-te-srlg-collect-03,
             October 2013.

   [DRAFT-METRIC] Ali, Z., Swallow, G., Filsfils, C., Hartley, M.,
             Kumaki, K., Kunze, R., "Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE) extension for recording TE
             Metric of a Label Switched Path", draft-ietf-ccamp-te-
             metric-recording-02, July 2013.

Author's Addresses

   Matt Hartley
   Cisco Systems

   Zafar Ali
   Cisco Systems

   Oscar Gonzalez de Dios
   Telefonica Global CTO

   Cyril Margaria
   Coriant R&D GmBH

   Xian Zhang
   Huawei Technologies

Disclaimer of Validity

   This document and the information contained herein are provided on

Hartley, Ali, Swallow, et al    Expires August 14, 2014        [Page 8]