Internet DRAFT - draft-baker-tags-rsvp
draft-baker-tags-rsvp
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:39:23 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 06 Dec 1996 11:08:36 GMT
ETag: "2e69b4-3642-32a7feb4"
Accept-Ranges: bytes
Content-Length: 13890
Connection: close
Content-Type: text/plain
Internet Draft Tag Switching with RSVP December 1996
Fred Baker
Yakov Rekhter
December 1996
Tag Switching with RSVP
draft-baker-tags-rsvp-00.txt
1. 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
2. Abstract
In this document we present a specification for binding RSVP flows to
tags, and to distributing tag binding information for these tags by
using RSVP messages.
3. Motivation
The purpose of this document is to propose a standard method for
hosts and routers that support tag switching and RSVP to use the RSVP
Protocol [RSVP] to associate RSVP flows with tags. Specifically this
document presents an addendum to Subsection 3.2 "Sending RSVP
Messages" of the RSVP Specification. It also defines a new RSVP
Object, RSVP_TAG, to carry the tag identifier.
While there are several alternatives to mapping RSVP sessions to
tags, this document specifies a "one tag per session" model, in which
each RSVP session creates a new tag. This model has the following
advantages:
Baker & Rekhter [Page 1]
Internet Draft Tag Switching with RSVP December 1996
(1) If tags are mapped into data link constructs, the model exploits
the traffic control and scheduling capabilities of the data link,
with their hardware or firmware mechanisms.
(2) It reduces the network level processing load by removing the need
for multiplexing of RSVP sessions onto a connection.
This is not to preclude the aggregation of flows onto a smaller set
of tags. Indeed, aggregation is a useful improvement. However, to
be honest, we are not sure how to do that yet. The it would be
correct and valid to do if the behavior of the network is
indistinguishable from the first case. For this to be true,
negotiated QoS features would continue to be observed, policing of
some flows does not affect the policing of other flows, and the set
of destinations to which each flow is delivered remain the same.
This model works well when the receiving end-point of the connection
or intermediate network elements are made aware of the association
between the RSVP session and the tags. For example, in the case of
an intermediate network element the tag constitutes a mechanism for
pre-sorting packets to their network level session. This can assist
the network device in performing appropriate forwarding and
scheduling actions at very high speeds, by leveraging data link level
capabilities. Similarly, an end-station can exploit the tag in de-
multiplexing arriving packets to their appropriate application. This
early de-multiplexing reduces latency and processing overheads within
the end-station, thereby improving the performance of multimedia
applications. Moreover, when the consuming application endpoint is a
device within the end-station (such as a graphics display adapter),
the tag can direct packets to the device.
Since RSVP flows establish and maintain their associated tags, we
think it is logical to ask RSVP to convey tag information between the
endpoints. Moreover, RSVP messages contain all the elements
necessary to identify the data flows that are tagged.
Baker & Rekhter [Page 2]
Internet Draft Tag Switching with RSVP December 1996
4. Specification
As mentioned above, in a tag switching environment it is desirable to
associate each RSVP flow with a tag. An RSVP flow [RSVP] is a
simplex flow from a sending application to a set of receiving
applications identified by an IP address, and a session may contain
several flows. An RSVP reservation may be flow specific (fixed
filter) or shared across flows (shared explicit and wildcard). The
association of flows to tags may be one-to-one or many-to-one and
would be influenced by several factors. These factors include the
type of reservation, the routing protocols used (unicast, multicast
with shared trees, or multicast with source-specific trees), local
forwarding capabilities, etc.
For example, it is logical to create a one-to-one mapping for flow
specific reservations since this would enable the separate treatment
of individual flows.
The association between RSVP flows and tags involves the allocation
of a tag to a flow, initiated either by the upstream or downstream
node. There are benefits with both choices of initiator, and the
approach described in this document can be used to support either
scheme.
We view the best use of upstream allocation as the means that the
upstream router can indicate which tag value it is using to identify
the flow. In cases where this is important (multicast flows), we
expect that tag allocation occurs outside the context of RSVP, and
the tag is carried for the convenience of the system receiving the
PATH message. Downstream allocation is the preferred approach for
unicast flows, which have no obvious external mechanism for tag
negotiation, and for which downstream tag selection simplifies the
algorithm.
In the case of upstream allocation, RSVP PATH messages carry the
information needed to associate RSVP flows with tags. In the case of
a per-flow downstream allocation, RESV messages would instead carry
the tags of the flows to which they apply.
In both cases, as the tag identifies data from a specific sender to
a set of receivers, the tag immediately follows the
FILTER_SPECIFICATIONs in the RESV or the SENDER_TEMPLATE in the PATH
message. In the case of a wildacrd filter (which has an implied
SENDER_TEMPLATE and FILTER_SPECIFICATION), RSVP_TAG immediately
follows the FLOW_SPECIFICATION.
The RSVP_TAG object class, encoded in accordance with RSVP Object
descriptions, has the following encoding:
Baker & Rekhter [Page 3]
Internet Draft Tag Switching with RSVP December 1996
RSVP_TAG class = xx, C_Type = Tag-Information
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the upstream allocation mode, both the upstream and downstream
nodes store the RSVP_TAG in the Path State Tables.
(1) When the downstream node sends a RESV message, it acknowledges the
association by including a the tag value specified by the upstream
node in the RSVP_TAG object. At that point, the upstream node may
start forwarding data using the tag.
(2) If no RSVP_TAG value is present in the RESV message, the downstream
node is not prepared to forward based on the tag value.
(3) If an RSVP_TAG value is present, but the tag value differs, the
downstream node is indicating either that it has not received a new
tag value or that the tag value requested is unacceptable.
(4) If the upstream node receives two successive RESVs with variant tag
values from the same downstream node, it must assume the latter
case and change the value it is advertising.
A logical choice of value would be one of the values offered by
downstream nodes, but the upstream node may select other values.
The downstream allocation mode is useful for unicast sessions in
which the QoS characteristics of a flow differ from the best effort
characteristics of the standard tagged routes. The node that expects
to receive the traffic assigns the tag values. The RESV's RSVP_TAG
object indicates the tag value that the receiver wants used with the
flow. If it is absent, the implication is that no tag value is
assigned; if one was previously assigned it is now not in use. The
sender may acknowledge in the PATH message, but the acknowledgment
has no real value.
Baker & Rekhter [Page 4]
Internet Draft Tag Switching with RSVP December 1996
5. Example
The figure below shows a simple example network in which two IP hosts
H1 and H2 communicate through a sequence of tag switched routers
(TSR1, TSR2).
+------+ +------+ +------+ | +------+
| H1 |-----| TSR1 |-----| TSR2 |--|--| H2 |
+------+ +------+ +------+ | +------+
5.1. Upstream allocation
H1 sends an RSVP PATH message to TSR1 using the mechanisms outlined
in this document. The PATH message carries the tag allocated by H1
in the RSVP_TAG Object as shown above.
When TSR1 receives the PATH message from H1, it performs its normal
RSVP processing and also creates a Path State Table entry that
includes the tag value carried in the RSVP_TAG object. TSR1 then
forwards the PATH message to TSR2 and specifies in the RSVP_TAG
object the tag value to be used between TSR1 and TSR2 for the flow.
TSR1 also stores this value in the Path State Table entry. As with
TSR1, when TSR2 receives the PATH message, it creates a Path State
Table entry that includes the tag value carried in the RSVP_TAG
object. TSR2 then forwards the PATH message to H2 and specified in
the RSVP_TAG object the tag value to be used between TSR2 and H2 for
the flow.
H2 determines that it would like to setup a Reservation for this
particular session, that is, it sends a RESV message with an RSVP_TAG
object that carries TSR2's tag value. When TSR2 receives this
message, along with normal RSVP processing, it retrieves from the
corresponding Path State Table entry the values of the tags it sent
to H2 and received from R1, respectively. These tags will then be
used to identify packets arriving from TSR1, and forward them to H2.
TSR2 then sends the RESV message to R1, this time with TSR1's tag
value in the RSVP_TAG object. When TSR1 receives the RESV message,
it also retrieves tag information from the corresponding Path State
Table entry. It uses this to allocate resources and ensure that
packets arriving with the specified tag value from H1 are directly
forwarded with the corresponding tag value on the link to TSR2. TSR1
similarly forwards the RESV message to H1; upon receiving the message
H1 proceeds to start sending the session's data with the tag it
allocated on the link to TSR1.
Baker & Rekhter [Page 5]
Internet Draft Tag Switching with RSVP December 1996
5.2. Downstream allocation - unicast flow
Following RSVP procedures, H1 sends an RSVP PATH to H2. The PATH
message traverses through TSR1 and TSR2.
H2 determines that it would like to setup a Reservation for this
particular session, so H2 allocates a tag, and sends a RESV message
to TSR2. The RESV message carries the value of the allocated tag in
the RSVP_TAG object. When TSR2 receives this message, along with
normal RSVP processing, it stores the value of the tag (carried in
the RSVP_TAG object) as part of the Path State Table entry
corresponding to the RESV message. TSR2 then allocates a tag, and
sends a RESV message to TSR1. The message carries the value of the
tag allocated by TSR2 in the RSVP_TAG object. When TSR1 receives
this message, along with normal RSVP processing, it stores the value
of the tag. TSR1 similarly allocates a tag, and places the tag into
the RSVP_TAG object of the RESV message that TSR1 sends to H1. Upon
receiving the message H1 proceeds to start sending the session's data
with the tag received in the RESV message.
6. Security Considerations
Security issues are not discussed in this document. We presume that
the security procedures defined for RSVP will handle any security
issues that arise with coupling tag switching with RSVP.
7. Acknowledgments
We would like to acknowledge Roch Guerin, Dilip Kandlur, and Doug
Williams for their help.
Baker & Rekhter [Page 6]
Internet Draft Tag Switching with RSVP December 1996
8. References
[WGK] Virtual Circuit Identification Support for an RSVP-based
Service, draft-williams-issll-vcuse-00.txt, Internet Draft,
September 1996.
9. Author Information
Fred Baker
519 Lado Drive
Santa Barbara, California 93111
fred@cisco.com
(408)526-4257
Yakov Rekhter
170 West Tasman
San Jose, California
yakov@cisco.com
(408)527-0918
Baker & Rekhter [Page 7]
