Internet Engineering Task Force J. Manner Internet-Draft T. Suihko Expires: November, 2002 M. Kojo M. Liljeberg K. Raatikainen May 14, 2002 Localized RSVP 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 November, 2002. 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. For stationary nodes this may be achieved but not so easily for mobile nodes. Many multimedia applications become less useful if the continuity of QoS is disturbed due to end-to-end signalling or slow re-reservations of resources after each handover. Additionally, if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources, especially wireless link resources. This draft proposes small modifications to RSVP, so that initial resource Manner et al Expires November 2002 [Page 1] Internet-Draft Localized RSVP May 2002 reservations and re-reservations due to host mobility can be done locally in an access network. Table of Contents 1 Introduction ................................................. 2 1.1 Related work ............................................... 3 2 Local QoS Support ............................................ 4 2.1 Upstream transfers ......................................... 4 2.2 Downstream transfers ....................................... 5 2.3 Additional functionality ................................... 5 3 Fast local repair ............................................ 7 4 Issues with the localized signalling ......................... 8 5 Signalling diagrams .......................................... 10 6 Security Consideration ....................................... 10 7 Summary and Future Work ...................................... 11 8 References ................................................... 12 9 Author's Addresses ........................................... 13 1. Introduction Future mobile 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 without knowledge of any higher layer data flows. At the same time different multimedia applications are becoming increasingly popular. These applications require better than best-effort service from the connecting network. They require strict Quality of Service (QoS) with guaranteed minimum bandwidth and maximum delay. Other applications, such as electronic commerce, network control and managment, and telnet-type applications, would also benefit from a differentiated treatment. The Internet Engineering Task Force (IETF) has proposed 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-signaled 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 nodes. 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 data stream to a mobile node behind a wireless link. If the correspondent node does not support RSVP it cannot signal its traffic characteristics to the network and request Manner et al Expires November 2002 [Page 2] Internet-Draft Localized RSVP May 2002 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 probably the wireless link. For illustration purposes, we will only consider a scenario with a mobile access network that is aware of the proposed signaling mechanism and has mobile nodes as its clients. In the absence of end-to-end QoS support, a mobile node could still want to reserve resources from the access network for both outgoing and incoming traffic. We propose a signaling mechanism based on a slightly modified RSVP. Access network specific reservations would be distinguished from the end-to-end reservations. The mobile node 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. However, the scheme is not tied to only mobile networks but can be used in any network that needs flexible local resource allocations. This would be very beneficial, even if the QoS support is only available in the access network. Furthermore, the same solution saves us from end-to-end signaling even if all intermediate nodes on the transmission path would support standard RSVP. This would allow, for example, the mobile node to reserve wireless resources separately from end-to-end resources. 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 the mobile node 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 prefered 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. A second 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 labeled. Still, this would require a protocol that the mobile node could use to dynamically adjust the mapping information stored at the access network edge for the incoming traffic. Manner et al Expires November 2002 [Page 3] Internet-Draft Localized RSVP May 2002 RSVP can provide the signalling mechanism for QoS requirements to the access network. For upstream reservations, the mobile node 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 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). In addition, we need a way to differentiate reservations that are internal to the access network. We suggest using one bit of the eight flag bits in the RSVP Session object for this purpose. We use the bit 0x8 and call the flag a Local Indication (LI). We also add a new message type called "Path Request" message with an initial message type number 8 and a message called "Path Request Tear" with an initial message type number 9. The first sketch of this solution appeared in [10] and [11], although some implementation ideas have changed since. When a mobile node wants to reserve resources in the local network, it uses the LI flag in RSVP messages to indicate a local reservation. The structure of the RSVP messages follow 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. 2.1. Upstream transfers Setting upstream reservations is straightforward and follows the standard RSVP functionality. The mobile node sends the usual Path message, but sets the LI flag. The Session Object defines the destination of the flow that will eventually be transmitted from the mobile, and the Sender Template provides information about the mobile itself. Manner et al Expires November 2002 [Page 4] Internet-Draft Localized RSVP May 2002 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. If a Resv message arrives at the mobile, the resources for the session defined in the Path message have been allocated. 2.2. Downstream transfers Before setting a downstream resource reservation, the mobile needs to be aware of the data senders. For multimedia communications, a session is usually initiated up with application layer protocols like SIP or RTSP [12]. From that correspondence, the mobile knows the necessary information about the sender. Another, more coarse reservation could be set, for example, for browsing different audio servers; the mobile node would indicate in the RSVP messages that the sender will use UDP. It is thus possible to make resource reservations for any sender that wants to communicate with the mobile. However, in order to allow for more accurate QoS support, more information should be given. In order to set up the downstream reservation we need a way to signal the LRSVP proxy to initiate the RSVP reservation setup on behalf of the sender(s), that is, to send a Path message. To achieve this, the mobile node sends the Path Request message with the LI flag set. 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 mobile in this case, and the Sender Template must define expected sender(s). The Traffic specification (TSpec) can either be based on the mobile users wishes or a best estimate of the incoming traffic characteristics, or on application level session signalling prior to the transfer. 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 field in a Path message. The proxy can now change the message type from Path Request to Path, keep the LI flag, and send this Path message towards the mobile node. Since the Session Object and Sender Template were originally set "backwards", the proxy can copy these entries directly as-is to the Path message. When the mobile node 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 mobile. 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. Manner et al Expires November 2002 [Page 5] Internet-Draft Localized RSVP May 2002 Downstream reservations are torn down with the Path Request Tear message. All messages used for local reservations must have the LI flag set in order to keep the signaling within the access network. Intermediate RSVP routers between the mobile node and the LRSVP proxy must not process the Path Request message and they must forward it as an ordinary IP packet. 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 mobile node 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 mobile node, 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 two mobile nodes 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 signaling, the RSVP CAP-object [14] could be used to carry the bit that identifies the signaling as local. 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 a single bit of information. In addition, the processing of the messages is more time consuming due to the extra header. In any case, a new Path Request message is 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 the RSVP packet 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 November 2002 [Page 6] Internet-Draft Localized RSVP May 2002 3. Fast local repair 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 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. It is also said in the RSVP specification 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, not all local mobility protocols, or even Mobile IP, affect routing directly in routers, and thus mobility may not be noticed at RSVP routers. When the mobile has moved, it can send a Path message for each upstream resource reservation and initiate the local repair mechanism. But for the downstream, the mobile will need to wait until it receives a Path message, refreshing the reservation states 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 could potentially be used in mobile networks to initiate a faster local repair on behalf of a mobile node that changed access points during an ongoing RSVP session. When the mobile node changes its access point in the network, it should send the Path Request message immediately after the handover. The Path Request message is forwarded through the intermediate RSVP routers until it arrives at the cross-over RSVP router that has the reservation for the mobile node stored on a different interface. The message would then instruct the cross-over router to initiate a local repair by sending the needed Path message. The cross-over router may be located between the LRSVP proxy and the mobile node and will therefore respond to the message. Otherwise, the Path Request message will arrive at an LRSVP proxy, which will initiate a reservation refresh for the mobile. Thus, the closest node to the mobile, the LRSVP proxy or cross-over router, will respond to the routing change. In some access networks, the access network gateways could also act as LRSVP proxies. If the movement of the mobile node results in packets to flow through a new gateway (and new proxy), the Path Request message would re-reserve the local resources for the new path. However, the faster local repair scheme has the requirement that the RSVP daemon running on the mobile needs to get an indication when a handover has occurred. The change of access points is best noticed by Manner et al Expires November 2002 [Page 7] Internet-Draft Localized RSVP May 2002 the link layer, through the actual wireless device. When the link layer address of the access point changes, this event could trigger a signal to the higher layers, including the RSVP-daemon that a handover has happened. The way the higher layers then take this signaling into account is not a concern of the link layer. Initiation of the local repair must be done every time the access point changes, regardless of whether the access router changes or remains the same after the handover. If the access router remains the same, the access router itself is the crossover router. The Path Request message sent will be intercepted by this access router, which will reply with the Path message and therefore initialize the resource sharing through its new interface. (Note, that we make the assumption, that each access point has its own dedicated network interface on the access router.) If the access router changes, the local repair mechanism will eventually arrive at either the crossover router or at the access network gateway. If the whole access network changes as a result of a handover, the situation becomes more complex, and may require a full authentication and admission control procedure to be initiated. From the QoS point of view, the situation does not differ from a situation, where both the access router and the network gateway changed. 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. Issues with the localized signalling An important question remains with the localized signalling mechanism: what destination address should the mobile use, when initiating a downstream reservation setup? This has implications on the network path, on which the reservation will be set up. The Session object and the Sender Template define the parties involved in the reservation. Thus, the destination IP address is not needed in the reservation set up but has an effect on the routing of the packets. The issue concerns the situations, where there are several ingress routes to the access network. In such a scenario, LRSVP proxies might be situated further away from the access routers, closer to the edge of the access network, for example. There are two fundamentally different options for the IP destination address. The first option is that the mobile node can use the IP address of the host that it intends to communicate with. This has the benefit that a Path message will be routed according to the usual IP routing mechanisms. Thus, the Path message will be routed to the proxy that will eventually also receive the upstream data flow. However, if the mobile wants to set up a reservation for the downlink, on behalf of the correspondent node, there is a potential Manner et al Expires November 2002 [Page 8] Internet-Draft Localized RSVP May 2002 problem. If the access network has several ingress routes, and hence, most probably, several LRSVP proxies, the data flow may eventually arrive through a path different from the path that had the reservation in place. This can happen due to the basic property of asymmetricy in IP routing. The mobile node might set up a reservation on behalf of the correspondent node through a path using LRSVP proxy A but the data will actually arrive through a path using proxy B. A same problem arises if the mobile node wants to reserve resources without an exact sender IP address. The mobile might want resources for audio streams initiated while browsing the Internet without specifying all possible web servers that it may be using. A solution to this problem is, that the mobile directs the localized RSVP messages to all LRSVP proxies. This can be achieved using a multicast address of all the LRSVP proxies. As a result, each LRSVP in the access network would receive the RSVP packets, a Path or a Path Request, and respond to the mobile. Since resource reservations are set up on several paths but only some are actually needed in the end, we need a way to remove unnecessary reservations. This can be accomplished through the RSVP soft state mechanism: Unused reservations are revoked using a timeout mechanism, no refresh messages are sent for those paths. This is possible if the reservation refresh is coupled with actual data transfered through that reservation. Reservations are only kept alive if data is actually sent through a particular path. The multicast functionality can be further modified, so that a proxy will not even send the Path message if it does not receive packets from the specified sender within a timeout. Thus, no downstream reservations are initialized for paths that are not carrying packets belonging to the request. It seems that there is no best solution to the destination problem. Both solutions have their benefits and drawbacks. The first solution has problems with asymmetric routing and undefined IP destinations (the data senders). The second solution can create a lot more signalling messages and a lot of unnecessary resource reservations. The second solution also requires that the access network supports multicast. Furthermore, one of the original design criteria for the localized signalling was to make the design to transparently co- operate with standard end-to-end RSVP. Now it seems that the localized signalling needs a separate mechanism although the changes required in standard RSVP routers and mobile nodes RSVP daemons are small. Regardless of the exact solution, an important functionality is that the implementation should be transparent to the mobile node. The mobile node would always operate in the same way when it wants to setup QoS for downstream flows. The access router can help in supporting the localized RSVP scheme. Thus, when the mobile node wants to reserve resources for the Manner et al Expires November 2002 [Page 9] Internet-Draft Localized RSVP May 2002 downstream, it will should as IP destination address either an LRSVP proxy address provided as part of host autoconfiguration or the default router address. The LRSVP proxy address can be a unicast or multicast address, and it is up to the access network to take care of removing unneeded reservations. If the mobile node does not have the LRSVP proxy address configured, it will use the default router address, which all IP hosts know. The access router can then perform routing lookup and address translation and forward the Path Request message to the correct proxy. Alternatively, it can just forward the message as any IP packet. Thus, the mobile node will always have an address to use as the recipient of the Path Request and the access network nodes will take care of proxy discovery. Similarly, in an unlikely but still possible case that a mobile would want to set QoS parameters for several upstream paths, it can use the configured LRSVP proxy address or the default router address in the Path message. The access router can then forward the Path to the correct number of LRSVP proxies, and these can then respond with the Resv message. However, how the unneeded reservations are rewoked is unknown. Thus, it seems, that an access network should consider allowing multiple local upstream reservations. Furthermore, if the host is mobile and is using Mobile IP to acquire the address, it must use the Care-of-Address as the address in the Session Object address field. If the CoA changes after a handover, the mobile node must create a new Path message, and hence Path state, to set up new upstream reservations. A new Path state is needed, if the filters in the old Path state used the mobile node's CoA as partial information. For local downstream reservations, the mobile node can send a new Path Request with the new CoA in the Session Object, and simultaneously send a Path Request Tear for the old reservation. The LRSVP proxy will thus create a new downstream reservation and must remove the old reservation state. For end-to-end reservations, an IPv6 correspondent node should use the MIPv6 Binding Update message as an indication to re-establish the Path state using a new destination address in the Session Object. 5. Signalling diagrams 6. Security Consideration The localized signalling does not raise new securiy issues. The security considerations with standard RSVP apply. Manner et al Expires November 2002 [Page 10] Internet-Draft Localized RSVP May 2002 7. Summary and Future Work In summary, the Localized RSVP requires the following changes in the standard RSVP protocol: a) A new message type and number, named Path Request, number 8. b) A new message type and number, named Path Request Tear, number 9. c) One bit from the Session Object for the use as the Local Indication (LI), bit 0x8 d) An RSVP router must keep the LI bit set in all messages belonging to that session, if it encounters packets with the bit set. e) An RSVP router that is not also a proxy, must forward an RSVP packet with a message type "Path Request" without storing state. f) An AN 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 affect point e), 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. g) Refresh of the soft state for downstream reservations should be tied to actual data flow. Alternatively, the soft state can be kept up by periodic Path Request messages sent by the mobile node. To summarize, these changes are small and would make RSVP more appealing as a signalling protocol for IP access networks. We still have to study the interactions between local and end-to-end reservations, for example, whether an existing local reservation could be upgraded into a full end-to-end reservation. Similary, we need to study whether an initial end-to-end reservation attempt could be changed flexibly into a local reservation in case the end-to-end reervation was not succesfull, for example, within the core network connecting the two access networks. Furthermore, we need to study, whether there could be need for nested proxies, so more than one proxy per path. In addition, a possibility to manage the communication between the end host and the LRSVP proxies would be to use UDP and a wellknown port number. Thus, "local" messages would be sent encapsulated in UDP packets. Manner et al Expires November 2002 [Page 11] Internet-Draft Localized RSVP May 2002 8. 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), July 2001 (draft-ietf-rsvp-proxy-02.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 Engineering Task Force, Request for Comments 2996, November 2000. Manner et al Expires November 2002 [Page 12] Internet-Draft Localized RSVP May 2002 [14] Hamid Sued, "Capability Negotiation: The RSVP CAP Object". Internet Draft (work in progress), February 2001 (draft-ietf-issll- rsvp-cap-02.txt). 9. 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 P.O. Box 1203 FIN-02044 VTT Finland Voice: +358-9-456-6078 Fax: +358-9-456-7028 E-Mail: tapio.suihko@vtt.fi Manner et al Expires November 2002 [Page 13] Internet-Draft Localized RSVP May 2002 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 November 2002 [Page 14]