Network Working Group Jonathan Sadler Internet Draft Zuchang Shen Intended Status: Standards Track Tellabs Expiration Date: April 2010 October 19, 2009 Multiplier (MT) support over Bundled Links in RSVP-TE draft-sadler-ccamp-rsvp-mt-bundled-links-00 Status of this Memo This Internet-Draft is submitted to IETF 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 19, 2010. Copyright Notice Copyright (c) 2009 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 (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Sadler, Shen CCAMP WG - October 2009 [Page 1] draft-sadler-ccamp-rsvp-mt-bundled-links-00 October 2009 Abstract When operating a multi-domain network, it is quite common for a domain to have a number of border-nodes that end up with a large number of connections between them using the same path. While support for LSP stitching has removed the need to maintain the data associated with each end-to-end session (e.g. Sender Template and Session object data) within the domain, the mechanisms used by GMPLS RSVP-TE to support out-of-band signaling still force individual sessions to be used between the border nodes for each connection. This has a negative impact on intermediate nodes, as it increases the amount of RSVP processing and memory required. This document details a method for GMPLS RSVP-TE to use a common session for an edge-to-edge LSP supporting multiple data-plane connections between border nodes. Table of Contents 1. Overview...................................................2 2. Acronyms and Definitions...................................3 3. Requirements and Analysis of existing protocols............3 3.1. Requirements...............................................3 3.2. Analysis...................................................4 4. Methods for Implementation and protocol extensions.........4 4.1. Operation over single physical links.......................4 4.2. Operation over multiple physical (Bundled) links...........5 4.2.1 Method....................................................5 4.2.2 Protocol Extension........................................5 5. Security Considerations....................................6 6. Contributors...............................................7 7. References.................................................7 7.1. Normative References.......................................7 7.2. Informative References.....................................7 8. Author's Addresses.........................................7 1. Overview When operating a multi-domain network, it is common for some domains to have a number of border-nodes with a large number of connections between them using the same path. It is desirable to support these connections with as few sessions within the domain as possible due to the load generated on intermediate nodes by each session. LSP stitching [RFC5150] has removed the need to maintain the data associated with end-to-end sessions (e.g. Sender Template and Session objects) within the domain. However, there are other issues that prevent the edge-to-edge LSP to support multiple connections. RSVP [RFC2205] allows for session merging, enabling a set of endpoints involved in communications with common traffic characteristics to share a common session. Addition/Removal of endpoints does not require additional sessions to be established or Sadler, Shen CCAMP WG - October 2009 [Page 2] draft-sadler-ccamp-rsvp-mt-bundled-links-00 October 2009 the overall session to be removed - the existing session can be resized, either increasing or decreasing the number of resources requested, to accommodate the changes in bandwidth required. The result is intermediate nodes have a reduced number sessions operating through them, with lower CPU processing and memory required. The mechanisms in RFC 2205 work well given the packet nature of the links being controlled -- packets from different connections can be interleaved without restriction while being associated with the same RSVP-TE session. GMPLS RSVP-TE [RFC3473] provides a similar capability by providing a list of labels to name the multiple data- plane connections covered by a session. However, problems are encountered when out-of-band signaling extensions and bundled links are used with LSPs requesting multiple signals. To support this scenario, methods and extensions need to be defined for bundled link operations. 2. Acronyms and Definitions 3. Requirements and Analysis of existing protocols 3.1. Requirements The signaling protocol must be able to: 1) Allow for multiple data-plane connections to be delivered using a single session without requiring contiguous TDM resources on a link. 2) Allow for resizing of a session between a pair of border nodes to increase the number of data-plane connections in use 3) Allow for use of paths that utilize links realized by a single physical link 4) Allow for use of paths that utilize links realized by a group of physical links (i.e. Bundled links [RFC 4201]) 5) Allow for connections to be spread over the component links that make up a bundled link Sadler, Shen CCAMP WG - October 2009 [Page 3] draft-sadler-ccamp-rsvp-mt-bundled-links-00 October 2009 3.2. Analysis Current GMPLS encodings for SONET/SDH [RFC 4606] and OTN [RFC 4328] allow for multiple data-plane connections to be established by a single control plane session. This is provided by the Multiplier (MT) field in the SENDER_TSPEC. When this field has a value greater than one, the downstream node will provide an "explicit ordered list of all labels that take part in the Final Signal." This list names each of the data-plane resources used for the data-plane connections. GMPLS extensions to enable out-of-band operation state the label returned is within the context of the interface identified by the RSVP_HOP object. At this time, the RSVP_HOP object is limited to identifying a single link for downstream traffic and (optionally) a single link for upstream traffic [RFC 4201]. The content of TLVs in the RSVP_HOP object is either the identifier for a non-bundled link, or a component link within a bundle. Because of the limitation to a single link in the RSVP_HOP object's TLVs, data-plane connections carried over a bundled link are limited to a single component link. This has two ramifications: 1) Setup of a connection with a multiplier (MT) greater than 1 may specify use of a bundled link where the bundle has adequate resources to satisfy the request, but the individual component links do not. Due to the protocol limitation to a single component link, the connections cannot be spread across the bundled link's components, and the request ends up failing for lack of available bandwidth. 2) A request to resize an existing RSVP session may be received by an intermediate node where the bundle has adequate resources to satisfy the request, but a component link does not. Again, this request will fail for lack of available bandwidth. In short, all requirements specified in section 3.1 can be met with the exception of requirement 5. 4. Methods for Implementation and protocol extensions 4.1. Operation over single physical links No specific extension is required for operation over a single physical link. The multiplier (MT) field states the required number of data-plane resources, and all label-related objects (i.e. UPSTREAM_LABEL and LABEL) contain a list of labels to satisfy the request. Sadler, Shen CCAMP WG - October 2009 [Page 4] draft-sadler-ccamp-rsvp-mt-bundled-links-00 October 2009 4.2. Operation over multiple physical (Bundled) links 4.2.1 Method When operating over bundled links, the resources requested may be delivered on a single component link or may be delivered on using multiple component links. When a single component link is used, the existing encoding required by RFC 4201 is utilized, with a single set of TLVs identifying the upstream and downstream components. However, when use of more than one component link is identified by the upstream node, the RSVP_HOP object sent to the downstream node needs to contain multiple TLVs to identify the downstream and upstream interfaces used. These interfaces identified in the TLVs have the same order as the labels in the UPSTREAM_LABEL object and the returned LABEL object. The specifics for how this encoded is described in the next section. 4.2.2 Protocol Extension Two protocol extensions are proposed for the RSVP_HOP object. The first provides a simple interface list encoding for TLVs while the second provides for Run-length encoding. 4.2.2.1 Interface List Encoding in RSVP_HOP TLVs The existing RSVP_HOP encoding utilizes one or two TLVs in sequence, where the sequence is described by: ::= [ ] The proposed extension utilizes the sequence: ::= + ::= [ ] For a unidirectional connection, identified by the lack of an UPSTREAM_LABEL object in the message, the Upstream interface is not provided. For a bidirectional connection, identified by the presence of an UPSTREAM_LABEL object in the message, the Upstream interface is always provided. The Upstream interface will repeat the information in the Downstream interface if the same link is used for both directions. 4.2.2.2 Run-Length Encoded List in RSVP_HOP In order to reduce the size of an RSVP message, a Run-length Encoding (RLE) is proposed for use when more than one resource is provided using the same component link. This requires a new set of RSVP_HOP TLVs which include the number of interface instances represented by the appearance of the TLV. Sadler, Shen CCAMP WG - October 2009 [Page 5] draft-sadler-ccamp-rsvp-mt-bundled-links-00 October 2009 Appearance of an RLE TLV in the RSVP_HOP object is the equivalent of the same number of upstream or downstream TLVs appearing in the RSVP_HOP object. Note: The RLE TLV does not cross the implied upstream/downstream TLV boundary. This means an even number of RLE TLVs must be utilized for bidirectional connections. Each of the new RLE TLV formats includes a run-length field which indicates the number of single-interface TLV instances being represented by the RLE TLV. A run-length of 0 is undefined -- a TLV received with a run-length of 0 MUST be ignored. The run-length SHOULD be 2 or more. 4.2.2.2.1 IPv4 RLE TLV format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run-length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.2.2.2 IPv6 RLE TLV format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run-length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.2.2.3 Unnumbered IPv4 RLE TLV format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run-length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Security Considerations This draft does not introduce any new security issues for RSVP-TE. Sadler, Shen CCAMP WG - October 2009 [Page 6] draft-sadler-ccamp-rsvp-mt-bundled-links-00 October 2009 6. Contributors The authors would like to thank Lou Berger for discussions on this problem and Don Koerkel for his contributions to this document. 7. References 7.1. Normative References [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4201] K. Kompella, Y. Rekhter, L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 7.2. Informative References [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC4328, January 2006. [RFC4606] E. Mannie, D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC4606, August 2006. [RFC5150] A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC5150, February 2008. 8. Author's Addresses Jonathan Sadler Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563 Phone: +1 630-798-6182 Email: Jonathan.Sadler@tellabs.com Zuchang Shen Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563 Phone: +1 630-798-6216 Email: Zuchang.Shen@tellabs.com Sadler, Shen CCAMP WG - October 2009 [Page 7]