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 Huawei February 14, 2014 RSVP-TE Extensions for RRO Editing draft-hartley-ccamp-rro-editing-01.txt 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 http://datatracker.ietf.org/drafts/current/. 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 (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 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. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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. 2.1. RRO-edit LSP_ATTRIBUTES TLV 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 LSP_REQUIRED_ATTRIBUTES object. 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 ignored. 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 receipt. . 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 document. 4. IANA Considerations 4.1. LSP_ATTRIBUTES Object IANA has made the following assignments in the "Attributes TLV Space" section of the "RSVP-TE PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- parameters.xml. 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 LSP_REQUIRED_ATTRIBUTES. 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 Email: mhartley@cisco.com Zafar Ali Cisco Systems Email: zali@cisco.com Oscar Gonzalez de Dios Telefonica Global CTO Email: ogondio@tid.es Cyril Margaria Coriant R&D GmBH Email: cyril.margaria@gmail.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE IETF TRUST, THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 8]