Internet Draft
Network Working Group Silvano Gai
Internet Draft Dinesh G Dutt
draft-ietf-rsvp-proxy-00.txt Nitsan Elfassy
Expiration Date: August 2000 Cisco Systems
Yoram Bernet
Microsoft
February 2000
RSVP Receiver Proxy
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Gai, Dutt, Elfassy, Bernet [Page 1]
RSVP Receiver Proxy February 2000
Abstract
RSVP has been extended in several directions [Policy], [Identity],
[DCLASS], [AggrRSVP], [DiffModel],[COPS-RSVP], These extensions have
broadened the applicability of RSVP characterizing it as a signaling
protocol usable both inside and outside the IntServ model.
With the addition of the "Null Service Type" [NullServ], RSVP is
being adopted also by mission critical applications that require some
form of prioritized service, but cannot readily specify their
resource requirements. These applications do not need to set-up a
reservation end-to-end, but only to signal to the network their policy
information [Policy], [Identity] and obtain in response an applicable
DSCP [DCLASS].
RSVP Receiver Proxy is an extension to the RSVP message processing
(not to the protocol itself), mainly designed to operate in
conjunction with the Null Service Type. If COPS is used for policy
control, an extension to the COPS for RSVP protocol [COPS-RSVP-EXT]
is also required.
1. Introduction
Network administrators and application developers would like to have
the QoS provided to a packet be based on information such as:
o the type of application a packet belongs to
o a specific transaction within the application that a packet belongs
to
o the user running the application that a packet belongs to.
In turn, the machine hosting the applications would like to know some
information about the QoS being provided to the applications. This
could include information such as the DSCP assigned to the packets
belonging to an application. The host machine could then use this
information to mark the packets appropriately. Since the data packets
themselves may not carry information such as application or user id,
an alternative approach is to therefore signal this information
separately.
RSVP [RFC2205] is a well established, standard IETF protocol that is
used by applications to signal their QoS requirements to the network
and obtain feedback about the network's ability to provide the
requested QoS. An existing draft [RSVP-APPID] defines the objects
that can be used to carry the application id/sub-id and user-id in an
RSVP message. Also, ISSLL has defined a new service type called Null
Service Type [NullServ] for use within the IntServ framework. This
service is intended for applications whose QoS requirements are
better left to the discretion of the network administrators. As a
result of these characteristics, RSVP emerges as a good choice as a
signaling protocol to carry information such as, application
id/sub-id and/or, user id.
Gai, Dutt, Elfassy, Bernet [Page 2]
RSVP Receiver Proxy February 2000
RSVP as currently defined travels end-to-end i.e. from the sender to
the receiver and back. For the applications discussed above, this
end-to-end nature of RSVP is not necessarily an useful feature. For
example, the latency incurred in the Resv message returning to the
sender might constitute a disadvantage. Or it might be that the
application has been modified only on the sender side and so there is
no use in forwarding this message to the receiver since it might not
support RSVP. RSVP Receiver Proxy is proposed to address such
concerns.
2. An overview of RSVP Receiver Proxy
RSVP Receiver Proxy is a functionality provided by a network device,
such as a switch or a router, in which the network device generates a
proxy Resv message in response to an incoming Path message, on behalf
of the receiver identified by the Path message.
The generation of the Resv message is done under policy
control. Policy control can either be performed using local policy or
by a policy server via a protocol such as COPS for RSVP
[COPS-RSVP]. The network device can be configured to classify the
packets and mark them with an appropriate DSCP. This marking decision
can also be communicated to the sender of the Path message via a
DCLASS [DCLASS] object carried in the proxy Resv message.
RSVP Receiver Proxy does not change the RSVP protocol. Only a
modification in the processing of the RSVP messages is required.
This document defines RSVP Receiver Proxy in association with the
Null Service Type, but there do not appear to be any obvious problems
in using this feature in association with other service types such as
the Controlled Load service. For example, PacketCable [DQOS] uses
RSVP Receiver Proxy to do admission control for voice in cable
networks.
RSVP Receiver Proxy does not provide any special support for subflows
(a set of packets inside a microflow). Of course, an application may
send different Path messages for the same flow at different times,
thus providing a support for subflows not overlapping in time.
3. RSVP Receiver Proxy: An Example
This section illustrates the RSVP Receiver Proxy functionality
provided by a network device. The description is focussed mainly on
the two fundamental messages in RSVP, i.e. the Path Message and the
Resv message. Other messages are discussed in Section 3.3.
Figure 1 depicts a simple network topology (two hosts H1 & H2 and
intermediate routers, R1-R4) that is used in the description that
follows.
Gai, Dutt, Elfassy, Bernet [Page 3]
RSVP Receiver Proxy February 2000
Path Message ----->
<----- Resv Message
+-----+ +-----+
| PS1 | +--| PS1 |
+-----+ / +-----+
/ | / /
/ | / /
/ | / /
+----+ +----+ +----+ +----+ +----+ +----+
| H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| H2 |
+----+ +----+ +----+ +----+ +----+ +----+
H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> H2 Case A: Normal
| RSVP Processing
v
H1 <---- R1 <---- R2 <---- R3 <---- R4 ----> H2
H1 ----> R1
| Case B: RSVP Receiver Proxy
v
H1 <---- R1
Hx: Host x
Ry: Router y
PSz: Policy Server z
Figure 1: Possible Message Forwarding Behaviors in RSVP
In figure 1 above, case A illustrates the normal RSVP message
processing. The Path message goes hop-by-hop from H1 to H2. The Resv
message uses the reverse of the path setup by the Path message and
goes from H2 to H1. The interaction between the network devices and
the policy servers is as specified by COPS for RSVP ([COPS],
[COPS-RSVP]).
With RSVP Receiver Proxy (case B) the RSVP Path message is terminated
by the router R1 acting as a proxy for H2 under the control of a
policy server (local policy at R1 could also have been used to
achieve the same result).
A possible sequence of steps that occurs is as follows:
o An application on H1 indicates to the RSVP subsystem that it is a
sender wishing to use RSVP. It might specify additional parameters
such as traffic characteristics and application specific
information.
Gai, Dutt, Elfassy, Bernet [Page 4]
RSVP Receiver Proxy February 2000
o This causes the RSVP subsystem on H1 to start transmitting RSVP
Path messages in accordance with normal RSVP/SBM rules.
o The first hop network device (R1) receives this message and it
communicates with the policy server for a decision on how to treat
the Path message. It copies all the relevant information contained
in the Path message in the request sent to the policy server.
o The policy server communicates a decision to R1 to not forward the
Path message, but instead to generate and send a Resv message to
H1. H1 data traffic can be marked with the right DSCP by the network
device if specified by the policy server. The policy server could
also specify the list of objects that need to be sent in the Resv
message.
o On receiving the Resv message, H1 might decide to mark the packets
of the traffic flow signaled, according to the DSCP specified in
the DCLASS object contained in the Resv.
In the example, the Receiver Proxy functionality was placed in the
network device that was the first hop from the sender of the Path
message. This is a possibility, but it is not a requirement. While
designing a network, the following trade-offs should be considered:
o Proxying closer to the sender of the Path message reduces turn
around time.
o Proxying farther from the sender of the Path message enables
additional downstream network elements to benefit from the
information carried in the signaling messages, and to participate
in the response.
The network administrator can decide how to make these trade-offs via
policy control.
3.1 Generation of the Resv message by the Proxy
The format of a Resv message generated by the proxy network device is
as follows (see [RFC2205] for details):
::= [ ]
[] [] [...]