Internet Engineering Task Force J. Manner
Internet-Draft T. Suihko
Expires: July, 2003 M. Kojo
M. Liljeberg
K. Raatikainen
January, 2003
Localized RSVP
<draft-manner-lrsvp-01.txt>
Status of this Memo
This document is a submission to the NSIS Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the nsis@ietf.org mailing list.
Distribution of this memo is unlimited.
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.
This Internet-Draft will expire in July 2003.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Guaranteed QoS for multimedia applications is based on reserved
resources in each node on the end-to-end path. Even if the
correspondent node does not support QoS, it would be useful to be
able to reserve at least local resources at the access network,
especially wireless link resources. Additionally, for mobile nodes
the continuity of QoS is disturbed due to end-to-end signalling or
slow re-reservations of resources after each handover. This draft
proposes a simple enhancement to RSVP, so that initial resource
reservations and re-reservations due to host mobility can be done
locally in an access network.
Manner et al Expires July 2003 [Page 1]
Internet-Draft Localized RSVP January 2003
Table of Contents
1 Introduction ................................................. 2
1.1 Related work ............................................... 3
2 Local QoS Support ............................................ 4
2.1 Upstream transfers ......................................... 5
2.2 Downstream transfers ....................................... 5
2.3 Additional functionality ................................... 6
2.4 Addressing Issues .......................................... 8
2.5 Interworking Issues ........................................ 8
3 Fast local repair for mobile nodes ........................... 10
4 Security Consideration ....................................... 12
5 IANA Considerations .......................................... 13
6 Summary ...................................................... 13
7 References ................................................... 14
8 Author's Addresses ........................................... 15
1. Introduction
Future mobile access networks will be based on IP technology. This
implies that, on the network layer, all traffic, both traditional
data and streamed data like audio or video, is transmitted as
packets. Increasingly popular multimedia applications would benefit
from better than best-effort service from the network, a forwarding
service with strict Quality of Service (QoS) with guaranteed minimum
bandwidth and maximum delay. Other applications, such as electronic
commerce, network control and management, and remote login
applications, would also benefit from a differentiated treatment.
The IETF has two main models for providing differentiated treatment
of packets in routers. The Integrated Services (IntServ) model [1]
together with the Resource Reservation Protocol (RSVP) [2] [3]
provides per-flow guaranteed end-to-end transmission service. The
Differentiated Services (DiffServ) framework [4] provides non-
signalled flow differentiation that usually provides, but does not
guarantee, proper transmission service. These architectures,
however, have problems. For example, RSVP requires support from both
communication end points and from the intermediate routers. DiffServ,
on the other hand, requires support from the sender of a stream and
from the network nodes. The Internet Architecture Board has outlined
additional issues related to these two architectures [5].
Let's consider a scenario, where a fixed network correspondent node
(CN) would be sending a multimedia stream to an end host behind a
wireless link. If the correspondent node does not support RSVP it
cannot signal its traffic characteristics to the network and request
specific forwarding services. Likewise, if the correspondent node is
not able to mark its traffic with a DiffServ Code Point (DSCP) to
trigger service differentiation, the multimedia stream will get only
best-effort service which may result in poor visual and audio quality
in the receiving application. Even if the connecting wired network is
over-provisioned, reserving local resources is especially important
in wireless access networks, where the bottleneck resource is most
Manner et al Expires July 2003 [Page 2]
Internet-Draft Localized RSVP January 2003
probably the wireless link.
In the absence of end-to-end QoS support, an end-host could still
want to reserve resources from the local (edge) network, for example
from its access network, for both outgoing and incoming traffic. We
propose a slight modification to RSVP that allows distinguishing
local network reservations from the end-to-end reservations. The end
host does not need to know the access network topology or the nodes
that will reserve the local resources. The reservation message itself
identifies the intention and the access network will find the correct
network node(s) to respond to the reservation. Note that the scheme
is not tied to only mobile networks but can be used in any access
network that needs flexible local resource allocations.
The localized RSVP signalling would fit well, for example, with a SIP
session, where a call set up can have a pre-condition: if the request
for local resources is successful, the end-host can send the COMET
message and make the call "ring" [SIP]. Both ends would use their own
local reservations.
All mobility-related terminology in this document are taken from
[16]. Therefore, the commonly used term 'access router' (AR) means
the 'default router'.
1.1. Related work
Currently we can identify two ways to signal QoS requirements to an
access network: DiffServ Code Points (DSCP) and RSVP with IntServ. In
the DiffServ-based solution an end host can mark the upstream packets
with proper DSCP values, but for the downstream the gateway on the
edge of the access network must be able to identify and handle the
preferred streams. This can be accomplished with default values for
different micro flows in the Service Level Agreement negotiated
between the client and the access network service provider.
An alternative way to make use of DiffServ could be through a
Bandwidth Broker [6] [7] [8] that dynamically returns the proper code
point for each flow: when the first packet of a flow arrives at the
access network edge router, it requests the proper code point from
the Bandwidth Broker. The router maintains a mapping from micro flow
identification to the DiffServ code point (soft state) so that future
packets can be directly identified and labelled. Still, this would
require a protocol that the end host could use to dynamically adjust
the mapping information stored at the access network edge for the
incoming traffic.
RSVP can provide the signalling mechanism for QoS requirements to the
access network. For upstream reservations, the end host would send
the Path message to the access network edge router, which would
return the Resv message and set up the reservations. The edge router
would act as an RSVP proxy [9]. However, the reservation in the
downlink direction is not as straightforward since the downlink
reservation needs to be initiated by the RSVP proxy. We would need a
Manner et al Expires July 2003 [Page 3]
Internet-Draft Localized RSVP January 2003
way to trigger the proxy to initiate the RSVP signalling for a
downlink flow.
Thus, these mechanisms do not seem to solve the problem entirely. The
DiffServ mechanisms cannot provide explicit resource reservations.
The problem with the RSVP proxy approach is that the proxy cannot
automatically distinguish reservations that would be answered by the
correspondent node and reservations that would require interception.
Additionally, the RSVP proxy needs a way to know when to allocate
resources for incoming flows. Mobile access networks also add to the
problems, since mobile nodes can frequently change their point of
attachment in the network and resource allocations need to be re-
arranged, including changing the serving RSVP proxy.
2. Local QoS Support
Our solution to the problem of localized QoS co-ordination is based
on proxies and the RSVP local repair mechanism [2]. The proxy is
running on an RSVP node and is called the Localized RSVP Proxy server
(LRSVP proxy). The first sketch of this solution appeared in [10] and
[11], although some implementation ideas have changed since.
To implement a local resource signalling, we first of all need two
flag bits from the unused Flags field in the RSVP Session Object.
The Local Indication (LI) bit (currently we use bit 0x8) is used to
differentiate reservations that are internal to the access network -
when the bit is set the RSVP message is part of local resource
signalling. A default value of zero indicates standard end-to-end
signalling.
The Expedited Refresh (ER) bit (currently we use bit 0x4) is used to
indicate that a Path message is sent as a refresh to a broken path
and must be forwarded immediately. This indication is needed because
each RSVP hop propagates a Path message before a timeout only if the
Path state has changed - when a route changes at the receiver end of
the data flow, a Path message is needed to set up again the Path
state. This is discussed in more detail later.
We also need two new message types called "Path Request" message with
an initial message type number 8 and "Path Request Tear" with an
initial message type number 9. The first message is used to request a
Path message from the access network LRSVP proxy and the second
message is used to tear down a downstream reservation. Note that due
to the new message types, all RSVP routers inside the access network
must be upgraded with the LRSVP extension.
When a local end host wants to reserve resources in the local access
network, it uses the LI flag in RSVP messages to indicate a local
reservation. The structure of the RSVP messages follows the RSVP
standard. The LRSVP proxy that receives an RSVP message with the LI
bit set will notice that the flag was set, does not forward the
message further to the next hop and responds according to the
following description.
Manner et al Expires July 2003 [Page 4]
Internet-Draft Localized RSVP January 2003
2.1. Upstream transfers
Setting upstream reservations is straightforward and follows closely
the standard RSVP functionality. The local end host sends the usual
Path message, but sets the LI flag bit in the Session Object. The
Session Object of the message defines the destination of the flow
that will eventually be transmitted from the local end host, and the
Sender Template provides information about the local end host itself.
[END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN]
| | | | |
|------------- Path towards CN (LI) ---------->| |
| | | | |
| | | (proxy intercepts) |
| | | | |
| | |<---- Resv ----| |
| |<---- Resv ----| | |
|<---- Resv ---| | | |
| | | | |
Figure 1: Local Upstream reservation
The Path message is routed within the access network and sets the
Path state in RSVP routers. When the LRSVP proxy receives the Path
message, it notes due to the LI bit that the reservation is meant to
stay within the access network and responds with a Resv message. It
will not forward the Path message further to the next hop. When a
Resv message arrives at the local end host, the resources for the
session defined in the Path message have been allocated.
2.2. Downstream transfers
Before setting a downstream resource reservation, the local end host
needs to be aware of the data senders. For multimedia communications,
a session is usually initiated with application layer protocols like
SIP [15] or RTSP [12]. Based on this correspondence, the local end
host knows the necessary information about the sender. Another, more
coarse reservation could be set, for example, for browsing different
audio servers; the local end host would indicate in the RSVP messages
that the sender will use UDP. It is, therefore, possible to make
resource reservations for any sender that wants to communicate with
the local end host. However, in order to allow for more accurate QoS
support, more information should be given. The way to find this
information is out of scope of this document.
In order to set up the downstream reservation we need a way to signal
the LRSVP proxy to initiate the RSVP reservation set up on behalf of
the sender(s), that is, to send a Path message. To achieve this, the
local end host sends the Path Request message with the LI flag bit
set (Fig. 2). The Path Request message is identical to a standard
Path message apart from the message type field. The Session Object
must include information about the recipient, the local end host in
this case, and the Sender Template must define the expected
Manner et al Expires July 2003 [Page 5]
Internet-Draft Localized RSVP January 2003
sender(s). The Traffic specification (TSpec) can either be based on
the local end user's wishes, a best estimate of the incoming traffic
characteristics, or on application level session signalling prior to
the transfer.
[END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN]
| | | | |
|------------ Path Request towards CN (LI) --->| |
| | | | |
| | | (proxy intercepts) |
| | | | |
| | |<- Path (LI) --| |
| |<- Path (LI) --| | |
|<- Path (LI) -| | | |
| | | | |
|- Resv (LI) ->| | | |
| |-- Resv (LI) ->| | |
| | |-- Resv (LI) ->| |
| | | | |
Figure 2: Local downstream reservation
When the LRSVP proxy receives this message, it detects that the
message is meant to stay within the access network. The message type
indicates that the proxy should initiate an RSVP reservation for a
downstream flow and use the information in the message to fill the
objects in a Path message. The proxy now generates a Path message
that includes the parameter values in the Path Request message and
sends it towards the local end host.
When the local end host receives the Path message, it responds with a
Resv message with the LI flag set. This reserves the downstream
resources within the access network for the senders originally
identified by the local end host.
The Path Request message could also be used end-to-end, to request
the correspondent node to initiate a resource reservation. In this
case, the LI bit must not be set, since it would stop the message at
the local access network.
2.3. Additional functionality
All the other features of RSVP are used with LRSVP in the standard
way including the local repair mechanism and reservation tear down.
Downstream reservations are torn down with the Path Request Tear
message. The operation follows that of the Path Request: the message
does not change states within the network, but only triggers the
proxy to send a Path Tear message towards the end host for the
specified session.
All messages used for local reservations must have the LI flag set in
order to keep the signalling within the access network. Intermediate
RSVP routers between the local end host and the LRSVP proxy should
Manner et al Expires July 2003 [Page 6]
Internet-Draft Localized RSVP January 2003
not process the Path Request message and they should forward it as an
ordinary IP packet. An enhancement to the local repair changes this
operation and is discussed later.
The proposed scheme also allows RSVP to be used to signal DiffServ
Code Points in a DiffServ access network using the RSVP DCLASS object
[13]. The DCLASS object is used to represent and carry DiffServ code
points within RSVP messages. The local end host can use the DCLASS
object to instruct the LRSVP proxy to mark incoming traffic with
certain DiffServ code points to trigger different forwarding behavior
within the DiffServ access network. The local end host, however,
needs to be aware of the different code point values and the related
services, especially if other than standardized code points are used.
This information can be part of host auto-configuration, for example.
In addition, the LRSVP proxy may need information on how to map RSVP
requests to proper DiffServ classes if it wants to have closer
control of downstream resource allocations. This can be accomplished
by using standardized code point values for the DiffServ Assured
Forwarding service. Thus, our signalling mechanism can also be used
to give relative priority to specific flows without explicit resource
reservations.
Furthermore, the proposed signalling can be used at both ends of a
data stream. For example, if the two end hosts in different access
networks are communicating with each other, both of them could use
the mechanism to allocate resources, for example on their own access
networks, independently of each other. This could happen, if the two
access networks had a different view of QoS, one uses only IntServ
and RSVP, while the other also uses DiffServ. In such a scenario,
however, it may be more practical to use RSVP end-to-end, even if the
core network connecting the two access networks does not support
RSVP.
If the reserved bits in the RSVP Session Object are deemed too
valuable to be used for this kind of signalling, the RSVP CAP-object
[14] could be used to carry the two bits needed by the localized
RSVP. The CAP object can be used in the RSVP Path message to convey
end host/upstream node capabilities to the downstream network/nodes.
This would, however, add another eight bytes of headers in order to
carry two bits of information. In addition, the processing of the
messages is more time consuming due to the extra header. In any
case, the new Path Request and Path Request Tear messages are still
needed, because it would complicate the message processing in routers
if the "request to send a Path" was indicated as another bit in the
CAP object. With the new message type intermediate routers on the
uplink can forward these two messages to the LRSVP proxy faster,
since the router does not need to examine the whole packet and the
CAP object in order to find the same information, just the message
type.
Manner et al Expires July 2003 [Page 7]
Internet-Draft Localized RSVP January 2003
2.4. Addressing Issues
When the local end host sends Path or Path Request messages, it needs
to use some IP address as the destination in the IP header. The first
option is to use the destination address of the correspondent host
our local end host is trying to initiate a reservation for. However,
the end host may not know the correspondent node address, for
example, if it wants to allocate resources only for certain services
regardless of the sender, HTTP, for example. In such a case, the end
host must be given an address of an LRSVP proxy through auto-
configuration. Alternatively, in an IPv6 access network, LRSVP
proxies could have a reserved anycast address.
A further concern arises if the access network has several inbound
routes. It is possible that the local downstream reservation
initiated by the end host is set on a wrong LRSVP proxy, one that
will not get the packets arriving to the end host. This seems more of
a network design issue and therefore the access network operator must
locate the LRSVP proxies based on the packet routing - the proxies
could even be co-located at the access routers.
Still, it is possible to make the RSVP daemon running on the access
router to multicast the messages from the local end host to all LRSVP
proxies in the network and, thus, set up reservation states for all
inbound routes. This could be done only when the LI bit is set and
the reservation does not define a specific correspondent node.
2.5. Interworking Issues
The Localized RSVP makes use of two bits in the Session Object and
adds two new message types. There can be situations where such a
currently non-standard message arrives at a standard RSVP router.
According to the message processing rules in RFC2209, the Path
Request and Path Request Tear messages would be forwarded intact by
standard RSVP routers. However, for standard RSVP message, the bits
used by LRSVP may or may not be kept between RSVP hops, and, thus,
the indication of local signalling or the need for an expedited
refresh may be lost. Therefore, all RSVP routers within an access
network wanting to support local reservations must be set to keep the
bits intact.
In one scenario, the local network of the end host would not
understand the LRSVP extension or even standard RSVP. Thus, Path
messages with the LI bit and Path Request message can be routed out
of the local network. If the local network of the correspondent node
has support for LRSVP, that LRSVP proxy gets the Path or Path Request
message with the LI bit set from the external network. The proxy must
drop the message and respond with a Perr message and use a new error
code called "LRSVP not supported". This would inform the host that
LRSVP is not supported and it still can try end-to-end signalling.
Another interesting scenario arrises when the correspondent node is a
Manner et al Expires July 2003 [Page 8]
Internet-Draft Localized RSVP January 2003
mobile node and the parties use route optimization. It can happen,
that the correspondent node is actually in the same access network as
the end host using LRSVP, and the mobile none or both nodes try to
reserve local resources indepdently of each other. Now it is possible
that Path and Path Request messages with the LI bit set are routed
directly to the correspondent node, without going through a local
network LRSVP proxy.
A solution would be that end hosts can also perform the same
functions as an LRSVP proxy, that is, answer to Path messages with
the LI bit set and, most importantly, handle Path Request messages as
well:
o If an end host receives an unsolicited Path message with the LI bit
set, it should respond with a Resv message and not set the LI bit.
The reason is that that if the LRSVP proxies drop Path messages with
the LI bit set coming from external networks, the local end hosts can
trust that if they receive such a message, it must have (if the
network is properly configured) arrived from a node in the local
access network. Now, if our end host that sent the Path message
receives the Resv without the LI bit, it can use this as an
indication that the correspondent node is in the local access network
and may remove the LI bit in subsequent messages belonging to the
same session.
o Similary, if the correspondent node receives a Path Request
message, it should respond with a Path message that does not have the
LI bit set. Again, if our end host receives a Path message without
the LI bit set in response to the local Path Request sent earlier, it
can use this as an indication that the correspondent node is in the
local domain and it may remove the LI bit in subsequent messages
belonging to the same session.
Now, if the correspondent node moves again and changes access
networks, the signalling is already set to standard end-to-end mode
and reservations in the new RSVP-aware access network would be set in
place.
In the latter scenario, it is quite possible, that the mobile
correspondent node, located in the same access network as our end
host, is not (L)RSVP aware. Thus, it cannot respond the RSVP messages
and local, actually, any kind of RSVP-based, reservations are not
possible.
A further issue concerns the interactions between local and end-to-
end reservations: could a local reservation be 'upgraded' into an
end-to-end reservation? This should be possible for both directions:
o If the proxy receives a fully standard Path message from the local
network with the same session information as an existing local
reservation, it must forward the message as usual, but set a pending
Path state indication for the end-to-end reservation. If a Resv
arrives from the external network for this same session, it must
change the reservation to an end-to-end reservation.
Manner et al Expires July 2003 [Page 9]
Internet-Draft Localized RSVP January 2003
o If the proxy receives a Path Request message from the local network
without the LI bit set, it must forward the message to the IP
destination address. If the proxy receives later a Path message from
the external network for an existing local session, it must set a
pending state for the end-to-end reservation. If a Resv is received
from the local end host without the LI bit set, the proxy must change
its state for the session to 'end-to-end' (by removing a local-
indication from its session structures) and forward the Resv message
further to the external network.
Thus, it would be possible to upgrade a local session to end-to-end
status. It is not clear whether there is a need for an end-to-end
session to be 'downgraded' into a local session.
3. Fast local repair for mobile nodes
The RSVP standard [2] defines that Path messages can perform a local
repair of reservation paths. When the route between the communicating
end hosts changes, a Path message will set the Path state of the
reservation on the new route and a subsequent Resv message will make
the resource reservation. Therefore, by sending a Resv message a host
cannot alone update the reservation, and thus perform a local repair,
before a Path message has passed. The RSVP specification also says
that in order to provide fast adaptation to routing changes without
the overhead of short refresh periods, the local routing protocol
module can notify the RSVP process of route changes for particular
destinations. The RSVP process should use this information to trigger
a quick refresh of state for these destinations, using the new route
(Chapter 3.6, RFC2205 [2]). However, for example, Mobile IP, does not
affect routing directly in routers, and thus mobility may not be
noticed at intermediate RSVP routers.
When the mobile node has moved, it can send a Path message for each
upstream resource reservation and initiate the local repair mechanism
(Fig. 3). However, for the downstream, the mobile node will need to
wait until it receives a Path message, settting up the Path state on
the new route. Only after receiving the Path message, the mobile can
send a Resv message to re-reserve the downstream resources.
[END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY]
| | | | |
|-- Path towards CN (LI)---->| | |
| | | | |
| | (X-over router intercepts) | |
| | | | |
| |<- Resv (LI) -| | |
|<- Resv (LI)-| | | |
| | | | |
Figure 3: Fast upstream reservation
The Path Request message can be used in mobile networks to initiate a
faster local repair of downstream reservations on behalf of a mobile
Manner et al Expires July 2003 [Page 10]
Internet-Draft Localized RSVP January 2003
node that changed access routers during an ongoing RSVP session. When
the mobile node changes its access router in the network, it should
send the Path Request message immediately after the handover (Fig 4).
The message must have the ER bit set to indicate that the request is
for an existing session and triggered due to movement. The Path
Request message is forwarded through the intermediate RSVP routers
until it arrives at the LRSVP proxy. The message would then instruct
the proxy to initiate a local repair by sending the needed Path
message. The proxy must set the ER bit in the Session Object to
indicate that this Path message is not an ordinary refresh message
but instead triggered by a routing change and therefore must be
forwarded immediately to the next hop. If the ER bit is not set, the
RSVP router in Fig. 4 would not forward the Path message immediately
towards the mobile node but, instead, would wait until its own
scheduled refresh timeout.
[END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY]
| | | | |
|-------------- Path Request towards CN (LI,ER) --------------->|
| | | | |
| | | |<-Path (LI,ER)-|
| | |<-Path (LI,ER)-| |
| |<-Path (LI,ER)-| | |
|<-Path (LI,ER)-| | | |
| | | | |
|- Resv (LI) -->| | | |
| |- Resv (LI) -->| | |
| | | | |
Figure 4: Fast downstream reservation
If the movement of the mobile node results in packets to flow through
a new LRSVP proxy, the Path Request message would re-reserve the
local resources for the new path. In this case, the proxy notes that
the ER bit is set, but, since there is no existing state, it will
initiate a new reservation. The ER bit must not be set in the
following Path message since the reservation is a new one for this
route.
A enhancement to the scheme would allow a cross-over RSVP router that
has the reservation for the mobile node stored on a different
interface to send the needed Path message (Fig. 5). RSVP routers
inside the access network would look into Path Request messages. If
the router notices it is the cross-over router, it sends a Path
message towards the local end host. If an RSVP router sends the Path
message, it must not send the Path Request message any further. This
requires more intelligence from intermediate RSVP routers, but allows
for faster state updates. This functionality would be especially
important when the session is end-to-end instead of local: the Path
Request message would not go to the correspondent node, but trigger
the closer cross-over router to repair the local path of the
reservation.
Manner et al Expires July 2003 [Page 11]
Internet-Draft Localized RSVP January 2003
[END HOST] [NEW AR] [X-OVER ROUTER] [PROXY]
| | | |
|- Path Request towards CN (LI,ER) ->| |
| | | |
| | (X-over router intercepts) |
| | | |
| |<--- Path (LI) ---| |
|<-- Path (LI) ---| | |
| | | |
|--- Resv (LI) -->| | |
| |--- Resv (LI) --->| |
| | | |
Figure 5: Enhancement of the fast downstream reservation
The LI flag must be set in all RSVP refresh messages if the
reservation is set for the local access network. This will prevent
refresh message, like the Path Request message, to be routed out of
the access network.
4. Security Consideration
The Path Request message is handled similarly to a Reservation
Confirmation. Thus, the message triggers most processing at the LRSVP
proxy. This could potentially be used for Denial of Service attacks.
A possible solution is to make RSVP daemons located on access routers
make a sanity check on all Path Request (and Path Request Tear)
messages: the receiver of the stream must be a node on a link
connected to the AR. This requires that a security association must
be set up between the local end hosts and the access routers. This
has the benefit that the proxy may trust that the access router has
authenticated and authorized the message; this can be seen as
distributed processing (of the authentication and authorization
data). The same considerations apply for the Path message.
The RSVP daemon at the end hosts and LRSVP proxy must also modify
their security/sanity checks to allow the end host to send the Path
Request with apparently suspicious session information (identifying
the correspondent node(s)). Also, the proxy must be able to send RSVP
messages "on-behalf" of external network nodes.
The LRSVP proxy must be configured to identify its ingress and egress
interfaces. If the proxy receives a Path or a Path Request message
with the LI bit set from outside the access network, it must drop the
message.
The two new messages can make use of the standard RSVP INTEGRITY and
POLICY objects. For the remaining functionality, the security
considerations with standard RSVP apply.
Manner et al Expires July 2003 [Page 12]
Internet-Draft Localized RSVP January 2003
5. IANA Considerations
IANA needs to allocate the two flag bits in the RSVP Session Object,
the LI and ER bits. In addition, IANA needs to give two RSVP message
type numbers to the Path Request and Path Request Tear messages and
one Error Type indicating that a local resource reservation is not
allowed.
6. Summary
In summary, the Localized RSVP requires the following changes in the
standard RSVP protocol:
a) A new message type and number, named Path Request (initially
number 8).
b) A new message type and number, named Path Request Tear (initially
number 9).
c) A bit from the Session Object for the use as the Local Indication
(LI) (initially bit 0x8).
d) A bit from the Session Object for use as the Expedited Refresh
(ER) indication (initially bit 0x4).
e) An RSVP router must keep the LI bit set in all messages belonging
to that session, if it encounters packets with the bit set.
f) An RSVP router that is not also a proxy, must forward an RSVP
packet with a message type "Path Request" without storing state.
g) An access network RSVP router should be able to use the Path
Request as an indication of the need for a local repair. This can
enable faster reservation set up following a handover. This affects
point f), because the router that receives a Path Request must first
check if it has the Path state stored on another network interface.
If one is present, the Path Request message must not be forwarded to
the next hop and instead the router must send a Path message towards
the mobile node.
h) A new error code to indicate that the access network does not
support local reservations. If local resources cannot be requested,
the end-host can always try to do end-to-end signalling.
To summarize, these changes are small and would make RSVP more
appealing as a signalling protocol for IP access networks. The
changes are required only within access networks, unless the Path
Request message is deemed useful for a wider application.
Manner et al Expires July 2003 [Page 13]
Internet-Draft Localized RSVP January 2003
7. References
[1] R. Braden, D. Clark, S. Shenker, "Integrated Services in the
Internet Architecture: an Overview". Internet Engineering Task Force,
Request for Comments 1633, June 1994.
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource
ReSerVation Protocol (RSVP), Version 1 Functional Specification.
Internet Engineering Task Force, Request for Comments 2205,
September, 1997.
[3] J. Wroclawski, "The Use of RSVP with IETF Integrated Services.
Internet Engineering Task Force, Request for Comments 2210,
September, 1997.
[4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
Architecture for Differentiated Services", Internet Engineering Task
Force, Request for Comments 2475, December, 1998.
[5] G. Huston, "Next Steps for the IP QoS Architecture". Internet
Engineering Task Force, Request for Comments 2990, November 2000.
[6] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet". Internet Engineering Task
Force, Request for Comments 2638, July 1999.
[7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, "SBM
(Subnet Bandwidth Manager): A Protocol for RSVP-based Admission
Control over IEEE 802-style networks". Internet Engineering Task
Force, Request for Comments 2814, May 2000.
[8] Phil Chimento and Ben Teitelbaum, "QBone Bandwidth Broker
Architecture". The Internet2 initiative, June 2000.
(http://qbone.internet2.edu/bb/bboutline2.html).
[9] S. Gai, D. G. Dutt, N. Elfassy, Y. Bernet, "RSVP Proxy". Internet
Draft (work in progress), March 2002 (expired) (draft-ietf-rsvp-
proxy-03.txt).
[10] Jukka Manner and Kimmo Raatikainen, "Extended Quality-of-Service
for Mobile Networks". Proceedings of the 9th International Workshop
on Quality of Service (IWQoS), June 2001, pp. 275-280. Published in
the series Springer Lecture Notes in Computer Science (LNCS) 2092.
[11] IST-BRAIN Project, "Deliverable D2.2: BRAIN architecture
specifications and models, BRAIN functionality and protocol
specification". March 2001, (available at: http://www.ist-
brain.org).
[12] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
Protocol (RTSP)". Internet Engineering Task Force, Request for
Comments 2326, April 1998.
[13] Y. Bernet,"Format of the RSVP DCLASS Object". Internet
Manner et al Expires July 2003 [Page 14]
Internet-Draft Localized RSVP January 2003
Engineering Task Force, Request for Comments 2996, November 2000.
[14] Hamid Sued, "Capability Negotiation: The RSVP CAP Object".
Internet Draft (work in progress), May 2001 (expired) (draft-ietf-
issll-rsvp-cap-03.txt).
[15] J. Rosenberg aet al., "SIP: Session Initiation Protocol". RFC
3261, June 2002
[16] J. Manner at al., "Mobility related terminology". Internet
Draft, November 2002 (draft-ietf-seamoby-mobility-
terminology-01.txt).
8. Author's Addresses
Questions about this document may be directed to:
Jukka Manner
Department of Computer Science
University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-9-191-44210
Fax: +358-9-191-44441
E-Mail: jmanner@cs.helsinki.fi
Markku Kojo
Department of Computer Science
University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-9-191-44179
Fax: +358-9-191-44441
E-Mail: kojo@cs.helsinki.fi
Kimmo Raatikainen
Department of Computer Science
University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-50-483-6275
Fax: +358-9-191-44441
E-Mail: kraatika@cs.helsinki.fi
Tapio Suihko
VTT Information Technology
Manner et al Expires July 2003 [Page 15]
Internet-Draft Localized RSVP January 2003
P.O. Box 1203
FIN-02044 VTT
Finland
Voice: +358-9-456-6078
Fax: +358-9-456-7028
E-Mail: tapio.suihko@vtt.fi
Mika Liljeberg
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Voice: +358-50-4836791
Fax: +358-
E-Mail: Mika.Liljeberg@nokia.com
Acknowledgement
This work has been partially performed in the framework of the IST
project IST-2000-28584 MIND, which is partly funded by the European
Union. The authors would like to acknowledge the help of their
colleagues in preparing this document, in particular Eleanor Hepworth
and Alberto Lopez.
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Manner et al Expires July 2003 [Page 16]