Internet-Draft Arun Viswanathan
Expires: September 1997 Vijay Srinivasan
IBM Corp.
March 1997
Soft State Switching
A Proposal to Extend RSVP for Switching RSVP Flows
<draft-viswanathan-aris-rsvp-00.txt>
Status of This Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes a mechanism for establishing a switched path with
guaranteed Quality of Service for RSVP [1] flows in an integrated
switch-router environment. It proposes an extension to the RSVP
protocol that allows establishment of a sequence of virtual
connections along the hop-by-hop routed path by enabling adjacent
nodes to exchange Layer-2 labels. The labels correspond to
information that identifies the virtual connections; for example, the
VPI/VCI value in the case of an ATM-based Layer-2 infrastructure.
Viswanathan, et al. Expires: September 1997 [Page 1]
Internet-Draft Soft State Switching March 1997
1. Introduction
An Integrated Switch-Router (ISR) is a switching node that has an IP
Control Point (IP-CP) and implements a IP switching technology [2-4].
The ISRs form adjacencies through a well-known virtual circuit (VC),
also called the default VC, that terminates at the adjacent ISR's
IP-CP. This hop-by-hop VC connectivity gives a cloud of ISRs the
same nature as any ubiquitous IP internet. The objective is to
switch RSVP flows in such an environment.
This document proposes an extension to RSVP that introduces new
objects to the existing RSVP messages. Using these objects, each
downstream ISR provides its neighboring upstream ISR with the Layer-2
(L2) label on which it wishes to receive a RSVP flow. In an ATM-
based ISR environment, this label would correspond to a VPI/VCI value
for the ATM virtual circuit on which the ISR wishes to receive
traffic from the RSVP flow. Then, using an approach similar to those
outlined in [2], [3], and [4], the L2 labels are spliced hop-by-hop
to form an end-to-end VC. The data from the RSVP flow then uses this
this end-to-end VC, and the RSVP signalling messages are forwarded
through the default VC. By moving RSVP flows from the default VCs to
a dedicated end-to-end VC, it is possible to leverage the QoS
capabilities of the underlying L2 technology to provide the type of
service desired for the RSVP flow.
In this memo the term virtual circuit (VC) is used loosely to imply a
switched data path under any switching technology that has the
ability to isolate flows from each other, e.g. ATM, Frame Relay etc.
The memo proposes a "one VC per sender" approach. Merging of RSVP
flows into a single VC will be considered in a later revision of the
draft.
It is assumed here that the ISRs on the edge of an ISR cloud can
either auto-learn or are configured to indicate that they are edge
ISRs (on a per interface basis).
2. Soft State Switching
In soft state switching, the goal is to switch traffic from an RSVP
flow at L2 instead of having to forward them hop-by-hop as in
conventional IP routers. By doing so, it is possible to leverage the
high-performance switching and Quality of Service capabilities of the
L2 technology. This is achieved when all neighboring ISRs along the
routed path could exchange L2 labels for establishing the switched
path for RSVP flows. Then, the L2 labels may be "spliced" hop-by-hop
to setup an end-to-end (ingress-to-egress) VC along the preferred
routed path. By splicing, we refer to the process by which an
Viswanathan, et al. Expires: September 1997 [Page 2]
Internet-Draft Soft State Switching March 1997
incoming VC is associated with an outgoing VC at L2, without traffic
from the incoming VC being processed at the network layer. For
example, this can be achieved in ATM switches by establishing this
association in the ATM switching tables. Once the splicing is
complete, the default VC carrying best effort traffic between
adjacent routers provides the IP forwarding path. The RSVP
signalling messages are forwarded on the default VC.
The L2 labels are assumed to have only unidirectional significance.
In other words, there exists a separate L2 label space for each
direction of flow on a link. Moreover, the downstream ISR is chosen
to be the L2 label space owner (allocator) on a link. The single
owner approach keeps the L2 label usage simple and manageable. If a
L2 label space had more than one owner, it would require that owners
synchronize their use of the L2 labels or the space would have to be
partitioned amongst the owners. For flexibility, the proposed
extension to RSVP also supports the concept of "upstream on demand"
allocation described in [3]. In this method, the upstream ISR
allocates labels when demanded by the downstream ISR. This enables
co-existence with other protocols that consume L2 labels.
3. Motivation
In this section, we discuss why the RSVP protocol is ideal for
establishing a switched path for RSVP flows.
One motivating factor for using RSVP is that mapping the network
layer QoS request to a L2 virtual connection is simple. The RESV
message carries the QoS requested by the receiver(s) of the RSVP
flow. For example, this could correspond to one of the Integrated
Service classes described in [6-8]. This QoS information is needed
when L2 labels are set up and spliced; i.e., when the resource
reservations are made. Otherwise, the VC establishment protocol
would have to carry its own QoS entity and/or map the VC setup to
RSVP tables at each ISR hop.
Another motivating reason for extending RSVP is multicast support.
RSVP is designed to scale well for multicast sessions requiring
resource reservation. RSVP also allows receivers to join existing
sessions with different QoS requirements. An independent VC
establishment protocol should be able to handle such session "joins"
equally well.
With the RSVP protocol the receivers can make sender selection
through the provision of different filter styles. In this, multiple
sender flows (as chosen by the receivers) in a RSVP session can be
associated with a single reservation. In other words, sender flows
Viswanathan, et al. Expires: September 1997 [Page 3]
Internet-Draft Soft State Switching March 1997
in a RSVP session can be merged into a single downstream reservation.
A new VC establishment protocol would have to support a similar
mechanism for seamless interoperability with the RSVP protocol.
Finally, any mechanism for set up the VCs would, in any case, require
extensive interfacing with RSVP protocol and/or its state tables.
Due to these reasons, it is best if RSVP can be extended without
changing its existing mechanics, to provide support for setting up
the switched path for RSVP flows. This need not be viewed as
"piggy-backing" another protocol on RSVP, but rather, a natural
extension to RSVP to provide QoS in an integrated switch-router
environment.
4. L2 Label Exchange Mechanism
The proposed extension to RSVP calls for adding a new object to carry
the L2 label information in the RESV message. The egress ISR, say
ISR A, (i.e. the "last" node in the ISR environment, or the ISR
through which the RSVP flow exits the ISR environment) places this
object in the RESV message and sends it to the PHOP ISR for the flow
(as stored in the Path state for this flow) -- call this ISR B. The
RESV message is sent to ISR B via the default routed path. ISR B
will use the L2 label in the RESV message to setup a VC to ISR A (in
this case, the egress ISR) on the outgoing interface. The QoS for
this VC corresponds to a mapping of the Integrated Service class
specified in the RESV message to an appropriate set of QoS values for
the L2 technology.
ISR B then chooses a new L2 label on the incoming interface through
which the RSVP flow enters the ISR, and sends this label to its own
PHOP, ISR C, using the new object in the RESV message. When a VC is
set up from ISR C to ISR B using this label, the L2 label on the
incoming interface of ISR B is then mapped to the L2 label of the
outgoing interface in ISR B's label swap table for L2 switching.
This completes the splicing process at ISR B.
Repeating this process at each PHOP ISR, the RESV eventually reaches
the ingress ISR (the ISR through which the RSVP flow enters the ISR
environment). The ingress ISR will make necessary entries to forward
packets for this flow through the VC identified by the L2 label in
RESV message. All ingress ISRs will delete the L2 object before
forwarding the RESV message to their PHOPs. The L2 labels used for
an RSVP session are released whenever the RSVP session is torn down
or is timed-out.
Using this process, an end-to-end switched path is established for an
Viswanathan, et al. Expires: September 1997 [Page 4]
Internet-Draft Soft State Switching March 1997
RSVP flow through an ISR network. The data packets from the RSVP
flow are forwarded via this switched path, while RSVP control
messages continue to use the default VCs between ISRs.
The procedure described in this section does not describe how flow
merging is performed in such an environment. Flow merging is a key
feature of RSVP, and the ability to perform merging in an ISR
environment is dependent on the capabilities of the ISRs. This topic
is addressed in detail in the following section.
5. Merging
There are several switching technologies available today (ATM, Frame
Relay etc.) and perhaps more in the future. Moreover, the
capabilities of a switch of a certain technology vary from vendor to
vendor. Three basic characteristics are identified that determine
how the underlying L2 technology can be used in conjunction with this
proposal to address merging of flows under appropriate environment.
They are:
o Attribute A: Can correctly merge several upstream VCs into
a single downstream VC. Frame switches are typically able
to do this in a straightforward manner. However, for ATM
switches without appropriate functionality built in, cells
from different AAL SDUs may become interleaved on the
outgoing VC, thus corrupting the higher layer information.
o Attribute B: Can treat a set of VCs as a single entity for
QoS purposes. A switch with this property is able to treat
all traffic from a set of VCs in a like manner for purposes
of scheduling, fair queueing etc. For example, an ATM
switch that performs per-class queueing would assign all
the VCs from a given set to a particular class. Then,
cells from all the VCs in the sets would receive the QoS
corresponding to that class.
o Attribute C: Can demultiplex senders flows in a single VC
into a separate VC for a sender. For example, using label
stack for L2 tunneling ([3], [4]).
The current version of the document does not address the logical
merging of sender flows in a RSVP session. The above attributes may
be used to determine how RSVP flows are merged into a single VC.
Viswanathan, et al. Expires: September 1997 [Page 5]
Internet-Draft Soft State Switching March 1997
6. Multicast Support
In order to support multicast sessions, at split points within the
ISR network, where data from upstream ISRs splits into multiple
downstream flows, the ISR can perform the required duplication (at L2
level) of flows through the hardware multicast capability (for
example, point-to-multipoint VC) of the switch, if available.
Otherwise, the flow has to be processed at the network layer and
multicast in the normal manner. Note that the network layer
forwarding is interoperable with all switch types.
7. Unreserved Receivers
When none of the receivers have reserved, the multicast session may
flow through the default VC as best-effort traffic. But as soon as a
receiver makes a reservation, the data flow may stop to receivers
that haven't made any reservation yet. The receivers without
reservation only get PATH messages but no data (even through best-
effort). This problem can be addressed in several different ways
determined by the switch architecture.
This problem does not exist for switches that support Attribute A.
They can add the default forwarding VC as a branch in the point-to-
multipoint VC. If the switch architecture allow adding the local
IP-CP to the point-to-multipoint VC, then the IP-CP can multicast the
packets only to those interface from which there is no reservation
but are listed in the multicast table. This would be the most
preferable approach for all switches.
Another way to alleviate this problem is to use the PATH message to
do the VC establishment from the node downstream on which there are
interfaces through which no reservation has been received [9]. This
reservation uses a UBR-like QoS. This is done when there is at least
one reservation in place for the RSVP session. This may not work in
environments where upstream label allocation is not permitted.
8. TTL Decrement
When IP packets flow through a switched path, the TTL value in the IP
header cannot be decremented. The decrementing of TTL value is used
to delete packets in a routing loop to avoid/reduce congestion. For
this purpose, the proposed PATH L2 Object carries a hop-count that
counts the number of consecutive ISR hops. The ISRs increment the
hop-count only if there is a switched path for that sender flow
through that ISR. All ISRs maintain the hop count in the Path State.
Only the egress ISR on which the VC terminates would use the count to
Viswanathan, et al. Expires: September 1997 [Page 6]
Internet-Draft Soft State Switching March 1997
decrement the TTL on packets for that sender flow. The ISRs of a
switching technology that have a TTL equivalent in the L2 header may
not use the PATH L2 Object.
9. Upstream on Demand Label Allocation
The memo describes the RSVP extension when the downstream ISR is the
label space owner. But a upstream label allocator can be supported.
In this, the RESV message uses a NULL L2 Object to indicate a request
for label allocation. The upstream ISR responds with a L2 label for
the RSVP session in the PATH messages to the downstream neighbor.
This flexibility allows co-existence with other IP switching
protocols. This can also be useful in other environments such as
[5].
10. Adjacency
The ISR neighbors need some mechanism to establish adjacencies. This
is required because the neighbors need to exchange the label range
for correct label allocation. They also need to elect the label
allocator. The current version of this memo does not propose any
extension to RSVP protocol for this mechanism. It is assumed that
adjacency would be established by another protocol (as proposed in
[2], [3] or [4]) and such information would be made available to the
RSVP module. In absence of such mechanism the ISRs would have to be
configured with the required information to operate as described in
this memo.
11. Object Formats
This section describes the object formats for the proposed extension.
The L2 object for different scenarios are defined below:
o L2 HOP COUNT object: Class = x, C-Type = 1
+-------------+-------------+-------------+-------------+
| Hop Count | Reserved |
+-------------+-------------+-------------+-------------+
Hop Count
Counts the length (in ISR hops) of the switched path.
o NULL L2 Object: Class = y, C-Type = 1
o ATM RESV L2 object: Class = y, C-Type = 2
Viswanathan, et al. Expires: September 1997 [Page 7]
Internet-Draft Soft State Switching March 1997
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------+-----+-------------+-------------+-------------+
| | VPI | VCI |
+-------+-------------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------+-----+-------------+-------------+-------------+
| | VPI | VCI |
+-------+-------------------+-------------+-------------+
IPv4 SrcAddress
IPv4 address of the sender.
VPI - 12 bits
Virtual Path Identifier. If lesser than 12 bits then its
right justified in this field.
VCI - 16 bits
Virtual Circuit Identifier. If lesser than 16 bits then
its right justified in this field.
o ATM PATH L2 object: Class = y, C-Type = 3
+-------+-------------------+-------------+-------------+
| Flags | VPI | VCI |
+-------+-------------------+-------------+-------------+
Flags - 4 bits
0x01 - Implies that the PATH message is in response to an
upstream on demand label allocation and may not be
propogated any further.
VPI - 12 bits
Virtual Path Identifier. If lesser than 12 bits then its
right justified in this field.
VCI - 16 bits
Virtual Circuit Identifier. If lesser than 16 bits then
its right justified in this field.
The IPv6 extension and error codes will be defined in a later
revision of the draft.
Viswanathan, et al. Expires: September 1997 [Page 8]
Internet-Draft Soft State Switching March 1997
The reader may have noticed that the new RESV L2 object has
duplicated information already present in the FILTER_SPEC object.
Another approach could be to extend the FILTER_SPEC object definition
to carry the link layer labels or insert the label object following
the FILTER_SPEC object.
12. Security Considerations
Security considerations are not discussed in this document.
13. Acknowledgements
The authors wishes to acknowledge Nancy Feldman for her input.
14. References
[1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification. Internet Draft, draft-ietf-rsvp-spec-14,
November 1996.
[2] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw,
T. Lyon, G. Minshall, Ipsilon Flow Management Protocol
Specification for IPv4, Version 1.0. Internet RFC 1953, May
1996.
[3] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D.
Farinacci, Tag Switching Architecture - Overview. Internet
Draft, draft-rekhter-tagswitch-arch-00.txt, January 1997.
[4] A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, ARIS:
Aggregated Route-Based IP Switching. Internet Draft, draft-
viswanathan-aris-overview-00.txt, November 1996.
[5] D. Farinacci, Partitioning Tag Space among Multicast Routers on
a Common Subnet. Internet Draft, draft-farinacci-multicast-tag-
part-00.txt, December 1996.
[6] S. Shenker, C. Partridge, R. Guerin, Specification of Guaranteed
Quality of Service. Internet Draft, draft-ietf-intserv-
guaranteed-svc-06.txt, August 1996.
[7] J. Wroclawski, Specification of the Controlled-Load Network
Element Service. Internet Draft, draft-ietf-intserv-ctrl-load-
svc-03.txt, August 1996.
Viswanathan, et al. Expires: September 1997 [Page 9]
Internet-Draft Soft State Switching March 1997
[8] F. Baker, R. Guerin, D. Kandlur, Specification of Committed Rate
Quality of Service. Internet Draft, draft-ietf-intserv-commit-
rate-svc-00.txt, June 1996.
Author's Address
Vijay Srinivasan
IBM Corporation
PO Box 12195
Research Triangle Park, NC 27709
Phone: +1 (919) 254-2730
Email: vijay@raleigh.ibm.com
Arun Viswanathan
IBM Corporation
17 Skyline Drive
Hawthorne, NY 10532
Phone: +1 (914) 784-3273
Email: arunv@vnet.ibm.com
Viswanathan, et al. Expires: September 1997 [Page 10]