NETLMM I. Akiyoshi Internet Draft M. Liebsch draft-akiyoshi-netlmm-protocol-00.txt NEC Expires: April 2006 October 2005 NETLMM Protocol draft-akiyoshi-netlmm-protocol-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 April 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. I. Akiyoshi Expires - April 2006 [Page 1]
Internet Draft NETLMM Protocol October 2005 Abstract This document specifies a network-based protocol which allows mobile nodes to remain reachable while moving around a certain administrative network called Edge Mobility Domain. This protocol also allows mobile nodes to keep their IP address when the mobile nodes move from one access router to another within the Edge Mobility Domain. 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]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Protocol Overview..............................................3 4. Protocol Specification.........................................6 4.1 Conceptual Data Structures.................................6 4.2 Access Router Operation....................................7 4.3 Edge Mobility Anchor Point Operation.......................7 Appendix A: Protocol Extensions...................................8 References.......................................................13 Author's Addresses...............................................14 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................14 Copyright Statement..............................................15 I. Akiyoshi Expires - April 2006 [Page 2]
Internet Draft NETLMM Protocol October 2005 1. Introduction There have been a number of protocol proposals for terminal mobility management such as MIPv6 [2], HIP [9] and MOBIKE [10]. Moreover there is a strong requirement of a hierarchical configuration to such mobility management schemes for achieving a world-wide IP-based mobile network. Provisioning a hierarchical configuration for each individual protocol makes a complex and expensive solution. Rather, providing a unified local mobility management will make a simple and inexpensive solution. NETLMM, which is described in this document, is a network-based localized mobility protocol for achieving such a simple solution. This document mainly describes the basic configuration of NETLMM. An advanced configuration is also described in the APPENDIX. 2. Terminology Access Router (AR) A router in an Edge Mobility Domain, which registers the association of a mobile node with its point of attachment to an Edge Mobility Anchor Point and provides routing services to the mobile node while registered. Edge Mobility Anchor Point (EMAP) A router in an Edge Mobility Domain, which maintains current location for a mobile node when the mobile node is in an Edge Mobility Domain and delivers packets to the mobile node. One or more EMAPs can be deployed in an Edge Mobility Domain. Edge Mobility Domain (EMD) An administrative network composed of Access Routers and Edge Mobility Anchor Points. 3. Protocol Overview NETLMM protocol is a network-based localized mobility management protocol operating within an Edge Mobility Domain (EMD). Each AR advertises the same prefix related to the EMAP's subnet, so that a mobile node (MN) keeps its IP address when it moves from an AR to another within an EMD. This section describes an overview of NETLMM protocol basic configuration. Within the scope of basic configuration of this protocol, it is assumed that a single EMAP exists within a single EMD. The architecture model is shown in Figure 1. The EMAP manages mapping of the MN's address to the AR's address where the MN connects. The mapping is used to manage a bi-directional I. Akiyoshi Expires - April 2006 [Page 3]
Internet Draft NETLMM Protocol October 2005 tunnel between a particular MN's current AR and its EMAP for forwarding packets from a correspondent node (CN) to the MN. +----------------------+ | Edge Mobility Domain | +----------+ | | | | +----+ | +----+ +------+ | | External | +----+ | MN |-+----| AR |--+--| EMAP |-------------------| CN | +----+ | | +----+ | +------+ | | Network | +----+ | | | | | | +----+ | | +----+ | | +----------+ | MN |-+ | | AR |--+ | +----+ | +----+ | | | +----------------------+ Figure 1: Architecture Model The procedure when a MN visits an EMD is shown in Figure 2. When a MN attaches to the EMD just after its power-on, the MN first acquires its IP address through a conventional mechanism, such as stateless [7] or stateful configuration [8] via an AR. Then the MN sends attach message including the MN's IP address (MN-IP) to the AR (AR1). The message may be related to Neighbor Discovery Protocol [4] such as Router Solicitation, Neighbor Solicitation for Duplicated Address Detection (DAD) and so on. Receiving the attach message, AR1 detects that the MN has connected to it. Then AR1 sends a Location Registration Request (LR Req) message to the EMAP within the EMD. The message includes the MN's identifier (MN-ID), the MN's IP address (MN-IP) and the AR's IP address (AR-IP). A MN-ID is needed to identify each MN by an identifier except the MN's IP address, since all ARs have the same prefix as EMAP's subnet. And then, AR1 creates a cache entry of "Location Registration List (LR List)". The cache entry includes mapping between the MN's IP address and the EMAP's address. When the EMAP receives the LR Req message, the EMAP creates a cache entry of mapping between the MN's IP address and AR1's address, which is called "Location Registration Cache (LR Cache)" in this document. And then, the EMAP sends a Location Registration Acknowledgement (LR Ack) back to AR1. After the LR Req/Ack exchange, the EMAP and AR1 establish a bi- directional tunnel between the EMAP and AR1. The tunnel is used for forwarding packets from/to the MN. And then EMAP also performs the mechanism for intercepting any packets addressed to the MN's IP address such as proxy Neighbor Discovery [4]. I. Akiyoshi Expires - April 2006 [Page 4]
Internet Draft NETLMM Protocol October 2005 The procedure of handover is shown in Figure 3. When the MN moves from AR1 to AR2, AR2 performs in the same way as AR1 in Figure 2. Receiving a LR Req message, the EMAP verifies if it has already had the LR cache entry for the MN or not. If the EMAP already has the entry and the AR address in the entry is different from the AR address in the LR Req message which the EMAP receives, the EMAP sends a Location Deregistration Request (LD Req) message to AR1 to delete the LR List entry on the AR1. Receiving the LD Req message, the AR1 deletes the LR List entry and sends a Location Deregistration Acknowledgement (LD Ack) to the EMAP. When the procedure which a MN detaches from an EMD such as power-off happens, an EMAP and an AR should delete the cache entry and the associated tunnel for the MN. The detail of the detach procedure is undefined in this document now. But the AR may send the EMAP a message for deletion of the cache entry or the EMAP and the AR may have a lifetime in each cache entry. MN AR1 EMAP | | | | Attach | | |----------------->| | | (MN-IP) | | | | | | Location Registration Request | |-------------------->| | |(MN-ID, MN-IP, AR1-IP) | | | | Location Registration Acknowledgement | |<--------------------| | | | | | | Figure 2: Attachment procedure I. Akiyoshi Expires - April 2006 [Page 5]
Internet Draft NETLMM Protocol October 2005 MN AR2 AR1 EMAP | | | | | Attach | | | |----------------->| | | | (MN-IP) | | | | | | | | | Location Registration Request | | |------------------------------------------>| | | (MN-ID, MN-IP, AR2-IP) | | | | | | | Location Registration Acknowledgement | | |<------------------------------------------| | | | | | | | | | | Location Deregistration Request | | |<--------------------| | | | (MN-ID, MN-IP) | | | | | | | Location Deregistration Acknowledgement | | |-------------------->| | | | | Figure 3: Handover procedure 4. Protocol Specification This section provides the detailed description of the protocol. As mentioned in the overview section, the entities that are introduced in this document are the Access Router (AR) and the Edge Mobility Anchor Point (EMAP): the detailed operation of both of them is described in following sections. Before that, the conceptual data structures that AR and EMAP need to implement are described. 4.1. Conceptual Data Structures The conceptual data structures used in this protocol are the following. - Location Registration Cache (LR Cache) - Location Registration List (LR List) An EMAP maintains a LR Cache of bindings between the MN and the AR where the MN connects. A separate LR Cache entry should be maintained for each MN. Each LR Cache entry contains the following fields: - The Identifier which identifies a MN. Network Access Identifier (NAI) [3] or L2-specific ID such as MAC address is assumed. I. Akiyoshi Expires - April 2006 [Page 6]
Internet Draft NETLMM Protocol October 2005 - The IP address of the MN. - The IP address of the AR where the MN is located. This is updated based on LR Req message received by the AR. An AR maintains a LR List. A separate LR List entry should be maintained for each MN. Each LR List entry contains the following fields: - The Identifier which identifies a MN. Network Access Identifier (NAI) [3] or L2-specific ID such as MAC address is assumed. - The IP address of the MN. - The IP address of AR where the MN is located. - The IP address of the node to which a LR Req was sent. 4.2. Access Router Operation All ARs within an EMD controlled by a singular EMAP sends Router Advertisement which includes the same prefix as the EMAP's subnet. Also the AR must be a default router for the MN. An AR sends a LR Req to an EMAP whenever a new MN attaches on its link. The LR Req includes the identifier of the MN, IP address of the MN and IP address of the AR itself. When sending the LR Req to the EMAP, the AR creates the corresponding LR List entry. When the AR receives a LR Ack with a status code indicating successful registration, it sets up a bi-directional tunnel for the MN. The endpoints of the tunnel are the AR and the EMAP. When the AR receives a LR Ack with a status code indicating an error, it must remove the LR List entry. In particular, if the error code indicates DAD failed, it must notify the MN that the IP address currently in use is no longer valid. When the AR receives a LD Req from the EMAP, it must remove the LR List entry for the MN. And then it sends a LD Ack back to the EMAP. Traffic from/to the MN goes through a bi-directional tunnel between the AR and the EMAP. So, the AR encapsulates packets from the MN to the CN and decapsulates packets from the CN to the MN on the other hand. 4.3. Edge Mobility Anchor Point Operation I. Akiyoshi Expires - April 2006 [Page 7]
Internet Draft NETLMM Protocol October 2005 When an EMAP receives a LR Req including an identifier and an IP address of a MN, it must verify the MN's IP address is unique or not in the EMD by means of searching LR Caches using the identifier and the IP address of the MN as a key. If the LR Req message is valid, the EMAP must then create a new entry in its LR Cache for this MN or update its existing LR Cache entry, if the entry already exists. Unless this EMAP already has a LR Cache entry for the MN, the EMAP must perform Duplicate Address Detection on the EMAP's link before returning the LR Ack. This ensures that no other node on the link was using the MN's IP address when the LR Req arrived. If this Duplicate Address Detection fails for the MN's address, then the EMAP must send the AR a LR Ack with a status code indicating Duplicate Address Detection failure. If all checks performed after receiving the LR Req have been successful, the EMAP sends the AR a LR Ack with successful code. If the EMAP already has the LR Cache entry and the AR address in the entry is different from the AR address in the LR Req message which the EMAP receives, the EMAP sends a LD Req message to the AR in the cache to delete the cache entry on the AR after sending a LR Ack. Traffic from/to the MN goes through a bi-directional tunnel between the AR and the EMAP. So, the EMAP decapsulates packets from the MN to the CN and encapsulates packets from the CN to the MN on the other hand. Appendix A: Protocol Extensions In this section, support for plural EMAPs and route optimization is described as protocol extensions. When an EMD is a large network such as cellular network, plural EMAPs and route optimization within a single EMD may be required from the viewpoint of load sharing and efficient use of wired network resources. In this case, all EMAPs should be on the same link to preserve location privacy. So, all ARs within the EMD to advertise EMAPs prefix as well as above basic description. This extension requires the MN to send the message to an AR for handover. Since context transfer between ARs is needed to take over some information of the MN, such as the EMAP address which manages the MN and the AR address where a CN connects, when the MN communicating with the CN on the optimized routing path moves from one router to another. I. Akiyoshi Expires - April 2006 [Page 8]
Internet Draft NETLMM Protocol October 2005 Attachment procedure is shown in Figure 4. AR1 performs almost in the same way as in Figure 2. The difference is that AR1 performs EMAP discovery procedure to get an EMAP's IP address for the MN, when AR1 detects the attachment. The mechanism is that AR1 obtains the EMAP address by requesting from a control server which manages states of EMAPs or performing similar procedure as Dynamic Home Agent Discovery procedure of MIPv6[2]. After EMAP discovery procedure, the AR1 sends LR Req to the MN's EMAP (EMAP1). EMAP1 operation is the same as the operation described in Figure 2. When EMAP1 performs DAD on the local link representing the EMAPs prefix, other EMAPs should listen to associated solicitations and perform kind of Proxy DAD for the registered MN. MN AR1 EMAP1 | | | | Attach | | |----------------->| | | (MN-IP) | | | | | | +-----------------+ | | | EMAP Discovery | | | +-----------------+ | | | | | Location Registration Request | |-------------------->| | |(MN-ID, MN-IP, AR1-IP) | | | | Location Registration Acknowledgement | |<--------------------| | | | | | | Figure 4: Attachment procedure Route optimization procedure is shown in Figure 5. The arrows with a wiggly line and a dual line in this figure indicate original data flows and tunneled data flows respectively. When AR1 receives a data packet from the MN to a CN attached to AR2 within the same EMD, AR1 verifies if the destination address has a same prefix as the EMAPs subnet. If the destination address has the same prefix, AR1 starts route optimization procedure. Otherwise AR1 performs packet processing operation described in subsection 4.2. AR1 tries to get the EMAP which manages the CN to inquire an AR address where the CN attaches. The detailed mechanism is still undefined, but AR1 may inquire it from EMAPs. The key for the inquiry is the CN's IP address. And then, the AR1 sends an AR query message to the EMAP2. The message includes the CN's IP address. I. Akiyoshi Expires - April 2006 [Page 9]
Internet Draft NETLMM Protocol October 2005 Receiving the AR query message, EMAP2 searches an AR address where the CN attached. The key for the search is the CN's IP address included in the AR query message. And then EMAP2 sends a Reply message to notify AR1 of the AR address where the CN attaches. AR1 sends a LR Req to AR2 after getting the AR address where the CN attaches. The message is used to notify AR2 of the mapping between the MN and AR1 where the MN attaches. The LR Req may not include the MN-ID. And then, AR1 creates a LR List entry for route optimization. Receiving the LR Req message, AR2 verifies if the LR Cache entry for route optimization already exists or not. Unless AR2 already has the entry, AR2 creates a new entry in its LR Cache entry for it. If AR2 already has the entry, AR2 updates the entry. If necessary, AR2 may send a LR Ack message to AR1. After the route optimization procedure, AR2 tunnels data packets, whose source and destination are IP address of the CN and the MN respectively, to AR1 directly. MN AR1 EMAP1 EMAP2 AR2 CN | | | | | | |Data Packet | | | | | |~~~~~~~~~~~>|============>|~~~~~~~~~~~~>|============>|~~~~~~~~~~~>| | | | | | | | | AR Query | | | | |-------------------------->| | | | | (CN-IP) | | | | | | | | | | | Reply | | | | |<--------------------------| | | | | (CN-IP, AR2-IP) | | | | | | | | | | | Location Registration Request | | | |---------------------------------------->| | | | (MN-IP, AR1-IP) | | | | | | | | | Location Registration Acknowledgement (If necessary) | | |<----------------------------------------| | | | | | | | |Data Packet | | | | | |<~~~~~~~~~~~|<========================================|<~~~~~~~~~~~| | | | | | | | | | | | | Figure 5: Route Optimization procedure I. Akiyoshi Expires - April 2006 [Page 10]
Internet Draft NETLMM Protocol October 2005 Handover procedure is shown in Figure 6. When the MN moves from AR1 to AR3, the MN sends a handover message to AR2. The message should include some information related to a previous AR, since the new AR needs to take over some contexts related to the MN from the previous AR. The context includes an EMAP address which manages the MN and an AR address where the CN attaches at least. Receiving the handover message, AR3 derives AR1 address from previous AR information included in the handover message. And then, AR3 sends a Context Transfer Request message to AR1. When AR1 receives the Context Transfer Request message, AR1 sends EMAP1 address which manages the MN and AR2 address which the MN communicates, if any. Receiving the Context Transfer Acknowledgement message, AR3 creates the LR List entry for the registration to EMAP1. If AR address is transferred, AR3 also creates the LR List entry for the registration to the AR. Then AR3 sends a LR Req message to EMAP1 to register the MN's new location. When EMAP1 receives the LR Req message, EMAP1 updates the LR Cache entry and send a LR Ack message back to AR3. And then EMAP1 also sends a LD Req message to AR1 to delete the cache entry on it. If AR address is transferred from AR1 to AR3, the AR3 sends a LR Req message to let AR2 update the entry in its LR Cache entry for it. Updating the cache, AR2 may send a LR Ack message as the reply, if necessary. I. Akiyoshi Expires - April 2006 [Page 11]
Internet Draft NETLMM Protocol October 2005 MN AR1 AR3 EMAP1 AR2 CN | | | | | | |Data Packet | | | | | |~~~~~~~~~~~>|========================================>|~~~~~~~~~~~>| | | | | | | O Move to AR3| | | | | | | | | | | | Handover | | | | |------------------------->| | | | (MN-ID or MN-IP, previous AR info) | | | | | | | | | | Context Transfer Request | | | | |<------------| | | | | (MN-Id or MN-IP) | | | | | | | | | | Context Transfer Acknowledgement | | | | |------------>| | | | | (EMAP1-IP, AR2-IP) | | | | | | | | | | | Location Registration Request | | | | |------------>| | | | | (MN-ID, MN-IP, AR3-IP) | | | | | | | | | | Location Registration Acknowledgement | | | | |<------------| | | | | | | | | | | | | | | | Location Deregistration Request | | | |<--------------------------| | | | | (MN-ID, MN-IP) | | | | | | | | | | Location Registration Acknowledgement | | | |-------------------------->| | | | | | | | | | | | | | | | | Location Registration Request | | | |-------------------------->| | | | | (MN-IP, AR3-IP) | | | | | | | | | | Location Registration Acknowledgement (If necessary) | | |<--------------------------| | | | | | | | |Data Packet | | | | | |<~~~~~~~~~~~~~~~~~~~~~~~~~|<==========================|<~~~~~~~~~~~| | | | | | | | | | | | | Figure 6: Handover procedure I. Akiyoshi Expires - April 2006 [Page 12]
Internet Draft NETLMM Protocol October 2005 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Aboba, et. al., B., "The Network Access Identifier", RFC2486, Jan. 1999. [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for IP Local Mobility", Internet- Draft, draft-kempf-netlmm-nohost-ps-00, June 2005. [6] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Requirements and Gap Analysis for IP Local Mobility", Internet-Draft, draft-kempf-netlmm-nohost-req-00, July 2005. [7] Thomson, S., Narten, T., Jinmei, T., "IPv6 Stateless Address Autoconfiguration", Internet-Draft, draft-ietf-ipv6-rfc2462bis-08, May 2005. [8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [9] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host Identity Protocol", Internet Draft, work in progress. [10] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol", Internet Draft, work in progress. I. Akiyoshi Expires - April 2006 [Page 13]
Internet Draft NETLMM Protocol October 2005 Author's Addresses Ippei Akiyoshi NEC Corporation 1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa, Japan Phone: +81 44 396 2807 Email: i-akiyoshi@ah.jp.nec.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 Email: marco.liebsch@netlab.nec.de Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. 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 implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, I. Akiyoshi Expires - April 2006 [Page 14]
Internet Draft NETLMM Protocol October 2005 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights I. Akiyoshi Expires - April 2006 [Page 15]