CCAMP Working Group Matt Hartley Internet Draft Zafar Ali Intended status: Standards Track Cisco Systems Expires: April 20, 2014 O. Gonzalez de Dios Telefonica I+D C. Margaria Coriant R&D GmbH October 21, 2013 RSVP-TE extensions for RRO editing draft-hartley-ccamp-rro-editing-00.txt 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 April 20, 2014. Copyright Notice Copyright (c) 2013 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Hartley, Ali, at al Expires April 21, 2014 [Page 1] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013 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 inter-domain networks....................3 1.1.2. RRO reduction........................................3 2. RSVP-TE signaling extensions...................................3 2.1. IPv4 RRO-edit RRO sub-object..............................3 2.2. IPv6 RRO-edit RRO sub-object..............................4 2.3. RRO-edit sub-object Processing Rules......................4 3. Security Considerations........................................5 4. IANA Considerations............................................5 4.1. ROUTE_RECORD Object.......................................5 5. Acknowledgments................................................6 5.1. Normative References......................................7 5.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 on the path traversed by the LSP ([RFC-3209], [RFC-3473], [RFC-4873], [RFC-5420], [RFC-5553], [DRAFT- SRLG], [DRAFT-METRIC]). There are several use cases, described in this document, in which one or more nodes on the path of an LSP may require that the RRO in the Path and/or Resv be edited to remove or summarize data contained in the RRO. However, it is important for the ingress or egress nodes to know what RRO subobjects have been edited by intermediate nodes. This document addresses this requirement. Hartley, Ali, et al Expires April 21, 2014 [Page 2] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013 1.1. Use Cases Use cases where RRO editing can take place are described in this subsection. 1.1.1. Overlay and inter-domain networks In the GMPLS overlay model there is a client-server relationship [RFC4208]. GMPLS User-Network Interface (UNI) is the reference point where policies can be applied. In this cases 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 RSVP packet fragmentation becomes a problem. In this case a node may summarize or remove information from the RRO to reduce its size. 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 RRO sub-object that can be used to reference what information in RRO has been edited, as detailed in the following. 2.1. IPv4 RRO-edit RRO sub-object A new RRO sub-object is defined in order to indicate that another RRO sub-object within the same hop has been edited. 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 |E|P|S|R|reserve| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Editing node address (4 bytes) | Hartley, Ali, et al Expires April 21, 2014 [Page 3] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sub-object fields are defined as follows: Type: The sub-object type, to be assigned by IANA (suggested value: TBD). Length: the total length of the TLV, in bytes. It MUST be 8. Edited type: the type of the sub-object within the same hop to which the flags in this sub-object apply. E (Edited) bit: When set, this bit indicates that the specified RRO sub-object has been edited in some way. P (Partial) bit: When set, this bit indicates that the data contained in the specified RRO sub-object is incomplete. S (Summary) bit: When set, this bit indicates that the data contained in the specified RRO sub-object has been summarized. R (Removed) bit. When set, this bit indicates that the specified RRO sub-object has been removed entirely. Reserved: This field SHOULD be set to zero on transmission, and MUST be ignored on receipt. Editing node address: an IPv4 address unique to the node that has edited the RRO and inserted this sub-object. 2.2. IPv6 RRO-edit RRO sub-object To be added in future revision. 2.3. RRO-edit sub-object Processing Rules The processing rules in this section apply to the processing of both Path and Resv RROs. 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. 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 Hartley, Ali, et al Expires April 21, 2014 [Page 4] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013 incomplete or summarized data on its own behalf, then the following rules apply at the processing node. . For each sub-object type that has been edited within a hop, a RRO-edited sub-object SHOULD be inserted into the same hop in the RRO. The RRO-edited sub-object MAY be omitted entirely if the processing node's policy prevents communication of this information. . Multiple RRO-edited sub-objects describing edits to the same type of sub-object (i.e. with the same "Edited type" field) SHOULD NOT be added in the same hop. . Multiple RRO-edited sub-objects describing edits to the same type of sub-object (i.e. with the same "Edited type" field) MAY be added to different hops if appropriate. . The node SHOULD add its own local address to the "editing node address" field of the RRO-edited sub-object. This field MAY be set to zero if the processing node's policy prevents self- identification. . The node SHOULD set the appropriate bits in the flags field to indicate the changes that have been made to the subsequent RRO sub-object. . A node SHOULD NOT insert a RRO-edited sub-object with all flags set to zero. . Unassigned flag bits are considered reserved. They SHOULD be set to zero. The following rules apply at a node processing a received RRO-edited sub-object: . Any set flag whose meaning is either unassigned or not understood SHOULD be ignored. . If an RRO is received with multiple RRO-edited sub-objects describing edits to the same type of sub-object within the same hop, the second and subsequent RRO-edited sub-objects SHOULD be ignored. 3. Security Considerations To be added in a future version. 4. IANA Considerations 4.1. ROUTE_RECORD Object IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. It is Hartley, Ali, et al Expires April 21, 2014 [Page 5] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013 requested that IANA make assignments from the ROUTE_RECORD RFC 3209 [RFC3209] portions of this registry. This document introduces a new RRO sub-object: Type Name Reference --------- ---------------------- --------- TBD RRO-edited sub-object This I-D 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. Hartley, Ali, et al Expires April 21, 2014 [Page 6] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013 References 5.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. 5.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. [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. [RFC5553] Farrel, A., Ed., Bradford, R., Vasseur, JP., "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, May 2009. [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. Hartley, Ali, et al Expires April 21, 2014 [Page 7] Internet-Draft draft-hartley-ccamp-rro-editing-00 October 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 I+D Email: ogondio@tid.es Cyril Margaria Email: cyril.margaria@gmail.com Hartley, Ali, et al Expires April 21, 2014 [Page 8]