Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: May 21, 2008 Huawei USA November 18, 2007 Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6 draft-xia-netlmm-fmip-mnagno-02 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 May 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Xia & Sarikaya Expires May 21, 2008 [Page 1] Internet-Draft MN Agnostic FMIP November 2007 Abstract Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility management protocol, that is, a mobile node does not implement any mobility management protocol. This document proposes an enhancement to PMIPv6 protocol in order to improve layer 3 handover performance and to transfer context borrowing some ideas from Fast Handovers for Mobile IPv6 (FMIPv6) protocol. In predictive mode, the previous mobile access gateway (PMAG) transfers context to the next MAG (NMAG) using Handover Indication (HI) message, while in reactive mode, NMAG uses Fast Binding Update (FBU) to request context from PMAG. A bi- directional tunnel is established between PMAG and NMAG to transfer packets during handover. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 4 3.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 6 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 7 4.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 9 4.3. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 9 4.4. Fast Binding Acknowledgement (FBack) . . . . . . . . . . . 10 4.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.1. Mobile Node Identifier Option . . . . . . . . . . . . 10 4.5.2. IPv4 Address Option . . . . . . . . . . . . . . . . . 10 4.5.3. Vendor Specific Option . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative references . . . . . . . . . . . . . . . . . . 12 Appendix A. Interaction Fast PMIPv6 and IEEE802.16e . . . . . . . 14 A.1. IEEE802.16e terminology . . . . . . . . . . . . . . . . . 14 A.2. IEEE 802.16e Network Entry and Handover Overview . . . . . 14 A.3. Interaction between Fast PMIPv6 and IEEE 802.16e . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Xia & Sarikaya Expires May 21, 2008 [Page 2] Internet-Draft MN Agnostic FMIP November 2007 1. Introduction [I-D.ietf-mipshop-fmipv6-rfc4068bis] introduces the operation of fast handovers for Mobile IPv6. [I-D.ietf-netlmm-proxymip6] defines Proxy Mobile IPv6 procedures. [I-D.ietf-netlmm-pmip6-ipv4-support] elaborates the support for the mobile node's IPv4 home address mobility in order to support the scenario where the local mobility anchor (LMA) and the mobile access gateway (MAG) are separated by an IPv4 transport network. This memo combines FMIPv6 operation with PMIPv6 protocol, and proposes a network based handover solution in PMIPv6. The handovers in FMIPv6 always involve the mobile node. In predictive mode, MN solicits the next access router (NAR)'s information by sending RtSolPr message; MN uses prefix information in PrRtAdv to formulate NCoA; MN initiates handover sending FBU to the previous access router (PAR); MN sends a UNA message to the NAR as soon as it regains connectivity on the new link so that arriving or buffered packets can be immediately forwarded. In PMIPv6, MNs attached to the same MAG have the same CoA which is called Proxy-CoA. Using network side layer 2 trigger, previous mobile access gateway (PMAG) can initiate predictive handover on behalf of MNs. The next mobile access gateway (NMAG) may also initiate reactive handover procedure when related layer 2 triggers are received. 2. Terminology 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 [RFC2119]. The terminology in this document is based on the definitions in [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in this section: [BS-ID, Proxy-CoA] tuple: Contains Proxy-CoA of an MAG and the Base Station (identified by BS-ID) which is attached to MAG. The tuple is probably manually configured or using other mechanisms that are out of scope. PMAG: Previous Mobile Access Gateway. The MN's default router prior to its handover. In this memo, it has the same meaning as the Previous Access Router (PAR) of FMIPv6. Xia & Sarikaya Expires May 21, 2008 [Page 3] Internet-Draft MN Agnostic FMIP November 2007 NMAG: New Mobile Access Gateway. The MN's default router subsequent to its handover. In this memo, it has the same meaning as the New Access Router (NAR) of FMIPv6. 3. Protocol Operation Depending on whether layer 2 Handover (HO) signaling is finished on a previous link, there are two modes of operation, that is, predictive and reactive mode. The predictive mode is that L2 HO signaling finish on the previous link. In the following section, BS and MAG can be collocated or in different physical entities. The picture in Figure 1 illustrates the scenario where BS and MAG are physically separated from each other. 3.1. Predictive Mode --------------- ----------- MN | s-BS PMAG | | NMAG t-BS | --------------- ----------- | 1 Network Entry | | | | |<----------------->|<---------->| | | | 2 L2 HO | | | | | Signalling | | | | |<=================>|===========>| | | disconnect | | | | | |3 L2-HO-IND | | | | |----------->| | | | | buffering | | | | | 4 HI | | | | |--------------->| | | | | 5 HAck | | | | |<---------------| | | | | 6 forward | | | | | packets | | | | |===============>| | | | | buffering | connect | | | | | | | | 7 LUP | | | | 8 RA |<------>| |<------------------------------------------------| | | | | 10 deliver | 9 PBU | | | | packets |---------->LMA |<================================================| | Xia & Sarikaya Expires May 21, 2008 [Page 4] Internet-Draft MN Agnostic FMIP November 2007 Figure 1: Predictive Mode The procedure is as follows: 1. MN performs network entry procedure in which access authentication and IPv6 address configuration is done. After finishing IP connectivity, the PMAG does the mobility related signaling on behalf of the MN. For detailed information, please refer to [I-D.ietf-netlmm-proxymip6]. 2. Before the MN moves from serving Base Station (s-BS) to target Base Station (t-BS), negotiation occurs between the MN and s-BS through L2 handover signaling. 3. When the L2 handover decision is made, the s-BS sends the PMAG L2-HO-IND message in which target BS-ID SHOULD be included. The details on L2-HO-IND is out of scope. 4. There are [BS-ID, Proxy-CoA] tuples in MAGs. Once receiving L2- HO-IND message, PMAG then * collects MN's related context which includes the following information: MN identifier, MN-HoA, MN-HNP, MN's Proxy-CoA in the PMAG and MN's MAC. * determines the NMAG's address for the destination of HI message. Using BS-ID in L2-HO-IND message, the PMAG retrieves NMAG's Proxy-CoA from [BS-ID, Proxy-CoA] tuple. * sends HI to NMAG with options which are defined in Section 4.1. 5. The NMAG creates a Binding Update List defined in [I-D.ietf-netlmm-proxymip6] for the MN based on the information in the HI message and probably synchronizes the context with corresponding BS. NMAG then sends HAck to the PMAG. Once HAck is received by the PMAG, a bi-directional tunnel is established, and the PMAG's Proxy-CoA and the NAR's Proxy-CoA are the tunnel's two ends. 6. Packets destined to the MN are tunneled from the PMAG to the NMAG based on the MN-HoA. PMAG decapsulates the packets received from the tunnel to the LMA, encapsulates into PMAG/NMAG tunnel, and then sends them to NMAG. NMAG SHOULD buffer the packets until the link between NMAG and MN is ready. 7. Network re-entry is performed when MN attaches to t-BS. Context transferred from PMAG can be used to expedite the procedure. When a layer 2 link is established, the t-BS sends a Link Up (LUP) message to NMAG. 8. The NMAG sends Router Advertisement(RA) with the NMAG's information which facilitates the MN to send packets. 9. The NMAG sends PBU for updating the binding in LMA. For detail, please refer to [I-D.ietf-netlmm-proxymip6]. 10. The NMAG delivers the buffered packets to the MN. Xia & Sarikaya Expires May 21, 2008 [Page 5] Internet-Draft MN Agnostic FMIP November 2007 3.2. Reactive Mode ---------- ------------ MN | s-BS PMAG | | NMAG t-BS| --------- ------------ | | | 1 Network Re-entry | | |<---------------------------------------------->|<------->| | | | | | | | 2 movement detection | | | | and buffering | | | | | | 3 LUP | | | | |<--------| | | | 4 FBU | | | | |<--------------------| | | | | | 5 PBU | | | | |---------->LMA | | | 6 FBack | | | | |-------------------->| | | | | | | | | | 7 forward packets | | | | |====================>| | | | | | | | | | 8 RA | | |<-----------------------------------------------| | | | | | | | | | 9 deliver packets | | |<===============================================| | | | | | | Figure 2: Reactive Mode The procedure is as follows: 1. MN performs network re-entry process to establish the link layer. Context from original session are necessary to expedite link establishment. 2. To minimize packet loss during handover, PMAG SHOULD automatically buffer packets for all MNs that have disappeared off its link. There are two cases to cover here. Case A, MN just moved and the PMAG didn't know that it was handing over. Case B, MN exchanged L2 messages with the PMAG and it knew that it was moving, but it may not have completed the whole procedure. PMAGs automatically buffer packets (perhaps for a default period of time) for each MN that is not on its link in case A, or PMAGs Xia & Sarikaya Expires May 21, 2008 [Page 6] Internet-Draft MN Agnostic FMIP November 2007 just buffer packets in case B because it's less open to denial of service (DoS) attacks or errors. 3. After network re-entry process is finished, t-BS sends a LUP message to the NMAG. The detail about LUP is out of scope. 4. Once previous BS-ID and MN's MAC are available during network re- entry process, NMAG sends FBU to the PMAG with the following information: the NMAG's Proxy-CoA and MN's MAC. NMAG determines the PMAG's address through referring to [BS-ID, Proxy-CoA] tuples in NMAG. In this step, it is reasonable to assume that the previous BS-ID is exchanged during network re-entry as for example in WiMAX links [802.16e]. 5. NMAG sends PBU for updating the binding in LMA. For details, please refer to [I-D.ietf-netlmm-proxymip6]. 6. Based on the MN's MAC, PMAG identifies MN's Binding Update List and collects MN's related context which includes the following information: MN identifier, MN-HoA, MN-HNP, MN's Proxy-CoA in the PMAG, and MN's MAC. PMAG transfers the context to NMAG through FBack message. When FBack is received by NMAG, a bi-directional tunnel is established, and the PMAG's Proxy-CoA and the NMAG's Proxy-CoA are the tunnel's two ends. 7. Once the bi-directional tunnel is established, PMAG forwards the buffered packets to NMAG. 8. NMAG sends Router Advertisement (RA) with the NMAG's information which facilitates the MN to send packets. 9. NMAG then delivers packets to the MN. 4. Message Formats All the messages between PMAG and NMAG are ICMPv6 messages and are as defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. Some new options are defined. Only the messages that require modification are specified below. 4.1. Handover Initiate (HI) HI is an ICMPv6 message sent by PMAG to NMAG to convey context and establish bi-directional tunnel. Please refer to [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.2.1 for details. The following information are included in options for bi-directional tunnel creation and context transfer: MN Identifier The information is conveyed by Mobile Node Identifier option defined in Section 4.5.1. The identifier is used for retrieving MN's profile from a policy store. Xia & Sarikaya Expires May 21, 2008 [Page 7] Internet-Draft MN Agnostic FMIP November 2007 Proxy-CoA of PMAG The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1. PMAG's Proxy-CoA is one end of the bi-directional tunnel between PMAG and NMAG. Proxy-CoA of NMAG The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The address is intended to be the other end of the bi-directional tunnel. NMAG can return another address in HAck message as the tunnel end if the address is not proper. MN MAC The information is conveyed by Link-layer Address (LLA) Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.3. MAC is used to correlate Bind Update List and the corresponding layer 2 link. MN-HoA The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1. It is the main element for Bind Update List in NMAG. All traffic from the source address MN-HoA is routed via the bi-directional tunnel between PMAG and NMAG when the new tunnel between LMA and NMAG is not created. The option is necessary only if MN is IPv6 or dual stack support. LMAA The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1. The address is configured on the interface of the local mobility anchor and is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway. The option is necessary only if transport network is IPv6. IPv4 LMAA The information is conveyed by IPv4 Address Option defined in Section 4.5.2. The option is necessary only if transport network is IPv4. MN-HNP The information is conveyed by New Router Prefix Information Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.2. To emulate MN's home link, MN's Home Network Prefix is included in the NMAG's Router Advertisement. Link-local Address of PMAG The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The value will be the link-local address of the first MAG to which this MN attached. NMAG MUST advertise RA using the PMAG's link-local address with the Router Lifetime field set to value 0, then it is possible to force the flush out of the Previous Default-Router entry from the mobile node's cache. Xia & Sarikaya Expires May 21, 2008 [Page 8] Internet-Draft MN Agnostic FMIP November 2007 DHCP Server Address The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. If Address Configuration using DHCP is supported on the link on which the mobile node is attached, the DHCP relay agent needs to be configured on the MAG. When the mobile node sends a DHCPv6 Request message, the relay agent function on the MAG must relay the message to the DHCP server. The option is necessary only if DHCP Server Address is IPv6. IPv4 DHCP Server Address The information is conveyed by IPv4 Address Option defined in Section 4.5.2. The option is necessary only if DHCP Server Address is IPv4. Vendor Specific Option A new option is defined in Section 4.5.3. This option is defined for implementation specific context such as security parameters, compression parameters and so on. 4.2. Handover Acknowledge (HAck) HAck is a reply to the HI message. Please refer to [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.2.2. The following option is needed: Proxy-CoA of NMAG The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. PMAG MUST use this as one end of a bi-directional tunnel. 4.3. Fast Binding Update (FBU) The Fast Binding Update message is defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.3.1. The following modifications are made: Proxy-CoA of PMAG . The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. PMAG's Proxy-CoA is one end of the bi-directional tunnel between PMAG and NMAG. Proxy-CoA of NMAG . The information is conveyed by IP Address Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The address is intended to be the other end of the bi-directional tunnel. NMAG can return another address in HAck message as the tunnel end if the address is not proper. Xia & Sarikaya Expires May 21, 2008 [Page 9] Internet-Draft MN Agnostic FMIP November 2007 MN MAC The information is conveyed by Link-layer Address (LLA) Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.3. MAC is used to correlate Bind Update List and corresponding layer 2 link. 4.4. Fast Binding Acknowledgement (FBack) FBack message is sent by the PMAG to acknowledge receipt of a Fast Binding Update message and is defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.3.2. The message has the same option set as HI message to establish bi-directional tunnel and transfer contexts. 4.5. New Options 4.5.1. Mobile Node Identifier Option Various forms of identifiers can be used to identify a MN. Since [I-D.ietf-netlmm-proxymip6] uses the mobile node identifier option for Mobile IPv6 defined in [RFC4283], this document also adopts the same format. 4.5.2. IPv4 Address Option A mobile node operating in IPv4-only mode or in a dual-stack mode should be able to obtain an IPv4 home address. When the transport network between the local mobility anchor and the mobile access gateway is an IPv4 network, LMA IPv4 address is necessary. This option is used for IPv4 address context transfer between PMAG and NMAG. 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 | Option-Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA Length the length of the option in units of 8 octets. Option-Code 1 IPv4 MN-HoA 2 IPv4 LMA Address when transport network is IPv4. Xia & Sarikaya Expires May 21, 2008 [Page 10] Internet-Draft MN Agnostic FMIP November 2007 IPv4 Address The IPv4 address defined by the Option-Code field 4.5.3. Vendor Specific Option Like Mobile IPv6 Vendor Specific Option defined in [I-D.ietf-mip6-vsm], the option defined here is for vendors specific implementation. MAGs not equipped to interpret the option MUST ignore it. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA Length The length of the option in units of 8 octets. Vendor ID The SMI Network Management Private Enterprise Code of the Vendor/ Organization as defined by IANA String The String field is one or more octets. The actual format of the information is site or application specific. It SHOULD be encoded as a sequence of type / length / value fields. Multiple sub-options MAY be encoded within a single Vendor Specific option. 5. Security Considerations AAA-based secret keys or local CAs can be used to protect the signalling exchange between PMAG and NMAG. Xia & Sarikaya Expires May 21, 2008 [Page 11] Internet-Draft MN Agnostic FMIP November 2007 6. IANA consideration The values of Vendor Specific Option and IPv4 Address Option MUST be allocated by IANA. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [802.16e] Institute of Electrical and Electronics Engineer, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE 802.16e/D12. 8.2. Informative references [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [I-D.ietf-mipshop-fmipv6-rfc4068bis] Koodli, R., "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-fmipv6-rfc4068bis-03 (work in progress), October 2007. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Xia & Sarikaya Expires May 21, 2008 [Page 12] Internet-Draft MN Agnostic FMIP November 2007 draft-ietf-netlmm-proxymip6-07 (work in progress), November 2007. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01 (work in progress), July 2007. [I-D.ietf-mip6-vsm] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", draft-ietf-mip6-vsm-03 (work in progress), October 2007. Xia & Sarikaya Expires May 21, 2008 [Page 13] Internet-Draft MN Agnostic FMIP November 2007 Appendix A. Interaction Fast PMIPv6 and IEEE802.16e A.1. IEEE802.16e terminology MOB_MSHO-REQ: handover request message sent by MN. MOB_BSHO-RSP: handover response message sent by BS. MOB_BSHO-REQ: handover request message sent by BS. MOB_HO-IND: handover indication message sent by MN. RNG-REQ: Ranging Request. RNG-RSP: Ranging Response. REG-REQ: Registration Request. REG-RSP: Registration Response. PKM-REQ: Privacy Key Management Request. PKM-RSP: Privacy Key Management Response. A.2. IEEE 802.16e Network Entry and Handover Overview Related IEEE 802.16e processes are highlighted in the following section. Network Entry. Once the MN makes a first network attachment, it conducts 802.16e ranging through which it can acquire physical parameters from the target BS, tuning its parameters to the target BS. After ranging with the target BS successfully, the MN negotiates basic capabilities such as maximum transmit power and modulator/ demodulator type. It then performs authentication and key exchange procedure, and finally registers with the target BS. After successful registration, the target BS become a serving BS. Handover Preparation. The handover preparation can be initiated by either the MN or the BS. During this period, neighboring BSs are compared by the metrics such as signal strength or QoS parameters and a target BS is selected among them. Once the MN decides handover, it notifies the serving BS by sending a MOB_MSHO-REQ message. The BS then replies with a MOB_BSHO-RSP containing the recommended BSs to the MN after negotiating with candidates. Optionally it may confirm handover to the target BS over backbone when the target is decided. The BS alternatively may trigger handover with a MOB_BSHO-REQ message. Xia & Sarikaya Expires May 21, 2008 [Page 14] Internet-Draft MN Agnostic FMIP November 2007 Handover Execution. When the MN is about to move to the new link after deciding the target BS, it sends a MOB_HO-IND message to the serving BS as a final indication for its handover. Network Reentry. The process is almost the same as the network entry. If the target BS has already learned some contexts such as authentication or capability parameters through backbone, it may omit the corresponding procedures. A.3. Interaction between Fast PMIPv6 and IEEE 802.16e o Predictive Mode. In handover execution phase which is described in the above section, a MN sends MOB_HO-IND to the serving BS. The target BSID should be included in the MOB_HO-IND. Upon receiving MOB_HO-IND, the serving BS notifies PMAG with L2-HO-IND event as described in Figure 1. The target BSID should be included in the L2-HO-IND. The PMAG can decide the corresponding NMAG by referring to [BS-ID, Proxy-CoA] tuple. The details of the handover are described in Section 3.1. o Reactive Mode. After switching links, the MN synchronizes with the target BS and performs the 802.16e network reentry procedure.The MN exchanges the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/ RSP and REG-REQ/RSP messages with the target BS. When the network reentry procedure is completed and the link layer is ready for data transmission, the target BS informs the NMAG with a LUP primitive in which the previous serving BSID is included. The NMAG can decide the corresponding PMAG by referring to [BS-ID, Proxy-CoA] tuple. The details of the handover are described in Section 3.2 Xia & Sarikaya Expires May 21, 2008 [Page 15] Internet-Draft MN Agnostic FMIP November 2007 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Xia & Sarikaya Expires May 21, 2008 [Page 16] Internet-Draft MN Agnostic FMIP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xia & Sarikaya Expires May 21, 2008 [Page 17]