IETF Mobile IP Working Group Eunhee Joo INTERNET-DRAFT Dr Robert Edwards Expires: May 2002 University of Sheffield Chern Nam Yap Seamoby Forum 2 November 2001 A Fast Reacting Mechanism for Terminal Mobility with Extended-RSVP Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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. Abstract Numerous studies have been done to improve RSVP performance. However, most of this research concentrates on fixed hosts. As mobility of hosts is having a significant impact on the Quality of Services, it is necessary to develop a new mechanism having the capabilities to support terminal mobility with RSVP. This document suggests a fast reacting mechanism for terminal mobility with Extended-RSVP. Fast reaction RSVP can be achieved using PathResv messages, which are novel. The process begins with a minimum reservation request but also retains old reservation. Higher possibility of acceptance from intermediate routers is gained by applying the minimum request first. For existing reservation, it is suggested that RSVP could use other information to identify a flow: for example, effective source address and effective destination address. The IP option field can also be used for this purpose. Eunhee Joo et al. Expires 2 May 2002 [Page i] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 Table of Contents Status of this Memo Abstract 1. Introduction 2. The Requirements to Support End-to-End QoS for Mobile Hosts 2.1 QoS Classification regarding Mobility 2.2 Mobility Consideration 2.3 QoS Requirements 3. Mobile-aware Resource Reservation Protocol 3.1 Interoperability Problems of Mobile IP and RSVP 3.1.1 Inefficiencies occurred by RSVP 3.1.2 Inefficiencies occurred by Mobile IP 3.1.3 Other protocols providing IP Mobility 3.1.4 SIP Mobility Support 3.2 A Flexible Framework 3.3 A Fast Reacting Mechanism for Terminal Mobility with Extended-RSVP 3.3.1 Additional Message type: PathResv 3.3.2 Basic Idea 3.3.3 Operation Procedures 3.3.3.1 In the Unicast Session 3.3.3.2 In the Multicast Session 3.3.4 Comparison with RSVP 3.4 Implementation Consideration 3.4.1 Implementation with using IP option field 3.4.1.1 IPv4 Option Field Layout 3.4.1.2 IPv6 Option Field Layout 3.4.2 Implementation with using RSVP Adaptation Layer 3.4.3 Router Alert Option 3.4.4 Requirements for All RSVP Hosts and Routers 3.4.5 PathResv Messages 4. IANA Consideration 5. Conclusions References Eunhee Joo et al. Expires 2 May 2002 [Page ii] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 1. Introduction RSVP (Resource reSerVation Protocol) was designed to play a role as a resource reservation protocol in the Integrated Services Network. RSVP has many excellent features such as soft-state maintaining and receiver-oriented nature and etc. However, RSVP cannot support mobility independent reservations as originally designed. RSVP assumes that the users are always attached to the same point in the network. Therefore if terminal mobility is introduced to RSVP, some additional issues MUST be considered. For example, when RSVP-capable node moves to different subnet while in service, RSVP gets routing reply from Mobile IP. Mobile IP is the most popular protocol to provide terminal mobility, however, it is not QoS-aware. One could think that the combination of two technologies brings us an appropriate method to satisfy both requirements. We address the potential problems of interoperation of RSVP and Mobile IP in a later section. Whilst we have tried to design a bigger frame of a Mobile-aware Resource Reservation Protocol, as a first step, a fast reacting mechanism for terminal mobility is proposed with Extended-RSVP. A RSVP session is established in a faster and a more efficient way with using newly defined PathResv message and with the strategy that request with minimum QoS first and the mechanism to be able to retain old reservation when a host is moving. The organization of the rest of this document is as follows. Firstly, the requirements to support end-to-end QoS for mobile hosts are addressed with the consideration of mobility in section 2. Section 3 describes a mobile-aware resource reservation protocol. This section includes a discussion of the interoperability problems of Mobile IP and RSVP, our future framework, a novel fast reacting mechanism for terminal mobility with Extended-RSVP. Implementation related issues are also in section 3. IANA consideration is handled in section 4, and finally we provide conclusions in section 5. 2. The Requirements to support End-to-End QoS for mobile hosts 2.1 QoS Classification regarding Mobility Wireless QoS Wired QoS <--------------------------------><--------------------------------> +-------------+------------+------------+------------+-------------+ | | | | | | | No mobility | Mobility | Mobility | Plug-in/ | No mobility | | in Wireless | Within | Between | Plug-out | in Wired | | | Subnet | Subnets | mobility | | | | | | | | +-------------+------------+------------+------------+-------------+ <--------------------------------------> QoS Mobility Figure [1]: QoS Classification regarding Mobility Eunhee Joo et al. Expires 2 May 2002 [Page 1] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 We here classified QoS related research area into five categories according to mobility. Note that the classification that we show does not include the movement of a user in the plain or train that is connected through wireless devices. And also there is no consideration of RF interface. Therefore we assume that handover is unambiguous. - No mobility in Wireless: Note that "wireless" does not mean "mobile". Desktop computers could be connected with wireless network devices. For example, a wireless network might be installed in an old building where it is difficult to install a wired network in that building. Or, people prefer a wireless network due to reasonable costs in some situations. In this case, QoS mechanism MAY have to deal with the nature of wireless network such as high packet loss rate, high packet delay and packet delay variation, but no need to worry about mobility portion. - Mobility Within Subnet: In the case where mobile hosts moves around either within a cell or between cells, but within the same subnet, there is no change of IP address by movement of the host. Users might move to different technology domain such as from 802.11 to wireless ATM. Further, there might not be enough bandwidth available in the new cell when handoff occurs. Wireless network QoS technologies SHOULD cover this kind of affect by movement of the host in addition to the nature of a wireless network. However, the movement of this category does not affect QoS in the wired network. This is often called Layer 2 QoS as a result. - Mobility Between Subnets: In the case where mobile hosts moves between subnets, there is a change of IP addresses during the lifetime of the connection. In order to support QoS with Mobility Between Subnets, we need to consider not just Layer 2 QoS but also Layer 3+ QoS mechanism. For example, in the case where RSVP is used to provide QoS, having different IP address could cause making resource reservation along the new end-to-end path whenever the host moves. Of course, there still needs QoS support from Layer 2. - Plug-in/Plug-out Mobility: For example, assume that a user is in the videoconferencing with a desktop computer. The user moves to another office during the conference for some reasons, but the user wants to continue to join the conference in another room. In the sight of this kind of scenario, the application in the computer in another room has to handle this connection request. QoS mechanisms might be required depending on the location where the user moves. If the user moves into a different subnet, we need to consider Layer 3+ QoS, but Wireless QoS is not involved in this category of movement. The old connection and resources reserved in the previous place where the mobile user was would be disconnected and released after timeout. However, when the user moves into a different subnet, they might need an additional mechanism in order to provide mobility transparent services to the hosts, or the plug-in host might be treated as a new host. - No Mobility in Wired: Conventional QoS in wired network where Eunhee Joo et al. Expires 2 May 2002 [Page 2] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 there is no movement, consequently there is no IP address changes SHOULD be applied. As we addressed above, QoS Mobility is overlapping area between wireless and wired QoS. In the light of this knowledge, to enable end-to-end QoS requires the cooperation of all network layers from top-to-bottom (from layer 2 to layer 3+), as well as every network element from end-to-end. 2.2 Mobility Consideration Providing QoS for a mobile user is a big challenge. The knowledge of a user's movement pattern would be a great help to accomplish this task. We briefly classify mobility pattern into 4 types to understand the relationship of movement and QoS. - Walking around: non-directional, not speedy - Driving a car: directional/non-directional, speedy - In a train/plane: directional, speedy, maybe use wired network between a mobile user and a train/plane, train/plane communicates through wireless network (It is assumed that one subnet covers a whole plane/train.) - Plug-out/Plug-in to another computer (in this case, terminal itself does not move) In the case where driving speed is faster than the speed of resource reservation, it is wasteful to perform resource reservation mechanism. While intermediate routers in path are trying to make reservations, if the mobile node already moved to another place, they MAY have to delete the resources reserved if necessary. Therefore when neighbouring cells reserve channels in advance, they SHOULD consider the speed of the vehicle. Just one cell ahead MAY not be enough. This problem becomes even more challenging as making reservation in advance scheme is performed in Layer 3. For example, in the case where we are using RSVP for Layer 3 resource reservation, it is required to compute how ahead we SHOULD reserve resources with the consideration of propagation and processing delay. 2.3 QoS Requirements In order to provide end-to-end QoS to a mobile host, it is necessary to identify concrete QoS requirements. 1) Lightweight signalling protocol Lightweight signalling protocol is needed for faster connection set-up especially in mobile environment. And it SHOULD be independent of network service model. 2) Flexible QoS specification/Adaptive application Specifications are often inexact as resource usage and flow characteristics are not generally completely defined in advance. It is suggested that due to the nature of mobile communications it is not practical to guarantee QoS levels. Instead, an adaptive approach is needed, where QoS management specifies a range of acceptable results. Eunhee Joo et al. Expires 2 May 2002 [Page 3] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 3) Efficient resource reservation in advance To support mobility independent QoS guarantees, advance reservation is needed. It SHOULD be done in an efficient way in terms of resource utilization, and in accurate ways in terms of mobility prediction. 3. Mobile-aware Resource Reservation Protocol 3.1 Interoperability Problems of Mobile IP and RSVP Currently we have RSVP to provide QoS and Mobile IP to support terminal mobility as actual protocols. However, just applying a combination of these protocols cannot achieve our final goal, end-to-end QoS for mobile users. We address the predictable inefficiencies when RSVP with Mobile IP is applied for mobile hosts in this section. 3.1.1 Inefficiencies occurred by RSVP 1) Long Session Establishment Delay RSVP needs at least one round-trip time between a sender and a receiver to establish a session even every router accepts a reservation request. If any of the routers rejects reservation request, longer delay would be taken. Such latency MAY not be very problematic when session is initiated (when the service begins), but could cause unacceptable service disruption in the middle of an active session. 2) RSVP Flow Identifier Since RSVP generally uses the 5-tuple (Source Address, Destination Address, IP Protocol Id, Source Port, Destination Port) to identify a specific flow, the change of any of elements in 5-tuple makes the flow become a different one. The old reservation cannot be retained when the source or the destination moves from one subnet to another due to a different source or destination address. Currently there is no mechanism that RSVP can distinguish between "really new session" and "actually no new session". 3) No Mechanism Supporting Mobility Conventional RSVP reserves only the resources along with the data path for the reason that the receiver's attached point on the network will not change during communication with senders. In order to acquire mobility independent service guarantees, resource reservation in advance is required. However, conventional RSVP is not able to handle resource reservation in advance. 3.1.2 Inefficiencies occurred by Mobile IP 1) Problems of Tunnelling Tunnelling causes outer header overheads. This could cause packet fragmentation and low network utilization as a result. This could affect QoS. In the case where Mobile IP and original plain RSVP is used, packets are always served in a best-effort way inside of the tunnel. This situation leads to large latency by non-optimal routes Eunhee Joo et al. Expires 2 May 2002 [Page 4] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 and non-guaranteed QoS in tunnels. And more important as regards to RSVP is that tunnelling makes the RSVP session become different due to outer packet header. 2) Triangular Routing Even when RSVP over tunnels is possible, there are still several problems to be solved. First, every packet sent to the mobile host has to go through a home agent in Mobile IP, non-optimal triangular routing problem has been resulted in. This situation increases not only end-to-end delay but it also generates wasted bandwidth in non-optimal paths that could be used for other connections. Second, resource reservation requests over the tunnel could possibly fail. The links or routers in the tunnel MAY not support due to the lack of available bandwidth or for other reasons. 3) When the mobile node moves from the foreign network to another foreign network There is no mechanism for the packets in flight from home agent to old foreign agent to be delivered to the mobile node. They are likely to be lost and needed to retransmit later. These lost packets could cause QoS degradation. 3.1.3 Other protocols providing IP mobility As support for mobility in the Internet has been topical, extended or modified versions of Mobile IP have been presented that claim enhanced performance. We describe these protocols briefly how these differ from Mobile IP and address potential problems of these protocols when used with RSVP. 1) Mobile-IPv4 Route Optimisation Even Route Optimisation provides an optimal route and foreign agent smooth handoff, there are still tunnelling overheads in each end nodes and the network link. Unless IP mobility protocol uses tunnelling, there would be inefficiencies when it is used with RSVP due to the way identifies a flow. And even it is possible to use an optimal route between a correspondent node and a mobile node, it takes time to set-up binding cache element in the correspondent nodes because all Binding Updates go home agent first. This kind of set-up delay could be very critical in terms of QoS. 2) Mobility Support in IPv6 Support for Route Optimisation is built in as a fundamental part of the IPv6. As mentioned above, it eliminates the problem of triangle routing present in the base Mobile IPv4 protocol. Additionally, most packets sent to a mobile node in Mobile IPv6 are sent using an IPv6 Routing Header rather than IP-IP encapsulation, whereas Mobile IPv4 MUST use IP-IP encapsulation for all packets. The use of Routing Header creates less overheads. However, the packets in flights are delivered by the encapsulation. In the context of RSVP, the use of Routing Header still cause The same problems as IP-IP encapsulation causes since the destination of IP packet is the care-of address of a mobile node, rather than the original destination address of a mobile node. Eunhee Joo et al. Expires 2 May 2002 [Page 5] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 3) Mobile-IP with Hierarchical Model While Mobile-IP has been trying to solve the macro mobility management problem, which is a more general mobility problem, in the Internet, micro mobility protocol is for a mobile node when it moves in a limited area such as a campus or a company. This method allows the home agent to remain unaware of the exact care-of address in use by the mobile node, as long as the mobile node stays within the same hierarchy. RSVP can keep the resources reserved for the session before moving between the correspondent node and the local foreign agent, and make a reservation for the new path between the local foreign agent and the mobile node. 3.2 A Flexible Framework We investigated potential problems of interoperability of Mobile IP and RSVP in the above section. Such problems arise because RSVP signalling for QoS was designed without consideration of mobility and Mobile IP does not support QoS with mobility. For example, the way Mobile IP uses tunnelling to support IP mobility does not work well with RSVP as we investigated above. Therefore a new approach is needed to support mobility independent QoS rather than applying two different protocols having different design purposes. We address a flexible framework for providing QoS in the mobile Internet. As a first step, we tried to figure out the mechanism which can achieve better performance with existing protocols without significant modifications of current protocols. The new suggested mechanism will be described in the next section. Applications SHOULD be able to choose an appropriate routing and QoS strategy among possible mechanisms. There are several protocols available that provide IP-level mobility as mentioned above, and there are various models deployed for providing QoS in different parts of the Internet such as IntServ, DiffServ or MPLS network. As a mobile user could move from one domain to another, it is not practical to assume for a mobile node to move always within the same domains. We can have better results of QoS with mobility in co-operation with these routing protocols since QoSs could be significantly affected by the protocol used. For example, we would have a better solution by using RSVP and Mobile IP hierarchical model instead of basic Mobile IP, if the mobile node moves within the network having Mobile IP hierarchical model and if QoS mechanism knows this situation. If an application is mission-critical, guaranteeing 100% QoS is much more important than considering efficient resource utilization. Then we could choose the protocol that provides resource reservation mechanism in advance. The problem is that "Is there a mechanism to know which IP mobility protocol is available in the subnet where MN (mobile node) is currently visiting?". The Quality of Service mechanism or Security mechanism developed to operate with a specific IP mobility protocol cannot work with others having different IP mobility protocols. In order to solve this problem, the senders and the receivers SHOULD consult a special-purpose server that provides this environmental Eunhee Joo et al. Expires 2 May 2002 [Page 6] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 information by queries. We call this server an "Information Broker (IB)". The router in the subnet could do this job since the Information Broker can work well within the same subnet. When the senders and the receivers construct Path or Resv messages, consult the Information Broker first to get the information needed. In addition, IB provides mobility specifications for mobile applications according to the link status and some direction or speed information given by mobile applications. Mobility independent QoS can be provided with the incorporation of a signalling protocol such as FR-RSVP (Fast Reacting Mechanism to Terminal Mobility with Extended-RSVP) and the Information Broker. This is because mobility prediction is executed concurrently with actual movement of the hosts, and lightweight signalling protocol which makes a reservation in a flexible and simple way to adapt well in varying mobile situations. 3.3 A Fast Reacting Mechanism to Terminal Mobility with Extended-RSVP This section describes a new approach to make resource reservation using RSVP for providing terminal mobility. We define a new message type, PathResv, in addition to two primary RSVP messages (Path, Resv) for our mechanism. 3.3.1 Additional Message type: PathResv A PathResv message is initiated by a sender host and travels downstream. Unlike a Path message it creates path state and a Resv message creates reservation state in each node, a PathResv message creates path state and also reservation state in each node. It contains SENDER_TEMPLATE object defining the format of the data packets and a SENDER_TSPEC object, specifying the traffic characteristics of the flow. And it also contains FLOW_SPEC object to create reservation state in the intermediate nodes. Note that PathResv message does not carry FILTER_SPEC object since SENDER_TEMPLATE have exactly the same expressive power and format as FILTER_SPEC. PathResv Messages are used temporarily. Once the sender receives a confirm message, it stops refreshing PathResv. And every operation will continue the same as the original RSVP operation. 3.3.2 Basic Idea There are three basic ideas in this suggested mechanism. The first one is that "Let's use known useful information such as receiver's QoS requirement when establish a session after moving". We let the sender initiate PathResv messages with known parameter information from the previous session. The second one is "Begin with minimum reservation request first" with minimum and maximum QoS requirement and the unit for increasing requirement each refreshing when the previous request is successful. The third one is "Keep the old reservation in the routers for the same flow having different flow identification". Eunhee Joo et al. Expires 2 May 2002 [Page 7] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 1) The use of a combined message: PathResv Once a RSVP connection has been established between a sender and a receiver, it is reasonable to presume that both end hosts know about traffic characteristics or requirements given by exchanging Path and Resv messages. It is unnecessary to establish a RSVP session in the same way as normal RSVP set-up procedures, i.e. it is possible to create path state and reservation state in the routers with one message (PathResv). The crucial point is which end host SHOULD initiate PathResv messages. We decide to let a sender do this job. These are the reasons we chose a sender : - The sender already knows the receiver's requirements from the previous RESV messages. - It is the sender that is reported mobile node's new location. If a receiver initiates a PathResv message after moving, there is no guarantee that a sender has binding information of receiver's new address. When the sender receives binding information, there is an optimal route they can use. Therefore it is the fastest way to let the sender initiate a PathResv message just after it knows the receiver's new address. When the receiver host get the PathResv message, it sends a confirm message back to the sender. Then the sender stops refreshing PathResv messages. - The route chosen from a receiver to a sender may not be the same as the route from a sender to a receiver. The main reason for RSVP having Path messages to build path states in the routers and letting Resv messages make reservations is to provide receiver heterogeneity. This suggested mechanism keeps RSVP's this feature to support various receiver's requirements. Additionally it provides an efficient way to setup a new RSVP session after moving. It would be much faster to omit (skip) one processing phase and combine two processing steps into one. 2) We begin with Minimum Reservation Request When the sender initiates a PathResv message, the message is sent with a minimum reservation request. Such minimum requests result in a higher probability of acceptance from intermediate routers. Subsequently, if acceptance is achieved, the sender gradually increases requests of resources. The RSVP keeps an existing reservation in place when making an admission control decision for a replacement reservation. If the new reservation fails, a ResvErr message is sent back but the original reservation is left in place. We use this mechanism in mobile Internet environment in order to have faster reaction from RSVP. The rejection from the routers causes delay to establish the session. Therefore, the less the reservation requests are rejected, the more the data transmitted can enjoy pipe-liked link, and the better service they can provide. 3) Retain the Old Reservation Even though the path between the correspondent node and the mobile node is different as the mobile node moves, most intermediate routers between CN and MN are still common . Being able to keep Eunhee Joo et al. Expires 2 May 2002 [Page 8] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 previous reservation is important not just because of time but also resource availability. For example, before the resources that were reserved for a previous flow are released, the reservation for another flows are requested, and if there is not sufficient bandwidth available, the request after moving would be rejected. As a result, this would cause QoS degradation. In common routers between an old path and a new path, there is no risk to be rejected due to lack of available bandwidth. There has been some research to combine RSVP and Mobile IP regional registration to better support for a mobile node in region [5]. This research has limitation to have to use a specific IP mobility protocol in a restricted environment. However, our mechanism can better support in more general mobility environments. We describe three possible choices for retaining resources: 1. Use IP option field for carrying effective addresses. Since options are not copied from the inner IP header in most encapsulation cases [7], add IP option into an IP outer header. The contents of this option field are effective source and destination address. More detail mechanism is described in section 3.4. RSVP control packets are encapsulated with Router Alert Option and Effective Address Option. Data packets are encapsulated with just Effective Address Option. This method has processing and bandwidth overhead due to additional Effective Address IP option. 2. Manage flow state information in routers. Routers manage some binding information between the IP addresses before moving and after moving for flows additionally. When a router receives RSVP control messages, the router refers its binding information to decide whether to create new state for it or just refresh it. The encapsulation point adds Router Alert Option in the outer IP header. By doing this, all intermediate RSVP-capable routers in the tunnel would take a look encapsulated RSVP messages more closely. Even the packets including RSVP messages are arrived with tunnel endpoint IP addresses, intermediate routers process them by the binding information. This method requires routers to manage binding information, therefore causes processing overhead in the routers. 3. Use IP addresses of inner IP headers as a flow identifier. To avoid bandwidth wasted by additional Effective Address option, it would be another solution to let the routers use IP address field of inner IP header as a flow identifier. When a router receives a packet, it knows whether this packet is encapsulated or not by protocol id of outer IP header. If the packet is encapsulated, the router checks inner the IP header to distinguish it. With this method, no more additional bandwidth is required even the packets are still needed to be encapsulated with Router Alert Option in outer header. However, this solution requires modifications at Eunhee Joo et al. Expires 2 May 2002 [Page 9] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 all routers and imposes further processing overheads on the packet distinguishing process. 3.3.3 Operation Procedures It is assumed that we use Mobile IPv4 route optimization/Mobile-IPv6 as a IP mobility protocol to avoid triangular routing. 3.3.3.1 In the Unicast Session 1) Receiver is moving subnet1 +------+ Path +-------+ Path +--------+ Path +--------+ | |----->| |----->| |----->| | | CN | |Router1| |Router2 | | MN | | |<-----| |<-----| |<-----| | | | Resv | | Resv +--------+ Resv +--------+ | | | | | | |=====>+-------+\\ | moved +------+ PathResv \\ V \\ +--------+ PathResv +--------+ pathResv\\ | |=========>| | \\|Router3 | | MN | \| | | | +--------+ +--------+ subnet2 CN: Correspondent Node MN: Mobile Node Figure [2]: Sample Operation Procedures of Suggested Mechanism when Receiver is moving The following sequence illustrates the process by which a sender and a receiver establish RSVP session when the receiver is moving from one subnet to another. - A sender host sends Path messges to a receiver along through Router1, Router2(Same as RSVP). - A receiver sends Resv messages to the sender (Same as RSVP). - A receiver in subnet1 moves to subnet2. - The receiver informs the sender of its new location by IP mobility protocol. (e.g. Mobile IP) - The sender creates PathResv message using the information from previous Resv messages exchanged with minimum QoS request. - The sender transmits PathResv messages to the receiver's new location along through Router1, Router3. - When Router1, which is common router between an old path and a new path, receives a PathResv message, Router1 checks its effective field and will find out there is a matching state. So it just refreshes the path and reservation state and forwards it. Eunhee Joo et al. Expires 2 May 2002 [Page 10] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 - When Router3, which is a new router, receives a PathResv message, it creates path and reservation state and forwards it. - When the PathResv arrives in the receiver's side, the receiver sends a confirm message to the sender. - Once the sender transmits PathResv, the sender refreshes it until receiving ResvConf. After the sender receives ResvConf, the sender stops refreshing PathResv. 2) Sender is moving When a sender is moving, basically same operation procedures are applied. 3.3.3.2 In the Multicast Session In the multicast session, when a receiver is mobile we can consider terminal mobility as joining a new member and leaving an old member. However when the mobile user moved to a different network which has no member, it SHOULD make resource reservation as it joined the multicast group first. It causes some delay to complete the reservation using RSVP. Furthermore, in the case where the sender moves, the flow id becomes different due to different sender's IP address. New resource reservation SHOULD be performed along the new path between the new sender's location and receivers. If we cannot retain the resource for previous flow id, it MAY not be possible to reserve resources in the same intermediate routers due to lack of available resource. 3.3.4 Comparison with RSVP In a case where there is no PathErr and ResvErr, the delay to establish RSVP session is essentially 1 round trip time between a sender and a receiver. This is because since RSVP path messages are sent to the receiver and then the receiver sends RSVP resv messages to the sender. With FR-RSVP, the set-up delay is 1 PathResv delay since the PathResv messages make Path and reservation state. Note that the processing time of PathResv messages is not exactly half of the 1 Round Trip time since a PathResv message does more jobs than each Path and Resv message does. However PathResv could save at least propagation delay of one transmission direction. In the case where one of the intermediate routers rejects the reservation request, the time when the receiver is notified the error is 1 Path Delay and Return time from the router reject to the receiver with RSVP. However, with FR-RSVP, return time is needed for the receiver to know the error. In order to send data with reservation guaranteed, the sender needs to wait for 1 Round Trip time with RSVP no matter where there is any router reject the request. However with FR-RSVP, the sender can send data with guarantee just after sending PathResv messages if there is enough resources. If any router rejects the reservation request, the data sent are served by Best Effort mode. Eunhee Joo et al. Expires 2 May 2002 [Page 11] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 3.4 Implementation Consideration In this section, we describe first two methods addressed in 3.3.2 which use the IP option field and RSVP adaptation layer in detail. We also define the PathResv message format. 3.4.1 Implementation with using IP option field (Effective Address Option) Our mechanism can be implemented both in IPv4 and IPv6. In this section, the layout of option field is shown in both cases. 3.4.1.1 IPv4 Option Field Layout There MAY be a number of options at the end of the header in IPv4. The presence or absence of options MAY be determined by examining the header length field. When there are no options, the header is 20 bytes long. If there are no other options except Effective Address Option, the header SHOULD be 32 bytes. 0 8 16 17 31 +------------+-------------+---+-----------------------------+ | Type | Length | M | Reserved | +------------+-------------+---+-----------------------------+ | Effective Source Address | +------------------------------------------------------------+ | Effective Destination Address | +------------------------------------------------------------+ Type 8 bits copied flag (1 bit) : 1 (all fragments must carry the option) option class (2 bits) : 0 (control) option number (5 bits) : decimal number Length 8 bits 12 (The length of this entire extension in bytes) M bit 0 : Both source and destination addresses are same as the effective addresses (No mobility happens, When M bit is 0, following Effective Source and Destination Address fields could be omitted) 1 : Either source or destination address is different from the effective address (Mobility happened) Reserved 15 bits Effective Source Address 32 bits Effective Destination Address 32 bits Eunhee Joo et al. Expires 2 May 2002 [Page 12] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 3.4.1.2 IPv6 Option Field Layout IPv6 Extension headers except for Hop-by-Hop options header are not examined until the packet reaches the node specified by the Destination Address field. In order for the intermediate routers to look closer the RSVP control messages, Hop-by-hop option header is used in IPv6 (Router Alert Option is defined within the IPv6 Hop-by-hop) header. Further, in order for the data packets destined to the mobile node having new care-of address to use the resources reserved before moving, each data packet SHOULD carry original IP addresses in Hop-by-hop options header. 0 16 24 31 +---------------+--------------+ | Option Type | Option Data | | | Length | +-----------------------------+---------------+--------------+ | Effective Source Address | +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | +------------------------------------------------------------+ | Effective Destination Address | +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | +------------------------------------------------------------+ | | +------------------------------------------------------------+ Option Type 8-bit identifier that specifies the option type Option Data Length 8-bit integer that indicates the length of the option data field Effective Source Address 128 bits Effective Destination Address 128 bits Eunhee Joo et al. Expires 2 May 2002 [Page 13] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 3.4.2 Implementation with using RSVP Adaptation Layer Just like Mobile IP manages home address and care-of address and Home Agent manages binding information between them, RSVP Adaptation Layer manages RSVP Binding Table. A PathResv message carries binding information. When a router receives a RSVP PathResv message, it creates or updates binding information in the Biding Table. If there is no matching entry in the table, a new entry will be created, and if there is a matching entry (i.e. a mobile node moves once more) but having different new flow identification, the existing entry will be replaced with the one carried by an arriving PathResv message. A binding entry will be deleted accordingly when a path or reservation state is deleted. This layer replaces filter spec of the original flow with new filter spec by the addresses found in the Binding Table. Therefore, the modified filter spec is passed to the packet classifier in the IntServ model. +----------------------------+------------------------------+ | Original Flow Identifier | Flow Identifier after moving | +----------------------------+------------------------------+ | SA+DA+SP+DP+PI | SA+DA(new)+SP+DP+PI | +----------------------------+------------------------------+ | . | . | | . | . | | . | . | +----------------------------+------------------------------+ SA: Source Address DA: Destination Address SP: Source Port Number DP: Destination Port Number PI: Protocol Number 3.4.3 Router Alert Option The router alert option SHOULD be set to indicate that the routers SHOULD investigate this message [6]. In IPv6, the Router Alert Option is used in Hop-by-hop option header. 3.4.4 Requirements for All RSVP Hosts and Routers - Every RSVP node MUST be able to process a Effective Address Option received in any packet upon using IP option field, otherwise every RSVP node MUST be implemented RSVP Adaptation Layer - Every RSVP node MUST be able to process a PathResv message 3.4.5 PathResv Messages In order to make PathResv message recognized, Message Type Field of RSVP common header SHOULD be extended. Currently there are seven message types. Eunhee Joo et al. Expires 2 May 2002 [Page 14] INTERNET-DRAFT Fast Reacting RSVP Protocol 2 November 2001 1 = Path 2 = Resv 3 = PathErr 4 = ResvErr 5 = PathTear 6 = ResvTear 7 = ResvConf In addition to these seven[R1] types, we need to define PathResv and PathResvErr types as follows. 8 = PathResv 9 = PathResvErr The format of a PathResv message is as follows: ::= [ ] [ ] [ ] [ ... ]