NETLMM BOF G. Giaretta Internet Draft I. Guardini Expires: April 14, 2006 E. Demaria Tilab October 14, 2005 Network-based localized mobility management (NETLMM) with distributed anchor routers 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 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes a network-based local mobility management protocol that implies minimal host involvement in mobility management procedures and fulfills the requirements provided in draft-kempf-netlmm-nohost-req-00. Giaretta, et al. Expires April 14, 2006 [Page 1] Internet-Draft NETLMM Protocol October 2005 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]. Giaretta, et al. Expires April 14, 2006 [Page 2] Internet-Draft NETLMM Protocol October 2005 Table of Contents 1. Introduction...................................................4 2. Terminology....................................................5 3. Reference architecture.........................................6 4. Protocol Overview..............................................7 5. Protocol Specification........................................11 5.1. Conceptual Data Structures...............................11 5.2. Visited Access Router Operation..........................12 5.2.1. HAR discovery.......................................12 5.2.2. Sending Location Updates............................13 5.2.3. Receiving Location Acknowledgements.................13 5.2.4. Packet processing...................................13 5.3. Home Anchor Router Operation.............................14 5.3.1. Receiving Location Updates..........................14 5.3.2. Sending Location Acknowledgements...................14 5.3.3. Packet Processing...................................14 6. Allocation of a centralized HAR within the LMMD...............16 7. Neighbor Discovery Considerations.............................17 8. Host Considerations...........................................19 8.1. Access through Neighbor Discovery........................19 8.2. Access through PANA/DHCP.................................23 9. Packets Formats...............................................27 10. Security Considerations......................................28 11. References...................................................29 11.1. Normative References....................................29 11.2. Informative References..................................29 12. Appendix A: Support for Route Optimization...................31 12.1. Basic Operation.........................................31 12.2. Management of host movements............................34 12.3. Recovery from error conditions..........................35 Authors' Addresses...............................................38 Intellectual Property Statement..................................39 Disclaimer of Validity...........................................39 Copyright Statement..............................................39 Acknowledgment...................................................39 Giaretta, et al. Expires April 14, 2006 [Page 3] Internet-Draft NETLMM Protocol October 2005 1. Introduction draft-kempf-netlmm-nohost-ps-00 [8] briefly describes the local mobility problem and describes the two most serious issues with existing protocols: the requirement for host support, and the complex security interactions required between the host and the network. A more complete list of requirements for a localized mobility management solution is provided in [9]. This document describes a network-based mobility management protocol that implies minimal host involvement in mobility management procedures and fulfills the requirements provided in [9]. The document is organized as follows: section 3 describes the reference network architecture and the reference scenario. Section 4 provides an overview of the protocol and section 5 describes the detailed protocol specification and related data structures. Section 6 describes an optional feature of the protocol to increase the degree of location privacy provided to hosts and section 7 raises some possible issues with standard Neighbor Discovery. Section 9 lists some approaches that can be used by hosts to configure their addresses and to trigger mobility management procedures. Finally, appendix A gives an overview on how the protocol may be extended to provide optimal routing to data packets. Giaretta, et al. Expires April 14, 2006 [Page 4] Internet-Draft NETLMM Protocol October 2005 2. Terminology General mobility terminology can be found in [4]. The following additional terms are used here: HAR Home Anchor Router. A router that provides mobility anchor point functionalities to a host. The HAR can be co-located with the Access Router where the host switches on or can be a separate node different from any Access Router. VAR Visited Access Router. The Access Router where the host is located. The VAR provides the HAR with the current location of the host. Location Cache This cache contains an entry for each host which the node is acting as HAR for. Its purpose and format are very similar to Mobile IPv6 Binding Cache. Location Update List This cache contains an entry for each host the Access Router acts as VAR. Its purpose and format are very similar to Mobile IPv6 Binding Update List. Giaretta, et al. Expires April 14, 2006 [Page 5] Internet-Draft NETLMM Protocol October 2005 3. Reference architecture The protocol described in this document can be used to handle IP mobility within an Localized Mobility Management Domain (LMMD). The reference network architecture is shown in Figure 1. A single LMMD can span a whole administrative domain (e.g. the network of an operator) or part of it. The edge of the LMMD is made of Access Routers (ARs) and Border Gateways (BGs). An AR can manage one or more IP links (i.e. layer 2 access networks), each one univocally associated with at least an IPv6 prefix. It represents the first IP router encountered by the mobile node on the way to the destination. The BGs are used to interconnect the LMMD with external networks, which can be traditional IP networks like the Internet or other LMMDs. There are no constraints on the internal topology of an LMMD. +--------------------------------+ | | +-----------------+ | LMM +---+ | External | | Domain |BG |--| Network | | +---+ | (e.g. Internet) | | | +-----------------+ | +---+ +---+ +---+ | | +---|AR1|-----|AR2|-----|AR3|----+ | +---+ +---+ +---+ +--+ | | | |CN| L2 | | | +--+ Access | | | -+-+-+- -+-+-+- -+-+-+- | | | | | | Base O O O O O O Stations Prefix-1 Prefix-2 Prefix-3 +--+ +--+ |MN| ----> |CN| +--+ Movement +--+ MN's address: IP-MN Figure 1 - Reference architecture As long as the mobile node remains within the same LMMD, it can keep on using the same IP address even if it happens to change the AR it is attached to. Giaretta, et al. Expires April 14, 2006 [Page 6] Internet-Draft NETLMM Protocol October 2005 4. Protocol Overview Each AR sends Router Advertisement messages as described in [2]. These RAs include one or more prefix options that are specific to the link. In case stateless auto-configuration can be used, the bit A in the prefix option is set to one. When a mobile node (MN) powers up on a link, it configures an address through an address configuration mechanism: stateless autoconfiguration [3], DHCP [7] or a AAA-based mechanism can be used for this purpose. The address configured by the host is topologically correct since it belongs to the network prefix announced by the Access Router. As soon as the host has configured an address, the Access Router receives an indication of the presence of the host. This is depicted in Figure 2 as an activate message. This message may be a Router Solicitation, a Neighbor Solicitation, an unsolicited Neighbor Advertisement or it can be a network trigger after the address configuration procedure. Figure 2 depicts the host and AR operation when the host activates on a link. When the AR receives an activate message including an IP address that belongs to one of its network prefixes, it does not need to perform any mobility management procedure. The traffic to and from the host is delivered using standard IP routing, which means that it is not tunneled. This is an important feature of the protocol since it does not introduce any packet or signaling overhead for nodes that are not moving or for nodes with limited mobility requirements. This scenario is similar to the case of a Mobile IPv6 MN located in the home network. Giaretta, et al. Expires April 14, 2006 [Page 7] Internet-Draft NETLMM Protocol October 2005 +--+ +---+ +---+ +--+ |MN| |AR1| |AR2| |CN| +--+ +---+ +---+ +--+ | | | | | /-----------\ | | | |/ Address \| | | |\ conf. /| | | | \-----------/ | | | | | | | |Activate (IP-MN) | | |-------------->| | | | | | | | Plain data packets (no tunneling) | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| Figure 2 - MN bootstrapping and routing from/to the home network When the MN moves to another link, it sends an activate message to the new AR (AR2 in Figure 3) with an indication of the IP address used on the previous link. The type of indication depends on the implementation of the activate message: some examples are described in section 8. The AR acts as the Visited Access Router for the host. Based on the IP address provided by the host the VAR discovers its HAR: this can be done based on an exchange with a topology server (i.e. a data-base maintaining the correspondence between prefixes and HARs) or based on records already present in the VAR. Once identified the HAR of the host, the VAR sends a Location Update message to the HAR including its own address and the IP address of the host. The HAR adds a new entry in its Location Cache and replies with a Location Acknowledgement message. The result of this message exchange is the set up of a bi-directional tunnel between HAR and VAR. HAR intercepts all packets sent to the host and forwards them to the tunnel interface. From an implementation point of view, since several hosts can share the same HAR and can be on the same VAR's link at the same time, HAR and VAR can share an unique tunnel for all these hosts. Giaretta, et al. Expires April 14, 2006 [Page 8] Internet-Draft NETLMM Protocol October 2005 HAR of MN VAR of MN +--+ +---+ +---+ +--+ |MN| |AR1| |AR2| |CN| +--+ +---+ +---+ +--+ | | | | Moves | | | to AR2 | | | | Activate (IP-MN) | | |------------------------------->| | | | | | | Location Update (IP-MN,AR2) | | |<---------------| | | +--------+ | | | |Location| | | | | Cache | | | | | Update | | | | +--------+ | | | | Location Ack. | | | |--------------->| | | | | | | | Plain data packets (no tunneling) | | O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | O Tunnel | | | O===============>O | | | O | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O | Figure 3 - First MN movement and Location Update Subsequent MN's movements are handled in the same way as the described in Figure 3. The only difference is highlighted in Figure 4: when the HAR receives a Location Update message from a new VAR, it updates its Location Cache and should send a Move Notify message to the old VAR (AR2 in Figure 4) including the IP address of the host. This can be needed in networks where AR2 does not have an explicit indication that host has moved. When it receives a Move Notify message, the VAR must delete the host- specific entry in its Location Update List. Giaretta, et al. Expires April 14, 2006 [Page 9] Internet-Draft NETLMM Protocol October 2005 HAR of MN VAR of MN +--+ +---+ +---+ +---+ +--+ |MN| |AR1| |AR2| |AR3| |CN| +--+ +---+ +---+ +---+ +--+ | | | | | Moves | | | | to AR3 | | | | | Activate (IP-MN) | | |--------------------------------------------->| | | | | | | | | Location Update (IP-MN,AR3) | | | |<-----------------------------| | | | | | | | +--------+ | | | | |Location| | | | | | Cache | | | | | | Update | | | | | +--------+ | | | | | Location Acknowledge | | | |----------------------------->| | | | | | | | Move Notify (IP-MN) | | | |------------>| | | | | | | | | | Move Ack. | | | | |<------------| | | | | | | | | | Plain data packets (no tunneling) | | O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | O HAR-VAR tunnel | | | O=============================>O | | | | O | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O | | | | | | Figure 4 - Subsequent MN movements Giaretta, et al. Expires April 14, 2006 [Page 10] Internet-Draft NETLMM Protocol October 2005 5. Protocol Specification This section provides the detailed description of the protocol. As mentioned in the overview, the entities that are introduced in this document are the Visited Access Router (VAR) and the Home Anchor Router (HAR): the detailed operation of both of them is described in following sections. Before that, the data structures that VAR and HAR need to implement are described. 5.1. Conceptual Data Structures The conceptual data structures introduced in this document are: the Location Cache (LC), the Location Update List (LUL), the Prefix Cache (PC) and the Active Visitors List (AVL). The Location Cache must be implemented by each HAR. Its purpose and format are very similar to Mobile IPv6 Binding Cache. It contains an entry for each host which the node is acting as HAR for. Conceptually, each Location Cache entry contains the following fields: o the IP address of the host for which this is the Location Cache entry; o the IP address of the VAR where the host is located. This is updated based on Location Update messages received by the HAR; o a lifetime value, indicating the remaining lifetime for this Location Cache entry. The lifetime value is initialized from the Lifetime field in the Location Update message; o the maximum value of the Sequence Number field received in previous Location Updates. The Location Update List must be implemented by each VAR. Its purpose and format are very similar to Mobile IPv6 Binding Update List. It contains an entry for each host the Access Router acts as VAR. Each Location Update List entry conceptually contains the following fields: o the IP address of the host for which this is the Location Update List entry; o the IP address of the HAR of the host; o the value of the Lifetime field sent in the last Location Update message; o the remaining lifetime for this Location Update List entry. This value is used by the VAR to schedule subsequent Location Update messages; Giaretta, et al. Expires April 14, 2006 [Page 11] Internet-Draft NETLMM Protocol October 2005 o the maximum value of the Sequence Number field sent in previous Location Updates to this HAR. The Prefix Cache must be implemented by each VAR. The purpose of this cache is to bind network prefixes to Home Anchor Routers. It is used by VARs to determine the HAR of the host that has sent an activate message. Prefix Cache entries can be statically configured or dynamically created based on queries to a topology server or based on some other protocols. The specification of the mechanisms used by Access Routers to fill this cache is out of the scope of this document. Each entry of the Prefix Cache conceptually contains the following fields: o the network prefix for which this is the Prefix Cache Entry. This field is used as the key for searching the Home Anchor Router of a host; o the IP address of node that acts as Home Anchor Router for the network prefix in the Prefix field; o the remaining lifetime of that matching. The Activate Visitors List must be implemented by all VARs. It contains an entry for each host connected to the VAR. This list is updated through activate messages and therefore can be implemented as part of Neighbor Discovery specific caches (e.g. Destination Cache, Neighbor Cache). This list is used if the link layer does not provide any hint on the presence of the host. Conceptually, each Activate Visitors List entry contains the following fields: o the IP address of the host the entry is related; o the time of the last hint of host's presence received by the VAR; o the remaining lifetime: this field is re-initialized when the VAR receives a hint of host presence. When this lifetime expires, the VAR removes the entry. 5.2. Visited Access Router Operation 5.2.1. HAR discovery When a host attaches to a new link, it sends an activate notification. This notification can be a neighbor discovery message (e.g. Router Solicitation) or a network trigger after the authentication procedure (e.g. PANA Bind Answer, an internal trigger from the AAA infrastructure) and must contain the global IP address of the host. Based on the global IP address provided by Giaretta, et al. Expires April 14, 2006 [Page 12] Internet-Draft NETLMM Protocol October 2005 the host, the VAR must identify a HAR for that host. This information is gathered from the Prefix Cache. The key for searching this information is the network prefix of the host address: since the VAR cannot be aware of the prefix length, a longest prefix match approach is applied. Once the VAR has identified a HAR for a host, it sends a Location Update. 5.2.2. Sending Location Updates A VAR sends a Location Update message whenever a new host attaches on its link or when the remaining lifetime field of a Location Update List entry is going to expire. The Location Update message is sent to the HAR of the host: this is discovered through the procedure described in section 5.2.1 for the initial Location Update and is gathered from the HAR field in the Location Update List entry for subsequent Location Updates. The Location Update message includes the IP address provided by the host, a sequence number and a lifetime value. By means of the Location Update the VAR requests the Home Anchor Router to serve as the Home Anchor Router for the given IP ddress. When sending the Location Update to the HAR, the VAR must also create or update the corresponding Location Update List entry. The last Sequence Number value sent to the HAR in a Location Update is stored by the VAR in its Location Update List entry. If the sending VAR has no Location Update List entry, the Sequence Number should start at a random value. 5.2.3. Receiving Location Acknowledgements When the VAR receives a Location Acknowledgement (LA) with Status 0 (success), it should track this in the Location Update List and it must start tunneling the packets from the host to the HAR. The outcome of a successful LU-LA exchange is the set up of a bi- directional tunnel between VAR and HAR that carries all packets from/to the host. When the VAR receives a Location Acknowledgement with Status greater than 128 it must remove the entry in the Location Update List. In particular, if the Status is 129 (DAD failed), it must notify the host that the IP address currently in use is no longer valid and another IP address has to be configured. The way this notification is delivered depend on the access protocol employed between MN and VAR (e.g. Neighbor Discovery, DHCP, PANA). 5.2.4. Packet processing As mentioned before, the outcome of a LU-LA exchange is the set-up of a bi-directional tunneling between the VAR and HAR. The tunnel end-points are the IP address of the VAR and the IP address of the Giaretta, et al. Expires April 14, 2006 [Page 13] Internet-Draft NETLMM Protocol October 2005 HAR. The same tunnel can be shared by all hosts; in this case, after a LU-LA exchange, the VAR needs only to update its forwarding table so that all traffic from and to the host is tunneled through the HAR. 5.3. Home Anchor Router Operation 5.3.1. Receiving Location Updates When a HAR receives a Location Update, it validates it checking that the host's IP address belongs to one of the network prefixes it announces and the sequence number is a correct one. If the Location Update is valid, the HAR searches in its Location Cache using the host's IP address as a key. If an entry is present, the HAR updates the entry. If no entry is present in the Location Cache for the IP address of the host and the Location Update has been validated, the HAR MUST create a new entry in its Location Cache for the host. In this case, before returning the Location Acknowledgement, the HAR MUST perform Duplicate Address Detection. This ensures that no other node on the link is using the host's address. If this Duplicate Address Detection fails for the given address, then the HAR MUST reject the complete Location Update, remove the Location Cache entry and MUST return a Location Acknowledgement to the VAR with the Status field set to 129 (DAD failed). 5.3.2. Sending Location Acknowledgements If all checks performed after receiving a Location Update has been successful, the HAR sends to the VAR a Location Acknowledgment with Status field set to 0. The HAR may refuse a Location Update. In this case it must send a Location Acknowledgement with Status field greater than 128. In particular, if the DAD for the IP address of the host has failed, the HAR must send a Location Acknowledgement with Status 129 (DAD failed). 5.3.3. Packet Processing When the HAR has a valid Location Cache entry in its Location Cache, it starts performing proxy Neighbor Discovery and defending the host's IP address. Moreover, the HAR must intercept packets that are addressed to the host. This is done in the same way a Mobile IPv6 Home Agent intercepts Mobile Node's packets [10]. When the HAR intercepts a packet to a host, it must lookup in its Location Cache to get the location of the host (i.e. the VAR) and must tunnel the packet to the VAR. Giaretta, et al. Expires April 14, 2006 [Page 14] Internet-Draft NETLMM Protocol October 2005 The HAR must also handle reverse tunneled packets since VAR tunnels packets from the host to the HAR. The HAR must decapsulate the packet and forward it to the actual destination. As in Mobile IPv6, the HAR MUST verify that the Source Address in the tunnel IP header is the host's IP address present in the Location Cache entry. Giaretta, et al. Expires April 14, 2006 [Page 15] Internet-Draft NETLMM Protocol October 2005 6. Allocation of a centralized HAR within the LMMD The protocol described in this document can be used also in network scenarios where the HAR assigned to the MN is not co- located with any of the available ARs, but is implemented as a dedicated piece of equipment associated with the whole LMMD. In this case, at power on (or the first time it enters the LMMD) the MN has to be configured with an IP address belonging to the "virtual link" managed by the centralized HAR. Standard Neighbor Discovery (ND) cannot be used for that purpose, in that the network prefix for stateless autoconfiguration is different from the one announced by the AR on the access interface. Instead, these are some possible suitable solutions: o the inclusion of a HAR Option in Router Advertisement (RA) messages. This option, which is similar to the MAP Option defined for Mobility Anchor Point discovery in HMIPv6 [10], could be used to carry the IP address of the HAR and the related prefix information; o the usage of standard DHCPv6; o the usage of PANA or EAP for assigning a global IPv6 address during the authentication procedure for network access. In this case the IPv6 address, and the correspondent HAR, to be allocated to the MN can be selected by the AAA server and then delivered to the MN by means of some newly defined AVPs/TLVs. Maintaining one or more HARs separated from the ARs has the advantage of improving location privacy, in that the IP address assigned to the MN does not disclose any information on the actual point of attachment of the MN within the LMMD. The drawback of this architecture is that data traffic exchanged by the MN gets always tunneled in the fixed network (i.e. higher overhead), since the MN can never be connected to its HAR (i.e. it is attached to a VAR at any time). Giaretta, et al. Expires April 14, 2006 [Page 16] Internet-Draft NETLMM Protocol October 2005 7. Neighbor Discovery Considerations Based on the protocol described in this document the host does not change its IP address after an IP handover. This implies that within a Localized Mobility Management Domain the host maintains the same IP address independently from its movements and its actual location. This feature of the protocol may arise some issues related to Neighbor Discovery and how the address resolution is made by hosts. When the host powers up on a link it gets an IP address specific to that link. The correspondent nodes that belong to the same IP link can send packets to the host directly after performing an address resolution procedure based on [2]. This is true if the prefixes announced by the Access Router have the bit L set, which implies that the prefix is used by hosts for on-link determination. When the host has moved, the scenario is similar to a movement of a Mobile IPv6 MN from the home network to a foreign network. The HAR starts performing Proxy Neighbor Discovery and the packets to the host are intercepted by the HAR and forwarded to the host itself. A scenario that may arise some issues related to Neighbor Discovery is the following: the host moves from one foreign network to another. While in the first foreign network, the host may communicate with a correspondent node located in the same link. In this case, if the prefix option sent by the VAR has the L bit set, the host understands that the correspondent node is in the same link. Therefore, it may perform an address resolution procedure with a Neighbor Solicitation and Neighbor Advertisement exchange in order to get the link local address of the correspondent node. In the Neighbor Solicitation message, based on [2], the host MUST include its link-layer address in a Source Link-Layer Address option. This implies that the correspondent node is aware of the link-layer address of the host and the communication takes place directly, without any involvement of the VAR. However, as soon as the host moves to another link, the correspondent node does not have any mechanism to quickly understand that the host is no more in its link. The unique tool provided by Neighbor Discovery for that purpose is the Neighbor Unreachability Detection procedure [2] but it requires a large amount of time that may disrupt real-time on-going communications. To avoid these problems, the VAR SHOULD send Router Advertisements with the L flag unset in the prefix option: this implies that hosts do not perform address resolution procedures with its correspondent nodes and therefore the communication always occurs through the Access Router. Based on the same motivations, the Access Router SHOULD NOT send Redirect messages to the correspondent nodes to inform them that Giaretta, et al. Expires April 14, 2006 [Page 17] Internet-Draft NETLMM Protocol October 2005 the host is on-link. The Access Router MAY send Redirect messages only if it is aware that both host and correspondent node are fixed and thus the issue described above does not apply. Giaretta, et al. Expires April 14, 2006 [Page 18] Internet-Draft NETLMM Protocol October 2005 8. Host Considerations The mobility management protocol specified in this document is independent from the procedure followed by the mobile node to gain access to the network, and is therefore applicable to several deployment scenarios (ISP, enterprise, etc.). Movement detection can be carried out using unsolicited Router Advertisements (RAs) with Interval Option, as specified in [10], or exploiting available optimizations to further reduce the handoff latency, such as DNA protocol [13][14][15][18] or L2 triggers. The impacts on the mobile node are minimal and are limited to slight modifications in the way IP addresses are renewed across mobility events. After any link change, a host compliant with this specification SHOULD always try to keep the IP address used in the previous point of attachment, unless an explicit indication to release it is received from the network. In order to enable this model, the employed access protocol(s) MUST be compliant with the following assumptions: o it MUST be possible for the MN to request the confirmation of the IP address used in a previously visited link; o it MUST be possible for the network (e.g. AR) to signal to the MN that an IP address cannot be reconfirmed and has to be immediately released (e.g. the MN has moved to a new LMMD). Possible access protocols that fulfill these requirements include: o Neighbor Discovery (ND), eventually coupled with CGAs for testing address ownership; o the usage of PANA together with DHCP. A few examples showing how to use ND and/or PANA in conjunction with the protocol described in this document are provided in the following sections. Other viable options may be the sole usage of DHCP or the exploitation of L2 protocols (or triggers) specific of the radio technology employed in the access network. 8.1. Access through Neighbor Discovery MN bootstrap using ND can be carried out as shown in Figure 5. Giaretta, et al. Expires April 14, 2006 [Page 19] Internet-Draft NETLMM Protocol October 2005 +--+ +---+ +---+ |MN| |AR1| |AR2| +--+ +---+ +---+ | | | +--------+ | | | Build | | | |LL addr.| | | +--------+ | | | NS (LL addr.) | DAD for link-local | |----------------------->| address | | | | +--------+ | | | Conf. | | | |LL addr.| | | +--------+ | | | RS | | |----------------------->| | | | | | RA (Prefix-1,bit A=1, | | | lifetime=infinite) | RA can be unsolicited | |<-----------------------| Valid and Preferred | | | lifetimes of advert. | +--------+ | prefixes are infinite | | Build | | | | global | | | +--------+ | | | NS (IP-MN) | DAD for global | |----------------------->| address | | | | | +----------------------+ | | |Verify addr. ownership| | | | (if IP-MN is CGA) | | | +----------------------+ | | | | | +------------+ | +--------+ |Enable IP-MN| | | Conf. | +------------+ | | global | | | +--------+ | | | | | Figure 5 - ND: MN bootstrap The procedure involves the following steps: o at power-on the MN builds a link-local address and performs Duplicate Address Detection (DAD). If the address proves to be unique, the MN configures it on its network interface; Giaretta, et al. Expires April 14, 2006 [Page 20] Internet-Draft NETLMM Protocol October 2005 o MN performs router discovery sending a Router Solicitation (RS) to the all routers multicast address; o AR responds with a solicited Router Advertisement (RA) including one or more Prefix Options, listing the IPv6 prefixes that can be used by the MN to build a valid global address through stateless autoconfiguration (i.e. bit A set to 1). Each prefix SHOULD be advertised with Valid and Preferred lifetimes set to infinite; o MN builds one or more global addresses through stateless autoconfiguration and performs a DAD check for each of them; o AR uses the Neighbor Solicitation (NS) message delivered as part of the DAD procedure as a trigger indicating the MN is asking the activation of a specific global address (i.e. IP-MN in Figure 5); o if the global address is a CGA (Cryptographically Generated Address) [6], AR can use the validity check specified in [5] to verify whether the MN is entitled to claim the ownership of the address. Otherwise, based on policy rules defined by the network administrator, the AR can decide to reject the request or to accept it all the same; o upon successful verification of the address ownership, AR enables the global address claimed by MN (e.g. adjustment of ingress filtering rules); o at the expiration of the time-out involved by the DAD procedure [3], the MN configures the global address on its network interface and starts using it. As long as the MN remains connected to the AR where it switched on, any communication can be carried out using standard IP routing, since the MN is using a topologically correct address. Subsequent movements can be handled as shown in Figure 6. Giaretta, et al. Expires April 14, 2006 [Page 21] Internet-Draft NETLMM Protocol October 2005 +--+ +---+ +---+ |MN| |AR1| |AR2| +--+ +---+ +---+ | | | Moves | | to AR2 | | | | | +------------+ | | |Detect loss | | | |of RAs from | | | |AR1 through | | | |int. option | | | +------------+ | | | NS (AR1) | | |----------------->X Neighbor Unreachability | |-------------->X Detection (NUD) for AR1 | | | | +------------+ | | |No replies: | | | |detects mov.| | | +------------+ | | | RS | | |------------------------------------------------->| | RA (Prefix-2,Flag A=1,Lifetime=Infinite) | |<-------------------------------------------------| | | | | NS (IP-MN) | | DAD for |------------------------------------------------->| IP-MN | | | | | +-------------------+ | | |Verify addr. owner.| | | |(if IP-MN is CGA) | | | +-------------------+ | | /---------------------\ | | AR1 is HAR |/ NETLMM \| | for MN |\ Protocol /| | | \---------------------/ | | | +------------+ | | |Enable IP-MN| | | +------------+ | | | Figure 6 - ND: mobility Giaretta, et al. Expires April 14, 2006 [Page 22] Internet-Draft NETLMM Protocol October 2005 The procedure involves the following steps: o MN detects the movement as described in [10], and therefore, after having discovered the loss of a sequence of RAs, performs Neighbor Unreachability Detection (NUD) for the previous AR. Other approaches for movement detection may be suitable as well and the choice does not impact on the rest of the procedure; o MN performs router discovery on the new link sending a Router Solicitation (RS) to the all routers multicast address; o the AR available on the new link (i.e. AR2 in the example of Figure 6) responds with a solicited Router Advertisement (RA) including one or more Prefix Options. Optionally the MN can use this fresh prefix information to build one or more topologically valid global addresses through stateless autoconfiguration; o MN signals that it is willing to keep the previous global address performing a new DAD check for it. Optimistic DAD solutions [16] can be applied to shorten DAD latency and enable fast handovers; o at the reception of the NS sent out as part of the DAD procedure, the AR verifies the ownership of the global address claimed by the MN (if the address is a CGA) and then triggers the NETLMM Protocol to adjust host routing within the Localized Mobility Management Domain (LMMD). The HAR of the MN is the AR where the MN switched on (i.e. AR1 in the example of Figure 6); o if the NETLMM protocol completes successfully, the AR enables the global address and the MN can start using it for exchanging data traffic with its correspondents. 8.2. Access through PANA/DHCP In case the MN has to authenticate itself for gaining network access and the authentication procedure is carried out relaying on PANA [17], the bootstrap phase can be handled as described in Figure 7. The procedure involves the following steps: o at power-on the MN undertakes a full PANA authentication. The MN is the PANA Authentication Client (PAC) and the AR is the PANA Authentication Agent (PAA). The PAA works as a pass- through for EAP authentication, that involves the PAC and a backend AAA server; o at the end of the authentication phase, the backend AAA server verifies if the MN has to be handled using the NETLMM protocol. This check can be performed based on the subscription information included in the user service profile; Giaretta, et al. Expires April 14, 2006 [Page 23] Internet-Draft NETLMM Protocol October 2005 o if NETLMM protocol has to be enabled, the AAA server selects a suitable HAR and allocates a global address. The selected HAR can be co-located on the AR visited by the MN or can be a dedicated machine located somewhere else within the LMMD; o the AAA server communicates to the AR the global address allocated to the MN (and related lifetimes) inserting a NETLMM AVP in the RADIUS (or Diameter) Access-Accept message. This AVP may optionally include also the address of the correspondent HAR, so that the AR does not have to discover it afterwards; o at the reception of the Access-Accept message, the AR delivers to the MN a PANA-Bind-Request including a Post PANA Address Configuration (PPAC) AVP [17]. The Flag D included in the PPAC AVP is set to 1, indicating that the MN is expected to configure a Post PANA Address using DHCP; o the MN responds with a PANA-Bind-Answer and then, as mandated by the previous PANA-Bind-Request, undertakes a DHCP handshake to get a valid global address; o the AR works as a local DHCP server and offers to the MN the global address previously received from the AAA server; o the MN confirms that it is willing to accept the configuration offered by the AR in the DHCP Request; o at the reception of the DHCP Request, the AR activates the NETLMM protocol to adjust host routing within the LMMD; o if the NETLMM protocol terminates successfully, the AR enables the global address assigned to the MN (e.g. tuning of ingress filtering policies) and sends the DHCP Reply. Giaretta, et al. Expires April 14, 2006 [Page 24] Internet-Draft NETLMM Protocol October 2005 +--+ +---+ +---+ +---+ +---+ |MN| |AR1| |AR2| |AAA| |HAR| +--+ +---+ +---+ +---+ +---+ | PANA Start Req. | | | | |<--------------------| | | | | PANA Start Answ. | | | | |-------------------->| | | | | /-----------------\ | /-------------------------\ | | |/ PANA authentic. \|/ RADIUS \| | |\ (N round trips) /|\ or Diameter /| | | \-----------------/ | \-------------------------/ | | | | | | | | PANA-Auth-Answer | | | | | (EAP-Response) | RADIUS Access-Request | | |-------------------->| (EAP-Response) | | | |---------------------------->| | | | | +---------+ | | | | |Authoriz.| | | | | | & addr. | | | PANA-Bind-Request | RADIUS Access-Accept |selection| | | (EAP-Success,PPAC | (EAP-Success,NETLMM AVP)+---------+ | | with Flag D=1) |<---------------|------------| | |<--------------------| | | | | | PANA-Bind-Answer | | | +--------------+ | |-------------------->| | | |IP address | | | DHCP Solicit | | +-->|to be assigned| | |-------------------->| | |to MN (IP-MN) | | | DHCP Advertise | | +--------------+ | |<--------------------| | | | | DHCP Request | | | | |-------------------->| | | | | | /-----------------------------------\ | | |/ NETLMM \| | |\ Protocol /| | | \-----------------------------------/ | | +------------+ | | | | |Enable IP-MN| | | | | DHCP Reply +------------+ | | | |<--------------------| | | | | | | | | Figure 7 - PANA/DHCP: MN bootstrap Any subsequent movement of the MN can be handled as depicted in Figure 8. The procedure involves the following steps: o after having attached to a new link, the MN has to repeat the PANA authentication procedure; Giaretta, et al. Expires April 14, 2006 [Page 25] Internet-Draft NETLMM Protocol October 2005 o as part of the authorization phase, the AAA server verifies whether the new AR (i.e. the PAA) is located within the same LMMD from which the previous access took place. If this is the case, the AAA server delivers to the new AR (through the NETLMM AVP) the IP address that was previously allocated to the MN. Otherwise, the AAA server allocates to the MN a new global address valid within the new LMMD; o the MN tries to keep the same IP address used in the previous link sending a DHCP Confirm; o at the reception of the DHCP Confirm, the AR verifies whether the IP address claimed by the MN is the same received from the AAA infrastructure. If this is the case, the AR activates the NETLMM protocol, enables the address and delivers a successful DHCP Reply to the MN. +--+ +---+ +---+ +---+ +---+ |MN| |AR1| |AR2| |AAA| |HAR| +--+ +---+ +---+ +---+ +---+ | | | | | Moves | | | | to AR2 | | | | | /------------------------------\ | /------------\ | | |/ PANA \|/ RADIUS or \| | |\ session /|\ Diameter /| | | \------------------------------/ | \------------/ | | | | | | | | DHCP Confirm (IP-MN) | | | |--------------------------------->| | | | | | /----------------------\ | | | |/ NETLMM \| | | |\ Protocol /| | | | \----------------------/ | | | +------------+ | | | | |Enable IP-MN| | | | DHCP Reply | +------------+ | | |<---------------------------------| | | | | | | | Figure 8 - PANA/DHCP: mobility Giaretta, et al. Expires April 14, 2006 [Page 26] Internet-Draft NETLMM Protocol October 2005 9. Packets Formats To be completed. Giaretta, et al. Expires April 14, 2006 [Page 27] Internet-Draft NETLMM Protocol October 2005 10. Security Considerations Location Update and Location Acknowledgement messages MUST be authenticated, integrity protected and optionally encrypted. IPsec MUST be used between HAR and VAR to protect the protocol signaling. The IPsec Security Associations shared by the ARs may be configured manually or dynamically set-up. Moreover, as mentioned in the draft, each IPsec Security Association can be used for traffic related to any MN since it is not MN-specific. This limits the number of SAs required by the protocol. This document does not specify a protocol for the interface between the Mobile Node and the Access Router. Some examples (Neighbor Discovery and PANA/DHCPv6) to implement this interface have been provided in this document but a deep security analysis has not been performed. Nonetheless, since any NETLMM solution implies that the MN does not change its IP address while moving across Access Routers that belong to the same LMMD, some generic issues related to MN-AR interface may arise. In particular, the Activate message, that is used by the MN to trigger NETLMM protocol operation, MUST be authenticated. Moreover, the Access Router must be sure that the IP address provided by the MN in the Activate Message has not been spoofed and is owned by the MN itself. Cryptographically Generated Addresses may be useful for this purpose but a AAA-based solution should be also investigated. It is worthwhile to mention that these issues are not specific to this NETLMM protocol, but apply to any NETLMM solution. Giaretta, et al. Expires April 14, 2006 [Page 28] Internet-Draft NETLMM Protocol October 2005 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T., Nordmark, E., Simpson, W., Soliman, H., "Neighbor Discovery for IP version 6 (IPv6)", Internet- Draft, draft-ietf-ipv6-2461bis-04, July 2005. [3] Thomson, S., Narten, T., Jinmei, T., "IPv6 Stateless Address Autoconfiguration", Internet-Draft, draft-ietf- ipv6-rfc2462bis-08, May 2005. 11.2. Informative References [4] Manner, J., Kojo, M., "Mobility Related Terminology", RFC 3753, June 2004. [5] Arkko, J., Kempf, J., Zill, B., Nikander, P., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [6] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [8] 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. [9] 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. [10] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [11] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [12] Soliman, H., Castelluccia, C., El Malki, K., Bellier, L., "Hierarchical Mobile IPv6 mobility management (HMIPv6)", RFC 4140, August 2005. [13] Choi, J., Nordmark, E., "DNA solution framework", Internet- Draft, draft-ietf-dna-soln-frame-00, April 2005. Giaretta, et al. Expires April 14, 2006 [Page 29] Internet-Draft NETLMM Protocol October 2005 [14] Narayanan, S., Daley, G., Montavont, N., "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", Internet-Draft, draft-ietf-dna-hosts-01, June 2005. [15] Choi, J., Nordmark, E., "DNA with unmodified routers: Prefix list based approach", Internet-Draft, draft-ietf- dna-cpl-01, April 2005. [16] Moore, N., "Optimistic Duplicate Address Detection for IPv6", Internet-Draft, draft-ietf-ipv6-optimistic-dad-05, February 2005. [17] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., Yegin, A., "Protocol for Carrying Authentication for Network Access (PANA)", Internet-Draft, draft-ietf-pana-pana-10, July 2005. [18] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Internet-Draft, draft-pentland-dna-protocol-01, July 2005. Giaretta, et al. Expires April 14, 2006 [Page 30] Internet-Draft NETLMM Protocol October 2005 12. Appendix A: Support for Route Optimization The basic protocol operation described in the previous sections may lead to sub-optimized routing paths, since data traffic addressed to a MN connected to a Visited Access Router (VAR) is always forwarded by the MN's Home Anchor Router (HAR). If the Localized Mobility Management Domain (LMMD) is very large, such as in the case of an LMMD spanning the whole network of an operator, this sub-optimal routing may generate an unacceptable increase in the end-to-end transfer latency as well as a significant waste of network resources. In order to solve these performance issues, the proposed protocol architecture has been extended with a route optimization procedure, that can be used to promptly switch to the shortest routing path, limiting transit through HAR to the first few data packets exchanged between MN and CN. The performance improvements of the route optimization procedure may depend on the network topology: if the HAR is not co-located with an Access Router (as described in section 6.1) and a star network topology is in place, it is possible that all packets are routed to the HAR anyway and therefore the route optimization procedure does not involve any performance improvement. 12.1. Basic Operation The basic route optimization procedure is shown in Figure 9. The first data packet transmitted from CN to MN is delivered using standard IP routing and therefore gets to MN's HAR, which tunnels it to MN's VAR. The need to perform forwarding through tunneling is treated by MN's HAR as an explicit indication that the origin of data traffic is not aware of the actual location visited by the MN. This triggers the route optimization procedure.Inspecting the source of received data packets, MN's HAR identifies the IP address of the CN. This information is used to discover the edge router that is injecting into the LMMD the data flow coming from the CN. This edge router can be: o the Access Router (AR) the CN is attached to, if the CN is an internal node connected to the same LMMD of the MN (this is the assumption made in the example of Figure 9), o or a Border Gateway (BG), if the CN is a node located in an external network. How to carry out this discovery procedure is out of the scope of the present specification. Possible technical approaches include: Giaretta, et al. Expires April 14, 2006 [Page 31] Internet-Draft NETLMM Protocol October 2005 o manual configuration on all ARs and BGs; o wild-card search within a data-base maintaining the list of available prefixes and correspondent HARs; o exploitation of topology information advertised within the routing protocol (e.g. iBGP, OSPF). HAR or MN VAR of MN +--+ +---+ +---+ +---+ +--+ |MN| |AR1| |AR2| |AR4| |CN| +--+ +---+ +---+ +---+ +--+ | | | | | | | First data packet from CN (no tunneling) | | Triggers O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<~~~~~~~~~| | delivery O Tunnel | | | | or RU O===========>O | | | | O | | |<~~~~~~~~~~~~~~~~~~~~~~~O | | | | | | | | | Route Update (IP-CN,IP-MN,AR2) | Explicit | | |------------------------------------->| ack. not | | | | | needed | | | | | | | Plain data packets | Tunnel | | |<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~| | | | | | Figure 9 - Route optimization: basic operation After the identification of the edge router on the CN side (i.e. the CN's AR, if the CN is located in the same LMMD of the MN, or the CN BG, if the CN is located in an external network), MN's HAR sends to it a Route Update (RU) message containing: o the IP address of the CN that triggered the route optimization procedure; o the IP address of the host; o the IP address of the current host's VAR (AR2 in the example of Figure 9). This Route Update message does not need to be explicitly acknowledged, in that, in case it gets lost, retransmissions are automatically triggered by the continuous arrival of non route optimized data packets on MN's HAR. At the reception of the RU message, the edge router on the CN side stores its content in a local cache and begins to tunnel data Giaretta, et al. Expires April 14, 2006 [Page 32] Internet-Draft NETLMM Protocol October 2005 packets addressed to the MN directly to the MN's VAR (i.e. the current visited location), thus restoring the shortest routing path. This local cache is similar to the Binding Cache that Mobile IPv6 correspondent nodes implement. It is important to note that the location information contained in the Route Update message can be applied to any CN willing to establish a communication session with the MN, and not only to the one that triggered the route optimization procedure on the host's HAR. This approach has the following advantages: o reduction of signaling overhead, since it is not necessary to trigger the delivery of a fresh Route Update any time the MN starts a new communication session. Instead, all the CNs communicating with the MN through the same edge router can share the location information included in the first Route Update received from the MN's HAR; o minimization of memory consumption on the edge routers, since they are not required to maintain any specific state related to the CN's the MN is communicating with. In case the CN is a mobile host, by just inspecting the source of received data traffic the MN's HAR can discover CN's HAR, but cannot figure out whether the CN is at home or attached to a VAR. Therefore as shown in Figure 10, the MN's HAR always sends the Route Update message to the CN's HAR. If the CN happens to be visiting a VAR, the CN's HAR looks up the actual location of the correspondent node in its Location Cache (LC) and immediately forwards the Route Update received from the MN's HAR to the CN's VAR. This allows to complete the route optimization procedure regardless of the actual position of the CN and without the need to disclose it to the MN's HAR. MN's HAR retransmits Route Update messages at regular intervals, in order to refresh location information on the receiving party. Edge routers are expected to immediately remove any Route Optimization state related to the MN at the expiration of its lifetime. This causes the restoration of traffic routing through the MN's HAR (i.e. anchor-based routing). Giaretta, et al. Expires April 14, 2006 [Page 33] Internet-Draft NETLMM Protocol October 2005 HAR or MN VAR of MN HAR of CN VAR of CN +--+ +---+ +---+ +---+ +---+ +--+ |MN| |AR1| |AR2| |AR4| |AR5| |CN| +--+ +---+ +---+ +---+ +---+ +--+ | | | | | | | | First data packet from CN (no tunneling) | | Triggers O<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<~~~~~~~~~| | delivery O Tunnel | | | | | or RU O===========>O | | | | | O | | | |<~~~~~~~~~~~~~~~~~~~~~~~O | | | | | | | | | | | RU (IP-CN,IP-MN,AR2) | | | | |------------------------>| | | | | | +------+ | | | | | |Lookup| | | | | | |in LC | | | | | | +------+ | | | | | | | | | | | RU (IP-CN,IP-MN,AR2) | | | | |----------->| | | | | | | | | Plain data packets | Tunnel | | |<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~| | | | | | | Figure 10 - Route optimization: mobile CN roaming in a VAR 12.2. Management of host movements In order not to break route optimization any time the host moves to a new location, the MN's HAR proactively re-transmits Route Update messages whenever it receives a Location Update showing that the MN has attached to a new VAR (see Figure 11).For that purpose, the host's HAR is required to keep a local cache listing all the CNs that have triggered route optimization towards the MN. This cache is similar to the Binding Update List that a Mobile IPv6 Mobile Node must implement for route optimization operation. Giaretta, et al. Expires April 14, 2006 [Page 34] Internet-Draft NETLMM Protocol October 2005 HAR or MN Old VAR New VAR +--+ +---+ +---+ +---+ +---+ +--+ |MN| |AR1| |AR2| |AR3| |AR4| |CN| +--+ +---+ +---+ +---+ +---+ +--+ | | | | | | | Plain data packets | Tunnel | | |<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~| Moves | | | | | to AR3 | | | | | | Activate (IP-MN) | | | |------------------------------------>| | | | | | | | | | | LU (IP-MN,AR3) | | | | |<------------------------| | | | | | | | | | | LA | | | | | |------------------------>| | | | | | | | | | | Route Update (IP-CN,IP-MN,AR3) | | | |------------------------------------->| | | | | | | | | Plain data packets | | Tunnel | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<===========O<~~~~~~~~~| | | | | | | Figure 11 - Route optimization: management of MN movements The MN's HAR stops proactive re-transmission of Route Update messages for a specific CN when it discovers that the communication session between MN and CN is terminated. Since with route optimization in place MN's HAR is not traversed by data traffic, this is done under explicit indication of the edge router on the CN side (i.e. AR or BG), that is required to continuously monitor the traffic exchanged with the MN. When the time elapsed since the last data packet sent to the MN, or received from the MN, overcomes a certain activity threshold, the edge router on the CN side replies to the Route Update with a Route Acknowledgement indicating that there are no on-going communications with the MN. At the reception of such an indication, the MN's HAR immediately stops the delivery of unsolicited RUs towards that edge router, and removes from its local cache all the state related to the CN. 12.3. Recovery from error conditions When operating in route optimization, the location information stored on the CN's edge router may happen to become outdated. In this case, data traffic generated by the CN gets erroneously tunneled to a VAR where the MN is no longer present. Giaretta, et al. Expires April 14, 2006 [Page 35] Internet-Draft NETLMM Protocol October 2005 This routing anomaly may occur at least in the following cases: o the MN moves to a new location but the proactive Route Update (RU) message sent by MN's HAR gets lost (as shown in the example of Figure 12). In this case, the CN's edge router continues to tunnel data packets to the old VAR, since it cannot detect that the MN has left it; o route optimization on a specific edge router has been triggered by a CN that afterwards has moved to a new location. In this case the MN's HAR stops delivering proactive Route Update messages to that edge router, whose location state may therefore become outdated if the MN changes its point of attachment. As a consequence, if a new CN starts communicating with the MN from that edge router before the expiration of its outdated route optimization state, data traffic gets erroneously delivered to the old MN's VAR. The solution that has been designed to recover from this routing anomaly is shown in Figure 12. If a VAR (AR2 in the example) receives tunneled data packets addressed to a MN that has moved away, it decapsulates the packets and forwards them using standard IP routing. As a consequence, the traffic gets to the MN'HAR that, after tunneling it to the right VAR, triggers the route optimization procedure. This involves the immediate delivery of fresh Route Update towards the CN's edge router, which causes it to adjust its route optimization state, thus recovering the shortest routing path. This approach ensures that data traffic sent from CN to MN is always delivered to the destination, even when outdated route optimization state is stored on some edge routers. The drawback is that for short transition periods the routing path followed by data packets may become sub-optimized, causing additional jitter and, depending on network topology and transfer delays, potential out of sequence delivery. Giaretta, et al. Expires April 14, 2006 [Page 36] Internet-Draft NETLMM Protocol October 2005 VAR or MN Old VAR New VAR +--+ +---+ +---+ +---+ +---+ +--+ |MN| |AR1| |AR2| |AR3| |AR4| |CN| +--+ +---+ +---+ +---+ +---+ +--+ | | | | | | | Plain data packets | Tunnel | | |<~~~~~~~~~~~~~~~~~~~~~~~O<========================O<~~~~~~~~~| Moves | | | | | to AR3 | | | | | | Activate (IP-MN) | | | |------------------------------------>| | | | | LU (IP-MN) | | | | |<------------------------| | | | | LA | | | | | |------------------------>| | | | | | | | | | | RU (IP-MN,IP-CN,AR3) | | | | |------------------------------->X | | | | | | RU does | | | | Move Notify| | not get | | | |----------->| | to AR4 | | | | Move Ack. | | | | | |<-----------| AR4 continues to | | | | | tunnel packets to AR2 | | | Triggers O<~~~~~~~~~~~O<========================O<~~~~~~~~~| | delivery O | | | | | of RU O========================>O | | | | | O | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O | | | | | | | | | | RU (IP-MN,IP-CN,AR3) | | | | |------------------------------------->| | | | | | | | | Plain data packets | Tunnel | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~O<===========O<~~~~~~~~~| | | | | | | Figure 12 - Route optimization: recovery from loss of RU Giaretta, et al. Expires April 14, 2006 [Page 37] Internet-Draft NETLMM Protocol October 2005 Authors' Addresses Gerardo Giaretta Telecom Italia Lab via Reiss Romoli 274 10148 Torino Italy Phone: +39 011 228 6904 Email: gerardo.giaretta@tilab.com Ivano Guardini Telecom Italia Lab via Reiss Romoli 274 10148 Torino Italy Phone: +39 011 228 5424 Email: ivano.guardini@tilab.com Elena Demaria Telecom Italia Lab via Reiss Romoli 274 10148 Torino Italy Phone: +39 011 228 5403 Email: elena.demaria@tilab.com Giaretta, et al. Expires April 14, 2006 [Page 38] Internet-Draft NETLMM Protocol October 2005 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, 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Giaretta, et al. Expires April 14, 2006 [Page 39]