< draft-manner-lrsvp-02.txt   draft-manner-lrsvp-03.txt >
Internet Engineering Task Force J. Manner Internet Engineering Task Force J. Manner
Internet-Draft T. Suihko Internet-Draft T. Suihko
Expires: December, 2003 M. Kojo Expires: July, 2004 M. Kojo
M. Liljeberg M. Liljeberg
K. Raatikainen K. Raatikainen
June, 2003 January, 2004
Localized RSVP Localized RSVP
<draft-manner-lrsvp-02.txt> <draft-manner-lrsvp-03.txt>
Status of this Memo Status of this Memo
This document is a submission to the Transport Area Working Group of This document is a submission to the Transport Area Working Group of
the Internet Engineering Task Force (IETF). Comments should be the Internet Engineering Task Force (IETF). Comments should be
submitted to the tsvwg@ietf.org mailing list. submitted to the tsvwg@ietf.org mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in December 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Guaranteed QoS for multimedia applications is based on reserved Guaranteed QoS for multimedia applications is based on reserved
resources in each node on the end-to-end path. Even if the 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 correspondent node does not support QoS, it would be useful to be
able to reserve at least local resources at the access network, able to reserve at least local resources at the access network,
especially wireless link resources. Additionally, for mobile nodes especially wireless link resources. Additionally, for mobile nodes
the continuity of QoS is disturbed due to end-to-end signaling or the continuity of QoS is disturbed due to end-to-end signaling or
slow re-reservations of resources after each handover. This draft slow re-reservations of resources after each handover. This draft
proposes a simple enhancement to RSVP, so that initial resource proposes a simple enhancement to RSVP, so that initial resource
reservations and re-reservations due to host mobility can be done reservations and re-reservations due to host mobility can be done
locally in an access network. locally in an access network.
Changes since -02
- Clarified parts of the text, e.g. Section 2.4
Changes since -01 Changes since -01
- Some clarifications and editorial changes - Some clarifications and editorial changes
Table of Contents Table of Contents
1 Introduction ................................................. 2 1 Introduction ................................................. 2
1.1 Related work ............................................... 3 1.1 Related work ............................................... 3
2 Local QoS Support ............................................ 4 2 Local QoS Support ............................................ 4
2.1 Upstream transfers ......................................... 5 2.1 Upstream transfers ......................................... 5
2.2 Downstream transfers ....................................... 6 2.2 Downstream transfers ....................................... 6
2.3 Additional functionality ................................... 7 2.3 Additional functionality ................................... 7
2.4 Addressing Issues .......................................... 8 2.4 Addressing Issues .......................................... 8
2.5 Interworking Issues ........................................ 9 2.5 Interworking Issues ........................................ 9
3 Fast local repair for mobile nodes ........................... 10 3 Fast local repair for mobile nodes ........................... 11
4 Security Consideration ....................................... 13 4 Security Consideration ....................................... 13
5 IANA Considerations .......................................... 13 5 IANA Considerations .......................................... 14
6 Summary ...................................................... 13 6 Summary ...................................................... 14
7 References ................................................... 14 7 Normative References ......................................... 15
8 Authors' Addresses ........................................... 16 8 Non-Normative References ..................................... 16
9 Authors' Addresses ........................................... 17
1. Introduction 1. Introduction
Future mobile access networks will be based on IP technology. This Future mobile access networks will be based on IP technology. This
implies that, on the network layer, all traffic, both traditional implies that, on the network layer, all traffic, both traditional
data and streamed data like audio or video, is transmitted as data and streamed data like audio or video, is transmitted as
packets. Increasingly popular multimedia applications would benefit packets. Increasingly popular multimedia applications would benefit
from better than best-effort service from the network, a forwarding from better than best-effort service from the network, a forwarding
service with strict Quality of Service (QoS) with guaranteed minimum service with strict Quality of Service (QoS) with guaranteed minimum
bandwidth and bounded delay. Other applications, such as electronic bandwidth and bounded delay. Other applications, such as electronic
skipping to change at page 3, line 5 skipping to change at page 3, line 10
mobile environments. DiffServ can only provide statistical mobile environments. DiffServ can only provide statistical
guarantees and is not well suited for dynamic environments. The guarantees and is not well suited for dynamic environments. The
Internet Architecture Board has outlined additional issues related to Internet Architecture Board has outlined additional issues related to
these two architectures [5]. these two architectures [5].
Let us consider a scenario, where a fixed network correspondent node Let us consider a scenario, where a fixed network correspondent node
(CN) would be sending a multimedia stream to an end host behind a (CN) would be sending a multimedia stream to an end host behind a
wireless link. If the correspondent node does not support RSVP it wireless link. If the correspondent node does not support RSVP it
cannot signal its traffic characteristics to the network and request cannot signal its traffic characteristics to the network and request
specific forwarding services. Likewise, if the correspondent node is specific forwarding services. Likewise, if the correspondent node is
not able to mark its traffic with a DiffServ Code Point (DSCP) to not able to mark its traffic with a proper DiffServ Code Point (DSCP)
trigger service differentiation, the multimedia stream will get only to trigger service differentiation, the multimedia stream will get
best-effort service which may result in poor visual and audio quality only best-effort service which may result in poor visual and audio
in the receiving application. Even if the connecting wired network is quality in the receiving application. Even if the connecting wired
over-provisioned, an end host would still benefit from local resource network is over-provisioned, an end host would still benefit from
reservations, especially in wireless access networks, where the local resource reservations, especially in wireless access networks,
bottleneck resource is most probably the wireless link. where the bottleneck resource is most probably the wireless link.
We propose a slight modification to RSVP that allows distinguishing We propose a slight modification to RSVP that allows distinguishing
local network reservations from the end-to-end reservations. The end local network reservations from the end-to-end reservations. The end
host does not need to know the access network topology or the nodes host does not need to know the access network topology or the nodes
that will reserve the local resources. The reservation message itself that will reserve the local resources. The reservation message itself
identifies the intention and the access network will find the correct identifies the intention and the access network will find the correct
network node(s) to respond to the reservation. Note that the scheme 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 is not tied to only mobile networks but can be used in any access
network that needs flexible local resource allocations. The first network that needs flexible local resource allocations. The first
sketch of this solution appeared in [10] and [11], although some sketch of this solution appeared in [10] and [11], although some
implementation ideas have changed since. implementation ideas have changed since.
The localized RSVP signaling would fit well, for example, with a SIP The localized RSVP signaling would fit well, for example, with a SIP
session, where a call set up can have a pre-condition: if the request 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 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 message and make the call "ring" [15]. Both ends would use their own
local reservations. local reservations.
All mobility-related terminology in this document are taken from All mobility-related terminology in this document are taken from
[16]. Therefore, the commonly used term 'access router' (AR) means [16]. Therefore, the commonly used term 'access router' (AR) means
the 'default router'. the 'default router'.
1.1. Related work 1.1. Related work
Currently we can identify two ways to signal QoS requirements to an Currently we can identify two ways to signal QoS requirements to an
access network: DiffServ Code Points (DSCP) and RSVP with IntServ. In access network: DiffServ Code Points (DSCP) and RSVP with IntServ. In
skipping to change at page 4, line 36 skipping to change at page 4, line 40
The usual signaling model of RSVP includes the data sender and The usual signaling model of RSVP includes the data sender and
receiver, and a network of RSVP routers. The data sender initiates receiver, and a network of RSVP routers. The data sender initiates
the RSVP signaling by sending the Path message. This message is the RSVP signaling by sending the Path message. This message is
routed through the network, setting states in RSVP routers, and routed through the network, setting states in RSVP routers, and
finally arriving at the data receiver. The receiver then responds to finally arriving at the data receiver. The receiver then responds to
the signaling by sending the Resv message, which applies the the signaling by sending the Resv message, which applies the
reservation for the data stream. reservation for the data stream.
If the data receiver is not RSVP-aware, it can not respond to the If the data receiver is not RSVP-aware, it can not respond to the
signaling and make the resource reservation happen. Similarly, if the signaling and make the resource reservation happen. Similarly, if the
receiver is RSVP-ware, but the sender is not, the sender can not receiver is RSVP-aware, but the sender is not, the sender can not
initiate the signaling for the resource reservation. initiate the signaling for the resource reservation.
In the Localized RSVP scheme, we expect the local end host to be In the Localized RSVP scheme, we expect the local end host to be
RSVP-aware and add an RSVP-aware application to a router in the local RSVP-aware and we add an RSVP-aware application to a router in the
access network. This 'proxy' is called the Localized RSVP Proxy local access network. This 'proxy' is called the Localized RSVP Proxy
server (LRSVP proxy) and is located somewhere within the local access server (LRSVP proxy) and is located somewhere within the local access
network - a good place would be the access network gateway. network - a good place would be the access network gateway. For local
reservations, the proxy acts on behalf of correspondent nodes. In
this discussion, from a software engineering point of view, the proxy
is its own process running on the router. Thus, the following three
logical functions are kept separate: basic IP routing, basic RSVP
message processing, and LRSVP proxy functionality.
Now, in order to distinguish local reservations from end-to-end Now, in order to distinguish local reservations from end-to-end
reservations, we use one bit in the unused Flags field in the RSVP reservations, we use one bit in the unused Flags field in the RSVP
Session Object. The Local Indication (LI) bit (currently we use bit Session Object. The Local Indication (LI) bit (currently we use bit
0x8) is used to differentiate reservations that are internal to the 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 access network. When the bit is set the RSVP message is part of local
resource signaling and the RSVP router running the proxy will not resource signaling and the RSVP router running the proxy will not
forward the message to the next hop but instead give the message to forward the message to the next hop but instead give the message to
the RSVP-application running on the router. A default value of zero the RSVP-application running on the router. A default value of zero
indicates standard end-to-end signaling, where the proxy application indicates standard end-to-end signaling, where the proxy application
skipping to change at page 5, line 36 skipping to change at page 5, line 45
network, it uses the LI flag in RSVP messages to indicate a local network, it uses the LI flag in RSVP messages to indicate a local
reservation. The structure of the RSVP messages follows the RSVP reservation. The structure of the RSVP messages follows the RSVP
standard. When the router running the LRSVP proxy receives an RSVP standard. When the router running the LRSVP proxy receives an RSVP
message with the LI bit set it will notice that the flag was set and message with the LI bit set it will notice that the flag was set and
does not forward the message further to the next hop. The RSVP daemon does not forward the message further to the next hop. The RSVP daemon
on the router gives the message to the local RSVP application, which on the router gives the message to the local RSVP application, which
responds according to the following description. responds according to the following description.
2.1. Upstream transfers 2.1. Upstream transfers
Setting upstream reservations is straightforward and follows closely Setting local upstream reservations is straightforward and follows
the standard RSVP functionality. The local end host sends the usual closely the standard RSVP functionality. The local end host sends the
Path message, but sets the LI flag bit in the Session Object. The usual Path message, but sets the LI flag bit in the Session Object.
Session Object of the message defines the destination of the flow The Session Object of the message defines the destination of the flow
that will eventually be transmitted from the local end host, and the that will eventually be transmitted from the local end host, and the
Sender Template provides information about the local end host itself. Sender Template provides information about the local end host itself.
[END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN] [END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN]
| | | | | | | | | |
|------------- Path towards CN (LI) ---------->| | |------------- Path towards CN (LI) ---------->| |
| | | | | | | | | |
| | | (proxy intercepts) | | | | (proxy intercepts) |
| | | | | | | | | |
| | |<---- Resv ----| | | | |<---- Resv ----| |
skipping to change at page 6, line 26 skipping to change at page 6, line 41
SIP [15] or RTSP [12]. Based on this correspondence, the local end SIP [15] or RTSP [12]. Based on this correspondence, the local end
host knows the necessary information about the sender. Another, more host knows the necessary information about the sender. Another, more
coarse reservation could be set, for example, for browsing different coarse reservation could be set, for example, for browsing different
audio servers; the local end host would indicate in the RSVP messages audio servers; the local end host would indicate in the RSVP messages
that the sender will use UDP. It is, therefore, possible to make that the sender will use UDP. It is, therefore, possible to make
resource reservations for any sender that wants to communicate with resource reservations for any sender that wants to communicate with
the local end host. However, in order to allow for more accurate QoS the local end host. However, in order to allow for more accurate QoS
support, more information should be given. The way to find this support, more information should be given. The way to find this
information is out of scope of this document. information is out of scope of this document.
In order to set up the downstream reservation we need a way to signal In order to set up a local downstream reservation we need a way to
the LRSVP proxy to initiate the RSVP reservation set up on behalf of signal the LRSVP proxy to initiate the RSVP reservation set up on
the sender(s), that is, to send a Path message. To achieve this, the behalf of the sender(s), that is, to send a Path message. To achieve
local end host sends the Path Request message with the LI flag bit this, the local end host sends the Path Request message with the LI
set (Fig. 2). The Path Request message is identical to a standard flag bit set (Fig. 2). The Path Request message is identical to a
Path message apart from the message type field. The Session Object standard Path message apart from the message type field. The Session
must include information about the recipient, the local end host in Object must include information about the recipient, the local end
this case, and the Sender Template must define the expected host in this case, and the Sender Template must define the expected
sender(s). The Traffic specification (Tspec) can either be based on sender(s). The Traffic specification (Tspec) can either be based on
the local end user's wishes, a best estimate of the incoming traffic the local end user's wishes, a best estimate of the incoming traffic
characteristics, or on application level session signaling prior to characteristics, or on application level session signaling prior to
the transfer. the transfer.
[END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN] [END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN]
| | | | | | | | | |
|------------ Path Request towards CN (LI) --->| | |------------ Path Request towards CN (LI) --->| |
| | | | | | | | | |
| | | (proxy intercepts) | | | | (proxy intercepts) |
skipping to change at page 7, line 16 skipping to change at page 7, line 35
downstream flow and use the information in the message to fill the downstream flow and use the information in the message to fill the
objects in a Path message. The proxy now generates a Path message objects in a Path message. The proxy now generates a Path message
that includes the parameter values in the Path Request message and that includes the parameter values in the Path Request message and
sends it towards the local end host. sends it towards the local end host.
When the local end host receives the Path message, it responds with a When the local end host receives the Path message, it responds with a
Resv message with the LI flag set. This reserves the downstream Resv message with the LI flag set. This reserves the downstream
resources within the access network for the senders originally resources within the access network for the senders originally
identified by the local end host. identified by the local end host.
The Path Request message could also be used end-to-end, to request The Path Request message can also be used end-to-end, to request the
the correspondent node to initiate a resource reservation. In this correspondent node to initiate a resource reservation. In this case,
case, the LI bit must not be set, since it would stop the message at the LI bit must not be set, since it would stop the message at the
the local access network. local access network.
2.3. Additional functionality 2.3. Additional functionality
All the other features of RSVP are used with LRSVP in the standard All the other features of RSVP are used with LRSVP in the standard
way including the local repair mechanism and reservation tear down. way including the local repair mechanism and reservation tear down.
Downstream reservations are torn down with the Path Request Tear Downstream reservations are torn down with the Path Request Tear
message. The operation follows that of the Path Request: the message message. The operation follows that of the Path Request: the message
does not change states within the network, but only triggers the does not change states within the network, but only triggers the
proxy to send a Path Tear message towards the end host for the proxy to send a Path Tear message towards the end host for the
specified session. specified session.
skipping to change at page 7, line 49 skipping to change at page 8, line 14
Code Points in a DiffServ access network using the RSVP DCLASS object Code Points in a DiffServ access network using the RSVP DCLASS object
[13]. The DCLASS object is used to represent and carry DiffServ code [13]. The DCLASS object is used to represent and carry DiffServ code
points within RSVP messages. The local end host can use the DCLASS points within RSVP messages. The local end host can use the DCLASS
object to instruct the LRSVP proxy to mark incoming traffic with object to instruct the LRSVP proxy to mark incoming traffic with
certain DiffServ code points to trigger different forwarding behavior certain DiffServ code points to trigger different forwarding behavior
within the DiffServ access network. The local end host, however, within the DiffServ access network. The local end host, however,
needs to be aware of the different code point values and the related needs to be aware of the different code point values and the related
services, especially if other than standardized code points are used. services, especially if other than standardized code points are used.
This information can be part of host auto-configuration, for example. 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 signaling mechanism can also be used
to give relative priority to specific flows without explicit resource
reservations.
Furthermore, the proposed signaling can be used at both ends of a Furthermore, the proposed signaling can be used at both ends of a
data stream. For example, if the two end hosts in different access data stream. For example, if the two end hosts in different access
networks are communicating with each other, both of them could use networks are communicating with each other, both of them could use
the mechanism to allocate resources, for example on their own access the mechanism to allocate resources, for example, in their own access
networks, independently of each other. This could happen, if the two networks, independently of each other. This could happen, if the two
access networks had a different view of QoS, one uses only IntServ access networks had a different view of QoS, one uses only IntServ
and RSVP, while the other also uses DiffServ. In such a scenario, 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 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 core network connecting the two access networks does not support
RSVP. RSVP.
If the reserved bits in the RSVP Session Object are deemed too If the reserved bits in the RSVP Session Object are deemed too
valuable to be used for this kind of signaling, the RSVP CAP-object valuable to be used for this kind of signaling, the RSVP CAP-object
[14] could be used to carry the two bits needed by the localized [14] could be used to carry the two bits needed by the localized
skipping to change at page 8, line 36 skipping to change at page 8, line 45
if the "request to send a Path" was indicated as another bit in the 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 CAP object. With the new message type intermediate routers on the
uplink can forward these two messages to the LRSVP proxy faster, uplink can forward these two messages to the LRSVP proxy faster,
since the router does not need to examine the whole packet and the 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 CAP object in order to find the same information, just the message
type. type.
2.4. Addressing Issues 2.4. Addressing Issues
When the local end host sends Path or Path Request messages, it needs 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 to use some IP address as the destination in the IP header. There are
option is to use the destination address of the correspondent host various options about which address the local end host can or can not
our local end host is trying to initiate a reservation for. However, use. The local end host must use in priority order (if known):
the end host may not know the correspondent node address, for
example, if it wants to allocate resources only for certain services 1. The address of the correspondent host,
regardless of the sender, HTTP, for example. In such a case, the end 2. The address of a proper LRSVP proxy,
host must be given an address of an LRSVP proxy through auto- 3. A well-known anycast address for LRSVP proxies,
configuration. Alternatively, in an IPv6 access network, LRSVP 4. The address of the next-hop RSVP router, or
proxies could have a reserved anycast address. 5. The address of the default router.
The first option may not be possible, if the end host wants to
allocate resources only for certain services regardless of the
sender, HTTP, for example. The second possible address could be given
through auto-configuration. Alternatively, in an IPv6 access network,
LRSVP proxies could have a reserved anycast address, as in the third
option. The fourth option would be to send the IP packet to the next-
hop RSVP router, if the end host has knowledge of it - ideally, this
would be the default router, in a mobile access network, it would be
the access router.
Finally, if any of the earlier addresses are not known, the end host
may try to send the RSVP packet to the default router, and see if the
router is also running an RSVP daemon and could handle the
reservation attempt. If the default router is not running an RSVP
daemon, it will return an ICMP error message. Currently, it is
unclear whether there is anything that still could be done, or just
turn the attempt for a local reservation down.
A further concern arises if the access network has several inbound A further concern arises if the access network has several inbound
routes. It is possible that the local downstream reservation routes. It is possible that the local downstream reservation
initiated by the end host is set on a wrong LRSVP proxy, one that 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 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 a network design issue and therefore the access network operator must
locate the LRSVP proxies based on the packet routing - the proxies locate the LRSVP proxies based on the packet routing - the proxies
could even be co-located at the access routers. could even be co-located at the access routers.
Still, it is possible to make the RSVP daemon running on the access Still, it is possible to make the RSVP daemon running on the access
skipping to change at page 9, line 12 skipping to change at page 9, line 40
proxies in the network and, thus, set up reservation states for all 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 inbound routes. This could be done only when the LI bit is set and
the reservation does not define a specific correspondent node. the reservation does not define a specific correspondent node.
2.5. Interworking Issues 2.5. Interworking Issues
The Localized RSVP makes use of two bits in the Session Object and 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 adds two new message types. There can be situations where such a
currently non-standard message arrives at a standard RSVP router. currently non-standard message arrives at a standard RSVP router.
According to the message processing rules in RFC2209, the Path According to the message processing rules in RFC2209 [18], the Path
Request and Path Request Tear messages would be forwarded intact by Request and Path Request Tear messages would be forwarded intact by
standard RSVP routers. However, for standard RSVP message, the bits standard RSVP routers. However, for standard RSVP message, the bits
used by LRSVP may or may not be kept between RSVP hops, and, thus, used by LRSVP may or may not be kept between RSVP hops, and, thus,
the indication of local signaling or the need for an expedited the indication of local signaling or the need for an expedited
refresh may be lost. Therefore, all RSVP routers within an access refresh may be lost. Therefore, all RSVP routers within an access
network wanting to support local reservations must be set to keep the network wanting to support local reservations must be set to keep the
bits intact. bits intact.
In one scenario, the local network of the end host would not In one scenario, the local network of the end host would not
understand the LRSVP extension or even standard RSVP. Thus, Path understand the LRSVP extension or even standard RSVP. Thus, Path
skipping to change at page 9, line 35 skipping to change at page 10, line 10
has support for LRSVP, that LRSVP proxy gets the Path or Path Request 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 message with the LI bit set from the external network. The proxy must
drop the message and respond with a PathErr message and use a new drop the message and respond with a PathErr message and use a new
error code called "LRSVP not supported". This would inform the host error code called "LRSVP not supported". This would inform the host
that LRSVP is not supported and it still can try end-to-end that LRSVP is not supported and it still can try end-to-end
signaling. signaling.
Another interesting scenario arises when the correspondent node is a Another interesting scenario arises when the correspondent node is a
mobile node and the parties use route optimization. It can happen, mobile node and the parties use route optimization. It can happen,
that the correspondent node is actually in the same access network as 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 the end host using LRSVP, and either or both nodes try to reserve
reserve local resources independently of each other. Now it is local resources independently of each other. Now it is possible that
possible that Path and Path Request messages with the LI bit set are Path and Path Request messages with the LI bit set are routed
routed directly to the correspondent node, without going through a directly to the correspondent node, without going through a local
local network LRSVP proxy. network LRSVP proxy.
A solution would be that end hosts can also perform the same A solution would be that end hosts can also perform the same
functions as an LRSVP proxy, that is, answer to Path messages with functions as an LRSVP proxy, that is, answer to Path messages with
the LI bit set and, most importantly, handle Path Request messages as the LI bit set and, most importantly, handle Path Request messages as
well: well:
o If an end host receives an unsolicited Path message with the LI bit 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. 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 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 the LI bit set coming from external networks, the local end hosts can
skipping to change at page 10, line 16 skipping to change at page 10, line 44
message, it should respond with a Path message that does not have the 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 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 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 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 local domain and it may remove the LI bit in subsequent messages
belonging to the same session. belonging to the same session.
Now, if the correspondent node moves again and changes access Now, if the correspondent node moves again and changes access
networks, the signaling is already set to standard end-to-end mode networks, the signaling is already set to standard end-to-end mode
and reservations in the new RSVP-aware access network would be set in and reservations in the new RSVP-aware access network would be set in
place. place. However, changing access networks implies most probably a
change in the IP address assigned to the CN, which forces a re-
reservation of resources.
In the latter scenario, it is quite possible, that the mobile In the latter scenario, it is quite possible, that the mobile
correspondent node, located in the same access network as our end correspondent node, located in the same access network as our end
host, is not (L)RSVP aware. Thus, it cannot respond the RSVP messages host, is not (L)RSVP aware. Thus, it cannot respond to the RSVP
and local, actually, any kind of RSVP-based, reservations are not messages and local, actually, any kind of RSVP-based, reservations
are not possible.
Moreover, the location of the LRSVP proxy may yet affect the
signaling of two nodes within the same access network. Consider the
case where each access router would also host an LRSVP proxy. Now if
the two communicating nodes are connected to different access
routers, the two nodes may use their own local reservations on the
last-hop link, but also a standard end-to-end reservation is
possible. possible.
A further issue concerns the interactions between local and end-to- A further issue concerns the interactions between local and end-to-
end reservations: could a local reservation be 'upgraded' into an end reservations: could a local reservation be 'upgraded' into an
end-to-end reservation? This should be possible for both directions: end-to-end reservation? This should be possible for both directions:
o If the proxy receives a fully standard Path message from the local o If the proxy receives a fully standard Path message from the local
network with the same session information as an existing local network with the same session information as an existing local
reservation, it must forward the message as usual, but set a pending reservation, it must forward the message as usual, but set a pending
Path state indication for the end-to-end reservation. If a Resv Path state indication for the end-to-end reservation. If a Resv
skipping to change at page 10, line 49 skipping to change at page 11, line 33
pending state for the end-to-end reservation. If a Resv is received 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 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- its state for the session to 'end-to-end' (by removing a local-
indication from its session structures) and forward the Resv message indication from its session structures) and forward the Resv message
further to the external network. further to the external network.
Thus, it would be possible to upgrade a local session to end-to-end 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 status. It is not clear whether there is a need for an end-to-end
session to be 'downgraded' into a local session. session to be 'downgraded' into a local session.
Note that when the resource signaling is going end-to-end, the local
repair functionality may be affected. If both nodes use only local
reservations, the local repair at either end is propagated at most to
the local LRSVP proxy. With end-to-end reservations, the local repair
may be propagated further away from the moving node and its access
network.
3. Fast local repair for mobile nodes 3. Fast local repair for mobile nodes
The RSVP standard [2] defines that Path messages can perform a local The RSVP standard [2] defines that Path messages can perform a local
repair of reservation paths. When the route between the communicating repair of reservation paths. When the route between the communicating
end hosts changes, a Path message will set the Path state of the 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 reservation on the new route and a subsequent Resv message will apply
the resource reservation. Therefore, by sending a Resv message a host the resource reservation. Therefore, by sending a Resv message a host
cannot alone update the reservation, and thus perform a local repair, cannot alone update the reservation, and thus perform a local repair,
before a Path message has passed. The RSVP specification also says before a Path message has passed. The RSVP specification also says
that in order to provide fast adaptation to routing changes without that in order to provide fast adaptation to routing changes without
the overhead of short refresh periods, the local routing protocol the overhead of short refresh periods, the local routing protocol
module can notify the RSVP process of route changes for particular module can notify the RSVP process of route changes for particular
destinations. The RSVP process should use this information to trigger destinations. The RSVP process should use this information to trigger
a quick refresh of state for these destinations, using the new route a quick refresh of state for these destinations, using the new route
(Chapter 3.6, RFC2205 [2]). However, for example, Mobile IP, does not (Chapter 3.6, RFC2205 [2]). However, for example, Mobile IP, does not
affect routing directly in routers, and thus mobility may not be affect routing directly in routers, and thus mobility may not be
noticed at intermediate RSVP routers. noticed at intermediate RSVP routers.
When the mobile node has moved, it can send a Path message for each When the mobile node has moved, it can send a Path message for each
upstream resource reservation and initiate the standard local repair upstream resource reservation and initiate the standard local repair
mechanism (Fig. 3). However, for the downstream, the mobile node will mechanism (Fig. 3). If there is no cross-over router, and the Path
need to wait until it receives a Path message, setting up the Path message arrives at a new LRSVP proxy, the proxy will reply to the
state on the new route. Only after receiving the Path message, the Path with a Resv, similarly as it would for a new resource
mobile can send a Resv message to re-reserve the downstream reservation request (what this actually looks like to the new proxy).
resources.
[END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY] [END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY]
| | | | | | | | | |
|-- Path towards CN (LI)---->| | | |-- Path towards CN (LI)---->| | |
| | | | | | | | | |
| | (X-over router intercepts) | | | | (X-over router intercepts) | |
| | | | | | | | | |
| |<- Resv (LI) -| | | | |<- Resv (LI) -| | |
|<- Resv (LI)-| | | | |<- Resv (LI)-| | | |
| | | | | | | | | |
Figure 3: Fast upstream reservation Figure 3: Fast upstream reservation
For the downstream, the mobile node will need to wait until it
receives a Path message, setting 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.
The Path Request message can be used in mobile networks to initiate a The Path Request message can be used in mobile networks to initiate a
faster local repair of downstream reservations on behalf of a mobile faster local repair of downstream reservations on behalf of a mobile
node that changed access routers during an ongoing RSVP session. When node that changed access routers during an ongoing RSVP session. When
the mobile node changes its access router in the network, it should the mobile node changes its access router in the network, it should
send the Path Request message immediately after the handover (Fig 4). send the Path Request message immediately after the handover (Fig 4).
[END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY] [END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY]
| | | | | | | | | |
|-------------- Path Request towards CN (LI,ER) --------------->| |-------------- Path Request towards CN (LI,ER) --------------->|
| | | | | | | | | |
skipping to change at page 13, line 7 skipping to change at page 13, line 52
Figure 5: Enhancement of the fast downstream reservation Figure 5: Enhancement of the fast downstream reservation
The LI flag must be set in all RSVP refresh messages if the The LI flag must be set in all RSVP refresh messages if the
reservation is set for the local access network. This will prevent reservation is set for the local access network. This will prevent
refresh message, like the Path Request message, to be routed out of refresh message, like the Path Request message, to be routed out of
the access network. the access network.
4. Security Consideration 4. Security Consideration
The Path Request message is handled similarly to a Reservation The Path Request message triggers most processing at the LRSVP proxy.
Confirmation. Thus, the message triggers most processing at the LRSVP This could potentially be used for Denial of Service attacks. A
proxy. This could potentially be used for Denial of Service attacks. possible solution is to make RSVP daemons located on access routers
A possible solution is to make RSVP daemons located on access routers
make a sanity check on all Path Request (and Path Request Tear) 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 messages: the receiver of the stream must be a node on a link
connected to the AR. This requires that a security association must connected to the AR. This has the benefit that the proxy may trust
be set up between the local end hosts and the access routers. This that the access router has validated the message; this can be seen as
has the benefit that the proxy may trust that the access router has distributed processing of the authentication and authorization data.
authenticated and authorized the message; this can be seen as The same considerations apply for the Path message. In order to
distributed processing (of the authentication and authorization secure any RSVP signaling, a security association must be set up
data). The same considerations apply for the Path message. between the local end hosts and the access routers.
The RSVP daemon at the end hosts and LRSVP proxy must also modify 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 their security/sanity checks to allow the end host to send the Path
Request with apparently suspicious session information (identifying Request with apparently suspicious session information (identifying
the correspondent node(s)). Also, the proxy must be able to send RSVP the correspondent node(s)). Also, the proxy must be able to send RSVP
messages "on-behalf" of external network nodes. messages "on-behalf" of external network nodes.
The LRSVP proxy must be configured to identify its ingress and egress The LRSVP proxy must be configured to identify its ingress and egress
interfaces. If the proxy receives a Path or a Path Request message 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 with the LI bit set from outside the access network, it must drop the
message. message.
The two new messages can make use of the standard RSVP INTEGRITY and The two new messages can make use of the standard RSVP INTEGRITY and
POLICY objects. For the remaining functionality, the security POLICY objects. This requires that the MN and ARs share the required
considerations with standard RSVP apply, which are analyzed well by keys. For the remaining functionality, the security considerations
the NSIS WG in [17]. with standard RSVP apply, which are analyzed well by the NSIS WG in
[17].
5. IANA Considerations 5. IANA Considerations
IANA needs to allocate the two flag bits in the RSVP Session Object, 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 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 type numbers to the Path Request and Path Request Tear messages and
one Error Type indicating that a local resource reservation is not one Error Type indicating that a local resource reservation is not
allowed. allowed.
6. Summary 6. Summary
skipping to change at page 14, line 15 skipping to change at page 15, line 8
d) A bit from the Session Object for use as the Expedited Refresh d) A bit from the Session Object for use as the Expedited Refresh
(ER) indication (initially bit 0x4). (ER) indication (initially bit 0x4).
e) An RSVP router must keep the LI bit set in all messages belonging 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. 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 f) An RSVP router that is not also a proxy, must forward an RSVP
packet with a message type "Path Request" without storing state. packet with a message type "Path Request" without storing state.
g) An access network RSVP router should be able to use the Path g) An RSVP router that is not also a proxy, must forward an RSVP
packet with a message type "Path Request Tear" without affecting the
stored state.
h) 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 Request as an indication of the need for a local repair. This can
enable faster reservation set up following a handover. This affects enable faster reservation set up following a handover. This affects
point f), because the router that receives a Path Request must first point f), because the router that receives a Path Request must first
check if it has the Path state stored on another network interface. 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 If one is present, the Path Request message should not be forwarded
the next hop and instead the router must send a Path message towards to the next hop and instead the router must send a Path message
the mobile node. towards the mobile node.
h) A new error code to indicate that the access network does not i) A new error code to indicate that the access network does not
support local reservations. If local resources cannot be requested, support local reservations. If local resources cannot be requested,
the end-host can always try to do end-to-end signaling. the end-host can always try to do end-to-end signaling.
To summarize, these changes are small and would make RSVP more To summarize, these changes are small and would make RSVP more
appealing as a signaling protocol for IP access networks. The changes appealing as a signaling protocol for IP access networks. The changes
are required only within access networks, unless the Path Request are required only within access networks, unless the Path Request
message is deemed useful for a wider application. message is deemed useful to use end-to-end through the Internet.
7. References 7. Normative References
[1] R. Braden, D. Clark, S. Shenker, "Integrated Services in the [1] R. Braden, D. Clark, S. Shenker, "Integrated Services in the
Internet Architecture: an Overview". Internet Engineering Task Force, Internet Architecture: an Overview". Internet Engineering Task Force,
Request for Comments 1633, June 1994. Request for Comments 1633, June 1994.
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource
ReSerVation Protocol (RSVP), Version 1 Functional Specification. ReSerVation Protocol (RSVP), Version 1 Functional Specification.
Internet Engineering Task Force, Request for Comments 2205, Internet Engineering Task Force, Request for Comments 2205,
September, 1997. September, 1997.
[3] J. Wroclawski, "The Use of RSVP with IETF Integrated Services. [3] J. Wroclawski, "The Use of RSVP with IETF Integrated Services.
Internet Engineering Task Force, Request for Comments 2210, Internet Engineering Task Force, Request for Comments 2210,
September, 1997. September, 1997.
[4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
Architecture for Differentiated Services", Internet Engineering Task Architecture for Differentiated Services", Internet Engineering Task
Force, Request for Comments 2475, December, 1998. Force, Request for Comments 2475, December, 1998.
[13] Y. Bernet,"Format of the RSVP DCLASS Object". Internet
Engineering Task Force, Request for Comments 2996, November 2000.
[18] R. Braden, "Resource ReSerVation Protocol (RSVP) -- Version 1
Message P rocessing Rules". Internet Engineering Task Force, RFC
2209, September 1997.
8. Non-Normative References
[5] G. Huston, "Next Steps for the IP QoS Architecture". Internet [5] G. Huston, "Next Steps for the IP QoS Architecture". Internet
Engineering Task Force, Request for Comments 2990, November 2000. Engineering Task Force, Request for Comments 2990, November 2000.
[6] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated [6] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated
Services Architecture for the Internet". Internet Engineering Task Services Architecture for the Internet". Internet Engineering Task
Force, Request for Comments 2638, July 1999. Force, Request for Comments 2638, July 1999.
[7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, "SBM [7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, "SBM
(Subnet Bandwidth Manager): A Protocol for RSVP-based Admission (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission
Control over IEEE 802-style networks". Internet Engineering Task Control over IEEE 802-style networks". Internet Engineering Task
skipping to change at page 15, line 33 skipping to change at page 16, line 41
[11] IST-BRAIN Project, "Deliverable D2.2: BRAIN architecture [11] IST-BRAIN Project, "Deliverable D2.2: BRAIN architecture
specifications and models, BRAIN functionality and protocol specifications and models, BRAIN functionality and protocol
specification". March 2001, (available at: http://www.ist- specification". March 2001, (available at: http://www.ist-
brain.org). brain.org).
[12] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming [12] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
Protocol (RTSP)". Internet Engineering Task Force, Request for Protocol (RTSP)". Internet Engineering Task Force, Request for
Comments 2326, April 1998. Comments 2326, April 1998.
[13] Y. Bernet,"Format of the RSVP DCLASS Object". Internet
Engineering Task Force, Request for Comments 2996, November 2000.
[14] Hamid Sued, "Capability Negotiation: The RSVP CAP Object". [14] Hamid Sued, "Capability Negotiation: The RSVP CAP Object".
Internet Draft (work in progress), May 2001 (expired) (draft-ietf- Internet Draft (work in progress), May 2001 (expired) (draft-ietf-
issll-rsvp-cap-03.txt). issll-rsvp-cap-03.txt).
[15] J. Rosenberg et al., "SIP: Session Initiation Protocol". RFC [15] J. Rosenberg et al., "SIP: Session Initiation Protocol". RFC
3261, June 2002 3261, June 2002
[16] J. Manner et al., "Mobility related terminology". Internet [16] J. Manner et al., "Mobility related terminology". Internet
Draft, November 2002 (draft-ietf-seamoby-mobility- Draft, (work in progress), November 2003.
terminology-01.txt).
[17] H. Tschofenig, "RSVP Security Properties". Internet Draft (work [17] H. Tschofenig, "RSVP Security Properties". Internet Draft (work
in progress), March 2003 (draft-ietf-nsis-rsvp-sec- in progress), March 2003.
properties-01.txt).
8. Authors' Addresses 9. Authors' Addresses
Questions about this document may be directed to: Questions about this document may be directed to:
Jukka Manner Jukka Manner
Department of Computer Science Department of Computer Science
University of Helsinki University of Helsinki
P.O. Box 26 (Teollisuuskatu 23) P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI FIN-00014 HELSINKI
Finland Finland
skipping to change at page 17, line 11 skipping to change at page 18, line 11
Voice: +358-9-456-6078 Voice: +358-9-456-6078
Fax: +358-9-456-7028 Fax: +358-9-456-7028
E-Mail: tapio.suihko@vtt.fi E-Mail: tapio.suihko@vtt.fi
Mika Liljeberg Mika Liljeberg
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Voice: +358-50-4836791 Voice: +358-50-4836791
Fax: +358-
E-Mail: Mika.Liljeberg@nokia.com E-Mail: Mika.Liljeberg@nokia.com
Acknowledgement Acknowledgment
This work has been partially performed in the framework of the IST This work has been partially performed in the framework of the IST
project IST-2000-28584 MIND, which is partly funded by the European project IST-2000-28584 MIND, which is partly funded by the European
Union. The authors would like to acknowledge the help of their Union. The authors would like to acknowledge the help of their
colleagues in preparing this document, in particular Eleanor Hepworth colleagues in preparing this document, in particular Eleanor Hepworth
and Alberto Lopez. and Alberto Lopez.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 43 change blocks. 
103 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/