Network Working Group Sun. Yi Internet-Draft ICT Intended status: Standards Track Feng. Bin Expires: August 12, 2007 BUPT Zhang. Yucheng UEST Zheng. Rusong ICT Dong. Wenxia SWJTU Shi. Jinglin ICT Dutkiewicz. Eryk University of Wollongong February 8, 2007 Extensions to Resource Reservation Protocol (RSVP) for Mobile IPv6 draft-sunyi-fast-rsvp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 on August 12, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Yi, et al. Expires August 12, 2007 [Page 1] Internet-Draft Fast RSVP February 2007 Abstract RSVP [1] is designed as a signaling protocol that provides end-to-end QoS guarantee for real-time services in the fixed hardwired network. However, when used in the mobile environment, the protocol doesn't work well due to the mobility of the endpoints. Immediately after a handover occurs, because of the lack of resource reservation in the handoff target subnet, QoS of the session degrades notably. Another problem is that when route optimization is implemented, the protocol will be invalidated due to certain features of the route optimization mechanism. This document proposes extensions to RSVP. The extensions enable RSVP to operate in the mobile IPv6 network while providing advanced resource reservation before handover and resource reservation on the optimized route after handover. With these features, QoS of the sessions can be guaranteed and the utilization of network resources can be enhanced resulting in the improvement of overall network performance. Yi, et al. Expires August 12, 2007 [Page 2] Internet-Draft Fast RSVP February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of RSVP Extensions . . . . . . . . . . . . . . . . . 9 3.1. Addressing the QoS Guarantee during Handover . . . . . . . 9 3.2. Cooperation between the RSVP Module and the Mobile IP Module . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. RSVP Extensions Operation . . . . . . . . . . . . . . . . 11 4. Details of RSVP Extensions . . . . . . . . . . . . . . . . . . 23 4.1. MN is the Receiver of the Session . . . . . . . . . . . . 23 4.2. MN is the Sender of the Session . . . . . . . . . . . . . 28 4.3. MN is both the Sender and the Receiver of the Session . . 33 5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1. RSVP Extensions Capability Exchange . . . . . . . . . . . 42 5.2. Distinguishing Handover Sessions and New Sessions . . . . 42 5.3. Bidirectional Reservation . . . . . . . . . . . . . . . . 42 5.4. Utilization of Advanced Reservation before Handover . . . 43 6. New Messages and Objects . . . . . . . . . . . . . . . . . . . 44 6.1. Modified Common Header . . . . . . . . . . . . . . . . . . 44 6.2. New Objects . . . . . . . . . . . . . . . . . . . . . . . 45 6.2.1. New MSESSION Object . . . . . . . . . . . . . . . . . 45 6.2.2. New Router_Notify Object . . . . . . . . . . . . . . . 46 6.2.3. New Tunnel_Info Object . . . . . . . . . . . . . . . . 47 6.3. New Messages . . . . . . . . . . . . . . . . . . . . . . . 48 6.3.1. HandoverForecast Message . . . . . . . . . . . . . . . 48 6.3.2. HandoverForecastResponse Message . . . . . . . . . . . 49 6.3.3. HandoverForecastConfirm Message . . . . . . . . . . . 49 6.3.4. TunnelStateChange Message . . . . . . . . . . . . . . 49 6.3.5. HandoverForecastError Message . . . . . . . . . . . . 50 6.3.6. HandoverForecastTear . . . . . . . . . . . . . . . . . 50 6.3.7. TunnelPath Message . . . . . . . . . . . . . . . . . . 51 6.3.8. TunnelResv Message . . . . . . . . . . . . . . . . . . 51 6.3.9. TunnelPathTear Message . . . . . . . . . . . . . . . . 51 6.3.10. TunnelResvTear Message . . . . . . . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 8.1. RSVP Common Header Flags . . . . . . . . . . . . . . . . . 54 8.2. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . . 54 8.3. RSVP Messages . . . . . . . . . . . . . . . . . . . . . . 54 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . . . 59 Yi, et al. Expires August 12, 2007 [Page 3] Internet-Draft Fast RSVP February 2007 1. Introduction RSVP [1]is designed as a signaling protocol that provides end-to-end QoS guarantee for real-time services in the fixed hardwired network. However, when used in the mobile environment, the protocol doesn't work well due to the mobility of the endpoints. Immediately after a handover occurs, because of the lack of resource reservation in the handoff target subnet, QoS of the sessions degrade notably. Another problem is that when route optimization is implemented (which is a compelling strategy in Mobile IPv6 network [2]), the protocol will be invalidated due to certain features of the route optimization mechanism. This document proposed extensions to RSVP. The extensions enable RSVP to operate in the mobile IPv6 network while providing advanced resource reservation before handover and resource reservation on the optimized route after handover. With these features QoS of the sessions can be guaranteed and the utilization of network resources can be enhanced resulting in the improvement of overall network performance. The extensions proposed in this document address the following problems: (1) How to make the mobile node realize fast handover with QoS guarantees and (2) How to establish resource reservation on the optimized route after Mobile IPv6 route optimization. The extensions proposed in this document divide a handover process with QoS guarantees into 2 stages: 1. Setup of the resource reservation neighbor tunnel before handover. 2. Resource reservation on the optimized route after handover. In the first stage, based on the handover prediction result that the mobile IP module makes, the extensions proposed in this document establish a QoS guaranteed tunnel in advance before the handover occurs. In the second stage, in co-operation with the route optimization mechanism used in Mobile IPv6 protocol, the extensions proposed in this document establish resource reservation on the optimized route after handover. The reference handover scenario is illustrated in Figure 1. To support the basic functions, some new messages are defined and some new objects are added to the messages in traditional RSVP. In addition, some primitives are also defined for exchanging information between the mobile IP module and the RSVP module within the same node. With the modifications of the RSVP module, most of the functions in this document can be met. However, some modifications of the mobile IP module are also required to fulfill the objectives Yi, et al. Expires August 12, 2007 [Page 4] Internet-Draft Fast RSVP February 2007 of this document. +---------------+ | Correspondent | | Node (CN) | +---------------+ | | +---------------+ /-------| IPv6 network |-------\ / +---------------+ \ / \ +---------------+ +---------------+ | Previous | | New | | Access Router | | Access Router | | (PAR) | | (NAR) | +---------------+ +---------------+ +-------------+ +-------------+ | Mobile Node |-------------------->| Mobile Node | | (MN) | | (MN) | +-------------+ +-------------+ Figure 1: Reference Scenario for Handover Yi, et al. Expires August 12, 2007 [Page 5] Internet-Draft Fast RSVP February 2007 2. Terminologies The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The use of the term, "silently ignore" and "silently discard" is not defined in RFC 2119. However, the terms are used in this document and can be similarly construed. The following terminology and abbreviations are used in this document. Mobile Node (MN) A mobile host supporting Mobile IPv6. Correspondent Node (CN) The peer host with which MN is communicating. Previous Access Router (PAR) The MN's default router before its handover event. New Access Router (NAR) The MN's default router after its handover event. Care-of Address (CoA) A unicast routable address associated with a MN while visiting a foreign link. Previous CoA (PCoA) The MN's care-of address used in PAR's subnet. New CoA (NCoA) The MN's care-of address used in NAR's subnet. Handover A procedure of terminating the IP connectivity to one subnet and obtaining a new IP connectivity to another subnet. RSVP Proxy The module on a access router which can initiate RSVP procedures or respond to RSVP requests on behalf of MN. Advanced Reservation Resource reservation which is established before Yi, et al. Expires August 12, 2007 [Page 6] Internet-Draft Fast RSVP February 2007 the handover event occurs. HandoverForecast.ind (HF.ind) A primitive from MN's mobile IP module to its RSVP module indicating a predicted handover. HandoverForecastConfirm.ind (HFConfirm.ind) A primitive from MN's mobile IP module to its RSVP module indicating a prediction is successful. HandoverForecastError.ind (HFError.ind) A primitive from MN's mobile IP module to its RSVP module indicating a prediction fails. SessionHandover.req (SH.req) A primitive from CN's (MN's) mobile IP module to its RSVP module requesting whether the session data to MN (CN) can be switched to the optimized route. SessionHandover.ind (SH.ind) A primitive from CN's (MN's) RSVP module to its mobile IP module indicating the session data to MN(CN) can be switched the optimized route. AddrNotify.ind (AN.ind) A primitive from router's RSVP module to its mobile IP module indicating the home address and care-of address of MN so that mobile IP module can rebuild the "Type 2 routing header" or "Home address option" accordingly. HandoverForecast (HF) A message from MN's RSVP module to PAR's (NAR's) RSVP module providing information about the predicted handover. The message acts as a trigger to establish the resource reservation tunnel. HandoverForecastResponse (HFRsp) A message from PAR's (NAR's) RSVP module to MN's RSVP module indicating whether the resource reservation tunnel has been established successfully. HandoverForecastConfirm (HFConfirm) A message from MN's RSVP module to PAR's RSVP module indicating the handover prediction is successful. TunnelStateChange (TSChange) A message from PAR (NAR) to NAR (PAR) to indicate the intermediate routers to change the reservation type Yi, et al. Expires August 12, 2007 [Page 7] Internet-Draft Fast RSVP February 2007 (see section 5.4). HandoverForecastError (HFError) A message from MN's RSVP module to PAR's (NAR's) RSVP module indicating the handover prediction fails, so that the resource reservation tunnel can be rebuilt in time. HandoverForecstTear (HFTear) A message from MN's RSVP module to PAR's RSVP module to indicate PAR tearing down the resource reservation tunnel which is mistakenly built by the false handover prediction. TunnelPath (TPath) A message exchanged between RSVP routers to establish PATH state over the resource reservation tunnel. TunnelResv (TResv) A message exchanged between RSVP routers to establish RESV state over the resource reservation tunnel. TunnelPathTear (TPathTear) A message exchanged between RSVP routers to release the resources reserved in advance on the falsely built resource reservation tunnel. TunnelResvTear (TResvTear) A message exchanged between RSVP routers to release the resources reserved in advance on the falsely built resource reservation tunnel. Yi, et al. Expires August 12, 2007 [Page 8] Internet-Draft Fast RSVP February 2007 3. Overview of RSVP Extensions 3.1. Addressing the QoS Guarantee during Handover In traditional RSVP, the SESSION object is used to label a session. Unfortunately, in mobile environment, the content of the SESSION object may change after a handover because the "IPv6 DestAddress" field changes. However, the resource reservation along the path still corresponds to the old SESSION object and therefore, the QoS of the service flow is no longer guaranteed. The extensions proposed in this document introduce a new MSESSION (see section 6.2.) object to replace the SESSION object in the traditional RSVP protocol. Compared with the SESSION object, MSESSION adds an "IPv6 HomeAddress" field in the object. The "IPv6 HomeAddress" field is filled with the MN's home address and its value is constant during handover, so we can utilize it to label the session. In mobile environment, the RSVP router MUST label a session based on the content of the MSESSION and set up the corresponding Path State and Resv State accordingly. The key factor affecting the QoS of the session during handover is how fast resource reservation can be re-established after MN hands over to a new subnet. To reduce the resource reservation re-establishment latency, the extensions proposed in this document enable the RSVP module to make advanced resource reservation on the neighbor tunnel when MN is still connected to PAR. Based on the handover prediction result made by MN's mobile IP module, the RSVP module of MN would send a HandoverForecast message to PAR (NAR) to inform it about the handover event. Then PAR (NAR) utilizes this information to make advanced resource reservation on the tunnel before the handover occurs. So when MN moves to NAR's subnet, the session between MN and CN can use this advanced resource reservation neighbor tunnel to transmit the session data and QoS of the session can be guaranteed. The extensions proposed in this document specify a resource reservation tunnel between PAR and MN's NCoA, via NAR. As illustrated in Figure 2, PAR and MN are the two endpoints of the resource reservation neighbor tunnel. However, the reservation should be established before the handover occurs, and MN is not within NAR's subnet at that time. Therefore, the extensions proposed in this document introduce a new entity named RSVP proxy, which can make advanced resource reservation on behalf of MN. In Figure 2, NAR acts as an RSVP proxy, sending or receiving RSVP messages on behalf of MN before MN hands over to its subnet. Yi, et al. Expires August 12, 2007 [Page 9] Internet-Draft Fast RSVP February 2007 +---------+ RSVP TUNNEL +---------+ +--------+ | PAR |-------------------| NAR |----| MN | | |-------------------| |----| | +---------+ +---------+ +--------+ (RSVP Proxy) Figure 2: RSVP TUNNEL and RSVP Proxy By setting up a resource reservation tunnel between two neighbor subnets in advance, the mobile node could realize handover with QoS guarantee. However, the use of tunnel induces the triangular route problem, thus causing network resource waste. In Mobile IPv6 [2], route optimization becomes a compelling strategy, and the reservation process on the optimized route should be considered. However, in order to guarantee the QoS of the session, communication between MN and CN must keep utilizing the tunnel until resources have been successfully reserved on the optimized route. 3.2. Cooperation between the RSVP Module and the Mobile IP Module With the extensions of the RSVP module, most of the functions can be met. However, some modifications to the mobile IP module and some information exchanging between RSVP module and mobile IP module are also required. The mobile IP module MUST have the following functions. 1. When predicting that a handover is imminent, the mobile IP module of MN MUST send a HandoverForecast.ind to the RSVP module. The HandoverForecast.ind MUST include the information such as the predicted NAR's IP address and the corresponding NCoA. 2. After MN hands over to the new subnet, the mobile IP module MUST check whether the current subnet is the same as the predicted handover target subnet and send certain indication to the RSVP module depending on the checking result. If the handover prediction is successful, a HandoverForecastConfirm.ind MUST be sent. Otherwise, a HandoverForecastError.ind MUST be sent immediately. The HandoverForecastError.ind MUST contain the current in use CoA and MAY contain the formerly falsely predicted CoA of MN. 3. When MN is stable in the new subnet, the mobile IP module MUST start the route optimization process. If the mobile IP module of the CN receives a BU message from MN, it MUST send a SessionHandover.req to the RSVP module and MUST NOT redirect the session data to the optimized route until receiving the SessionHandover.ind from the RSVP module. The Yi, et al. Expires August 12, 2007 [Page 10] Internet-Draft Fast RSVP February 2007 SessionHandover.req MUST contain the session's home address and NCoA. 4. If intermediate routers on the optimized route receive a PATH or RESV message with "Type 2 routing header" or "Home address option" in IP header fields, the mobile IP module of the router MUST utilize the AddrNotify.ind acquired from the RSVP module to rebuild the "Type 2 routing header" or "Home address option" before delivering the message to the next hop. 3.3. RSVP Extensions Operation The extensions proposed in this document begin when the mobile IP module on MN sends a HandoverForecast.ind to the RSVP module on the same node and then the RSVP module sends a HandoverForecast message (see section 6.3.1.) to PAR or NAR depending on whether MN is the sender or the receiver of the session. If MN is the session receiver, the HandoverForecast message will be sent to PAR. Otherwise, the HandoverForecast message will be sent to NAR. The mobile IP module MAY send a HandoverForecast.ind at any convenient time, for instance as a response to some link-specific event (a "trigger") or simply after a handover prediction by GPS. However, the expectation is that prior to sending the HandoverForecast message, the mobile IP module on MN MUST have discovered the predicted handover target subnet (i.e., NAR in Figure 1) and acquired a NCoA that can be used in that subnet. With the information provided in the HandoverForecast message, PAR (NAR) formulates a TunnelPath message (see section 6.3.7) and NAR (PAR) replies a TunnelResv message (see section 6.3.8). Finally, through the message exchange between PAR and NAR, a resource reservation tunnel is established in advance and MN can use this QoS- guaranteed path immediately after the handover event if the handover prediction is successful. When PAR (NAR) receives the TunnelResv message, it sends a HandoverForecastResponse message (see section 6.3.2) to MN to indicate the completion of the resource reservation tunnel establishment. However, if the reservation on the tunnel fails, the router also sends a HandoverForecastResponse message to MN to indicate the failure, and then MN will stop the following process. After MN moves to the new subnet, it checks whether the current subnet is the same as the predicted handover target subnet (e.g. comparing the IP address of the current access router and the predicted access router). Depending on whether the handover prediction is correct, there are two modes of the operation. Yi, et al. Expires August 12, 2007 [Page 11] Internet-Draft Fast RSVP February 2007 1. The prediction is successful. The mobile IP module of MN starts the binding update process with PAR. After that, it sends a HandoverForecastConfirm.ind to the RSVP module in the same node and the latter sends a HandoverForecastConfirm message (see section 6.3.3.) to PAR or NAR depending on whether MN is the receiver or the sender of the session. On receiving the HandoverForecastConfirm message, PAR (NAR) sends a TunnelStateChange (see section 6.3.4) message to NAR (PAR) to indicate to the intermediate routers to change the reservation type (see section 5.4). 2. The prediction fails. The mobile IP module of MN locates the correct NAR and then starts the binding update process with PAR. After that, it sends a HandoverForecastError.ind to the RSVP module on the same node so that the RSVP module SHALL take the following actions: If MN is the session receiver, it sends a HandoverForecastError message (see section 6.3.5.) to PAR to indicate that the handover prediction fails. After receiving the HandoverForecastError message, PAR sends a TunnelPath message to the current NAR of MN to establish the resource reservation tunnel. In addition, MN sends a HandoverForcastTear message (see section 6.3.6) to PAR and on receiving this message PAR sends a TunnelPathTear message (see section 6.3.9.) to the formerly predicted NAR to release the previously mistakenly built reservation tunnel. If MN is the session sender, it sends a HandoverForecastError message to the current NAR to indicate the handover prediction fails. After receiving the HandoverForecastError message, NAR sends a TunnelPath message to PAR of MN to establish the resource reservation tunnel. In addition, MN sends a HandoverForcastTear message to PAR and on receiving this message, PAR sends a TunnelResvTear message (see section 6.3.10) to the formerly predicted NAR to release the previously mistakenly built reservation tunnel. The scenarios with successful handover predictions are illustrated in Figure 3, Figure 4 and Figure 5, considering MN act as the session receiver only, the session sender only, and both the session receiver and session sender respectively. For convenience, these scenarios are characterized as a "prediction success" mode of operation. The scenarios with failed handover predictions are illustrated in Figure 6, Figure 7 and Figure 8, considering MN act as the session receiver only, the session sender only, and both the session receiver and session sender respectively. For convenience, these scenarios are characterized as a "failure recovery" mode of operation. Yi, et al. Expires August 12, 2007 [Page 12] Internet-Draft Fast RSVP February 2007 MN PAR NAR |----------------------------| | | | Mobile IP RSVP | | | | Module Module | | | |----------------------------| | | | | | | predict | | | handover | | | |------HF.ind----->| | | | |-----HF---->| | | | |----TPath--->| | | |<---TResv----| | |<---HFRsp---| | | | | | disconnect | | | | | | | connect | | | | | | | |------------------------BU------------------>| | | |<-----BU-----| | | |-----BAck--->| |<----------------------BAck------------------| |--HFConfirm.ind-->| | | | |-HFConfirm->| | | | |--TSChange-->| | | | | Figure 3: "Prediction Success" Mode (MN is the session receiver) Yi, et al. Expires August 12, 2007 [Page 13] Internet-Draft Fast RSVP February 2007 MN PAR NAR |----------------------------| | | | Mobile IP RSVP | | | | Module Module | | | |----------------------------| | | | | | | predict | | | handover | | | |------HF.ind----->| | | | |------------HF----------->| | | |<---TPath----| | | |----TResv--->| | |<----------HFRsp----------| | | | | disconnect | | | | | | | connect | | | | | | | |------------------------BU------------------>| | | |<-----BU-----| | | |-----BAck--->| |<----------------------BAck------------------| |--HFConfirm.ind-->| | | | |---------HFConfirm------->| | | |<--TSChange--| | | | | Figure 4: "Prediction Success" Mode (MN is the session sender) Yi, et al. Expires August 12, 2007 [Page 14] Internet-Draft Fast RSVP February 2007 MN PAR NAR |----------------------------| | | | Mobile IP RSVP | | | | Module Module | | | |----------------------------| | | | | | | predict | | | handover | | | |------HF.ind----->| | | | |-----HF(B=1)---->| | | | |---TPath(B=1)-->| | | |<-----TResv-----| | | |<-----TPath-----| | | |------TResv---->| | | |<---ResvConf----| | |<-----HFRsp------| | disconnect | | | | | | | connect | | | | | | | |---------------------------BU----------------------->| | | |<------BU-------| | | |------BAck----->| |<-------------------------BAck-----------------------| |--HFConfirm.ind-->| | | | |-HFConfirm(B=1)->| | | | |-TSChange(B=1)->| | | |<---TSChange----| | | | | Figure 5: "Prediction Success" Mode (MN is both the receiver and the sender of the session) Yi, et al. Expires August 12, 2007 [Page 15] Internet-Draft Fast RSVP February 2007 MN PAR Error Correct |----------------------------| | NAR NAR | Mobile IP RSVP | | | | | Module Module | | | | |----------------------------| | | | | | | | | predict | | | | handover | | | | |------HF.ind----->| | | | | |-----HF---->| | | | | |----TPath--->| | | | |<---TResv----| | | |<---HFRsp---| | | disconnect | | | | | | | | | connect | | | | |--------------------------BU------------------------->| | | |<---------BU----------| | | |---------BAck-------->| |<------------------------BAck-------------------------| |----HFError.ind-->| | | | | |---------------------HFError------>| | | |<-------HFError-------| | | |--------TPath-------->| | | |<-------TResv---------| | |---------------------HFTear------->| | | |<-------HFTear--------| | | |--TPathTear->| | | | | | | Figure 6: "Failure Recovery" Mode (MN is the session receiver) Yi, et al. Expires August 12, 2007 [Page 16] Internet-Draft Fast RSVP February 2007 MN PAR Error Correct |----------------------------| | NAR NAR | Mobile IP RSVP | | | | | Module Module | | | | |----------------------------| | | | | | | | | predict | | | | handover | | | | |------HF.ind----->| | | | | |------------HF----------->| | | | |<---TPath----| | | | |----TResv--->| | | |<----------HFRsp----------| | disconnect | | | | | | | | | connect | | | | |--------------------------BU------------------------->| | | |<---------BU----------| | | |---------BAck-------->| |<------------------------BAck-------------------------| |----HFError.ind-->| | | | | |---------------------HFError------>| | | |<-------TPath---------| | | |--------TResv-------->| | |---------------------HFTear------->| | | |<-------HFTear--------| | | |--TResvTear->| | | | | | | Figure 7: "Failure Recovery" Mode (MN is the session sender) Yi, et al. Expires August 12, 2007 [Page 17] Internet-Draft Fast RSVP February 2007 MN PAR Error Correct |-------------------------| | NAR NAR | Mobile IP RSVP | | | | | Module Module | | | | |-------------------------| | | | | | | | | predict | | | | handover | | | | |-----HF.ind---->| | | | | |-HF(B=1)->| | | | | |---TPath(B=1)--->| | | | |<-----TResv------| | | | |<-----TPath------| | | | |------TResv----->| | | | |<-----ResvConf---| | | |<--HFRsp--| | | disconnect | | | | | | | | | connect | | | | |-----------------------BU---------------------------->| | | |<------------BU-----------| | | |-------------BAck-------->| |<---------------------BAck----------------------------| |--HFError.ind-->| | | | | |---------------HFError(B=1)--------->| | | |<-----HFError(B=1)--------| | | |---------TPath(B=1)------>| | | |<--------TResv------------| | | |<--------TPath------------| | | |---------TResv----------->| | | |<--------ResvConf---------| | |----------------HFTear(B=1)--------->| | | |<------HFTear(B=1)--------| | | |-TPathTear(B=1)->| | | | |<---TPathTear----| | | | | | | Figure 8: "Failure Recovery" Mode (MN is both the receiver and the sender of the session) After MN becomes stable in the new subnet, the route optimization process would start. In the case that MN is the session receiver, CN is responsible for initiating the reservation process on the optimized route. The extensions proposed in this document introduce a new cache named Pending Cache. In addition to maintaining a Binding Cache, the Yi, et al. Expires August 12, 2007 [Page 18] Internet-Draft Fast RSVP February 2007 mobile IP module of CN also maintains a Pending Cache. Every entry in the Pending Cache contains a (home address, care-of address) pair. When the mobile IP module of CN receives a BU message from MN, it simply updates the corresponding entry of MN in the Pending Cache (without updating the corresponding entry of MN in the Binding Cache) and sends a SessionHandover.req to its RSVP module. Since the IP layer of CN only checks the Binding Cache to decide the destination addresses of the packets after it receives session data from the upper layer, thus when to redirect session data to the new optimized route is controlled entirely by the RSVP module. On receiving the SessionHandover.req message, the RSVP module of CN checks whether the mobile node (indicated in the SessionHandover.req message) has multimedia sessions requiring resource reservation. If MN has no such sessions, the RSVP module of CN immediately sends a SessionHandover.ind message to the mobile IP module. If MN does have sessions with resource reservation requirements, the RSVP module of CN MUST start the resource reservation process on the optimized route. Before the resource reservation process on the optimized route completes, Binding Cache remains unchanged, so sessions between CN and MN are still transmitted along the old route and the resource reservation neighbor tunnel. Only after the RSVP module completes the resource reservation on the optimized route and sends a SessionHandover.ind message to the mobile IP module SHOULD the mobile IP module update the corresponding entry of MN in the Binding Cache. Then the session data is switched to the new optimized route and seamless handover between the two routes without QoS degradation can be achieved. The reservation process on the optimized route when MN is the receiver of the session is illustrated in Figure 9. Yi, et al. Expires August 12, 2007 [Page 19] Internet-Draft Fast RSVP February 2007 MN router CN |--------------------| | |--------------------| | Mobile IP RSVP | | | RSVP Mobile IP | | Module Module | | | Module Module | |--------------------| | |--------------------| | | | | | MN is stable | | | | in new subnet | | | | |-----------------------BU---------------------->| |<---------------------BAck----------------------| | | | |<-SH.req--| | |<---Path-----|<---Path----| | | |----Resv---->|----Resv--->| | | | | |--SH.ind->| | | | | redirect | | | | session data | | | | | Figure 9: Reservation on the Optimized Route (MN is session receiver) In the case when MN is the session sender, MN itself is responsible for initiating the reservation process on the optimized route. When the mobile IP module of MN receives a BA message from CN, it sends a SessionHandover.req to its RSVP module. When to redirect session data to the new optimized route is then controlled entirely by the RSVP module. On receiving the SessionHandover.req message, the RSVP module of MN checks whether it has multimedia sessions requiring resource reservation. If MN has no such sessions, its RSVP module immediately sends a SessionHandover.ind message to the mobile IP module. If MN does have sessions with resource reservation requirements, its RSVP module MUST start the resource reservation process on the optimized route. Before the resource reservation process completes, sessions between MN and CN are still transmitted along the old route and the resource reservation neighbor tunnel. Only after the RSVP module completes resource reservation on the optimized route and sends a SessionHandover.ind message to the mobile IP module SHOULD the mobile IP module redirect the session data to the new optimized route. Thus seamless handover between the two routes without QoS degradation can be achieved. The reservation process on the optimized route when MN is the sender of the session is illustrated in Figure 10. Yi, et al. Expires August 12, 2007 [Page 20] Internet-Draft Fast RSVP February 2007 MN router CN |--------------------| | |--------------------| | Mobile IP RSVP | | | RSVP Mobile IP | | Module Module | | | Module Module | |--------------------| | |--------------------| | | | | | MN is stable | | | | in new subnet | | | | |-----------------------BU---------------------->| |<---------------------BAck----------------------| |--SH.req->| | | | | |----Path---->|----Path--->| | | |<---Resv-----|<---Resv----| | |<-SH.ind--| | | | redirect | | | | session data | | | | | | | | | Figure 10: Reservation on the Optimized Route (MN is session sender) By exchanging Path and Resv messages between MN and CN, the resource reservation process on the optimized route can be achieved. When the mobile IP module of the intermediate router on the optimized route receives a Path message, it sends the message to the RSVP module for processing. After the RSVP module receives the Path message, it checks whether it already has the corresponding Path State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Path State is found, the RSVP module on the router only needs to update this state; otherwise, it sets up the corresponding Path State for the session. When the RSVP module completes processing the Path message, it would send the message back to the mobile IP module. In addition, the RSVP module on the router should notify the mobile IP module of MN's home address by sending a AddrNotify.ind, so that the mobile IP module could fill this address in "Type 2 Routing Header" (if MN is the session receiver) or "Home address option" (if MN is the session sender) when re-encapsulating the Path message. The scenario about the process of the Path message on the intermediate router is illustrated in the Figure 11. Yi, et al. Expires August 12, 2007 [Page 21] Internet-Draft Fast RSVP February 2007 | | |Path MN CN | |--------------------| PATH |--------------------| V-->| |------>| | | Mobile IP | PATH | RSVP | | Module |<------| Module | | | AN.ind| | |<--| |<------| | | |--------------------| |--------------------| |Path V Figure 11: Process of the Path Message on the Intermediate Router Yi, et al. Expires August 12, 2007 [Page 22] Internet-Draft Fast RSVP February 2007 4. Details of RSVP Extensions 4.1. MN is the Receiver of the Session When the mobile IP module of MN predicts that a handover event from PAR to NAR is imminent, it sends an indication message HandoverForecast.ind to the RSVP module. The HandoverForecast.ind MUST contain the NCoA that will be used by MN in NAR's subnet. Then the RSVP module: 1. extracts the NCoA and the home address from the HandoverForecast.ind and then uses this information to form the Router_Notify object (see section 6.2.2). The Router_Notify object MUST contain the NCoA and Code 0 (see section 6.3.1.). 2. extracts the MSESSION object from the corresponding Path or Resv State on MN and fills the "IPv6 DestAddress" field with NCoA to form a new MSESSION object. Note that this new MSESSION object corresponds to the tunnel reservation and MUST NOT affect the MSESSION object in the Path or Resv State on MN. 3. uses the Router_Notify object formed in step 1 and the new MSESSION formed in step 2 to construct a HandoverForecast message with 'B' flag unset (see section 5.3) and sends it to the current access router PAR. When PAR receives the HandoverForecast message, it SHALL check the 'B' flag in Common Header to make sure it is unset, then the RSVP module of it: 1. extracts the MN's NCoA and the Code in the Router_Notify object and confirms that the Code is 0 (it means that the router acts as PAR for MN). 2. looks up the matching Path State of the session according to the "IPv6 HomeAddress", "DstPort" and "Protocol Id" in the MSESSION object that can be found in the HandoverForecast message and extracts the SENDER_TSPEC (defines the traffic characteristics of a sender's data flow) [3] contained in the matching Path State. 3. uses the SENDER_TSPEC and the MSESSION (copied from the HandoverForecast message) to construct the TunnelPath message with the 'B' flag unset. The TunnelPath message shares the same format with the Path message, except that it has a different "Msg Type" field value (see section 6.3.6.) in Common Header to indicate that it corresponds to the tunnel resource reservation and not to the usual resource reservation between the session endpoints. Yi, et al. Expires August 12, 2007 [Page 23] Internet-Draft Fast RSVP February 2007 4. sets up the Path State according to the TunnelPath message and sends it to MN's NCoA to establish the resource reservation tunnel. When intermediate routers receive the TunnelPath message, they set up the Path State for the session according to the content of the message and forward the message to the next hop. Finally, when the router of the handover target subnet (NAR) receives the TunnelPath message, it SHALL check the 'B' flag in Common Header to make sure it is unset, then its RSVP module: 1. sets up the Path State according to the content of the TunnelPath message. 2. acts as a RSVP proxy for MN, constructing a TunnelResv message with 'B' flag unset and then sending it out on the reverse direction to PAR. The TunnelResv message shares the same format with the Resv message, except that it has a different "Msg Type" (see section 6.3.7) field value in Common Header to indicate that it corresponds to the tunnel resource reservation and not to the usual resource reservation between the session endpoints. 3. sets up the Resv State according to the content of the TunnelResv message. When intermediate routers receive the TunnelResv message, they make an advanced resource reservation for the session locally, set up the corresponding Resv State and forward the TunnelResv message to the previous hop. Finally, when PAR receives the TunnelResv message, it sets up the Resv State, and a resource reservation tunnel between PAR and NAR is successfully built. As a response to HandoverForecast message, PAR SHALL send a HandoverForecastResponse message to MN indicating one of the following possible conditions: 1. If the resource reservation tunnel establishment is successful, PAR MUST construct a HandoverForecastResponse message with Code 0 in the Tunnel_Info object (see section 6.2.3) and send it to MN indicating the successful establishment of the resource reservation tunnel. The MSESSION object in this message is copied from the corresponding Path or Resv State. 2. If the resource reservation tunnel establishment fails, PAR SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation procedure. Choosing Yi, et al. Expires August 12, 2007 [Page 24] Internet-Draft Fast RSVP February 2007 the appropriate algorithm is outside the scope of this document. If the resource reservation on the tunnel fails even after TPATH_RETRIES, PAR MUST assume that not enough resources are available on the neighbor tunnel and then PAR SHALL construct a HandoverForecastResponse message with Code 1 in the Tunnel_Info object and send it to MN indicating the failure in building the tunnel. The MSESSION object in this message is copied from the corresponding Path or Resv State. If MN receives a HandoverForecastResponse message with Code 1 or even if it doesn't receive the HandoverForecastResponse message until the handover occurs, it MUST skip the step of resource reservation on the tunnel and process the optimized route resource reservation step described below. After MN hands over to a new subnet, its mobile IP module sends a BU message to PAR, so PAR can redirect the session data to MN's new position. In addition, the mobile IP module of MN MUST check whether the current subnet is the same as the predicted handover target subnet. Then depending on the result of this check, MN MUST take one of the following actions: 1. If the handover prediction is successful, the mobile IP module of MN MUST send a HandoverForecastConfirm.ind to the RSVP module. When the RSVP module of MN receives this indication, it MUST construct a HandoverForecastConfirm message with the 'B' flag unset and send it to PAR. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. 2. If the handover prediction fails, the mobile IP module of MN MUST send a HandoverForecastError.ind to the RSVP module. This indication message MUST contain the current in use CoA and the formerly falsely predicted CoA of MN. When the RSVP module of MN receives this indication message, it MUST construct a HandoverForecastError message with the Router_Notify object including the current in use CoA as well as Code 0 and then send the message to PAR directly. The 'B' flag in this message MUST be unset. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. MN MUST also construct a HandoverForecastTear message containing the formerly falsely predicted CoA and send the message to PAR directly. The 'B' flag in this message MUST be unset. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. If the handover event doesn't occur within a certain time, the mobile Yi, et al. Expires August 12, 2007 [Page 25] Internet-Draft Fast RSVP February 2007 IP module of MN MUST also construct a HandoverForecastTear message containing the formerly falsely predicted CoA and send the message to PAR directly. The 'B' flag in this message MUST be unset. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. When receiving the HandoverForecastConfirm message, PAR SHALL check the 'B' flag in Common Header to make sure it is unset, then it MUST send a TunnelStateChange message with 'B' flag unset and send the message to NAR. The MSESSION object in this message is copied from the HandoverForecastConfirm message so the intermediate routers can change the reservation type (see section 5.4). When receiving the HandoverForecastError message, PAR SHALL check to make sure that the 'B' flag in Common Header is unset and the Code in Router_Notify object is filled with 0. Then it MUST extract MN's current in use CoA and send a new TunnelPath message with 'B' flag unset to MN's current subnet (e.g. Correct NAR in Figure 6). The MSESSION object in this message is copied from the HandoverForecastError message. When receiving this TunnelPath message, NAR MUST reply with a TunnelResv message with the 'B' flag unset so that resource reservation on the correct tunnel can be established. When receiving the HandoverForecastTear message, PAR SHALL check the 'B' flag in Common Header to make sure it is unset, then it MUST extract the MN's formerly falsely predicted CoA and send a TunnelPathTear message with the 'B' flag unset to MN's falsely predicted subnet (e.g. Error NAR in Figure 6). The MSESSION object in this message is copied from the HandoverForecastTear message. When receiving this message, intermediate routers MUST remove the corresponding Path State and Resv State so that the resources reserved in advance on the falsely built tunnel can be released. When MN gets stable in the handover target subnet, it sends a BU message to CN. After the mobile IP module of CN receives this BU message, in addition to replying with a BA message to MN, the mobile IP module of CN also takes the following actions: 1. extracts MN's home address and NCoA (included in the BU message) and updates the corresponding entry of MN in the Pending Cache (see section 3.1.) to record the (home address, NCoA) pair. 2. sends a SessionHandover.req to the RSVP module inquiring whether or not to redirect the session data to the new optimized route. The SessionHandover.req MUST contain the (home address, NCoA) pair of MN. Yi, et al. Expires August 12, 2007 [Page 26] Internet-Draft Fast RSVP February 2007 On receiving the SessionHandover.req, the RSVP module of CN MUST try to lookup the matching Path or Resv State according to the home address of MN. Then: 1. If matching Path or Resv State is not found, it means that MN doesn't have any multimedia sessions requiring resource reservation. Then the RSVP module MUST immediately send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of the MN. 2. If matching Path or Resv State is found, it means that MN does have multimedia sessions requiring resource reservation. Then the RSVP module of CN MUST initiate the resource reservation process on the optimized route. The RSVP module of CN generates the Path message with the 'B' flag unset and sends it to MN. In addition, the RSVP module updates the corresponding Path state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA). The MSESSION object in the Path message MUST contain the NCoA as well as the home address of MN. The SENDER_TSPEC in the Path message MUST be extracted from the corresponding Path State of MN. After an intermediate RSVP router on the transmission path receives the Path message, it MUST check whether it already has the corresponding Path State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Path State is found, the RSVP module on the router only needs to update this state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise, it MUST set up the corresponding Path State for the session. In addition, the RSVP module on the router MUST send an AddrNotify.ind to the mobile IP module to indicate MN's home address and NCoA, so that the mobile IP module could fill these addresses in "Type 2 Routing Header" and the IP header when re-encapsulating the Path message. After the Path message corresponding to the optimized route finally reaches MN, MN SHALL check the 'B' flag in Common Header to make sure it is unset, then the RSVP module of MN replies with the proper Resv message with the 'B' flag unset and updates the corresponding Path and Resv state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA). After an intermediate RSVP router on the transmission path receives the Resv message, it checks whether it already has the corresponding Resv State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Resv State is found, the RSVP module on the router only needs to update this state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise, it tries to reserve resources for the session locally and set up the Yi, et al. Expires August 12, 2007 [Page 27] Internet-Draft Fast RSVP February 2007 corresponding Resv State. Finally, when the RSVP module of CN receives the Resv message and updates the corresponding Resv state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA), the resource reservation process on the optimized route successfully completes. Then the RSVP module MUST send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of MN. If the reservation on the optimizated route fails, CN SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation process. The choice of the appropriate algorithm is outside the scope of this document. If the resource reservation on the optimized route fails even after the ROPATH_RETRIES, CN MUST assume that resources are not available on the optimized route. Then session data from CN to MN SHALL be kept transmitting along the old resource reservation path and the resource reservation neighbor tunnel. On receiving the SessionHandover.ind, the mobile IP module of CN MUST update the proper entry in the Bindng Cache according to the (home address, NCoA) pair of MN which can be extracted from the SessionHandover.ind, thus session data is redirected to the optimized route from then on. 4.2. MN is the Sender of the Session When the mobile IP module of MN predicts that a handover event from PAR to NAR is imminent, it sends an indication message HandoverForecast.ind to the RSVP module. The HandoverForecast.ind MUST contain the PAR's IP address. Then the RSVP module: 1. extracts the NCoA and the home address from the HandoverForecast.ind and then uses this information to form the Router_Notify object (see secton 6.2.2). The Router_Notify object MUST contain the PAR's IP address and Code 1 (see section 6.3.1.), 2. extracts the MSESSION object from the corresponding Path or Resv State on MN and fills the "IPv6 DestAddress" field with PAR's IP address to form a new MSESSION object. Note that this new MSESSION object corresponds to the tunnel reservation and MUST NOT affect the MSESSION object in the Path or Resv State on MN. 3. uses the Router_Notify object formed in step 1 and the new MSESSION formed in step 2 to construct a HandoverForecast message with 'B' flag unset (see section 5.3) and sends it to the predicted access router NAR. The SENDER_TSPEC object in this message is copied from the corresponding Path state. Yi, et al. Expires August 12, 2007 [Page 28] Internet-Draft Fast RSVP February 2007 When NAR receives the HandoverForecast message, it SHALL check the 'B' flag in Common Header to make sure it is unset, then the RSVP module of it: 1. extracts the PAR's IP address and the Code in the Router_Notify object that can be found in the HandoverForecast message and confirms that the Code is 1 (it means that the router acts as NAR for MN), 2. extracts the SENDER_TSPEC object and the MSESSION object both of which are included in the HandoverForecast message. 3. acts as an RSVP proxy of MN and uses the SENDER_TSPEC object as well as the MSESSION object to construct the TunnelPath message with the 'B' flag unset. The TunnelPath message shares the same format with the Path message, except that it has a different "Msg Type" field value in Common Header to indicate that it corresponds to the tunnel resource reservation and not to the usual resource reservation between the session endpoints. 4. sets up the Path State of the session accordingly and sends the TunnelPath message to PAR. When intermediate routers receive the TunnelPath message, they set up the Path State for the session according to the content of the message and forward the message to the next hop. Finally, when PAR receives the TunnelPath message, it SHALL check the 'B' flag in Common Header to make sure it is unset, then its RSVP module: 1. sets up the Path State according to the content of the TunnelPath message. 2. constructs a TunnelResv message with the 'B' flag unset and then sends it out on the reverse direction to NAR. The TunnelResv message shares the same format with the Resv message, except that it has a different "Msg Type" (see section 6.3.7) field value in Common Header to indicate that it corresponds to the tunnel resource reservation and not to the usual resource reservation between the session endpoints. 3. sets up the Resv State according to the content of the TunnelResv message. When intermediate routers receive the TunnelResv message, they make an advanced resource reservation for the session locally, set up the corresponding Resv State and forward the TunnelResv message to the previous hop. Yi, et al. Expires August 12, 2007 [Page 29] Internet-Draft Fast RSVP February 2007 Finally, when NAR receives the TunnelResv message, it sets up the Resv State, and a resource reservation tunnel between NAR and PAR is successfully built. As a response to HandoverForecast message, NAR SHALL send a HandoverForecastResponse message to MN indicating one of the following possible conditions: 1. If the resource reservation tunnel establishment is successful, NAR MUST construct a HandoverForecastResponse message with Code 0 in the Tunnel_Info object (see section 6.2.3) and send it to MN indicating the successful establishment of the resource reservation tunnel. The MSESSION object in this message is copied from the corresponding Path or Resv State. 2. If the resource reservation tunnel establishment fails, NAR SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation procedure. The choice of the appropriate algorithm is outside the scope of this document. If the resource reservation on the tunnel fails even after TPATH_RETRIES, NAR MUST assume that not enough resources are available on the neighbor tunnel and then NAR SHOULD construct a HandoverForecastResponse message with Code 1 in the Tunnel_Info object and send it to MN indicating the failure in building the tunnel. The MSESSION object in this message is copied from the corresponding Path or Resv State. If MN receives a HandoverForecastResponse message with Code 1 or even if it doesn't receive the HandoverForecastResponse message until the handover occurs, it MUST skip the step of resource reservation on the tunnel and process the optimized route resource reservation step described below. After MN hands over to a new subnet, its mobile IP module sends a BU message to PAR, so PAR can redirect the session data to MN's new position. In addition, the mobile IP module of MN MUST check whether the current subnet is the same as the predicted handover target subnet. Then depending on the result of this check, MN MUST take one of the following actions: 1. If the handover prediction is successful, the mobile IP module of MN MUST send a HandoverForecastConfirm.ind to the RSVP module. When the RSVP module of MN receives this indication, it MUST construct a HandoverForecastConfirm message with the 'B' flag unset and send it to NAR. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to PAR's IP address. Yi, et al. Expires August 12, 2007 [Page 30] Internet-Draft Fast RSVP February 2007 2. If the handover prediction fails, the mobile IP module of MN MUST send a HandoverForecastError.ind to the RSVP module. This indication message MUST contain the current in use CoA and the formerly falsely predicted CoA of MN. When the RSVP module of MN receives this indication message, it MUST construct a HandoverForecastError message with the Router_Notify object including the IP address of MN's previous access router (PAR) as well as Code 1 and then send the message to NAR directly. The 'B' flag in this message MUST be unset. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to PAR's IP address. The SENDER_TSPEC object in this message is copied form the corresponding Path state. MN MUST also construct a HandoverForecastTear message containing the formerly falsely predicted CoA and send the message to PAR directly. The 'B' flag in this message MUST be unset. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to PAR's IP address. If the handover event doesn't occur within a certain time, the mobile IP module of MN MUST also construct a HandoverForecastTear message containing the formerly falsely predicted CoA and send the message to PAR directly. The 'B' flag in this message MUST be unset. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to PAR's IP address. When receiving the HandoverForecastConfirm message, NAR SHALL check the 'B' flag in Common Header to make sure it is unset, then it MUST send a TunnelStateChange message with the 'B' flag unset to PAR, the MSESSION object in this message is copied from the HandoverForecastConfirm message so that the intermediate routers can change the reservation type (see section 5.4). When receiving the HandoverForecastError message, NAR SHALL check to make sure that the 'B' flag in Common Header is unset and the Code in Router_Notify object is filled with 1, then it MUST extract PAR's IP address and send a new TunnelPath message with the 'B' flag unset to PAR. The MSESSION object and the SENDER_TSPEC object in this message are copied from the HandoverForecastError message. When receiving this TunnelPath message, PAR MUST reply with a TunnelResv message with the 'B' flag unset so that the resource reservation on the correct tunnel can be established. When receiving the HandoverForecastTear message, PAR SHALL check the 'B' flag in Common Header to make sure it is unset, then it MUST extract the MN's formerly falsely predicted CoA and send a TunnelResvTear message with the 'B' flag unset to MN's falsely Yi, et al. Expires August 12, 2007 [Page 31] Internet-Draft Fast RSVP February 2007 predicted subnet (e.g. Error NAR in Figure 7). The MSESSION object in this message is copied from the HandoverForecastTear message. When receiving this message, intermediate routers MUST remove the corresponding Resv State so that the resources reserved in advance on the falsely built tunnel can be released. When MN gets stable in the handover target subnet, it sends a BU message to CN and receives a BA message from CN. After that, the mobile IP module of MN sends a SessionHandover.req to the RSVP module inquiring whether or not to redirect the session data to the new optimized route. The SessionHandover.req MUST contain the (home address, NCoA) pair of the MN. On receiving the SessionHandover.req, the RSVP module of MN MUST try to lookup the matching Path or Resv State according to the home address of MN. Then: 1. If matching Path or Resv State is not found, it means that MN doesn't have any multimedia sessions requiring resource reservation. Then the RSVP module MUST immediately send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of the MN. 2. If matching Path or Resv State is found, it means that MN does have multimedia sessions requiring resource reservation. Then the RSVP module of MN MUST initiate the resource reservation process on the optimized route. The RSVP module of MN generates the Path message with the 'B' flag unset and sends it to CN. The SENDER_TSPEC in the Path message MUST be extracted from the corresponding Path State of the MN. After an intermediate RSVP router on the transmission path receives the Path message, it MUST check whether it already has a corresponding Path State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Path State is found, the RSVP module on the router only needs to update this state; otherwise, it MUST set up the corresponding Path State for the session. In addition, the RSVP module on the router MUST send an AddrNotify.ind to the mobile IP module to indicate MN's home address and NCoA so that the mobile IP module could fill these addresses in "Home Address Option" [2] and the IP header when re-encapsulating the Path message. When the Path message corresponding to the optimized route finally reaches CN, CN SHALL check the 'B' flag in Common Header to make sure it is unset, then the RSVP module of CN replies with the proper Resv message with the 'B' flag unset. After an intermediate RSVP router on the transmission path receives the Resv message, it checks whether it already has the corresponding Resv State of the Yi, et al. Expires August 12, 2007 [Page 32] Internet-Draft Fast RSVP February 2007 session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Resv State is found, the RSVP module on the router only needs to update this state; otherwise, it tries to reserve resources for the session locally and set up the corresponding Resv State. Finally, when the RSVP module of MN receives the Resv message, the resource reservation process on the optimized route successfully completes. Then the RSVP module MUST send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of MN. If the reservation on the optimizated route fails, MN SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation process. The choice of the appropriate algorithm is outside the scope of this document. If the resource reservation on the optimized route fails even after the ROPATH_RETRIES, MN MUST assume that resources are not available on the optimized route. Then session data from MN to CN SHALL be kept transmitting along the old resource reservation path and the resource reservation neighbor tunnel. On receiving the SessionHandover.ind, the mobile IP module of MN MUST redirect the session data to the optimized route and utilize Home Address Option to send packets from then on. 4.3. MN is both the Sender and the Receiver of the Session When the mobile IP module of MN predicts that a handover event from PAR to NAR is imminent, it sends an indication message HandoverForecast.ind to the RSVP module. The HandoverForecast.ind MUST contain the NCoA that will be used by MN in NAR's subnet. Then the RSVP module: 1. extracts the NCoA and the home address from the HandoverForecast.ind and then uses this information to form the Router_Notify object (see section 6.2.2). The Router_Notify object MUST contain the NCoA and Code 0 (see section 6.3.1), 2. extracts the MSESSION object from the corresponding Path or Resv State on MN and fills the "IPv6 DestAddress" field with NCoA to form a new MSESSION object. Note that this new MSESSION object corresponds to the tunnel reservation and MUST NOT affect the MSESSION object in the Path or Resv State on MN. 3. uses the Router_Notify object formed in step 1 and the new MSESSION formed in step 2 to construct a HandoverForecast message and sends it to the current access router PAR. The 'B' flag in the Common Header of the HandoverForecast message MUST be set (see section 5.3) to inform PAR that the reservation is Yi, et al. Expires August 12, 2007 [Page 33] Internet-Draft Fast RSVP February 2007 bidirectional. When PAR receives the HandoverForecast message, it SHALL check the 'B' flag in Common Header to make sure it is set, then its RSVP module: 1. extracts the MN's NCoA and the Code in the Router_Notify object and confirms that the Code is 0 (it means that the router acts as PAR for MN), 2. looks up the matching Path State of the session according to the "IPv6 HomeAddress", "DstPort" and "Protocol Id" in the MSESSION object that can be found in the HandoverForecast message and extracts the SENDER_TSPEC (defines the traffic characteristics of a sender's data flow) [3] contained in the matching Path State, 3. uses the SENDER_TSPEC and the MSESSION (copied from the HandoverForecast message) to construct the TunnelPath message with the 'B' flag set. The TunnelPath message shares the same format with the Path message, except that it has a different "Msg Type" field value (see section 6.3.6) in Common Header to indicate that it corresponds to the tunnel resource reservation and not to the usual resource reservation between the session endpoints. 4. sets up the Path State according to the TunnelPath message and sends it to MN's NCoA to establish the resource reservation tunnel. When intermediate routers receive the TunnelPath message, they set up the Path State for the session according to the content of the message and forward the message to the next hop. Finally, when the router of the handover target subnet (NAR) receives the TunnelPath message, it SHALL check the 'B' flag in Common Header to make sure it is set (If MN is both the sender and receiver of the session, this flag bit is always set), then its RSVP module: 1. sets up the Path State according to content of the TunnelPath message. 2. acts as an RSVP proxy for MN, constructing a TunnelResv message with the 'B' flag unset and then sending it out on the reverse direction to PAR. The TunnelResv message shares the same format with the Resv message, except that it has a different "Msg Type" (see section 6.3.7) field value in Common Header to indicate that it corresponds to the tunnel resource reservation and not to the usual resource reservation between the session endpoints. Yi, et al. Expires August 12, 2007 [Page 34] Internet-Draft Fast RSVP February 2007 3. sets up the Resv State according to the content of the TunnelResv message. 4. extracts the MSESSION object from the TunnelPath message received from PAR and changes the "IPv6 DestAddress" field with PAR's IP address to form a new MSESSION object. This new MSESSION object corresponds to the resource reservation on the reverse direction from NAR to PAR. 5. constructs a new TunnelPath message. This message MUST include the new MSESSION object formed in step 4 as well as the SENDER_TSPEC object copied from the TunnelPath message received from PAR. Note that the 'B' flag in this message MUST be unset. 6. sends the TunnelPath message formed in step 5 to PAR so that the reservation on the reverse direction can be established. When intermediate routers receive the TunnelResv message, they make an advanced resource reservation for the session locally, set up the corresponding Resv State and forward the TunnelResv message to the previous hop. When intermediate routers receive the TunnelPath message corresponding to the resource reservation on the reverse direction, they set up the Path State for the session according to the content of the message and forward the message to the next hop. When PAR receives the TunnelPath message from NAR, it MUST reply a TunnelResv message (including the RESV_CONFIRM object) to NAR. So when the reservation on the reverse direction completes, NAR will reply with a ResvConf message. Finally, when PAR receives both the TunnelResv message and the ResvConf message from NAR, the birectional reservation is successfully established. As a response to HandoverForecast message, PAR SHALL send a HandoverForecastResponse message to MN indicating one of the following possible conditions: 1. If the resource reservation tunnel establishment is successful, PAR MUST construct a HandoverForecastResponse message with Code 0 in the Tunnel_Info object (see section 6.2.3) and send it to MN indicating the successful establishment of the resource reservation tunnel. The MSESSION object in this message is copied from the corresponding Path or Resv State. Yi, et al. Expires August 12, 2007 [Page 35] Internet-Draft Fast RSVP February 2007 2. If the resource reservation tunnel establishment from PAR to NAR fails, PAR SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation procedure. If the resource reservation tunnel establishment from NAR to PAR fails, NAR SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation procedure. The choice of the appropriate algorithm is outside the scope of this document. If the resource reservation on the tunnel from NAR to PAR fails even after TPATH_RETRIES, NAR MUST assume that not enough resources are available on the neighbor tunnel and give up. If the resource reservation on the tunnel from PAR to NAR fails even after TPATH_RETRIES or PAR doesn't receive ResvConf message from NAR within CONF_TIMEOUT, PAR MUST assume that the bidirectional resource reservation tunnel cannot be built, and then PAR SHALL construct a HandoverForecastResponse message with Code 1 in the Tunnel_Info object and send it to MN indicating the failure in building the tunnel. The MSESSION object in this message is the same as that in the original HandoverForecast message from MN. If MN receives a HandoverForecastResponse message with Code 1 or even if it doesn't receive the HandoverForecastResponse message until the handover occurs, it MUST skip the step of resource reservation on the tunnel and process the optimized route resource reservation step described below. After MN hands over to a new subnet, its mobile IP module sends a BU message to PAR, so PAR can redirect the session data to MN's new position. In addition, the mobile IP module of MN MUST check whether the current subnet is the same as the predicted handover target subnet. Then depending on the result of this check, MN MUST take one of the following actions: 1. If the handover prediction is successful, the mobile IP module of MN MUST send a HandoverForecastConfirm.ind to the RSVP module. When the RSVP module of MN receives this indication, it MUST construct a HandoverForecastConfirm message and send it to PAR. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. The 'B' flag in the Common Header of this HandoverForecastConfirm message MUST be set (see section 5.3) to inform PAR that the reservation is bidirectional. 2. If the handover prediction fails, the mobile IP module of MN MUST send a HandoverForecastError.ind to the RSVP module. This indication message MUST contain the current in use CoA and the formerly falsely predicted CoA of MN. When the RSVP module of MN receives this indication message, it MUST construct a Yi, et al. Expires August 12, 2007 [Page 36] Internet-Draft Fast RSVP February 2007 HandoverForecastError message with the Router_Notify object including the current in use CoA as well as Code 0 and then send the message to PAR directly. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. MN MUST also construct a HandoverForecastTear message containing the formerly falsely predicted CoA and send the message to PAR directly. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. The 'B' flag in the Common Header of both the HandoverForecastError and HandoverForecastTear message MUST be set (see section 5.3) to inform PAR the reservation is bidirectional. If the handover event doesn't occur within a certain time, the mobile IP module of MN MUST also construct a HandoverForecastTear message containing the formerly falsely predicted CoA and send the message to PAR directly. The MSESSION object in this message is copied from the corresponding Path or Resv State but with the "IPv6 DestAddress" field changed to MN's NCoA. The 'B' flag in the Common Header of this HandoverForecastTear message MUST be set (see section 5.3) to inform PAR that the reservation is bidirectional. When receiving the HandoverForecastConfirm message, PAR SHALL check the 'B' flag in Common Header to make sure it is set, then it MUST construct a TunnelStateChange message and send it to NAR. The MSESSION object in this message is copied from the HandoverForecastConfirm message and the 'B' flag in the message MUST be set. When NAR receives the TunnelStateChange message, it SHALL check the 'B' flag in Common Header to make sure it is set, then NAR MUST reply with a TunnelStateChange message with the 'B' flag unset so that the intermediate routers on the bidirectional path can change the reservation type (see section 5.4). When receiving the HandoverForecastError message, PAR SHALL check to make sure that the 'B' flag in Common Header is set and the Code in Router_Notify object is filled with 0, then it MUST extract MN's current in use CoA and send a new TunnelPath message with the 'B' flag set to MN's current subnet (e.g. Correct NAR in Figure 8), the MSESSION object in this message is copied from the HandoverForecastError message. When receiving this TunnelPath message, NAR MUST reply with a TunnelResv message. In addition, NAR MUST also send a TunnelPath message on the reverse direction with the same SENDER_TSPEC object but with the 'B' flag unset so that the bidirectional resource reservation on the neighbor tunnel can be established. When receiving the HandoverForecastTear message, PAR SHALL check the Yi, et al. Expires August 12, 2007 [Page 37] Internet-Draft Fast RSVP February 2007 'B' flag in Common Header to make sure it is set, then it MUST extract the MN's formerly falsely predicted CoA and send a TunnelPathTear message with the 'B' flag set to MN's falsely predicted subnet (e.g. Error NAR in Figure 8), the MSESSION object in this message is copied from the HandoverForecastTear message. When receiving this message, intermediate routers MUST remove the corresponding Path State and Resv State. When NAR receivers this message, it SHALL check to make sure that the 'B' flag in Common Header is set, then NAR MUST send a TunnelPathTear message on the reverse direction with the same SENDER_TSPEC object and with the 'B' flag unset so that the bidirectional resources reserved in advance on the falsely built tunnel can be released. When MN is both the receiver and the sender of the session, the resource reservation process on the optimized route can be divided into two parts: the reservation from CN to MN and the reservation from MN to CN. CN is responsible for the former part and MN is responsible for the latter part. When MN gets stable in the handover target subnet, it sends a BU message to CN. After the mobile IP module of CN receives this BU message, in addition to replying with a BA message to MN, the mobile IP module of CN also takes the following actions: 1. extracts MN's home address and NCoA (included in the BU message) and updates the corresponding entry of the MN in its Pending Cache (see section 3.1.) to record the (home address, NCoA) pair. 2. sends a SessionHandover.req to the RSVP module inquiring whether or not to redirect the session data to the new optimized route. The SessionHandover.req MUST contain the (home address, NCoA) pair of MN. On receiving the SessionHandover.req, the RSVP module of CN MUST try to lookup the matching Path or Resv State according to the home address of MN. Then: 1. If matching Path or Resv State is not found, it means that MN doesn't have any multimedia sessions requiring resource reservation. Then the RSVP module MUST immediately send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of the MN. 2. If matching Path or Resv State is found, it means that MN does have multimedia sessions requiring resource reservation. Then the RSVP module of CN MUST initiate the resource reservation process on the optimized route. The RSVP module of CN generates Yi, et al. Expires August 12, 2007 [Page 38] Internet-Draft Fast RSVP February 2007 the Path message with the 'B' flag unset and sends it to MN as well as updates the corresponding Path state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA). The MSESSION object in the Path message MUST contain the NCoA as well as the home address of MN. The SENDER_TSPEC in the Path message MUST be extracted from the corresponding Path State of MN. After an intermediate RSVP router on the transmission path receives the Path message, it MUST check whether it already has the corresponding Path State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Path State is found, the RSVP module on the router only needs to update this state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise, it MUST set up the corresponding Path State for the session. In addition, the RSVP module on the router MUST send an AddrNotify.ind to the mobile IP module to indicate MN's home address and NCoA, so that the mobile IP module could fill these addresses in "Type 2 Routing Header" and the IP header when re- encapsulating the Path message. After the Path message corresponding to the optimized route finally reaches MN, the RSVP module of MN replies with the proper Resv message as well as updates the corresponding Path and Resv state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA). After an intermediate RSVP router on the transmission path receives the Resv message, it checks whether it already has the corresponding Resv State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Resv State is found, the RSVP module on the router only needs to update this state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA); otherwise, it tries to reserve resources for the session locally and set up the corresponding Resv State. Finally, when the RSVP module of CN receives the Resv message and updates the corresponding Resv state (especially updating the IPv6 DestAddr field of the MSESSION with MN's NCoA), the resource reservation process on the optimized route from CN to MN is successfully completed. Then the RSVP module MUST send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of MN. If the reservation on the optimizated route fails, CN SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation process. The choice of the appropriate algorithm is outside the scope of this document. If the resource reservation on the optimized route fails even after the ROPATH_RETRIES, CN MUST assume that resources are not available on the optimized route. Then session data from CN to MN SHALL be kept transmitting along the old resource reservation path and the resource reservation neighbor tunnel. Yi, et al. Expires August 12, 2007 [Page 39] Internet-Draft Fast RSVP February 2007 On receiving the SessionHandover.ind, the mobile IP module of CN MUST update the proper entry in the Binding Cache according to the (home address, NCoA) pair of MN which can be extracted from the SessionHandover.ind, thus session data from CN to MN is redirected to the optimized route from then on. In addition, when MN receives the BA message from CN, the mobile IP module of MN sends a SessionHandover.req to the RSVP module inquiring whether or not to redirect the session data to the new optimized route. The SessionHandover.req MUST contain the (home address, NCoA) pair of the MN. On receiving the SessionHandover.req, the RSVP module of MN MUST try to lookup the matching Path or Resv State according to the home address of MN. Then: 1. If matching Path or Resv State is not found, it means that MN doesn't have any multimedia sessions requiring resource reservation. Then the RSVP module MUST immediately send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of the MN. 2. If matching Path or Resv State is found, it means that MN does have multimedia sessions requiring resource reservation. Then the RSVP module of MN MUST initiate the resource reservation process on the optimized route. The RSVP module of MN generates the Path message with the 'B' flag unset and sends it to CN. The SENDER_TSPEC in the Path message MUST be extracted from the corresponding Path State of the MN. After an intermediate RSVP router on the transmission path receives the Path message, it MUST check whether it already has a corresponding Path State of the session according to the "IPv6 HomeAddress" "DstPort" and "Protocol Id" in the MSESSION object. If the corresponding Path State is found, the RSVP module on the router only needs to update this state; otherwise, it MUST set up the corresponding Path State for the session. In addition, the RSVP module on the router MUST send an AddrNotify.ind to the mobile IP module to indicate MN's home address and NCoA so that the mobile IP module could fill these addresses in "Home Address Option" [2] and the IP header when re-encapsulating the Path message. When the Path message corresponding to the optimized route finally reaches CN, CN SHALL check the 'B' flag in Common Header to make sure it is unset, then the RSVP module of CN replies with the proper Resv message with the 'B' flag unset. After an intermediate RSVP router on the transmission path receives the Resv message, it checks whether it already has the corresponding Resv State of the session according to the "IPv6 HomeAddress" "DstPort" and Yi, et al. Expires August 12, 2007 [Page 40] Internet-Draft Fast RSVP February 2007 "Protocol Id" in the MSESSION object. If the corresponding Resv State is found, the RSVP module on the router only needs to update this state; otherwise, it tries to reserve resources for the session locally and set up the corresponding Resv State. Finally, when the RSVP module of MN receives the Resv message, the resource reservation process on the optimized route successfully completes. Then the RSVP module MUST send a SessionHandover.ind to the mobile IP module. The SessionHandover.ind MUST contain the (home address, NCoA) pair of MN. If the reservation on the optimizated route fails, MN SHOULD use a certain algorithm (e.g., the binary exponential backoff algorithm) to retry the reservation process. The choice of the appropriate algorithm is outside the scope of this document. If the resource reservation on the optimized route fails even after the ROPATH_RETRIES, MN MUST assume that resources are not available on the optimized route. Then session data from MN to CN SHALL be kept transmitting along the old resource reservation path and the resource reservation neighbor tunnel. On receiving the SessionHandover.ind, the mobile IP module of MN MUST redirect the session data to the optimized route and utilize Home Address Option to send packets, thus session data from MN to CN is redirected to the optimized route from then on. Yi, et al. Expires August 12, 2007 [Page 41] Internet-Draft Fast RSVP February 2007 5. Miscellaneous 5.1. RSVP Extensions Capability Exchange The MN expects a HandoverForecastResponse message in response to its HandoverForecast message. If the MN does not receive a HandoverForecastResponse message even after HF_RETRIES, it MUST assume that PAR (NAR) does not support the extensions proposed in this document if MN is the receiver (sender) of the session. Then MN MUST stop re-sending the HandoverForecast message. Even if the access router to which MN sends the HandoverForecast message is capable of the extensions, the other routers on the neighbor tunnel may still be incapable of the extensions proposed in this document. This is indicated to MN through the HandoverForecastResponse message with a Code value of 1. 5.2. Distinguishing Handover Sessions and New Sessions Experience shows that users are more sensitive to terminating an ongoing session compared with blocking a new session. So the extensions proposed in this document introduce a new mechanism to distinguish resource reservation requests from different kinds of sessions, giving handover sessions a higher priority, therefore reducing the forced termination rate of sessions due to handover. When the router receives a reservation request, it SHALL first check whether the request is included in a Resv message or a TunnelResv message, so as to distinguish whether the request is from a new session or a handover session. Then the router SHALL use certain algorithms (eg. Guard Channel) to allocate resources to handover sessions with a higher priority. The allocation algorithm itself is out of the scope of this document. Distinguishing handover sessions and new sessions is a fundamental part of the extensions proposed in this document and MUST be implemented in every access router that supports the extensions. 5.3. Bidirectional Reservation In some types of service (e.g. Voice over IP), bidirectional communication is carried out and therefore, bidirectional reservation is required. However, in traditional RSVP, two distinct sets of message exchanges must be implemented to establish the bidirectional reservation. This is troublesome, and may cause considerable delay in setting up the resource reservation path. The extensions proposed in this document solve this problem by adding a 'B' Flag in the Common Header of the RSVP messages (see section 6.1.). When this bit is set to 1, it indicates that it is a bidirectional reservation; otherwise, it is a unidirectional reservation. When receiving a Path Yi, et al. Expires August 12, 2007 [Page 42] Internet-Draft Fast RSVP February 2007 (or TunnelPath) message, the session endpoint SHOULD check whether the 'B' flag is set. If it is set, in addition to sending a Resv (or TunnelResv) message, the node SHOULD also send a Path (or TunnelPath) message with the same SENDER_TSPEC object and without the 'B' flag set on the reverse direction. The 'B' flag in the Common Header can also be meaningful in the messages such as TunnelPathTear and TunnelStateChange. Similarly, when receiving these messages with the 'B' flag set, the receiver SHOULD consider that the reservation is bidirectional and tear down or change the reservation type on the reverse direction. Bidirectional Reservation is an optional complement of the extensions proposed in this document and the 'B' flag MUST be silently ignored if the node does not recognize it. 5.4. Utilization of Advanced Reservation before Handover The resources reserved in advanced on the tunnel are wasted until the handover occurs. To avoid this problem, the extensions proposed in this document add an 'A' flag in the Common Header of the RSVP messages (see section 6.1.). When receiving a TunnelPath (or TunnelResv) message with the 'A' flag set, the intermediate routers SHOULD create the corresponding Path State (or Resv State) and mark the state as "advanced reservation" indicating that the resources are reserved in advance and can be used temporarily by other applications until the session which makes the reservation indeed hands over to the target subnet. The routers can allocate the advanced reservation to some applications with lower priorities (e.g. the Best Effort application) or some short time packet bursts. How to allocate the advanced reserved resources is out of the scope of this document. When MN moves to the new subnet, it SHALL send a HandoverForecastConfirm message to PAR or NAR, depending on whether MN is the session receiver or the session sender. When receiving the HandoverForecastConfirm message, PAR (NAR) SHOULD check whether the reservation type corresponding to this session is "advanced reservation". If it is, PAR (NAR) MUST send a TunnelStateChange message to NAR (PAR). When intermediate routers receive the TunnelStateChange message, they SHALL change the Path State and Resv State from the "advanced reservation" to "normal reservation", so that the resources SHALL be exclusively used by the handover session of MN from then on. Utilization of Advanced Reservation is an optional complement of the extensions proposed in this document and the 'A' flag MUST be silently ignored if the intermediate routers do not recognize it. Yi, et al. Expires August 12, 2007 [Page 43] Internet-Draft Fast RSVP February 2007 6. New Messages and Objects 6.1. Modified Common Header The extensions proposed in this document introduce two flags in the Common Header of the RSVP message to support bidirectional reservation and the utilization of advanced reservation before the handover. If the session endpoint wants to establish bidirectional reservation, it can set the 'B' flag in the Common Header of the Path (TunnelPath) message. When receiving a Path (TunnelPath) message with the B flag set, in addition to replying with the (TunnelResv) message, the session endpoint SHALL send a Path (TunnelPath) message in the reverse direction. The 'B' flag MAY also be set in the Common Header of HandoverForecast, HandoverForecastConfirm, HandoverForecastError, HandoverForecastTear, TunnelStateChange and TunnelPathTear messages to indicate the bidirectional reservation. If the access router decides that the advanced resource reservation on the tunnel can be temporarily utilized by other sessions before MN's handover event, it can set the A flag in the Common Header of the TunnelPath message and then the intermediate routers SHOULD mark the reservation state as "advanced reservation". Yi, et al. Expires August 12, 2007 [Page 44] Internet-Draft Fast RSVP February 2007 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Msg Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Send_TTL |B|A|Reserved | RSVP Length | +-------------+-------------+-------------+-------------+ Vers See RFC 2205 [1]. Flags See RFC 2205 [1]. Msg Type See RFC 2205 [1]. RSVP Checksum See RFC 2205 [1]. Send_TTL See RFC 2205 [1]. B flag The B flag is set if the reservation is a bidirectional reservation. A flag The A flag is set if the reservation is an advanced reservation. RSVP Length See RFC 2205 [1]. Figure 12: Format of Common Header 6.2. New Objects 6.2.1. New MSESSION Object The extensions proposed in this document define a new MSESSION object to replace the SESSION object. Compared with the SESSION object, MSESSION adds "IPv6 HomeAddress" field in the object. The "IPv6 HomeAddress" field is filled with the MN's home address and its value is constant during handover, so we can utilize it to label the session. In the mobile environment, the RSVP router MUST label a session based on the content of the MSESSION and set up the corresponding Path State and Resv State accordingly. Yi, et al. Expires August 12, 2007 [Page 45] Internet-Draft Fast RSVP February 2007 Class = To be allocated by IANA C-Type = To be allocated by IANA 0 1 2 3 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Protocol ID | Flags | DstPort | +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 HomeAddress (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 DestAddress The IP unicast or multicast care of address of the session. This field must be non-zero and may change during the life time of the session. Protocol ID See RFC 2205 [1]. Flags See RFC 2205 [1]. DstPort See RFC 2205 [1]. IPv6 HomeAddress The IP unicast or multicast home address of the session. This field must be non-zero and remain constant during the life time of the session. Figure 13: Format of MSESSION object 6.2.2. New Router_Notify Object The extensions proposed in this document define a new Router_Notify object. This object is included in the HandoverForecast message, HandoverForecastError message and HandoverForecastTear message. The Yi, et al. Expires August 12, 2007 [Page 46] Internet-Draft Fast RSVP February 2007 Code in this object is to notify the access router whether it should act as PAR or NAR. If MN is the session receiver, the tunnel endpoint's IP address is MN's NCoA and if MN is the session sender, the tunnel endpoint's IP address is PAR's IP address. Class = To be allocated by IANA C-Type = To be allocated by IANA 0 1 2 3 +-------------+-------------+-------------+-------------+ | | + + | | + TunnelEndPointAddr (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | Code | Reserved | +-------------+-------------+-------------+-------------+ TunnelEndPointAddr The IP address of the tunnel endpoint. Code 0 The access router should act as PAR. 1 The access router should act as NAR. Reserved See RFC 2205 [1]. Figure 14: Format of Router_Notify object 6.2.3. New Tunnel_Info Object The extensions proposed in this document define a new Tunnel_Info object. This object is included in the HandoverForecastResponse message to indicate whether the resource reservation tunnel is established successfully. Yi, et al. Expires August 12, 2007 [Page 47] Internet-Draft Fast RSVP February 2007 Class = To be allocated by IANA C-Type = To be allocated by IANA 0 1 2 3 +-------------+-------------+-------------+-------------+ | Tunnel Code | Reserved | +-------------+-------------+-------------+-------------+ Tunnel Code 0 Establishment of the RSVP tunnel is successful. 1 Establishment of the RSVP tunnel fails. Reserved See RFC 2205 [1]. Figure 15: Format of Tunnel_Info object 6.3. New Messages 6.3.1. HandoverForecast Message When receiving the HandoverForecast.ind from the mobile IP module, the RSVP module of MN would send a HandoverForecast message to PAR (NAR) to indicate a handover event. If MN is the session receiver, the Router_Notify object in the HandoverForecast message MUST contain the care-of address that will be used in the predicted handover target (NCoA) as well as Code 0. If MN is the session sender, the Router_Notify object in the HandoverForecast message MUST contain the PAR's IP address as well as Code 1. The information contained in HandoverForecast message will be used by PAR (NAR) to establish the resource reservation tunnel. If MN is the sender of the session, the sender descriptor object MUST also be contained into this message. If MN is the receiver of the session or MN is both the sender and receiver of the session, the sender descriptor object need not be included. The Msg Type of the HandoverForecast message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] [] ::= Yi, et al. Expires August 12, 2007 [Page 48] Internet-Draft Fast RSVP February 2007 6.3.2. HandoverForecastResponse Message No matter weather the establishment of the resource reservation tunnel is successful or not, PAR or NAR MUST send a HandoverForecastResponse message to MN. The new Tunnel_Info object in the HandoverForecastResponse message contains a Tunnel Code to specify the result of the resource reservation tunnel establishment (we only define Code 0 and 1 right now). The Msg Type of the HandoverForecastResponse message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] ::= 6.3.3. HandoverForecastConfirm Message When receiving the HandoverForecastConfirm.ind from the mobile IP module, the RSVP module of MN MUST send a HandoverForecastConfirm message to PAR or NAR, depending on whether MN is the session receiver or session sender. The Msg Type of the HandoverForecastComfirm message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] 6.3.4. TunnelStateChange Message When receiving the HandoverForecastConfirm message, PAR (NAR) MUST send a TunnelStateChange message to NAR (PAR) so that the intermediate routers can change the reservation type form "advanced reservation" to "normal reservation". Msg Type = To be allocated by IANA ::= [] Yi, et al. Expires August 12, 2007 [Page 49] Internet-Draft Fast RSVP February 2007 6.3.5. HandoverForecastError Message When receiving the HandoverForecastError.ind from the mobile IP module, the RSVP module of MN MUST send a HandoverForecastError message to PAR or NAR, depending on whether MN is the session receiver or session sender. If MN is the session receiver, the Router_Notify object in the HandoverForecast message MUST contain the current in use care-of address of MN as well as Code 0. If MN is the session sender, the Router_Notify object in the HandoverForecast message MUST contain the PAR's IP address as well as Code 1. The information contained in HandoverForecastError messge will be used by PAR (NAR) to re-establish the resource reservation tunnel. If MN is the sender of the session, the sender descriptor object MUST also be contained in this message. If MN is the receiver of the session or MN is both the sender and receiver of the session, the sender descriptor object need not be included. The Msg Type of the HandoverForecastError message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] [] ::= 6.3.6. HandoverForecastTear When receiving the HandoverForecastError.ind from the mobile IP module, the RSVP module of MN MUST send a HandoverForecastTear message to PAR, and then PAR can release the resources reserved in advance on the falsely built tunnel. The TunnelEndPointAddr field in the Router_Notify object MUST contain MN's formerly falsely predicted CoA and the Code field MUST be ignored. The Msg Type of the HandoverForecastTear message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] [] ::= Yi, et al. Expires August 12, 2007 [Page 50] Internet-Draft Fast RSVP February 2007 6.3.7. TunnelPath Message TunnelPath message is sent for each session on MN that requests the establishment of a resource reservation tunnel. The MSESSION object includes MN's home address, this address together with the "DstPort" and "Protocol Id" can be used to uniquely label a session in the mobile environment. If the bidirectional reservation is required, the 'B' flag in the Common Header MUST be set and if the "advanced reservation" type is supported, the 'A' flag in the Common Header SHOULD be set. The Msg Type of the TunnelPath message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] [...] [] 6.3.8. TunnelResv Message TunnelResv message is sent for each session on MN that requests the establishment of a resource reservation tunnel. If the "advanced reservation" type is supported, the 'A' flag in the Common Header SHOULD be set. The Msg Type of the TunnelResv message needs to be allocated by IANA. Msg Type = To be allocated by IANA ::= [] [] [] [...]