Mobile IP Working Group Andrea De Carolis INTERNET DRAFT Luca Dell'Uomo Fabio Pugini Document: draft-decarolis-qoshandover-02.txt University of Category: Informational Rome "La Sapienza" April 2000 QoS-Aware handover for Mobile IP: Secondary Home Agent Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or 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. 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. Abstract This document specifies an extension to the Mobile IPv6 [1] Protocol that enables a Mobile Node to perform a particular kind of handover called QoS-Aware handover. This kind of handover allows the Mobile Node to change the current point of attachment to the Internet without loosing the perceived QoS. This extension is part of a larger effort toward the integration of Mobility and QoS over IP. In this document a new mobile agent, the Secondary Home Agent (SHA), is introduced. The SHA allows the mobile node (MN) to establish a new QoS reservation before dropping the old one. This is realised without reserving resources for both the new and the old data path. We will show that the introduction of this new network entity is useful to maintain the perceived QoS during the handover and it can avoid some routing inefficiencies that MAY arise during this phase. The amount of the improvement with respect to a plain Mobile IPv6 architecture is also taken into account. It is important to remark that no modifications need to be applied to the correspondent nodes in order to support the proposed way of operation. De Carolis Informational - September 2001 1 QoS-Aware handover for Mobile IP April 2001 Table Of Contents Status of this Memo..........................................1 Abstract.....................................................1 Table Of Contents............................................2 1.Assumptions................................................3 2. Conventions used in this document.........................4 3. Introduction..............................................5 3.1 Non QoS-Aware Approach...................................7 3.2 QoS Aware Approach.......................................7 3.3 SHA operations for the uplink connections................9 3.4 SHA operations for the downlink connections.............10 4. Definition of the QoS Service:...........................11 4.1 Uplink QoS-Handover Procedure...........................12 4.2 Downlink QoS-Handover Procedure.........................13 5. Integrated Support for QoS and Mobility..................15 5.1 First Connection........................................15 5.2 Forced handover.........................................16 5.3 QoS-Aware HandOver Procedure (HOP procedure)............17 5.4 Resource Reservation on the new link....................21 5.4.1 Uplink Reservation....................................21 5.4.2 Downlink Reservation..................................24 6. Extensions concerning the Mobile IP Protocol.............25 7. Extensions concerning the RSVP Protocol..................25 8. Security Considerations, AAA.............................25 9. References...............................................26 10. Acknowledgments.........................................27 11. Author's Addresses......................................27 De Carolis Informational - September 2001 2 QoS-Aware handover for Mobile IP April 2001 1.Assumptions In the following we assume that the RSVP signalling protocol [RFC2205] is supported by both the Mobile Node and the Access Routers and that it is used in order to setup the resource reservations and guarantee the desired IP-QoS level. We also assume that wired or wireless data link layers are able to support the same QoS levels, or at least to signal to the RSVP modules that a certain reservation is not possible. Further background assumptions of this work are: A mobile node can choose to access the Internet through more than one link layer technology at the same time. This means, for example, that in case of a wireless access network made up of different access technologies (like UMTS/GPRS and WLAN IEEE 802.11), the coverage areas MUST considerably overlap in order to achieve a QoS Handover. For a successful completion of the QoS-aware handover, the router hosting the SHA MUST belong to both the new and the old path connecting the CN to the MN. The last condition can be achieved in two different ways: When the SHA will be placed in the GMA (in case of use of Regionalised Registration [11] option) and in the MAP (in case of Hierarchical Mobile IP [10] option) When the above condition is satisfied by means of the routing algorithm and by the particular topology of the network. Furthermore to avoid modifications to the RSVP protocol that would consider two PATH messages coming from different links as belonging to the same session, the SHA should be placed at the path crossover Router (i.e. before another RSVP router do merge the flows). We will show that this assumption is important for the correct functioning of the QoS-aware handover of downlink connections. In this scenario it COULD be possible for a Mobile Node to perform a handover because the link-layer connectivity has dropped, but also to take handover decisions depending on QoS needs, Geographical Location or other issues. Performing an handover for the latter reasons makes sense only if during the handover the IP QoS perceived on the old link is maintained. The proposed solution to reach this goal is to test the availability and QoS performance of the new link before dropping the old one, that is to verify the resource availability along the data path with the RSVP protocol PATH/RESV messages and, if the connection De Carolis Informational - September 2001 3 QoS-Aware handover for Mobile IP April 2001 is accepted, reserve the needed resources before completing the handover sequence. On the other hand when the drop in the QoS during the handover cannot be avoided, then the handover SHOULD be performed only for link-layer QoS considerations (for example when a fading of the radio signal raises the Bit Error Rate). 2. Conventions used in this document ISP - Internet Service Provider: An entity that provides the following services: IP Access, AAA, Billing, Security and a temporary IP address. SAP - Service Access Point: It represents a particular interface between two layers of the network architecture where a particular service is available. SLA - Service Level Agreement: This term refers to a particular agreement between ISPs about QoS policies between their networks. IP-Level handover: The Mobile IP handover, needed in order to take packets addressed to the Mobile Node Home address up to its actual point of attachment to the Internet (represented by a CoA). Link-Layer-Level handover: The switch between interfaces, driven by the Mobile Node. We want to underline the difference between IP-Level and Link-Layer- Level handover: The former involves a change in the Care-of Address but not necessarily a change in the type of access. An example is when a Laptop is unplugged from a LAN and plugged in again, for example, in a different building. The latter basically involves a switch between two physical links available at the same time for the node, for example the handover from a UMTS interface to a WLAN 802.11 one. In order to integrate QoS and Mobility it is important to specify some terms and aspects related to the handover: Forced handover It occurs when there is a drop of the QoS in the link layer (for example due to interference or fading that occurs in a wireless radio signal, or to the unplugging of the LAN connector). In this case it is not possible to support IP QoS or IP connectivity on the current link any De Carolis Informational - September 2001 4 QoS-Aware handover for Mobile IP April 2001 longer. In this case a handover procedure is started in order to connect to a new link, get a new CoA and so on. QoS-Aware handover It MAY occur for example when a "Better" (for example with respect to QoS performances or according to a precedence list of access interfaces) link becomes available. In this case the Mobility Support Module of the Operating System installed inside the Mobile Node, SHOULD verify the possibility to start an handover for those active sessions that require QoS. If a large bandwidth demanding session is still active, and it cannot be served by the new Link with the same QoS level that it is perceiving on the old link, a QoS-Aware handover SHOULD NOT be performed. On the other hand if the QoS available on the new link is compatible with the current needs of the application, a QoS-Aware handover COULD be performed. Access Router It is a router that sends in downlink the Router Advertisements and provides IP connectivity towards the Mobile nodes Access Segment It is an access technology that allows a Mobile Node to connect at data link layer to the access router 3. Introduction Let's assume that a Mobile Node is connected to a certain Access Router AR1 by means of a wireless connection. This Access Router is the Mobile NodeÆs fixed Point of Attachment to the Internet. This AR is currently supporting a certain number of QoS Sessions belonging to the Mobile Node. After that the Mobile Node has performed some measurements on the beacon signals received from base station controlled by AR1 and AR2, it decides to move all the active QoS Sessions on the wireless link towards the second Access Router AR2. We assume that the Mobile Node MUST be able to activate the wireless link towards the AR2. The situation is shown in Fig.1. We assume that the QoS architecture is that of the Integrated Service framework [RFC1633]. Thus, we will assume that QoS is provided by means of explicit per-flow resource reservations that are installed with RSVP signalling protocol. Guaranteed Service is a clear example of such a strategy. Further work is being carried out to consider also architectures based on Differentiated Service [RFC 2474, 2475] approach in the Access Network. De Carolis Informational - September 2001 5 QoS-Aware handover for Mobile IP April 2001 We are also supposing that the Mobile Node is involved in a unicast communication with the correspondent nodes. In this context, before the mobile node could operate the handover of its active sessions with QoS, it checks the availability of resources on the new link toward which it is moving. If the new link is able to uphold those sessions then the handover is performed. Otherwise the current connection with the first AR is maintained. +------------+ +------------+ | Access | < | Home Agent | | Router |---- > ---+ +------------+ /| | < \ * * * * / / | AR1 | \ * * / / +------------+ \ * * / +------------+ * * +----+ | | * IP * | | | Secondary | * * +---------------+ | MN | | Home |-* Network *-| Correspondent | | | | Agent | * * | Node | | |\ | | * * +---------------+ +----+ \ +------------+ * * \ / * * \ +------------+ / * * * \ | Access | < / \| Router |-- > -+ | | < | AR2 | +------------+ Fig.1. The basic Secondary Home Agent architecture This way of operation is called QoS-Aware handover. It is different by a common handover because it is not triggered by events related to radio link failures (like in the case of Forced handover). We briefly summarise the RSVP way of operation: The sender end-system issues a PATH message towards the receiver end-system. The PATH message is modified by each router on the path towards the receiver in order to insert particular parameters that will be used by the RSVP module (of the receiver host) in order to determine the needed resources (these are the error terms parameters). Moreover in each RSVP-capable router, the PATH message is used to install a soft state entry that is necessary to provide QoS to the requesting flow. This soft state includes the flow identifiers and the previous router address from which the PATH message was received. In this way it is De Carolis Informational - September 2001 6 QoS-Aware handover for Mobile IP April 2001 possible to correctly route the RESV messages that are the signalling messages needed to reserve resources that are estimated by the receiver and to refresh the soft state in each RSVP-capable router along the path from the receiver to the source. This is a simple solution to have the reverse path identical to the direct one. If the packet is not dropped by any of the reverse path routers than the connection is accepted. The above mentioned operations imply that the PATH message is associated to the path followed by the packets. This means that, if the path changes after that an handover from AR1 to AR2 is performed, then also the error terms parameters included in the PATH message received by the destination end-system will change. Thus, also the amount of resources that has been reserved to a particular flow on the old path will probably change after the route change. Then if we want to maintain the QoS perceived by a flow after a route change, it is necessary to test resource availability on the new link before we perform the handover, we need to send a PATH message through the new link before making the real handover. 3.1 Non QoS-Aware Approach The current approach to the Mobility does not consider the possibility to send PATH messages on the new link, that Mobile node built up with the AR2, before the handover is completed. More in detail, as far as uplink connections are concerned, the mobile node has to complete the handover in order to get a new Care-of Address and correctly update the bindings both at its Home Agent and at its correspondent node. After the completion of the location update procedure, the Mobile Node can use the newly acquired Care-of Address as source address in the new PATH message sent through AR2. On the other side, for the downlink sessions, the correspondent node keeps issuing PATH messages towards the known Care-of Address on the old link towards AR1 until it receives a new binding update, i.e. until the handover from AR1 to AR2 has been completed. Thus a QoS connection denial (i.e. a RESVERR message [RFC 2205] sent on the new path) could happen after the old link has been dropped. This implies that the QoS level that the Mobile Node was perceiving on the old path through AR1, cannot be guaranteed on the new link after that an handover occurred. 3.2 QoS Aware Approach LetÆs first consider uplink sessions. In our proposal when a handover for uplink sessions is initiated, the mobile node sends PATH messages on both the old and new link: on the former to maintain the soft state reservations, on the latter to test the resource availability. The two PATH messages will meet in a node, that is shown in Fig.1, where the Secondary Home Agent (SHA) De Carolis Informational - September 2001 7 QoS-Aware handover for Mobile IP April 2001 functionality is installed. This is a merging node for RSVP signalling messages and for traffic packets. In order to avoid a double resource reservation along the rest of the path, i.e. from the SHA to the Correspondent node, the SHA has to be aware of the particular handover that is undergoing. In our proposal the handover is always Mobile Node driven, i.e. the Mobile Node sends a signalling message called handover Initiation Messages (HIM) to the SHA in order to start a QoS-Aware handover. Then the Mobile Node can send PATH messages towards AR1 and AR2. Upon receiving the PATH messages from both the old and the new link, the SHA can recognise them as belonging to the same session for which the Mobile Node asked a QoS-aware handover with the HIM message. Thus the SHA will forward only one PATH message towards the correspondent node. The SHA chooses to forward the PATH message that carries the worst error terms, i.e. the PATH message that will generate, in the receiver, the larger bandwidth R to be reserved along the data path; the other PATH message is not forwarded. The chosen PATH message can be the one from the old link or the one from the new link indifferently. It should be noted that the PATH messages SHOULD not meet before the SHA, because intermediate routers (unaware of QoS handover Approach) could assume that a change has occurred in the routing. The two PATH messages can be distinguished at the SHA because the old and the new path towards the receiver are different. Then in the PATH message the previous router field is different. The SHA forward towards destination only one PATH message: the one that has the worst deviation parameters from the fluidic model. When this message arrives to the receiver end-system, that is the Correspondent Node the bandwidth R to be requested is evaluated according to the Parekh and Gallagher formulas [23]. Then R is inserted in a RESV message that is sent back along the path. We define Rn as the bandwidth that has to be reserved on the new path in order to guarantee the desired QoS level (that is the same that the Mobile Node was perceiving on the old path) while Ro is the amount of bandwidth that was previously reserved on the old path to obtain a certain QoS level. Then it can be easily seen that the following relationship holds: R=max(Ro,Rn) This choice is made because we donÆt want that the old reservation along the old path to break: in other terms we want to be able to come back to the old reservation in case that the handover on the new link would fail for any reason. De Carolis Informational - September 2001 8 QoS-Aware handover for Mobile IP April 2001 This relationship implies that during the QoS-aware handover, a bandwidth R can be reserved which is larger than the necessary: this leads to a temporary reserved resource waste. This waste, due to the forwarding of the PATH message with worst case parameters, could happen when: 1) Ro>Rn and the handover is completed (that is the mobile node switches on the new link). In this case the reserved bandwidth on the new link is less than the old bandwidth previously reserved on the old link, but the old bandwidth has been reserved anyway also on the new link. 2) Ro fcSTEP4 | First connection steps +----------+---------+ | / \ Is previous SHA in the set of SHAs / \ associated with the new AR ? +----<-------+ ? +-------->--------+ | Y \ / N +-------+-----------------+ | \ / | +-----+-----+ | Binding +-----+-----+ + | | fcSTEP5 | | Update | fhSTEPa | | +-----+-----+ fhSTEPb | to SHA +-----+-----+ | +-----+-----+ | | | | fcSTEP6 | | | | +-----+-----+ | | +-------+-----------------+ | +-----------+ | +-------->| END |<-------------+ +-----------+ Forced Handover concluded! fc : first connection ; fh : forced handover ; Fig.3. Forced Handover procedure 5.3 QoS-Aware HandOver Procedure (HOP procedure) When the link-layer connectivity on the current Interface is still good (i.e. is not under the threshold that would trigger an handover for link disruption), the Mobile Node MAY start the HOP Procedure. This procedure COULD be triggered, for example, when the Mobile Node detects, according with a certain internal algorithm, that it is using a data link that is no more adequate to the applications needs or that is largely under exploited. It should be noted that the connections towards the old AR1 in Fig.1 (and also the previously reserved resources on the involved links) are not released until the handover procedure is completed. De Carolis Informational - September 2001 17 QoS-Aware handover for Mobile IP April 2001 The following steps are performed: 0). (hopSTEP0): A timer is started to limit the procedure duration. 1). (hopSTEP1): Is the aggregation of the steps fcSTEP0 (the current Link identifier and the actual needs of bandwidth are passed to a segment selection algorithm together with the access- routers list associated with the current SHA), fcSTEP1, fcSTEP2, fcSTEP3, and fcSTEP4 2). (hopSTEP2): the Mobile node examine the list of SHA associated with the new Access Router. This list is attached to router advertisement or to DHCP message in case the IPv6 CoA is obtained from DHCP server. If the current SHA is not in the above list the QoS-handover fails. Future HOP extensions can connect to this point, for example for the integration with hierarchical registration. 3). (hopSTEP3): If the current SHA is in the list then the HOP procedure goes on, individuating each RSVP Session that is in active state on the Mobile Node (both Uplink and Downlink MUST be taken into consideration). Further extensions of the HOP protocol could modify the last statement limiting the action of the QoS-Aware handover to a sub-set of connections. 4). (hopSTEP4): For each session from the hopSTEP3, the Mobile Node sends to the SHA a QoS-Aware handover Initiation Message (HIM). 5). (hopSTEP5): This step is the most important one. It is supported by a distributed procedure, and is described in detail in the paragraph 5.4. In this step, for each session individuated at the hopSTEP3, QoS availability on the new link is tested and both link-layer resources and IP-layer resources are reserved. De Carolis Informational - September 2001 18 QoS-Aware handover for Mobile IP April 2001 6). (hopSTEP6): If the hopSTEP5 does not fail, the Mobile Node sends to the SHA a Binding Update (Mobile IP handover).Each connection is automatically moved on the new link and the resources allocated on the previous link are released (The SHA for the Downlink and the MN for the Uplink issue an RSVP PATHTEAR Message. It has to be remarked that the SHA MUST NOT forward the received RSVP PATHTEAR message received by the Mobile node). 7). (hopSTEP7): The Mobile node communicates to the SHA the successful completion of the QoS-Aware handover by means of an handover Completion Message (HCM). 8). (hopSTEP8): The resources used at link layer for supporting QoS on the old link are released using appropriate signalling messages on the old link. A flow chart of the HOP procedure is shown in Fig. 4. De Carolis Informational - September 2001 19 QoS-Aware handover for Mobile IP April 2001 +-----------------+ | START | +--------+--------+ +--------+--------+ | hopSTEP0 | a timeout timer is started +--------+--------+ +--------+-------------------------------------+ | | +-------------------+| Select the new | +--------------->| fcSTEP0 & fcSTEP1 || interface for example | +---------+---------+| WLAN1 | +---------+---------+| Connection setup, | hopSTEP1 | fcSTEP2 & fcSTEP3 || CoA Generation | +---------+---------+| | +---------+---------+| | +---------<------| fcSTEP4 || Get the SHA list | | +---------+---------+| +--------+-------------------------------------+ +--------+--------+ | hopSTEP2 | check the new SHA list for the presence of the +--------+--------+ current SHA | / \ the current SHA is / ? \ not present in the list \ /--------------------------------------> QoS handover fails! \ / | the current SHA is present in the list +--------+--------+ | hopSTEP3 | list of active QoS Sessions +--------+--------+ (uplink and downlink) +--------+--------+ | hopSTEP4 | send HIM messages +--------+--------+ +--------+--------+ start uplink and downlink | hopSTEP5 | distributed QoS handover management procedures +--------+--------+ +--------+--------+ | hopSTEP6 | send Binding Updates messages +--------+--------+ +--------+--------+ | hopSTEP7 | send HCM message +--------+--------+ +--------+--------+ | hopSTEP8 | release resources on the old link +--------+--------+ +--------+--------+ | END | QoS handover completed +-----------------+ fc : first connection ; hop : handover procedure; Fig.4. QoS-Aware HandOver Procedure De Carolis Informational - September 2001 20 QoS-Aware handover for Mobile IP April 2001 5.4 Resource Reservation on the new link We now go in further detail into the of resources reservation on the new link. For the sake of simplicity, we separate the procedure for the Uplink and for the Downlink. 5.4.1 Uplink Reservation If the Time Out set at the beginning of the QoS-handover is exceeded while waiting for all QoS connections to be transferred on the new link, then the QoS-handover Fails. 0). (rrSTEP0): If new RESV message arrives to the mobile node from the old link, indicating that there is a new active reservation for an outgoing flow, then the list of active QoS-flows, that has been generated in hopSTEP3, is extended, and a new HIM message for the new installed flow is sent to the SHA. The MN selects the next uplink session in the list generated in the hopSTEP3. 1). (rrSTEP1): The MN sends PATH messages related with the selected session on both the new and the old link. When using OPWA reservation style, each PATH message MUST be properly adapted to the underlying link layer, in particular the right link Latency Time and the Error Terms MUST be added to compute the new overall path Error Terms. 2). (rrSTEP2): When the SHA receives the PATH messages from the MN, worst case is selected with an external algorithm which select the worst case PATH message 3). (rrSTEP3): The SHA forwards only the worst case PATH message. 4). (rrSTEP4): As long as the Sender template used in the two PATH messages is the same, the SHA, that knows that a QoS handover is in progress because it received the HIM message from Mobile node, not only considers the last received PATH message (normal behaviour for plain RSVP router) but operates a worst case merging. After this selection, a single PATH message is forwarded towards the receiver, on the path that is not object of handover. This PATH message could carry information about the new link, and, once received, it could generate a RESV message with De Carolis Informational - September 2001 21 QoS-Aware handover for Mobile IP April 2001 a larger bandwidth demand. Even if the network discards this message because no resources are available, the previous installed soft-state, according to the RSVP protocol, is not cleared since PATH messages, issued by the mobile node on the old link, maintain the soft-state. Then, even if the QoS-HandOver Procedure fails to reserve resources for the new link, all the applications continue to see the expected QoS on the previous link. When the SHA receives the RESV messages from the Correspondent Node, and the sender description corresponds to a session that is involved in a QoS-Aware handover, it forwards the RESV message only on the new link, otherwise it sends the RESV message only to the old link. The set of sessions generated at hopSTEP3 COULD be extended with the new session only after the RESV message arrives to the Mobile node. While the Mobile node is waiting for RESV messages for a certain session it continues to send PATH messages. From this protocol step on, the HandOver Procedure executed at the Mobile node, can run in background and continue to transfer another session on the new link, repeating all the shown steps, starting from rrSTEP0. 5). (rrSTEP5): When the Mobile node receives RESV message on the new link, it performs a Link-Layer QoS reservation for the uplink 6). (rrSTEP6): If the Link-layer QoS reservation fails the QoS- Aware handover fails 7). (rrSTEP7): In the case that the link-layer QoS reservation is successful, and this is the last session in the set generated at hopSTEP3, then the protocol will continue with hopSTEP6. If this is not the last session in the set from hopSTEP3 then the procedure will continue with rrSTEP0. De Carolis Informational - September 2001 22 QoS-Aware handover for Mobile IP April 2001 +-----------------+ | START | a timeout timer is started +--------+--------+ +------------>+ | / \ timeout | check / ? \-----------------------------> QoS handover fails! | timer \ / | \ / | + no timeout | +--------+--------+ | | rrSTEP0 | Select a QoS Session | +--------+--------+ | +--------+--------+ | | rrSTEP1 | receive 2 PATH messages | +--------+--------+ | +--------+--------+ | | rrSTEP2 | select 1 PATH message | +--------+--------+ | +--------+--------+ | | rrSTEP3 | forward the PATH message | +--------+--------+ | +--------+--------+ wait and receive the RESV message, while | | rrSTEP4 | waiting another session can be processed | +--------+--------+ | +--------+--------+ | | rrSTEP5 | try to reserve resources | +--------+--------+ | / \ few resources | / ? \-------------------------> QoS handover fails! | \ / | \ / | | resources reserved correctly | there are / \ | other / ? \ +---------- \ / sessions \ / | last session +--------+--------+ | END | QoS handover completed for +-----------------+ the Uplink Fig.5. Resource Reservation procedure on the new link De Carolis Informational - September 2001 23 QoS-Aware handover for Mobile IP April 2001 5.4.2 Downlink Reservation If the Time Out set for the QoS-handover is exceeded while waiting, then the QoS-handover Fails. If new PATH messages arrive to the MN from the old link then the set of sessions generated at hopSTEP3 is extended and a new handover Initiation Message is sent to the SHA in order to describe the new sessions. The MN selects the next Downlink session in the set from hopSTEP3 (rrSTEP0). The SHA examines each PATH message, when it detects a Sender Description conformant to the one specified in a HIM message, it duplicates the PATH message and forwards them both on the new and the old link. Each AR has the task to update each PATH message in such a way that (once it is received at the MN) it will report the OPWA parameters corresponding to the link layer it is going to use. When the MN receives two PATH messages it propagates to the standard RSVP module (or to the destination) only the worst case one (as explained for the Uplink). At Receiver side the Application (or the Operating System) computes the needed bandwidth to be reserved, inserts this information in a new RESV message and forwards it to the MN routing module. If the RESV message generated by the applications does not contain a ResvConf reservation confirm object, this is added. The MN forwards the RESV packet only on the new link (the packets that continue to arrive from the old link still perceive the expected QoS because the soft state are maintained by the PATH messages issued by the SHA). If the RESV message is discarded by the network, a ResvError Message is propagated back to the SHA and to the MN. The MN does not propagate the ResvError to the applications, but it sends again the PATH message of the first link to the applications that answer with a RESV message that is propagated on the old link. The QoS-Aware handover Fails (but the old link is still supporting the QoS sessions). A timer is set to wait for the ResvConf message, the QoS-Aware handover Fails when the timeout is triggered by the timer. If ResvConf message arrives at the Mobile Node and this is the last element of the session set from hopSTEP3, the Mobile Node first performs hopSTEPS6 and hopSTEPS7, then it sends to the application the ResvConf message, finally it performs hopSTEPS8. If there are other elements in the set from hopSTEP3, then the protocol goes back to rrSTEP0. De Carolis Informational - September 2001 24 QoS-Aware handover for Mobile IP April 2001 6. Extensions concerning the Mobile IP Protocol Mobile Node The Mobile Node needs to solicit SHA advertisements every time it connects to an AR. The format of the packets used for this exchange of information is not specified in this work. The Mobile Node MUST support the HOP protocol, and be conformant to the background assumptions (see section 1). Secondary Home Agent It needs to extend Regionalised Registration with the integration of SHA functionality. It MUST be able to manage the QoS as required by the HOP procedure. Access Routers The ARs need to be extended in order to exchange information about the SHA they are connected to. 7. Extensions concerning the RSVP Protocol No extension to the RSVP protocol is needed to perform QoS-aware handover when SHA are adopted. Hence this is a remarkable point of our proposal. 8. Security Considerations, AAA In this proposal no further AAA considerations are needed since QoS- aware handover does not introduce modifications in the actions needed for the handover, but it simply modifies their sequence. Then the security considerations of Mobile IP apply. De Carolis Informational - September 2001 25 QoS-Aware handover for Mobile IP April 2001 9. References [1] P. Conforto, G. Losquadro, C. Tocci, N. Blefari-Melazzi, A. De Carolis, F. Di Cola, P.M.L. Chan, Y.F. Hu: "Mobility Management in the SUITED/GMBS Multi-Segment System", Mobile Summit 2000 [2] P. White: "RSVP and integrated services in the Internet: a tutorial", IEEE Communications magazine, Vol. 35, N. 5, May 1997. [3] Charles E. Perkins: "Mobile IP", Communications Magazine, May Æ97, pp.84-99. [4] X.Xiao, L.M.Ni: "Internet QoS: a big picture", IEEE Network, Mach/April 1999, pag.8-18. [5] A. Parekh and R. Gallagher, "A Generalized Processor Sharing Approach to Flow Control -- The Single Node Case," IEEE/ACM Trans. Networking, vol. 1, no. 3, 1993, pp. 356-57. [6] H. Soliman, C. Castelluccia, K. Malki, L. Bellier: "Hierarchical MIPv6 mobility management", IETF-DRAFT, Nov 30, 2000 (work in progress) [7] R. Hinden, S. Deering: "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995 [8] D. Johnson, C. Perkins: "Mobility Support in IPv6", IETF-DRAFT, (work in progress) [9] C. Castelluccia, L. Bellier: "Mobile Networks Support in Mobile IPv6", IETF-DRAFT, (work in progress) [10] K. El-Malki, H. Soliman, C. Castelluccia, L. Bellier: "Hierarchical MIPv6 mobility management", IETF-DRAFT, (work in progress) [11] J. T. Malinen, F. Le, C. Perkins: "Mobile IPv6 Regional Registrations" IETF-DRAFT, (work in progress) [12] G. Krishnamurthi, R. C. Chalmers, C. Perkins: "Buffer Management for Smooth Handovers in IPv6" IETF-DRAFT, (work in progress) De Carolis Informational - September 2001 26 QoS-Aware handover for Mobile IP April 2001 10. Acknowledgments Thanks to Pietro Tou for the review of this document. Special thanks to Charlie Perkins for his letters and suggestions. 11. Author's Addresses Andrea De Carolis E-Mail: ade_carolis@tin.it Luca DellÆUomo Fabio Pugini University of Rome "La Sapienza" - INFOCOM Department Via Cavour, 256 00100 - Rome Italy E-Mail: delluomo@infocom.uniroma1.it E-Mail: pugini@infocom.uniroma1.it Full Copyright Statement "Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. De Carolis Informational - September 2001 27