Mobile IP Peter J. McCann Internet Draft Tom Hiller Document: draft-mccann-mobileip-limiph-00.txt Lucent Technologies Category: Standards Track August, 2000 Low Interruption Mobile IP Handoff Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [Bradner96]. 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 There are currently a number of proposals for different mechanisms intended to reduce the overhead of IP mobility management. Generally speaking, the goal of these proposals is twofold: first, to reduce the latency or interruption due to handoffs; and second, to reduce the signaling load on the Mobile IP Home Agent (and Correspondent Nodes, for the case of Mobile IPv6). These techniques are meant to improve the performance of real-time applications like voice or video over IP over wireless networks. By minimizing the period of interruption during a handoff from one point of attachment to another, the proposals attempt to minimize packet loss when these events occur. This draft argues that the best solution to this problem is a "transparent" one that requires no changes to the Mobile IP clients in mobile nodes and that gives control over routing functionality to the operator of a wireless network. We review some of the existing proposals and describe in detail a new proposal that can provide for low interruption handoffs in a more transparent manner. McCann, Hiller Standards Track - Expires 02/01 1 LIMIPH August 2000 2. Conventions used in this document 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 The Mobile IP protocol [Perkins00, Johnson00] provides support for wide-area mobility. Invoking the entire Mobile IP protocol including a round-trip to an HA on every mobility event may be too slow for latency-sensitive applications. Both the anchor handoff (ANCH) draft [Dommety00] and the proactive foreign agents (PFA) draft [Kempf00] purport to provide support for fast handoffs in a wireless environment. This draft agrees with the basic philosophy of ANCH that the complexity of a static hierarchy is not necessary for providing fast handoffs. However, it also agrees with PFA that a pro-active approach, based on link-layer handoff information, is better able to meet the stringent requirements of a very fast handoff suitable for voice-over-IP applications. In fact we take this philosophy even further and argue that for many networks, a completely pro-active approach is sufficient to complete a handoff without any assistance from the mobile node's layer-3 software. This approach relies on layer-2 authentication to guarantee that packets are not mis-routed by malicious mobile nodes. 4. Network Reference Model We define the term "domain" to mean the region within which a mobile node may acquire and continuously make use of a care-of address (COA). To resolve any ambiguity, we mean the care-of address visible to the HA. We assume that each COA is associated with exactly one FA (for IPv6, we use the term FA to refer to some unique last-hop router) somewhere in the domain. MNs connect to FAs via direct, link-layer connections. Because an FA is directly connected to the link-layer, it may obtain link-layer information such as power measurements that might indicate the necessity of a handoff to a new FA. The FA can also gain assurance of the MN's identity through link-layer authentication, and can authenticate the stream of traffic coming from the MN, including any power measurements or other indications used for handoff. The FA also terminates some layer-2 protocol. This issue is revisited at the end of the draft. Consider a handoff that must take place from FA 1 to FA 2. We refer to FA 1 as the "source FA" and FA 2 as the "target FA." There is no need for the link technology on FA 1 and 2 to be the same. However, McCann, Hiller Standards Track - Expires 02/01 2 LIMIPH August 2000 the acquisition of a "trigger" to signal that a handoff is necessary may be more difficult when the technologies differ. We assume that any such trigger will be sufficient for FA 1 to derive the identity (IP address) of FA 2. If such a trigger is not available or if the MN decides on its own that a handoff is to take place, then one of the FAs can often still derive the identity (IP address) of the other from link-layer messages. We call the FA that does such a derivation the "initiating FA". If such a derivation is possible then we assume that there also exists a trust relationship and security association between FA 1 and FA 2. This is analogous to the relationships that existing cellular operators maintain between neighboring systems that are capable of handing off to one another. In summary, this draft covers a handoff scenario not addressed by the existing drafts: that of a pro-active, network-controlled, anchor-chained handoff. 5. Handoff Operation See Figure 1 for an overview of handoff. A MN connects (1) to FA 1 through link-layer establishment. It receives an advertisement, acquires a COA, and sends (2) a registration request to its HA and to any CNs that are capable of receiving them. We assume that some "attendant registration protocol" runs at layer-3 during this process in order to authenticate the MN's layer-3 identity (for IPv4 this is Mobile IP itself - we assume that the 'R' bit will always be set in advertisements and that the MN-AAA extension is used). Now, assume that FA 1 gets a link-layer indication (3) that a handoff to FA 2 is required, and begins whatever link-layer procedure is necessary to effect a handoff. McCann, Hiller Standards Track - Expires 02/01 3 LIMIPH August 2000 ____ | HA | |____| > / /(2) / (4a) ____/_ --------> ______ | | (4b) | | | FA 1 | <-------- | FA 2 | | | (5a) | | |______| <-------- |______| ^ (5b) | --------> |(1) | __| __| | | | | |MN| -------> |MN| |__| (3) |__| Figure 1: Overview of Handoff Operation If FA 1 is the initiating FA, it immediately sends (4a) a Binding Update to FA 2. The Binding Update has the Home Address field set to FA 1's address, and has the Care-of Address field set to FA 2's address. The Binding Update contains link-layer identification information for the MN in a special extension given in Section 7. This enables FA 2 to match up the newly handed-off link-layer connection with the Binding Update. The FA 2 then responds (4b) with a Binding Acknowledge to the source address/port of the Binding Update. Each of these messages is authenticated with the appropriate security association between FA 1 and FA 2. If FA 2 is the initiating FA, then step 4 is skipped, and we proceed directly to step 5. In either case, FA 2 sends (5a) a Registration Request to FA 1. The Request is sent to the address copied from the Home Address field of the Binding Update, if one was received from an initiating FA 1, or from link-layer messages otherwise. The Registration Request has the G and T bits set to 1, and has the Home Address field set to zero. The Home Agent Address field is set to FA 1's address and the Care-of Address field is set to FA 2's address. The Registration Request also contains link-layer identification information for the MN in a special extension. This enables FA 1 to match the request to some existing link-layer connection. The extension also contains a Key field that will be used for GRE packet demultiplexing. The FA 1 then responds (5b) with a Registration Reply. McCann, Hiller Standards Track - Expires 02/01 4 LIMIPH August 2000 After executing step 5, FA 1 and FA 2 have established a bi- directional tunnel for IP packets. This tunnel uses GRE encapsulation and makes use of the Key field for packet demultiplexing. If packets arrive for the MN's COA at FA 1, they should be forwarded to FA 2 and delivered to the MN. When using FA- located COA FA 1 should strip out the care-of address before forwarding to FA 2. If packets are sent from the MN to FA 2, they should be reverse tunneled to FA 1 and then routed as appropriate, with FA 1 placing its COA on the packets if using FA-located COA. FA 2 MAY send Agent Advertisements (or for IPv6, Router Advertisements) to the MN. If it does so these are inserted into the packet stream and delivered to the MN. Any packets from the MN addressed directly to FA 2 MUST NOT be tunneled to FA 1 but will rather be received and processed by FA 2. This will enable the MN to carry out the attendant registration protocol with FA 2. After successfully registering with the attendant, the MN's packets may be directly routed to the Internet from FA 2 without being reverse tunneled to FA 1, assuming that the MN is using a co-located COA and that there is no problem of ingress filtering when such packets originate from FA 2. When using FA-located COA, or when the MN has requested a reverse tunnel back to its HA, FA 2 must wait for a properly formed registration reply from a home agent before directly routing such packets. We allow that the registration reply may or may not be "piggybacked" on the layer-3 attendant registration protocol so there may or may not be any delay between the occurrences of these two events. Although the MN has now completed its registration with FA 2, there may still be packets in flight towards FA 1. For this reason FA 1 should continue to forward any received packets for the MN to FA 2 until the agreed Lifetime for the FA 1 to FA 2 tunnel has expired. This Lifetime should be set large enough to allow the MN time to register with FA 2, but not so large that it places an unreasonable burden on FA 1 and FA 2 to maintain the unused state information. The proper Lifetime is a parameter that should be chosen by the network operator(s) depending on their particular network characteristics. 6. Reducing Signaling Traffic Section 5 above provides for a fast handoff between neighboring FAs but, unlike hierarchical schemes, does nothing to reduce the signaling traffic to the HA. It may be the case that FA handoffs do not happen very frequently and that there is therefore no need to address this problem. However, very small FA coverage areas, as well as rapid "ping-pong" motion between FA coverage areas, may lead to a high rate of Registration Requests from MNs which can produce too much load on the air interface, too much load on HAs, or too McCann, Hiller Standards Track - Expires 02/01 5 LIMIPH August 2000 many lost in-flight packets. We note that even the hierarchical schemes can suffer from these problems for those nodes that are sitting on the boundary between two hierarchical domains. In this section we outline a non-hierarchical approach to addressing this problem. 6.1 Anchor Chaining First, note that the requirement that FA 2 send Agent Advertisements was a "MAY" and not a "MUST". We allow that FA 2 may never send an advertisement or may wait for an undetermined amount of time before sending one. By delaying the advertisement, FA 2 can make sure that the MN has been within its coverage area for a certain minimum amount of time before initiating the costly registration process. Because the mobility event can be completely hidden during this time from the MN's Mobile IP client implementation, no over-the-air messages other than the link-layer signaling required for handoff need to be sent until FA 2 decides to send an Agent Advertisement. Note that if FA 2 refrains from sending such advertisements for a long time it must continue to renew the Lifetime of the tunnel to FA 1. Also, the MN must continue to receive Advertisements from FA 1 so that it may renew its overall Mobile IP registration as needed. For this reason, we require that FA 1 continue to send Advertisements through the tunnel towards FA 2 but allow that FA 2 may filter out such Advertisements if it wishes to force the MN to register directly with FA 2. If the MN moves to a new FA, say FA 3, before it has registered with FA 2, then FA 2 will send a Binding Update to FA 3 (assuming FA 2 is the initiating FA). Because FA 2 is maintaining no layer-3 state for the MN, it may optionally include FA 1's address as the Home Address in the Binding Update, if it knows that FA 1 and FA 3 share a direct security association. That way FA 3 can register directly with FA 1, and packets will be tunneled directly between FA 1 and FA 3. If no such knowledge exists at FA 2, then it can send the Binding Update as outlined in Section 5, using its own address. This creates a chain of tunnels from FA 1 to FA 2 to FA 3. To prevent such chains from becoming unreasonably long, some FA along the chain should send an Agent Advertisement that is not filtered out by the downstream FAs. Note that any FA along the chain may do so and the time at which each agent decides to send Advertisements may be given by some probability distribution that is chosen to provide optimal performance. When the MN receives such an Advertisement it may detect that it has moved and will then send a Registration Request. This Request will be forwarded backwards to the FA that sent the Advertisement and will be processed by that FA, according to the forwarding rules outlined in Section 5. This allows the MN to register with a "recently visited" FA, even though it may have already moved several hops away. Also note that an McCann, Hiller Standards Track - Expires 02/01 6 LIMIPH August 2000 Advertisement may be sent to an MN that is directly attached to FA 2, then the MN may move away to FA 3, and finally the MN may register with FA 2 even though its current point of attachment is FA 3. This allows for the chains to be cut even in the presence of very rapid motion. Steps must be taken to ensure that the MN retains its COA while in such an anchor-chained situation. For an FA-located COA this is straightforward. For an MN-located COA, the MN may continue to interact with any address allocation agent that may exist on FA 1's network, because all packets from the MN are reverse tunneled to FA 1 unless they are addressed directly to FA 2. This includes any broadcast or multicast packets. 6.2 Ping-Pong Motion Some link-layers are subject to rapid motion of MNs between two FAs. For example, even though link-layer power measurements may indicate to FA 1 that a handoff to FA 2 is necessary, the MN may fail to attach to FA 2 and return almost immediately to FA 1. If a given link-layer is subject to such "ping-pong" behavior, then FA 2 SHOULD set the 'S' bit in the Registration Request sent to FA 1. In this case FA 1 continues to forward packets directly to its local coverage area, in addition to forwarding a copy of each packet along the FA 1 to FA 2 tunnel. Also, FA 1 should continue to handle traffic from the MN that arrives directly from the local coverage area. FA 2 may subsequently re-register with FA 1 with the 'S' bit clear, once it has determined that it has a stable and authentic link-layer connection to the MN, or FA 1 may cease to forward packets to its local coverage area once it receives an authentic Registration Request from the MN along the FA 2 to FA 1 tunnel. FA 1 may cease to forward packets along the FA 1 to FA 2 tunnel if it has some indication that the MN has returned; in this case it should send a Binding Update to FA 2 with both the Home Address and Care-of Address set to FA 1's address. McCann, Hiller Standards Track - Expires 02/01 7 LIMIPH August 2000 7. Extension Format The link-layer identification extension follows that given by Xu [Xu00]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MN Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN ID Type | MN ID Length | MN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 39 (not-skippable). Length A one-octet field that indicates the length (in bytes) of the extension, NOT including the Type and Length fields. Protocol Type A two-octet field that indicates the type of the protocol to be tunneled between FA 1 and FA 2. It is same as the Protocol Type field in the GRE header. For IP packets (assumed in this draft) this should be set to 0x0800. Key This is a four-octet value assigned by FA 2. It is used in the GRE encapsulation between FA 1 and FA 2 to indicate to which MN the traffic belongs. Reserved A two-octet field. It is not used and is set to zero. MN Connection ID A two-octet field that is used to differentiate the multiple sessions from the same Mobile Node. It is locally unique to a Mobile Node. MN ID Type A two octet field that indicates the type of the following Mobile Node ID value. Type value 1 will be reserved for International Mobile Station Identity (IMSI) McCann, Hiller Standards Track - Expires 02/01 8 LIMIPH August 2000 encoded in ASCII format. For detailed description of the IMSI, see IS-95 [TIA]. MN ID Length This is a one octet field and it indicates the length (in bytes) of the following Mobile Node ID field. For IMSI MN ID encoded in ASCII format, the length field value ranges from 10 to 15 bytes. MN ID This is the Mobile Node ID, which is globally unique. It is used to uniquely identify a Mobile Node. For Type 1 MN ID, the most significant digit of IMSI will be coded in ASCII and stored as the most significant byte of the MN ID. 8. Stateful Link Layers The level of interruption depends heavily on the time for the data link to re-initialize when handing off from FA 1 to FA 2. For wireless architectures that involve significant link negotiations, such as LCP and NCP of PPP, the level of interruption for voice over IP is not acceptable. An approach outside the scope of this draft is to replace the layer-3 tunnels with layer-2 tunnels so that movement of the mobile allows the data link layer to the previous foreign agent to be maintained while the mobile performs MIP registration. This change is possible because of the degree of transparency offered by our architecture. When this approach is taken it will not be possible for downstream FAs to "filter out" Agent Advertisements from upstream FAs, but the new registration with FA 2 will be carried out on a separate link-layer connection, enabling the MN to close the old connection once handoff is complete. 9. Security Considerations This draft assumes that the MN is authenticated at the link layer. Furthermore, the link must be secure; otherwise, untrusted mobile nodes may be able to inject or intercept packets to a given FA. If the target FA 2 is unable to authenticate the MN at the link layer, then it SHOULD set the 'S' bit in the Registration Request to FA 1. Then FA 1 will duplicate received packets, sending one copy to FA 2 and another copy directly to its local coverage area. FA 1 may cease such duplication upon receipt of an authentic Registration Request from the MN along the FA 2 to FA 1 tunnel. McCann, Hiller Standards Track - Expires 02/01 9 LIMIPH August 2000 10. References [Bradner96]Scott Bradner., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [Bradner97]Scott Bradner. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [Dommety00]Gopal Dommety and Tao Ye. "Local and Indirect Registration for Anchoring Handoffs", Internet Draft draft-dommety-mobileip-anchor-handoff-01.txt, July 2000. Work In Progress. [Johnson00]David Johnson and Charles Perkins. "Mobility Support in IPv6", Internet Draft draft-ietf-mobileip-ipv6-12.txt, April 2000. Work In Progress. [Kempf00] James Kempf, Pat Calhoun, and Chandana Pairla. "Foreign Agent Assisted Handoffs", Internet Draft draft-calhoun- mobileip-proactive-fa-01.txt, June 2000. Work In Progress. [Perkins00]Charles Perkins, editor. "IP Mobility Support for Mobile IPv4, revised", Internet Draft draft-ietf-mobileip- rfc2002-bis-02.txt, July 2000. Work In Progress. [TIA] TIA/EIA IS-95 B. [Xu00] Yingchun Xu et al. "Mobile IP Based Micro Mobility Management Protocol in the Third Generation wireless Network", Internet Draft draft-ietf-mobileip-3gwireless- ext-04.txt, June 2000. Work In Progress. McCann, Hiller Standards Track - Expires 02/01 10 LIMIPH August 2000 11. Authors' Addresses Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 713 9359 FAX: +1 630 713 4982 EMail: mccap@lucent.com Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 979 7673 FAX: +1 630 979 7673 EMail: tom.hiller@lucent.com Intellectual Property Statement The IETF is hereby notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. A letter setting forth Lucent Technologies' policy with respect to licensing such intellectual property is on file with the IETF Secretariat. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice McCann, Hiller Standards Track - Expires 02/01 11 LIMIPH August 2000 this standard. Please address the information to the IETF Executive Director. Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McCann, Hiller Standards Track - Expires 02/01 12