Mobile IP Andrea De Carolis Internet Draft CoRiTel Document: draft-decarolis-qoshandover-00.txt November 2000 Category: Informational 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. 1. 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. The peculiarity of this kind of Handover is that it allows the Mobile Node to change the current point of attachment to the Internet without loosing the QoS, even if the Handover process takes a long time. This extension is part of a larger effort toward the integration of Mobility and QoS over IP. This document contains also a procedure that COULD be used by a Mobile Node to support such a QoS-Aware Handover. The background assumptions of this work are: 1. A Mobile Node can access the Internet using more than one physical link at the same time. For example different access technologies could be used at the same time (like UMTS + WLAN 802.11). De Carolis Informational 1 Internet Draft QoS-Aware Handover for Mobile IP November 2000 2. Each link-layer can manage link-layer QoS using a Mobile driven signaling protocol that can be interfaced with the ones supported by the Mobile Node for the IP-level QoS (i.e. RSVP). In this scenario it COULD be possible for a Mobile Node to perform a link-layer and IP-level Handover because the link-layer QoS has dropped, but also to take Handover decisions depending on QoS needs, Geographical Location or other issues. Performing an handover for those reasons makes sense only if during the handover the IP QoS is maintained. On the other hand if a drop in the QoS during the Handover cannot be avoided, then the IP-level and Link-layer handover SHOULD be performed only for link-layer QoS considerations (for example when a fading of the radio signal raises the Bit Error Rate). In this document we propose an extension to the Mobile IP protocol that enables Mobile Nodes (conformant to our background assumptions) to perform QoS-Aware Handover. Table Of Contents 1. Abstract .......................................................1 2. Conventions used in this document ..............................2 3. Introduction ...................................................4 4. Definition of the Service: .....................................5 5. Integrated Support for QoS and Mobility ........................8 5.1 First Connection .............................................8 5.3 QoS-Aware HandOver Procedure (HOP procedure) .................9 5.4 Resource Reservation on the new link ........................10 6. Extensions concerning the Mobile IP Protocol ..................12 7. Extensions concerning the RSVP Protocol .......................12 8. Security Considerations, AAA ..................................12 9. References ....................................................12 10. Acknowledgments ..............................................15 11. Author's Addresses ...........................................15 Full Copyright Statement .........................................15 2. Conventions used in this document ISP - Internet Service Provider SAP - Service Access Point It represents a particular interface between two layers of the network architecture where a particular service is available. De Carolis Informational 2 Internet Draft QoS-Aware Handover for Mobile IP November 2000 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 addresss up to its actual point of attachment to the Internet (represented by a CoA). This handover could be performed on the same interface, for example when we unplug a Laptop and we plug it in again in a different room. Link-Layer-Level Handover The switch between interfaces, driven by the Mobile Node. 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 of the wireless radio signal, or to the unplugging of the LAN connector). In this case it is not possible to support anymore IP QoS or IP connectivity on the current link. An Handover procedure is started to connect to a new link, get a new CoA and so on. QoS-Aware Handover It MAY occur for example when a "Better" link becomes available (for example when we come back home and a Local Wireless 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 of the current QoS Sessions. If a large bandwidth demanding sessions is still active that cannot be served by the new Link, no QoS-Aware Handover should be performed. On the other hand if the QoS available on the new link is compatible with the one currently needed by the application, a QoS- Aware Handover can be performed. Location-Aware Handover It MAY occur when the Mobile Node detects (by means of properly generated location De Carolis Informational 3 Internet Draft QoS-Aware Handover for Mobile IP November 2000 information) that it is moving away from the current area of coverage of a certain network. In this case the Mobile Node COULD initiate a QoS-Aware Handover in order to seamlessly switch its point of attachment to the Internet, without any drop in the IP QoS. 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 [1]. 3. Introduction Let's assume that a Mobile Node is connected to a certain ER by means of a wireless connection. This ER is currently supporting a certain number of QoS Sessions belonging to the Mobile Node. After a while the Mobile Node decides to move the active QoS Sessions on another wireless link that it has just activated with a second ER. Before it operates the Handover it checks the availability of resources on the new link. If the new link is able to uphold the Sessions the handover is performed. Otherwise the current connection with the first ER is maintained. 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). To uphold this way of operation there is a key information that we need to determine for each session: how many resources do we need to allocate to this session on the new link? The only entity in the network that can answer to this question is the RSVP module of the receiver (placed in the MN for the Downlink and in the Correspondent Node for the Uplink). In the case of Guaranteed Services this entity can determine the needed bandwidth only if it receives a PATH message. The PATH message is modified by each router on the path in order to insert particular parameters that will be used by the RSVP module of the receiver Host to determine the needed resources. This means that the PATH message is associated to the path followed by the packets. If the path changes, then also the PATH message received by the Correspondent Node will change. Then if we want to test resource availability on the new link before we perform the De Carolis Informational 4 Internet Draft QoS-Aware Handover for Mobile IP November 2000 handover, we need to send a PATH message on the new link. The current approach to the Mobility does not foresee the possibility to send PATH messages on the new link before the Handover is completed. Moreover, in order to continue to receive QoS on the current Link, the Mobile Node MUST send PATH messages also on the current Link (otherwise after a while the resources would be de-allocated). Then a Logical Flow Duplication is needed at the Mobile Node to support the QoS-Aware Handover. If we consider also the Downlink we realize that, in order to receive PATH messages on the new downlink, and keeping QoS on the current Link, we need another object (located at network side), that operates a duplication of the PATH messages, sending them both on the new and on the old links. This object needs to be reachable both via the new and the old link. That characteristic is a quite peculiar requirement for an internet Node, but if we manage Mobility by means of Mobile IP an we perform a Regionalised Registration [21] then we have a Node that is reachable both via the new and the old link in the network that provides the Regionalised Registration. This Node can also be used to control the Handover, by means of Mobile IP. What we suggest in this draft is to add in the router that supports the Regionalised Registration a new integrated QoS & Mobility Support Agent that will make the note not only able to manage the Regionalised Registration but also to cooperate with the Mobile Node to reserve resources on the new link before the Handover. We call this Agent the Secondary Home Agent. 4. Definition of the Service: In order to provide QoS-Aware Handover we need to add to the protocol stack of the Mobile Node a Service Access Point where a particular Service is available for the IP packets. This Service is a particular kind of QoS-Aware IP connectivity that is transparent to IP Mobility related issues. Moreover, in order to test the availability of resources before the Mobile IP handover (no resources available implies no QoS-Aware Handover), we need to add also a set of functions needed to test and manage resource availability. Applications, Routers or Hosts that connect (by means of the Mobile Node) to the SAP where this Service is available, will not see drops De Carolis Informational 5 Internet Draft QoS-Aware Handover for Mobile IP November 2000 in the QoS when the Mobile Node is performing, or has just performed, a QoS-Aware Handover. This means that if they received IP-QoS availability confirmation they can trust that the underlying systems will provide this IP QoS for the time granted by the network, even if a QoS-Aware Handover occurs, then if a new link is used to provide the connectivity. This approach implies that a Mobile Node performing a QoS-Aware Handover, is in charge of supporting IP-QoS, for each active session, even during the Handover. This is not possible using only Mobile IP because the QoS is managed end-to-end and, with plain Mobile IP, it is possible to understand if bandwidth is available on the new link only after the handover has occurred (this means that IP-QoS on the new end-to-end path is not present). The full end-to-end approach (Forced Handover) is the best we can do if the handover takes place for issues related to radio coverage (or if the Mobile Node is unplugged from a network and plugged again in another one). Anyway Forced Handover is not the best solution in other cases, for example when the handover is aimed to move the QoS sessions to a new link in order to provide QoS to a new RSVP session. Then in order to support this new kind of handover, we need a particular HandOver Procedure (that we called HOP). This procedure will interact with the network to reserve resources on the new link before the actual Mobile IP Handover takes place. The procedure will also stop the handover if the QoS on the new link is not available. Logical-flow duplication is managed by the HOP procedure. This duplication has two reasons: 1) transmitting RSVP packets on the new link layer to reserve new resources 2) transmitting RSVP packets on the current link layer to keep old resources The issues related to the reservation of the new resources are addressed in the following sections. The HOP procedure is run both at Mobile Node side and at Network side. This symmetry is due to the fact that (in the worst case) both the Uplink and the Downlink will need this Logical Flow duplication. We need to separate Uplink and Downlink in order to describe the interaction between the Mobile Node and the SHA needed for the resources reservation on the new link and for keeping the resources reserved on the current link: For the Uplink De Carolis Informational 6 Internet Draft QoS-Aware Handover for Mobile IP November 2000 1. At the Mobile Node side we envisage to apply a duplication of the RSVP PATH messages. Each generated PATH message MUST reflect the actual characteristics of the next hop in the OPWA parameters. This means that the PATH messages sent on different links by the same Mobile Node may be different (for example if each link introduces a different latency time); 2. each PATH message will be received by a different Edge Router, will travel on a different path and will be modified by different routers, finally it will arrive at the Secondary Home Agent; 3. the SHA will receive the PATH messages from both the new and the old link. It will then unify the flows, operating a decision on which flow to propagate. After the SHA only one path will be used to support the QoS Session; For the Downlink 1. The same scheme applied for the Uplink can be used for the downlink. This means that, for the Downlink, is the Secondary Home Agent that operates the logical flow duplication (that in practice means a duplication of the RSVP PATH messages). 2. each PATH message will be received by a different Edge Router, will travel on a different path and will be modified by different routers, finally it will arrive at the Secondary Home Agent; 3. the Mobile Node will receive the PATH messages from both the new and the old link. It will then unify the flows, operating a decision on which flow to propagate. After this decision only one path will be used to support the QoS Session; Then in order to support the HOP procedure the following requirements must be met: 1. the Secondary Home Agent is added to the network. 2. The IP address assigned to a certain SHA is known by each Edge Router in each segment (a SHA MUST be connected to different ERs, each ER COULD be connected to more than one SHA). 3. The ER can advertise the availability of a certain set of SHAs to the Mobile Node as soon as it assigns to the Mobile Node an IP Address (CoA). 4. The packets sent by the Secondary Home Agent can physically reach the Mobile Node using both IP-QoS-Aware networks and Link Layer- QoS-Aware connections. De Carolis Informational 7 Internet Draft QoS-Aware Handover for Mobile IP November 2000 It is important to remark how the Secondary Home Agent functionality is a set of functions used only during the QoS-Aware Handover to provide packet flow duplication, after the Handover the Node that supports this Agent continues to operate as a common router (supporting QoS by means of RSVP). 5. Integrated Support for QoS and Mobility In this chapter we present the main points of an integrated Mobility and QoS management. The "first connection", the "Forced handover" and the "QoS Aware Handover" are examined. Each procedure is explained following this convention: sentence (stepcodeSTEPstepnumber) The stepcode is used to distinguish steps belonging to different procedures while the stepnumber is used to enumerate the steps belonging to the same procedure. 5.1 First Connection When the Mobile Node (Mobile Router) is first switched on, it is not connected to the Internet, then it needs to obtain a first Point of Attachment to the Internet. This point of attachment can be assigned by a segment that SHOULD be selected according with an external selection procedure (fcSTEP0). This procedure takes the decision about which interface to use for the first connection (fcSTEP1). After the link-layer connection is set up (fcSTEP2), the network assigns an address to the current interface of the Mobile Node (fcSTEP3). This address is used to exchange information between the Edge Router (ER) and the Mobile Node. The Mobile Node MAY send solicitations to the ER to trigger this exchange. The information sent back to the MN MUST contain the address of at least one SHA and an associated list of the edge-domains connected to that SHA (fcSTEP4). A SHA is selected taking into consideration that a SHA associated with more edge-domains gives larger probability of QoS-Aware Handover (fcSTEP5). The locally generated CoA is sent to the selected SHA that performs a Regionalised Registration with the Home Agent of the Mobile Node (fcSTEP6). 5.2 Forced Handover When the link-layer connectivity is lost on the current Interface (for example because the network connector is unplugged) a Forced Handover procedure is started: the first connection procedure is followed from fcSTEP0 to fcSTEP4. De Carolis Informational 8 Internet Draft QoS-Aware Handover for Mobile IP November 2000 If the previous SHA is in the set of SHAs associated with the new ER, a Binding Update with the new CoA is sent to the SHA (and to the previous ER) (fhSTEPa). In this case there is no need to inform the correspondent Nodes of the handover because the Mobile Node is still in the same region (the Handover should be Fast). If the previous SHA is not in the set of SHAs associated with the new ER then fcSTEP5 and fcSTEP6 are executed again (fhSTEPb). In this case there is the need to inform the correspondent Nodes of the handover because the Mobile Node has moved into a region covered by a different SHA (the Handover COULD be slow). 5.3 QoS-Aware HandOver Procedure (HOP procedure) When the link-layer connectivity on the current Interface is still good, the Mobile Node (Mobile Router) MAY start the HOP Procedure. This Procedure COULD be triggered, for example, when the Mobile Node detects, according with a certain algorithm, that it is using a link that is not adequate to the needs of the applications or that is largely under exploited (hopSTEP0). The current connection is not released. The following steps are performed: fcSTEP0 (the current Link identifier and the actual needs of bandwidth are passed to the external selection algorithm together with the edge-domains list associated with the current SHA); fcSTEP1; fcSTEP2; fcSTEP3; fcSTEP4 (hopSTEP1). The list of SHA associated with the new Edge Router is taken into consideration (hopSTEP2). 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. 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) (hopSTEP3). 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. For each session from the hopSTEP3, the Mobile Node sends to the SHA a QoS-Aware Handover Initiation Message (HIM). The HIM message COULD be sent using the same transport protocol used for RSVP messages (hopSTEP4). De Carolis Informational 9 Internet Draft QoS-Aware Handover for Mobile IP November 2000 The next step is the most important one, it is supported by a distributed procedure, and is described in detail in the paragraph 5.3: for each session from the hopSTEP3, QoS availability on the new link is tested and both link-layer resources and IP-layer resources are reserved (hopSTEP5). If the hopSTEP5 does not fail the Mobile Node sends to the SHA a Binding Update (Mobile IP handover) (hopSTEP6). 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 issues an RSVP PathTear Message) (hopSTEP7). Link Layer QoS is released by means of QoS signaling on the old link (hopSTEP8) 5.4 Resource Reservation on the new link. UPLINK If the Time Out set for the QoS-Handover is exceeded while waiting, then the QoS-Handover Fails; if new RESV message arrives to the MN from the old link then the set generated in hopSTEP3 is extended and a new HIM message is sent to the SHA. The MN selects the next Uplink session in the set from hopSTEP3, (rrSTEP0). 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. (rrSTEP1) When the SHA receives the PATH messages from the MN, worst case is selected with an external algorithm (rrSTEP2). The SHA forwards only the worst case PATH message (rrSTEP3). As long as the Sender template used in the two PATH messages is the same, after this selection a PATH packet with the old Sender Template is forwarded on the stable part of the route (that is the one that is not in handover). This PATH message could carry information about the new link that, once received, could generate a RESV message with larger bandwidth demands. Even if the network discards this message because no resources are available, the previous soft-state, according with the RSVP protocol, SHOULD NOT be cleared: PATH messages maintain the soft state. Then, even if the QoS-HandOver Procedure fails to reserve resources for the new link, the applications continue to see the expected QoS on the previous link. De Carolis Informational 10 Internet Draft QoS-Aware Handover for Mobile IP November 2000 When the SHA receives the RESV messages from the Correspondent Node, and the sender description corresponds to a session in QoS-Aware HO, it forwards the reservations only on the new link, otherwise it sends the RESV message only to the old link. The set of session from hopSTEP3 COULD be extended with the new session only after the RESV message arrives to the MN (rrSTEP4). While the MN waits for RESV messages it continues to send PATH messages. From this point the HOP at MN side can work in multi- tasking and go on with another session starting from rrSTEP0. When the MN receives RESV on the new link, it performs a Link-Layer QoS reservation for the UPLINK (rrSTEP5) If the Link-layer QoS reservation fails the QoS-Aware Handover fails (rrSTEP6). Else if the link-layer QoS reservation succeeds and this is the last session in the set generated at hopSTEP3 then continue with hopSTEP6. If this is not the last session in the set from hopSTEP3 then continue with rrSTEP0 (rrSTEP7). DOWNLINK If the Time Out set for the QoS-Handover is exceeded while waiting, then the QoS-Handover Fails; if new PATH messages arrives to the MN from the old link then the set generated at hopSTEP3 is extended and a new Handover Initiation Message is sent to the SHA. The MN selects the next Downlink session in the set from hopSTEP3, (rrSTEP0). 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. The ER has the tasks 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 only the worst case one (as explained for the Uplink). At Receiver side the Application (the Operating System) computes the new RESV message and forwards it to the MN. 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 continue to arrive from the old link and see the expected QoS because the soft state are mantained by the PATH messages). De Carolis Informational 11 Internet Draft QoS-Aware Handover for Mobile IP November 2000 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 set from hopSTEP3, it first performs hopSTEPS6 and hopSTEPS7, then it sends to the application the ResvConf message, then it performs hopSTEPS8. If there are other elements in the set from hopSTEP3, then go back to (rrSTEP0). 6. Extensions concerning the Mobile IP Protocol Mobile Node The Mobile Node needs to solicit SHA advertisements every time it connects to an ER. 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. Edge Routers The ERs need to be extended in order to exchange information about the SHA they are connected to. 7. Extensions concerning the RSVP Protocol None. 8. Security Considerations, AAA The same considerations as Mobile IP apply. 9. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 De Carolis Informational 12 Internet Draft QoS-Aware Handover for Mobile IP November 2000 2 P. White: "RSVP and integrated services in the Internet: a tutorial", IEEE Communications magazine, Vol. 35, N. 5, May 1997. 3 X.Xiao, L.M.Ni: "Internet QoS: a big picture", IEEE Network, Mach/April 1999, pag.8-18. 4 C. Perkins: "IP Mobility Support", RFC2002, October 1996 5 C. Perkins: "IP Encapsulation within IP", RFC 2003, October 1996 6 C. Perkins: "Minimal Encapsulation within IP", RFC 2004, October 1996 7 D. Cong & M. Hamlen, C. Perkins: "The Definitions of Managed Objects for IP Mobility Support using SMIv2", RFC 2006, October 1996 8 G. Montenegro: "Reverse Tunneling for Mobile IP", 2344, May 1998 9 G. Montenegro, V. Gupta: " Sun's SKIP Firewall Traversal for Mobile IP", 2356, June 1998 10 J. Postel ,J. Reynolds: "Instructions to RFC Authors", RFC 2223, October 1997 11 J. Solomon: "Applicability Statement for IP Mobility Support", RFC 2005, October 1996 12 R. Atkinson: "IP Authentication Header", RFC 1826, August 1995 13 R. Atkinson: "IP Authentication Header", RFC 1826, August 1995 14 R. Hinden, S. Deering: " Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995 15 R. Hinden, S. Deering: "IP Version 6 Addressing Architecture", RFC 1884, December 1995 16 S. Bradner: "The Internet Standards Process -- Revision 3", RFC 2026, October 1996 17 W. Simpson, T. Narten, E. Nordmark: "Neighbor Discovery for IP Version6 (IPv6)", RFC 1970, August 1996 18 S. Thomson, T. Narten: "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996 De Carolis Informational 13 Internet Draft QoS-Aware Handover for Mobile IP November 2000 19 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 20 D. Johnson, C. Perkins: "Mobility Support in IPv6", IETF-DRAFT, (work in progress) 21 J. Malinen, C. Perkins: " Mobile IPv6 Regional Registrations", IETF-DRAFT, (work in progress) 22 H. Soliman, K. El Malki: "Hierarchical Mobile IPv6 and Fast Handoffs", IETF-DRAFT, June 28, 2000 (work in progress) 23 Charles E. Perkins: "Mobile IP", Communications Magazine, May '97, pp. 84-99. De Carolis Informational 14 10. Acknowledgments Tanks to Pietro Tou for the review of this document. Special tanks to Charlie Perkins for his letters and suggestions. 11. Author's Addresses Dr. Eng. Andrea De Carolis CoRiTel - University of Rome "La Sapienza" - INFOCOM Department Via Cavour 256 00100 Rome Italy Mail:decarolis@coritel.it http://www.coritel.it Full Copyright Statement "Copyright (C) The Internet Society (date). 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 - May 2001 15