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:
<RSVP_HOP_TLVs> ::= <Downstream interface> [ <Upstream interface> ]
The proposed extension utilizes the sequence:
<RSVP_HOP_TLVs> ::= <TLV_interfaces>+
<TLV_interfaces> ::= <Downstream interface> [ <Upstream interface> ]
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]