Mobile-IP Working Group Hesham Soliman, Ericsson INTERNET-DRAFT Karim El Malki, Ericsson Expires December 2000 June 28, 2000 Hierarchical Mobile IPv6 and Fast Handoffs Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will improve the performance of MIPv6 in terms of handoff speed and is well-suited to implement access control and handoffs between different access technologies. Hesham Soliman and Karim El Malki [Page 1] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 TABLE OF CONTENTS 1. Introduction.................................................3 2. Fast Handoffs................................................3 2.1 Initiating Fast Handoffs through the "previous" AR...........4 3. Hierarchical Mobility Management using MIPv6.................5 4. Overview of the MIPv6 Hierarchical Mobility Management.......6 5. Neighbour Discovery extension - MAP discovery................9 6. MIPV6 extensions - Sending Binding Updates...................10 7. MN Operation.................................................11 7.1 MAP Discovery................................................11 7.2 Sending Binding Updates......................................12 7.3 Receiving packets in a foreign network.......................12 7.4 Fast Handoff scenario........................................13 8. MAP Operation................................................14 8.1 MAP Discovery................................................14 8.2 Receiving and forwarding Packets for a MN....................14 8.3 Fast handoff scenario........................................15 9. HA Operation.................................................15 10. AAA Considerations for IPv6..................................16 11. Acknowledgements.............................................16 12. Notice Regarding Intellectual Property Rights................16 13. References...................................................17 14. Authors' addresses...........................................17 Hesham Soliman and Karim El Malki [Page 2] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 1. Introduction This draft introduces the concept of a Hierarchical Mobile IPv6 network, utilizing a new node called the Mobility Anchor Point (MAP). Fast Handoffs can be achieved by anticipating the movement of Mobile Nodes by utilizing simultaneous bindings at a MAP in order to "multicast" traffic to potential Mobile Node movement locations. Fast Handoffs coupled to layer 2 mobility can help in achieving seamless handoffs between access routers by anticipating a MN's movement between access routers. In Mobile IPv6 there are no Foreign Agents, but there is still the need to provide a central point of access control and, similarly to MIPv4, Mobile IPv6 can benefit from reduced mobility signalling with external networks by employing a regional hierarchical structure. For this reason a new Mobile IPv6 node, called the Mobility Anchor Point (MAP, is used and can be located at any level in a hierarchical Mobile IPv6 network. Unlike FAs in IPv4, a MAP is not required on each subnet. The MAP is used by a MN as an alternate-care-of address (COA) while roaming within a hierarchical (MAP) domain, where such a domain involves all access routers advertising that MAP. The MAP will limit the amount of Mobile IPv6 signalling outside the domain and will support Fast Handoffs to help Mobile Nodes in achieving seamless mobility. Other advantages of the introduction of the MAP functionality are covered in chapter 3. This draft assumes the generic case of scaleable multi-level Hierarchical Mobile IP (HMIP) networks and is therefore applicable to HMIP networks in general. Hierarchical MIPv6 (HMIPv6)and Fast Handoffs offer advantages which are especially important for the support of real-time services. 2. Fast Handoffs Fast Handoffs address the need to achieve seamless Mobile IP Handoffs when the MN moves between different access routers (ARs). This is done by "bicasting" traffic to the "previous" AR and "new" AR while moving between them. The anticipation of the MN's movement is dependant on the handoff scenario. Two different scenarios may exist: a) The MN can be simultaneously attached (on layer 2) to both ARs. This can occur if the radio technology allows such attachment or the handoff is done between different access technologies (ie. between two different interfaces on the MN). In this case a seamless handoff can be achieved. b) The MN can only be physically attached to one AR. This is the most common case. In the latter scenario, a fast handoff anticipation can be achieved by tight coupling with Layer 2 functionality which is dependent on the type of access technology used. "Bicasting" is achieved through simultaneous bindings, where the MN activates the new "B" flag in a MAP Registration. Hesham Soliman and Karim El Malki [Page 3] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 When a MAP Registration Request has the "B" bit set, the receiving MAP which has an existing binding with the MN will add the relevant new binding for the MN but will also maintain any other existing bindings it had for the MN. When the MN has multiple active bindings with a MAP, it may or may not receive multiple copies of the same traffic directed to it. The use of simultaneous bindings does not necessarily mean that the MN is receiving packets contemporarily from multiple sources. This depends on the characteristics of the access (L2) technology. The "bicasting" of packets is used to anticipate the MN's movement and speed up handoffs by sending a copy of the data to the AR which the MN is moving to. Until the MN actually completes the L2 handoff to the new AR, the data "copy" reaching this AR may be discarded. In this way the total handoff delay is limited to the time needed to perform the L2 handoff. Thus, Fast Handoffs coupled to the L2 access potentially result in loss-less IP-layer mobility. As described in 2.1, depending on the L2 characteristics, it is also possible for an MN to initiate a Fast Handoff through the "current" AR without having direct access to the "new" AR. When the MN receives router advertisements including more MAP options than the ones it is aware of, it SHOULD perform MAP registrations in the following manner: - "Eager" to perform new bindings - "Lazy" in releasing existing bindings The above means that the MN will perform Regional Registrations with any "new" MAP from which it receives the MAP option (Eager). However the MN should not release existing bindings until it no longer receives advertisement from the AR that include its current MAP address in one of the MAP options. When one of the MAPs being used disappears from the router advertisement, the MN MUST inform all CNs using that address to use another MAP's address or the MN's actual COA. 2.1 Initiating Fast Handoffs through the "current" AR In the case in which the wireless L2 technology allows the MN to be data-connected to multiple wireless access points simultaneously, the MN may solicit advertisements from access routers before handoffs. Some existing wireless L2 technologies and their implementations do not allow a MN to be data-connected to multiple wireless access points simultaneously. Thus, in order to perform a Fast Handoff it is necessary for some form of interworking between layers 2 and 3. It should be noted that the method by which a router determines when a MN has initiated an L2 handoff is outside the scope of this draft. A Fast Handoff in this case requires the MN to receive "new" router advertisements through the "old" wireless access points, this can be done as explained below. Hesham Soliman and Karim El Malki [Page 4] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 I. Piggy-backing Advertisements on L2 messaging When a MN initiates an L2 handoff between two different APs/RANs (Note that it may not be the MN which takes decisions on handoffs). It is assumed that when an L2 handoff is initiated, both APs/RANs perform L2 messaging procedures to negotiate the L2 handoff. Since the MN would not be attached to the new AP/RAN yet, the new AP will be unaware of the IP address of the MN and cannot send an advertisement to it. Therefore it is necessary for the L2 procedures to interwork with Mobile IP. Once a L2 handoff is initiated, such that both APs/RANs are in communication, it is possible for the current AP/RAN to receive an advertisement piggy-backed on L2 messages between the two routers and send it to the MN. Once this is received by the MN, the MN can form a new address and perform a MAP registration with the newly formed address even though the MN has no data-connection to the new AP/RAN yet. The precise definition of such L2 procedures is outside the scope of Mobile IP. 3. Hierarchical Mobility Management using MIPv6 The aim of introducing the hierarchical mobility management model in MIPv6 is to enhance the network performance while minimising the impact on MIPv6 or other IPv6 protocols. This is achieved by using the MIPv6 protocol combined with layer 2 features to manage both IP micro and macro mobility, leading to rationalisation and less complex implementations in the MN and other network nodes. This hierarchical MIPv6 scheme introduces a new function, the Mobility Anchor Point (MAP), and minor extensions to the MN and the Home Agent operations. The CN operation will not be affected. The introduction of the MAP concept minimises the latency due to handoffs between access routers. Furthermore, the addition of bicasting to a MAP allows for Fast Handoffs which will minimise the packet losses due to handoffs and consequently improve the throughput of best effort services and performance of real time data services over the radio interface. Just like MIPv6, this solution is independent of the underlying access technology, allowing Fast Handoffs between different types of access networks. Furthermore, a smooth architectural migration can be achieved from Hierarchical MIPv4 networks, since a dual operation of IPv4 and IPv6 Hierarchies will be possible making use of the similarity in architecture. The introduction of the MAP concept will further diminish signalling generated by MIPv6 over the radio interface. This is due to the fact that a MN only needs to perform one regional update (MAP) when Hesham Soliman and Karim El Malki [Page 5] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 changing its layer 3 access point within the MAP domain.The advantage can be easily seen when compared to other scenarios (no MAP) where at least two BUs (Binding Updates) will be sent (to one CN and HA). A MAP may also be used as a point of access control and key distribution for the AAA protocol in IPv6. 4. Overview of the MIPv6 Hierarchical Mobility Management In order to introduce hierarchical mobility management in MIPv6, the protocol is extended with a new function. The proposed new functionality is the Mobility Anchor Point (MAP). It simply provides an optional mobility management function that can be located at any level in the hierarchy starting from the access router upwards. The MAP is used by a MN as an alternate-COA [1] while roaming within a certain MAP domain. A MAP domain's boundaries are defined by the Access Routers (ARs) advertising the MAP information to the attached Mobile Nodes. When the MAP is used as an alternate COA, the MAP will receive all packets on behalf of the MN and will encapsulate and forward them directly to the MN's current address. If the MN changes its current address within a regional MAP domain, it needs to register the new address with the MAP. This makes the MN's mobility transparent to the CNs it is communicating with. The MAP can also be used to execute a Fast Handoff between ARs as will be explained later. The detailed extensions to MIPv6 and operations of the different nodes will be explained later in this document. Although the proposed method is independent of the network topology, it is best suited to a hierarchical network or one with multi-access technologies. It should be noted that the MAP concept is simply an extension to the MIPv6 protocol. Hence a MAP-aware MN with an implementation of MIPv6 MAY choose to use the MAP or simply use the standard MIPv6 implementation as it sees fit. Furthermore, a MN can at any time stop using the MAP. This provides great flexibility, both from a MN or a network operations point of view. The network architecture shown below illustrates an example of the use of the MAP in a foreign domain. Hesham Soliman and Karim El Malki [Page 6] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 _______ | HA | |_______| _______ \ | CN | \ |_______| \___ | \ | \ ____| _\___|_ | | | MAP | |_______| / \ / \ / \ / \ ____/____ \_________ | | | | | AR1 | | AR2 | |_________| |_________| | | | | __\/____ \/ | | | MN | |________| __________________\ Movement / Figure 1: Hierarchical MIPv6 domain In Figure 1, the MAP can help in providing seamless mobility for the MN as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), while communicating with the CN. It is possible to use multi-level hierarchies of routers and implement MAP functionality in AR1 and AR2 if needed. It should be noted that AR1 and AR2 could be two points of attachment in the same RAN (Radio Access Network) or in different RANs. Upon arrival in a foreign domain, the MN will discover the global address of the MAP. This address is stored in the Access Routers and communicated to the MN via Router Advertisements. The discovery phase will also inform the MN of the distance of the MAP from the MN. For example, the MAP could also be implemented in AR1 and AR2, in which case the MN can choose the first hop MAP, second hop MAP, or both. A Router advertisement extension is proposed later in this document for MAP discovery. Other service discovery methods may also be used for the same purpose. If a router advertisement is used for MAP discovery, as described in this document, all ARs belonging to the Hesham Soliman and Karim El Malki [Page 7] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 MAP domain MUST advertise the MAP's IP address. The same concept should be used if other methods of MAP discovery are introduced. The process of MAP discovery continues as the MN moves from one subnet to the next. As the MN roams within a MAP's domain, the same information announcing the MAP should be received. If a change in the advertised MAP's address is received, the MN should act on the change by sending the necessary Binding Updates to its HA and CNs. If the MN is not MAP-aware then the discovery phase will fail resulting in the MN using the MIPv6 protocol for its mobility management. On the other hand, if the MN is MAP-aware it MAY choose to use the MAP implementation. If so, the MN will first need to register with a MAP by sending it a BU containing its Home Address and current address. The MAP MUST store this information to be able to forward packets to their final destination when received from the different CNs or HAs. The Home Address contained in the MAP registration MUST be the same Home Address sent in the Home Agent registration. If a MN sends different BU's for different Home Addresses (in the case it has multiple Home Addresses), the same process MUST be performed for the MAP registrations. This is essential to allow a MAP to forward packets to the right COA when they are tunnelled from the HA. The MN SHOULD also have a prefix length of 128 in its BUs to the HA. This would stop the HA from being proxy for other unregistered Home addresses. The MN will then need to update all CNs and its HA with its new COA. The new COA in this case SHOULD be the MAP's global IP address received earlier in the discovery phase. Hence all packets meant for the MN will be sent through the MAP's address as specified by the MN in its BU. The MAP will (acting like a HA) tunnel the packets addressed to the MN to its current address. The details of the MAP operation will be given later in this document. The MN will always need to know the original sender of any received packets. Since all packets will be tunnelled by the MAP, the MN is not always able to determine whether the packets were originally tunnelled from the Home Agent or received directly from a CN. This knowledge is needed by the MN to decide whether a BU needs to be sent to a CN in order to initiate route optimisation. For this purpose a check needs to be performed on the internal packet's routing header to find out whether the packet was tunnelled by the HA or originated from a CN using route optimisation instead. If a routing header exists in the internal packet, having the MN's Home Address as the final destination, then route optimisation was used. Otherwise, triangular routing through the HA was used. The MAP also needs to know how the final destination in the packet corresponds to the registered address of a MN. This should be obvious when the packets are sent from a CN to the Home Address of the MN or Hesham Soliman and Karim El Malki [Page 8] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 to the COA with a routing header. However, if the HA tunnels packets with addresses other than the MN's Home Address (eg. Site-local, organisation-local or multicast), of which the MAP would have no knowledge, the HA MUST add a routing header to the outer packet. This routing header must use one of the MN's Home Addresses as the final destination. This will enable the MAP to tunnel the packet to the correct destination (i.e. the MN's current address). To use the network bandwidth in a more efficient manner, a MN may decide to register with more than one MAP simultaneously and use each MAP address for a specific group of CNs. For example, in Fig 1, if the CN happens to exist on the same link as the MN, it would be more efficient to use the first hop MAP (in this case assume it is AR1) for communication between them. This will avoid sending all packets via the "highest" MAP in the hierarchy and hence result in a more efficient usage of network bandwidth. The MN can use its current address as a COA as well. 5. Neighbour Discovery extension - MAP discovery The process of MAP discovery can be performed in many different ways. In this document, router advertisements are used for the discovery phase by introducing a new option. The access router is required to send the MAP option in all router advertisements. This option includes the distance from the MN in terms of number of hops, the preference for this particular MAP and the MAP's global IP address. The ARs can be configured manually or automatically with this information. In the case of automatic configuration, each MAP in the network needs to be configured with a default preference, the right interfaces to send this option on and, if necessary, the IP address to be sent. The initial value of the "HOPS" field MUST be set to a value of one. Upon reception of a router advertisement with the MAP option, given that a router is configured to resend this option on certain interfaces, the router MUST copy the option and resend it after incrementing the HOPS field by one. If the router was also a MAP, it SHOULD send its own option in the same advertisement. In this manner information about a MAP at a certain level in a hierarchy can be dynamically passed to a MN. Furthermore, by performing the discovery phase in this way, different MAP nodes are able to change their preferences dynamically based on the local policies, node overload or other load sharing protocols being used. Hesham Soliman and Karim El Malki [Page 9] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 The following figure illustrates the new MAP option. 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 | HOPS | Pref | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The alignment requirements for this option is 8n. Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. HOPS An 8 bit unsigned integer showing the number of hops away from the receiver of the advertisement. It MUST be set to one in the initial advertisement. Pref The preference of this MAP. An 8 bit unsigned integer. A value of 255 means lowest preference. Global Address One of the MAP's global addresses. 6. MIPV6 extensions - Sending Binding Updates This section outlines the extensions proposed to the BU option used by the MN in MIPv6. Two new flags were added: the M flag that indicates MAP registration and the B flag that indicates a request for bicasting. When a MN registers with the MAP, the M flag MUST be set to distinguish this registration from a Home Registration or a BU being sent to a CN. The B flag is used during handoffs and signifies a request that a MAP bicast all received packets to the MN's current address (source Address on the packet) and the Alternate-COA specified in the sub-option. Hesham Soliman and Karim El Malki [Page 10] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 A MN MAY choose to use this flag to achieve a Fast Handoff, described in section 11.4. If the MN sends a BU with the B flag set, it MUST include an Alternate- care-of address sub-option, otherwise the BU MUST be rejected by the MAP. The B flag is only valid in BUs to a MAP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|M|B|Res| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Description of extensions to the BU option: M If set indicates a MAP registration. B A request to bicast all received packets to the source address and the alternate COA given. Res 2 bit reserved field 7. MN OPERATION This section is concerned with the extensions to the MN's operation in a foreign network due to the introduction of the MAP. Unless otherwise specified, the normal MN operation in [1] applies. 7.1 MAP discovery When a MAP-aware MN receives a router advertisement, it should search for the MAP option. One or more options may be found for different IP addresses. A MN SHOULD register with the MAP having the lowest preference value. A MAP with a preference value of 255 SHOULD not be used in the MAP registration. A MN MAY however choose to register with one MAP rather than another depending on the value received in the HOPS field, as long as the preference value is below 255. A MN SHOULD store the received option(s) and choose at least one MAP IP address to register as its COA. Storing the options is essential as they will be compared to other options received later for the purpose of the move detection algorithm. If no MAP options are found in the router advertisement, the MN MUST Hesham Soliman and Karim El Malki [Page 11] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 use the MIPv6 protocol as specified in [4]. If the MN receives a duplicated MAP option with different preference values or HOPS values, the MAP IP address MUST not be used as an Alternate-COA in any BU's sent by the MN. A MN MAY choose to register with more than one MAP simultaneously or use both MAP address and its own address as COAs simultaneously with different CNs. 7.2 Registration with the MAP - Sending Binding Updates After MAP discovery has taken place, a MN can register with one or more MAPs. The MN performs this local registration by sending a BU to the MAP with the appropriate flags set. When registering with a MAP, the A and M flags MUST be set in the BU. The H flag MUST not be set when registering with a MAP. A MN MUST wait for a BAck (Binding Acknowledgement) from the MAP before using the MAP address as an alternate COA in its BUs. After successfully performing registration with a MAP, a MN can start sending BUs, with the MAP's IP address as an Alternate-COA, to CNs and its HA. The MAP's IP address MUST be included in the Alternate-COA sub-option. For each home address registration sent to the HA with a MAP's address as the COA, a BU MUST be sent to the same MAP using the same home address. The MN SHOULD send a separate home registration BU for each home address, with the prefix length value set to 128. This stops the HA from forming home addresses for that MN on each link that the HA is connected to, thus ensuring consistency in the Binding Caches of both the MAP and HA for the MN. 7.3 Receiving packets in a foreign network When in a foreign network, a MN needs to know which path a packet has taken from the CN to the MN. That is, whether triangular routing was used via the HA or route optimisation was used. When using the MAP as an alternate-COA, all packets received from a CN will be tunnelled by the MAP to the MN. If a HA tunnels a packet to the MAP, it will be decapsulated and then encapsulated again with the MAP's address as the source address. Therefore a check on whether the packet was tunnelled by the HA will not be sufficient to decide whether route optimisation is required. However, a check for the existence of a routing header in the encapsulated packet (i.e. with CN as source address), where the MN's home address is the final address, will be sufficient to determine whether the path was route optimised or not. If the routing header does not exist, the MN SHOULD send a BU with the appropriate information to initiate route optimisation. Hesham Soliman and Karim El Malki [Page 12] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 7.4 Fast Handoff scenario In this section, a mechanism is explained for the execution of a Fast Handoff between two access routers within a MAP domain. A Fast Handoff using this mechanism can be achieved independently of the underlying access technology, provided the appropriate movement detection algorithm is being used. One way of achieving a Fast Handoff is by sending the next access point's router advertisement to the MN via the current access point. The router advertisement must be sent unicast to the MN concerned. This can be achieved by treating the advertisement as a solicited one, hence having the MN's global IP address in the destination field of the router advertisement. Possible mechanisms to achieve this are described in chapter 2. It should be noted that it may be more suitable (depending on the access technology) for a MN to solicit such advertisement. The decision on the method of receiving such advertisement is dependent on the access technology and will not be covered in this document. Upon reception of the new router advertisement, a MN should check whether it is still within the same MAP domain. If it is, a BU SHOULD be sent to the MAP containing the following information: - M flag MUST be set indicating a MAP registration - The B flag SHOULD be set to indicate that bicasting is required - If the B flag is set, the lifetime should not be more than 5 seconds - The A flag SHOULD be set. - The MN's future COA formed from the new prefix in the router advertisement. This new COA MUST be included in the alternate-COA sub-option. - The source address in the packet MUST be the MN's current address. This BU enables the MAP to send all packets for the MN to both addresses until a deregistration is made for the old COA. It should be noted that the addition of the "B" flag in the BU does not imply that a MN is required to receive packets from both ARs simultaneously. Sending of packets over the air interface need only be done by the AR to which the MN is currently attached. In some cases (eg. Handoff between two different access technologies) the MN may be able to receive traffic simultaneously from both ARs. In this case there is no need to set the "B" flag in the MAP registration. However to ensure no packet loss during the handoff, the MN should set the "A" flag in the MAP registration. When receiving the BAck from the MAP, the MN will be certain that all traffic from there on will be directed to the new AR. Hence, the old L2 connection can be terminated if necessary. After the Handoff is executed, the MN SHOULD deregister its old COA from the MAP to stop the bicasting. This is done by sending a BU to Hesham Soliman and Karim El Malki [Page 13] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 the MAP with only the M and A flags set, which would cause the MAP to remove previous entries for the MN in its Binding Cache. The new router advertisement received by the MN during handoff may also include a new MAP option on top of the existing one. Depending on its level in the hierarchy and its preference value, the MN MAY register with the new MAP as well without informing all CNs during the handoff. This may be useful since the current MAP may disappear during the following handoff. If the MN receives a new MAP option during handoff, and finds that its current MAP will disappear, it MUST register with the new MAP as explained earlier in MAP discovery. The MN MUST then update all the CNs and HA if necessary. The MN MUST also deregister with its previous MAP. This is done by sending a BU with the current COA and a lifetime of zero. Alternatively, a MN can simply send another BU with its new COA to the MAP. This BU should contain a short lifetime as it is a way of forwarding to the new COA those packets still being sent to the old COA. The deregistration method may depend on roaming agreements between the two domains. 8. MAP Operation 8.1 MAP Discovery As mentioned previously, the MAP discovery is done via router advertisements having the new MAP option added. A MAP will be configured to send its option or relay other MAPs' options on certain interfaces. The choice of interfaces is done by the network operator and depends on the network architecture. A default preference value should be assigned to each MAP. It should be noted that a MAP can change its preference value at any time due to various reasons (e.g. node overload, load sharing etc.). A preference value of 255 means that the MAP SHOULD not be chosen by a MN. This value could be reached in cases of node overload or node failure. The MAP option is propagated down the hierarchy. Each router along the path to the access router will increment the HOPS field. If a router that is also a MAP receives advertisements from other MAPs, it SHOULD add its own MAP option and propagate both options to the next level in the hierarchy. 8.2 Receiving and forwarding Packets for a MN The MAP operation is in many ways similar to the HA operation described in [4] with some modifications. Upon reception of a BU from a MN with the M flag set, and provided it is allowed to accept this message (i.e. no local policy restrictions) the MAP MUST store the MN's current address and its Home Address in its Binding Cache. The MAP MUST also update its routing table accordingly. If the A flag was set in the BU, the MAP MUST then reply to the MN with a BAck (Binding Hesham Soliman and Karim El Malki [Page 14] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 Acknowledgement) having the format specified in [4]. If both the M and H flags are set in a BU, the MAP MUST reject the Binding Update by sending a BAck with the appropriate error code. Upon reception of an encapsulated packet with no routing header in the outer packet, the packet is decapsulated in the normal way. If the inside packet contains a destination address that doesn't belong to the MAP, the MAP should check its Binding Cache to see if the address belongs to any of its registered MN's. If it does, the packet MUST be tunnelled to the MN's current address. Otherwise, the packet is processed in the normal way. If the encapsulated packet contains a routing header in the outer packet containing the MN's home address as the next destination, the MAP MUST process the routing header in the normal way, then tunnel the packet to the MN's current address. 8.3 Fast handoff scenario When a MAP receives a BU from a MN with the B flag set it SHOULD check for the following: - The M flag MUST be set. - An Alternate-COA sub-option exists. - The MN's new address is not the same as the old one. If any of the checks above fail, the MAP SHOULD reject the BU with the appropriate error code. If the registration lifetime for the "bicast" BU is greater than that specified by the local network's policy, the lifetime stored SHOULD be reduced to the maximum allowed time. The new lifetime SHOULD then be sent in the BAck. If the A flag is set, the MAP MUST reply with a BAck to the MN's current address. If the packet passes all of the checks above, the MAP should add a new entry in its Binding Cache for the MN's home address. All packets that are to be tunnelled to the MN after this point MUST be tunnelled to both entries in the Binding Cache. If the new entry (with the B flag set) times out, the MAP MUST remove only that entry. After the handoff is executed, the MN SHOULD send a BU to the MAP with its new COA (the previous alternate-COA used in the bicast request) with only the M and A flags set. The MAP should replace both entries in the Binding cache with the new BU information, resulting in the termination of the bicast. 9. HA Operation The Home Agent operations are affected in a minor way by the Hesham Soliman and Karim El Malki [Page 15] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 introduction of the MAP. The only change foreseen on the HA implementation is that when tunnelling packets to the MN with destination addresses other than the addresses registered by the MN in its Home Registration, the HA MUST include a routing header in the outer packet with the MN's registered home address as the final destination. This is done to enable the MAP to find the right routing entry for the MN, since it has no knowledge of a non-unicast global home address for the MN. 10. AAA Considerations for IPv6 The MAP can be utilised to perform access control on MNs and may interact with the protocol which will be defined for AAA in IPv6. The MAP can speed up a handoff by having the MN's security credentials which will allow it to verify whether a certain node is allowed access to the network. This allows greater efficiency in distributing keys only to certain nodes in the network. One example of the interaction between a MAP and the AAA infrastructure can be seen when considering the handoff scenario. A MAP can store the MN's security credentials after the MN is allowed network access by the AAA infrastructure. During an intra-domain handoff, the MAP could pass the MN's secrity credentials to the "new" AR to avoid performing the AAA process. These credentials depend on the access enforcement policies in AAAv6 and will not be covered by this draft. 11. Acknowledgements The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this draft. Additionally, the authors would like to thank Eva Gustaffson, Annika Jonsson and Fergal Ladley for their thourough review of the first version of the draft. 12. Notice Regarding Intellectual Property Rights Ericsson may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this disclosure are or become protected by one or more patents assigned to Ericsson, Ericsson intends to disclose those patents and license them on reasonable and non-discriminatory terms. Future revisions of this draft may contain additional information regarding specific intellectual property protection sought or received. Hesham Soliman and Karim El Malki [Page 16] INTERNET-DRAFT HMIPv6 and Fast Handoffs June 29, 2000 13. References [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-10.txt, February 2000. [2] E. Gustafsson, A. Jonsson and C. Perkins, " Mobile IP Regional Tunnel Management ", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March 2000. [3] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1996. [4] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4". (work in progress) 14. Authors' Addresses Questions about this memo can be directed to: Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au Karim El Malki Ericsson Radio Systems AB Access Networks Research SE-164 80 Stockholm SWEDEN Phone: +46 8 7573561 Fax: +46 8 7575720 E-mail: Karim.El-Malki@era.ericsson.se Hesham Soliman and Karim El Malki [Page 17]