NETLMM WG Xiaoyan Shi Internet Draft Shiyong Tan Expires: February 2010 Huawei Hanwen Zhang Yujun Zhang Institute of Computing Technology, Chinese Academy of Sciences September 5, 2009 Proxy Mobile IPv6 Reliability Protocol draft-shi-netlmm-pmipv6-reliability-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 February 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Shi, et al. [Page 1] Internet Draft PMIPv6 Reliability Protocol September 2009 Abstract The Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) are the key entities to realize system function of Proxy Mobile IPv6 (PMIPv6). It is critical to provide LMA/MAG reliability in the event of a LMA/MAG becoming failed or overloaded. This document provides a mechanism of LMA/MAG failure detection and service switching for failed or overloaded entities. Table of Contents 1. Introduction...................................................3 2. Conventions and Terminology....................................4 2.1 Conventions Used in This Document..........................4 2.2 Terminology................................................4 3. Protocol Overview..............................................5 3.1 MAG Pool Deployment........................................7 3.2 Status Detection Mechanism.................................7 3.3 MAG Service Switching Mechanism............................8 3.4 LMA Service Switching Mechanism............................9 4. Message Format................................................11 4.1 Service Switching Message.................................12 4.2 LMA Control Message.......................................14 4.3 Load Information Option...................................15 4.4 LMA Address Option........................................16 4.5 Handoff Condition Option..................................17 5. MPM Operation.................................................17 5.1 Conceptual Data Structures................................18 5.2 Operation about MAG list..................................19 5.3 Processing Heartbeat Message..............................19 5.3.1 Sending Heartbeat Request............................19 5.3.2 Receiving Heartbeat Acknowledgement..................20 5.4 MAG Switching Message.....................................20 5.4.1 Sending MAG Switching Request........................20 5.4.2 Receiving MAG Switching Acknowledgement..............21 6. MAG Operation.................................................22 6.1 Takeover MAG Service......................................22 6.2 Get Failure-Affected-MNs?information......................22 6.3 Heartbeat Message.........................................23 6.4 MAG Switching Message.....................................23 6.4.1 Receiving MAG Switching Request......................23 6.4.2 Sending MAG Switching Acknowledgement................24 6.4.3 Sending MAG Switching Finish Announcement............25 6.4.4 Receiving MAG Switching Finish Announcement..........26 6.5 Handoff Registration Message..............................26 6.5.1 Sending Handoff Registration Request.................26 6.5.2 Receiving Handoff Registration Acknowledgement.......28 6.6 LMA Switching Message.....................................28 6.6.1 Receiving LMA Switching Request......................28 6.6.2 Sending LMA Switching Acknowledgement................29 6.6.3 Receiving LMA Switching Finish Announcement..........30 Shi, et al. Expires - Expiration February 2010 [Page 2] Internet Draft PMIPv6 Reliability Protocol September 2009 6.6.4 Sending LMA Switching Finish Announcement............31 7. LMA Operation.................................................31 7.1 Conceptual Data Structures................................31 7.2 Operation about LMA list..................................32 7.3 Get Failure-Affected-MNs?information......................33 7.4 Heartbeat Message.........................................33 7.4.1 Sending Heartbeat Request............................33 7.4.2 Receiving Heartbeat Request..........................33 7.4.3 Sending Heartbeat Acknowledgement....................34 7.4.4 Receiving Heartbeat Acknowledgement..................34 7.5 LMA Control Message.......................................35 7.5.1 Sending Supervisor-LMA Request.......................35 7.5.2 Receiving Supervisor-LMA Request.....................35 7.5.3 Sending Supervisor-LMA Acknowledgement...............36 7.5.4 Receiving Supervisor-LMA Acknowledgement.............36 7.5.5 Sending Supervisor-LMA Update Announcement...........36 7.5.6 Receiving Supervisor-LMA Update Announcement.........37 7.6 Handoff Registration Message..............................37 7.6.1 Receiving Handoff Registration Request...............37 7.6.2 Sending Handoff Registration Acknowledgement.........38 7.7 LMA Switching Message.....................................39 7.7.1 Sending LMA Switching Request........................39 7.7.2 Receiving LMA Switching Acknowledgement..............40 7.7.3 Sending LMA Switch Finish Announcement...............41 8. Security Considerations.......................................41 9. Protocol Configuration Variables..............................41 10. IANA Considerations..........................................42 11. Acknowledgements.............................................42 12. References...................................................42 Authors' Addresses...............................................43 1. Introduction As defined in [RFC5213], PMIPv6 enables network-based mobility for Mobile Nodes(MN) that do not implement any mobility protocols. In a PMIPv6 domain, LMA is the topological anchor point for the mobile node's home network prefixes and is the entity that manages the mobile node's binding state. Once the LMA becomes failed or overloaded, the whole PMIPv6 domain will lose the mobility service capability. As the access router of MN, MAG manages the mobility-related signaling for the MN that is attached to its access link. Therefore, once a MAG fails to provide service, all MNs attached to it will lose their reachability. Shi, et al. Expires - Expiration February 2010 [Page 3] Internet Draft PMIPv6 Reliability Protocol September 2009 In this document, we propose a PMIPv6 reliability solution which makes the failed or overloaded LMA or MAG to be quickly detected and took over by other corresponding network entities (also LMA or MAG). In such solution, the address of Failure-Affected-MNs is unchanged so that the session connection is maintained. Additionally, this solution also considers the load-balance among LMAs and MAGs. o MAG Service Switching Mechanism A group of MAGs which have overlapped areas can take over service for each other. Such MAGs constitute a MAG Pool in which there is a management entity called MPM (MAG Pool Manager). When a MAG becomes failed or overloaded, MPM will choose another MAG to take over all or part of the mobility service of the failed/overloaded MAG. MAG service switching process is transparent to MN. o LMA Service Switching Mechanism LMAs, in the same PMIPv6 domain, establish supervision relationship between each other. When one LMA detects another LMA becomes failed or overloaded, it will send LMA Switching Request (Section 7.5.1) to related MAGs and take over the mobility service of the failed/overloaded LMA. LMA service switching process is transparent to MN. 2. Conventions and Terminology 2.1 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]. 2.2 Terminology MAG Pool A MAG set in which MAG can take over the service of each other. In other words, these MAGs MUST have overlapped areas. MPM The manager of a MAG Pool. The function of a MPM includes: maintaining the status information of MAGs in its MAG Pool; Shi, et al. Expires - Expiration February 2010 [Page 4] Internet Draft PMIPv6 Reliability Protocol September 2009 making decisions when entities becomes failed or overloaded; choose MAG for MN when MN attached. Supervisor-LMA The LMA responsible for failure detection and service taking over of other LMAs. Each LMA has only one Supervisor-LMA. And a LMA can be the Supervisor-LMA of multiple LMAs. Supported-LMA A LMA is called Supported-LMA of its Supervisor-LMA. Takeover-LMA/MAG The LMA or MAG which takes over the service of Previous- LMA/MAG (The LMA or MAG which needs service switching). Failure-Affected-MNs The MNs attached to Failed-LMA/MAG or Overload-LMA/MAG. 3. Protocol Overview This specification describes a PMIPv6 reliability protocol. It includes MAG Service Switching Mechanism and LMA Service Switching Mechanism. The deployment scenario of PMIPv6 reliability protocol is shown in Figure 1. Shi, et al. Expires - Expiration February 2010 [Page 5] Internet Draft PMIPv6 Reliability Protocol September 2009 +---------+ +---------+ | LMA1 | ... | LMAn | +---------+ +---------+ / / \ / / / / | \ / / \ / / / / | \ +----/----/----------+---------------/-/-/-/----+----\----+ ( / + | IPv4/IPv6 / / / / | \ ) ( / | | Network / / / / | \ ) +-/------+-----------+------------/-/-/-/-------+-------\-+ / _____|___________|___________/ / / + | \ + / | ________|____________/ / | | \ | + | / | __________/ | | \ | | | + | / | | + | | | | | + | | | +---|-|------|-|---------|-|---+ +----|--------|-----------|----+ | +-+-+-+ +-+-+-+ +-+-+-+ | | +--+--+ +--+--+ +--+--+ | | |MAG11| |MAG12| ... |MAG1n| | | |MAG21| |MAG22| ... |MAG2n| | | +--+--+ +--+--+ +--+--+ | | +--+--+ +--+--+ +--+--+ | | \ | / | | \ | / | | +---+ | +------+ | | +---+ | +------+ | | | | | | | | | | | | +-+--+--+-+ | | +-+--+--+-+ | | | MPM1 | | | | MPM2 | | | +---------+ MAG Pool 1| | +---------+ MAG Pool 2| +----+----------+----------+---+ +--------+-----------+---------+ | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | MN1 | | MN2 | | MN3 | | MN4 | | MN5 | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 1: Deployment scenario of PMIPv6 reliability protocol In PMIPv6 reliability protocol, MAGs which can take over mobility service for each other constitute a MAG Pool. The manager of a MAG Pool (MPM) is responsible for detecting status of each MAG in the MAG Pool. Once MPM detects a MAG become failed or overloaded, it SHOULD choose Takeover-MAG based on MAG List (Section 5.1) and trigger MAG service switching process (Section 3.3). There are multiple LMAs in a PMIPv6 domain. Each LMA MUST configure one and only one Supervisor-LMA. Supervisor-LMA is responsible for detecting status of its Supported-LMA. When Supervisor-LMA becomes failed or overloaded, Supported-LMA MUST choose another LMA as its Supervisor-LMA (Section 3.4). When a Supported-LMA becomes failed or overloaded, its Supervisor-LMA MUST trigger LMA service switching process (Section 3.4). Shi, et al. Expires - Expiration February 2010 [Page 6] Internet Draft PMIPv6 Reliability Protocol September 2009 In MIPv6, HA only manages MNs which have been registered in Home Link. However, in PMIPv6 domain, LMAs manage MNs of multiple access links so that the mobility information (such as PBCE) maintained in one LMA is very huge. Thus, if it is using one network entity to manage all LMA in one PMIPv6 domain, the management cost of such entity will be very huge and this deployment can also introduce large process delay to LMA. Contrarily, there are one or several MAGs to manage MNs, which are attached to one access link, so that the mobility information (such as BUL) maintained in one MAG is limited. Thus, using one entity to manage all MAGs in one access link is feasible. 3.1 MAG Pool Deployment The deployment of MAG Pool and MPM depends on the specific L2 network. We divide it into two scenarios. The first deployment scenario can be called non-overlap mode. The most exact example is WLAN. In WLAN, MAG deploys in the default access router in each link so that only can MAGs in the same link take over each other's service. Therefore, to attain the reliability, several MAGs SHOULD be deployed in each access link. These MAGs in the same link constitute a MAG Pool. Any MAG in MAG Pool can be configured as MPM. The second deployment scenario can be called overlap mode. The most exact example is 3GPP SAE. In SAE, MAGs which have connection with the same eNodeB can provide service instead of each other so that coverage areas of MAGs are overlapped. Therefore, one MAG can belong to several MAG Pool. MPM can be set in MME. 3.2 Status Detection Mechanism To achieve validity detection of mobility entities, we implement heartbeat message between them. The heartbeat mechanism for PMIPv6 is specified in [HEARTBEAT-PMIPV6]. MPM can use heartbeat message to detect validity of MAGs in its MAG Pool and LMA can use heartbeat message to detect validity of its Supervisor-LMA and Supported-LMA. To achieve overload detection of mobility entities, we add Load Information Option (Section 4.3) to heartbeat message. MAG carries Load Information Option in its heartbeat reply, so that MPM can get the load information of MAG; LMA carried Load Shi, et al. Expires - Expiration February 2010 [Page 7] Internet Draft PMIPv6 Reliability Protocol September 2009 Information Option in its heartbeat request/reply, so that the Supervisor-LMA or Supported-LMA can obtain its load information. 3.3 MAG Service Switching Mechanism Based on the Status Detection Mechanism, when MPM detects MAG becomes failed or overloaded, it should trigger the MAG service switching process (Figure 2). MPM Previous-MAG Takeover-MAG LMA | | | | 1. Get Previous-MAG | | | Information | | | | | | | | 2. MAG Switching Req | | |----------------------+---------------------->| | | | | | +---+----------------------+-----------------------+---+ | . | 3. Context Syn Req | | . | . |--------------------->| | . | . | | 4. Context Syn | . | . | |<--------------------->| . | . | 5. Context Syn Ack | | . | . |<---------------------| | . | +---+----------------------+-----------------------+---+ | | | | | | | | 6. Handoff Reg Req | | | |---------------------->| | | | | | | | 7. Updates Mobility Session | | | | | | | 8. Handoff Reg Ack | | | |<----------------------| | | | | | | 9. Service Failure-Affected-MNs | | | | | | 10. MAG Switching Ack | | |<---------------------------------------------| | | | | | | +-----------+-----------------------+---+ | | . | 11. MAG Switching | . | | . | Finish Announcement | . | | . |<----------------------| . | | . | | . | | . 12. Stop serving | . | | . Failure-Affected-MNs | . | Figure 2: MAG Service Switching Mechanism Shi, et al. Expires - Expiration February 2010 [Page 8] Internet Draft PMIPv6 Reliability Protocol September 2009 MPM gets Previous-MAG information (the MAG which is failed or overloaded) by the heartbeat message between MPM and MAG. Bases on the previous-MAG information, MPM determines whether such MAG is overload/failed or not. In either case, MPM should choose a Takeover-MAG in the MAG Pool and send a MAG Switching Request message to the Takeover-MAG. Additionally, if the Previous-MAG is overloaded, MPM should trigger the Previous-MAG to transfer context information of the Failure-Affected-MNs (the MNs that attach to the Previous-MAG domain) to the Takeover-MAG. For updating the mobility sessions of the Failure-Affected-MNs in LMA, Takeover-MAG sending Handoff Registration Request to such LMA. Upon accepting the Handoff Reg Req message, LMA should update the Proxy Binding Update Entries of Failure-Affected-MNs and change its endpoint of the bi-directional tunnel from Previous-MAG to the Takeover-MAG. After updating the mobility sessions of the Failure-Affected-MNs, LMA send a Handoff Reg Ack message to Takeover-MAG. In the case that Previous-MAG is failed, the Handoff Reg Ack message should also include the information of the Failure-Affected-MNs in order to let the Takeover-MAG create BUL correspondingly. The Takeover-MAG on receiving the Handoff Reg Ack message sets up its endpoint of the bi-directional tunnel to the LMA and also sets up the forwarding for the Failure-Affected-MNs?traffic. In the case that the Previous-MAG is overloaded, the Takeover-MAG should report to MPM the handoff result and notify the Previous- MAG to stop to provide mobility service for the Failure- Affected-MNs (such as stop to send RA to such MNs).At this point, the Takeover-MAG begins to provide mobility service for the Failure-Affected-MNs. 3.4 LMA Service Switching Mechanism Based on the Status Detection Mechanism, LMA and its Supervisor- LMA detect status of each other. When Supervisor-LMA detects its Supported-LMA failed or overloaded, it should initiate the LMA Service Switching Mechanism (Figure 3). Shi, et al. Expires - Expiration February 2010 [Page 9] Internet Draft PMIPv6 Reliability Protocol September 2009 MAGs Takeover-LMA Previous-LMA | | | | 1. LMA Switching Re | | |<-------------------------| | | | | | | | | 2. LMA Switching Ack | | |------------------------->| | | | | | 3. Create or Activate PBCE | | | | | 4. LMA Switching | | | Finish Announcement | | |<-------------------------| | | | | | 5. LMA Switching Finish Announcement | |------------------------------------------------->| | | | | | | | 6. MN Information Syn | | |------------------------->| | Figure 3: LMA Service Switching Mechanism Once the Previous-LMA (the LMA which is failed or overload) becomes overloaded/failed, the Takeover-LMA (the Supervisor-LMA of the Previous-LMA) should request all MAGs in the PMIPv6 domain to redirect mobility session to the Takeover-LMA by sending LMA Switching Request message. Upon receiving the LMA Switching Request message, MAG(which has mobility session with the Previous-LMA) should send a LMA Switching Ack message to the Takeover-LMA to indicate whether the MAG accepts switching request or not. If MAG accepts the switching request, the LMA Switching Ack message should include the mobility information of the Failure-Affected-MNs in order to let Takeover-LMA create mobility session correspondingly. Upon receiving the LMA Switching Ack message, the Takeover-LMA creates or activates PBCE for Failure-Affected-MNs and sets up its endpoint of the bi-directional tunnels to the MAGs. Then the Takeover-LMA sends LMA Switching Finish Announcement to the MAGs, indicating takeover result. At this point, the Takeover-LMA begins to provide mobility service for the Failure-Affected-MNs. The MAGs on receiving the LMA Switching Finish Announcement changes its endpoint of the bi-directional tunnel from Previous- Shi, et al. Expires - Expiration February 2010 [Page 10] Internet Draft PMIPv6 Reliability Protocol September 2009 LMA to Takeover-LMA and sends LMA Switching Finish Announcement to Previous-LMA to indicate takeover result. Based on the Status Detection Mechanism, when Supported-LMA detects its Supervisor-LMA failed or overloaded, it should choose another LMA as its Supervisor-LMA (Figure 4). LMA Candidate Supervisor-LMA(s) Other-LMA | | | 1. Choose candidate | | Supervisor-LMA(s) | | | | | | 2. Supervisor-LMA Req | | |------------------------->| | | | | | 3. Accept Req | | | | | 4. Supervisor-LMA Ack | | |<-------------------------| | | | | 5. Update | | Supervisor-LMA | | | | | | 6. Supervisor-LMA Update Announcement | |------------------------------------------------->| | | | | | 7. Update LMA List Figure 4: Supervisor-LMA update operation The Supported-LMA should choose other LMA(s) as candidate Supervisor-LMA(s) and send Supervisor-LMA request message(s) to the chosen LMA(s). Candidate supervisor-LMA should reply with a Supervisor-LMA Ack message to the Supported-LMA to indicate whether it desires to be a supervisor-LMA or not. If the Supported-LMA gets more than one Supervisor-LMA Ack messages from multiple candidate Supervisor-LMAs, it should choose only one of such LMAs as its Supervisor-LMA. Then the Supported-LMA sends Supervisor-LMA Update Announcement messages to all the other LMAs in the PMIPv6 domain in order to update the Supervisor-LMA domain of their LMA List. 4. Message Format All the following messages use Mobility Header defined in [RFC3775]. Shi, et al. Expires - Expiration February 2010 [Page 11] Internet Draft PMIPv6 Reliability Protocol September 2009 4.1 Service Switching Message Service Switching Message is used to control MAG or LMA switching procedure, including MAG Switching Message, Handoff Registration Message, LMA Switching Message and MAG/LMA Switching Finish Announcement Message. These messages has the same MH Type value TBD. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |handoff| Status |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Previous-Entity Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Mobility Options | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Service Switching Message Sequence Number A 16-bit unsigned integer used by the receiving node to sequence service switch request message and by the sending node to match a returned service switch acknowledgement message with this request message. If the 'Type' field is 6 or 7, this field MUST be set to 0. Synchronization Flag (S) A 1-bit flag that indicates whether Takeover-MAG and Previous-MAG or Takeover-LMA and Previous-LMA have finished Context Synchronization. If Context Synchronization is finished, the flag MUST be set to 1. Otherwise, the flag MUST be set to 0. Additionally, flag S is not used in some types of message, such as MAG Switching Request message. In Shi, et al. Expires - Expiration February 2010 [Page 12] Internet Draft PMIPv6 Reliability Protocol September 2009 this case, we still set S to 0 and just define the corresponding operation in the receiver node (usually ignore this flag). Type A 4-bit field that indicates different Service Switching Messages. It can be assigned one of the following values: 0: MAG Switching Request 1: Handoff Registration Request 2: LMA Switching Request 3: MAG Switching Acknowledgement 4: Handoff Registration Acknowledgement 5: LMA Switching Acknowledgement 6: MAG Switching Finish Announcement 7: LMA Switching Finish Announcement Handoff A 4-bit field that indicates the handoff reason or the type of handoff. The value of this field can be: 0: Previous entity overload 1: Previous entity fail 2: All MNs handoff 3: Partial MNs handoff If the 'Type' field is 0, 3 or 6, this field MUST be set to 0 or 1, indicating the status of Previous-MAG. When the 'Type' field is 2, 5 or 7, this field MUST be set to 2 or 3, indicating the type of Failure-Affected-MNs. If the 'Status' field is 3, LMA MUST carry Handoff Condition Option (Section 4.5) when it sends LMA Switching Request message to MAGs. Status An 8-bit unsigned integer indicating the disposition of the request message in Service Switching message. The Status value is shown as follow: Switching Success TBD Switching fail TBD No failed/overloaded entity address TBD Not enough MN information TBD Unrecognized sequence number TBD No handoff condition TBD Reserved Set to 0 and ignored by the receiver. Shi, et al. Expires - Expiration February 2010 [Page 13] Internet Draft PMIPv6 Reliability Protocol September 2009 Previous-Entity Address The address of overloaded or failed MAG/LMA. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. At the time of writing this document, the options can be LMA Address Option (Section 4.4), Handoff Condition Option (Section 4.5), or options defined in Section 8 of [RFC5213]. 4.2 LMA Control Message This message is used to update LMA information between LMAs in the same PMIPv6 domain. This message has the MH Type value TBD. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Status| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Mobility Options | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: LMA Control Message Sequence Number A 16-bit unsigned integer used by the receiving node to sequence Supervisor-LMA Request message and by the sending node to match a returned Supervisor-LMA Acknowledgement message with this request message. If the 'Type' field is 2 or 3, this field MUST be set to 0. Type A 4-bit field that indicates different LMA Control Messages. It can be assigned one of the following values: Shi, et al. Expires - Expiration February 2010 [Page 14] Internet Draft PMIPv6 Reliability Protocol September 2009 0: Supervisor-LMA Request 1: Supervisor-LMA Acknowledgement 2: Supervisor-LMA Update Announcement Status A 4-bit field that indicates the status of the LMA whose address is in 'LMA Address' field. The value of this field can be: 0: Active 1: Failed 2: Overloaded Reserved Set to 0 and ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. At the time of writing this document, the options can be Restart Counter Mobility Option defined in Section 3.4 of [HEARTBEAT-PMIPV6]. Additionally, LMA Address Option MUST be present in this message when the Type field is 2 . 4.3 Load Information Option MAG SHOULD carry this option when it sends Heartbeat Acknowledgement message to MPM, so that MPM can get the load information of the MAG. LMA MUST carry this option when it sends Heartbeat Request or Acknowledgement message to other LMA, so that the peer can get the load information of the LMA. 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 | Overhead | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Load Information Option Type Shi, et al. Expires - Expiration February 2010 [Page 15] Internet Draft PMIPv6 Reliability Protocol September 2009 A 8-bit field that indicates that it is a LMA Address Option. Length A 8-bit field that indicates the length of this option in octets excluding the 'Type' and 'Length' fields. It is set to 4. Overhead A 16-bit field that indicates the current overhead. 4.4 LMA Address Option MAG MAY carry this option when it sends Heartbeat Acknowledgement message to MPM, so that MPM can get the LMA address which has mobility session with the MAG. Also MPM MAY carry this option when it sends MAG Switching Request message to the Takeover-MAG, so that Takeover-MAG can get the LMA address which has mobility session with the Previous-MAG. 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 | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | LMA Address | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: LMA Address Option Type A 8-bit field that indicates that it is a LMA Address Option. Length A 8-bit field that indicates the length of this option in octets excluding the 'Type' and 'Length' fields. It is set to '16'. LMA Address Shi, et al. Expires - Expiration February 2010 [Page 16] Internet Draft PMIPv6 Reliability Protocol September 2009 A 128-bit field that indicates a LMA address. 4.5 Handoff Condition Option This option is used in LMA Switching Request message. Takeover- LMA MAY notify MAGs of the type of Failure-Affected-MNs with this 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 | Handoff Condition | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Handoff Condition Option Type A 8-bit field that indicates that it is a Handoff Condition Option. Length A 8-bit field that indicates the length of this option in octets excluding the 'Type' and 'Length' fields. Handoff Condition A 8-bit field that indicates which type of MN needs to handoff. It can be the percentage of MN, access technology type, etc. The format of this field is TBD. 5. MPM Operation The PMIPv6 reliability protocol described in this document introduces a new functional entity, the MAG pool manager (MPM). The MPM is the entity that is responsible for maintain the status of the MAGs in the MAG pool and initiating MAG switch when failure or overload occurs on the MAGs. The MPM is a function that typically runs on an MAG in the MAG pool. However, implementations MAY choose to split this function and run it across multiple systems. The specifics on how that is achieved or the signaling interactions between those functional entities are beyond the scope of this document. The MPM has the following key functional roles: Shi, et al. Expires - Expiration February 2010 [Page 17] Internet Draft PMIPv6 Reliability Protocol September 2009 1. Maintaining the status of MAGs in the MAG pool by the Heart Beat messages between MPM and each MAG in the MAG pool. 2. It is responsible for detecting the MN's attaching to the MPM pool and assign a MAG to the MN. 3. Responsible for initiating MAG switch when it detect a MAG failure or overload event. 5.1 Conceptual Data Structures MPM MUST maintain a MAG List in its local database. MAG List is used to store the running status of all MAGs in the MAG Pool and is updated by Heartbeat Acknowledgement messages which MPM received. For supporting this specification, the data structure of MAG List includes following fields. MAG Address The network-layer address of a MAG in the MAG Pool. This address is the unique identification of MAG in MAG List and is obtained from the source address of heartbeat message from MAG. MAG Load The load information of MAG, can be the number of MN attached to the MAG, or the variable which can represent the real load condition of the MAG. Such information is obtained from the Load Information Option in the heartbeat message sent by MAG. This field is not necessary in the MAG List because, in some scenarios, load balance function is not required. This variable MUST be initialized to a value of ALL_ZERO. MAG Status The status of MAG (Failed, Overloaded or Active), which is correspond to the failed MAG, overloaded MAG or active MAG (not failed and overloaded). Such status is set by the MPM based on the Heartbeat Acknowledgement message from MAG. This variable MUST be initialized to a value of Active. LMA address list Shi, et al. Expires - Expiration February 2010 [Page 18] Internet Draft PMIPv6 Reliability Protocol September 2009 The addresses of LMAs which have mobility session with the MAG. LMA address list is obtained from the LMA Address Option in the Heartbeat Acknowledgement message from MAG. 5.2 Operation about MAG list The addresses of all the MAGs in the MAG pool MUST be statically configured and stored in MPM list. To obtain the status of MAG, MPM MUST periodically send Heartbeat Request messages to all the MAGs in the MAG list. The other fields in MAG list are configured as section 5.1. MPM detects a MAG failed as described in [HEARTBEAT-PMIPV6]. In this case, MPM MUST change status of the failed MAG to Failed and trigger the MAG Service Switch Mechanism. When MPM is required to maintain MAGs?load information, it MUST include Load Information Option in the Heartbeat Request message. When MPM receives Heartbeat Acknowledgement message with Load Information Option from MAG, MPM learns the load information of MAG from this option and records the load information in the MAG load attribute of MAG list entry. If MPM receives Heartbeat Acknowledgement message without Load Information Option, MPM just take the failed detection (section 3.2) to that MAG. When MPM detects that MAG becomes failed or overloaded, it MUST select a Takeover-MAG from the MAG list. For load balance purpose, the selection MUST be based on the load information of MAGs. MPM MUST select an active MAG with the lowest load in the MAG list. Otherwise, it should just select an active MAG based on other consideration depend on implement. 5.3 Processing Heartbeat Message In this specification, MPM gets MAG information by sending Heartbeat Request and receiving Heartbeat Acknowledgement message. MPM should process other cases (receiving Heartbeat Request and sending Heartbeat Acknowledgement message) according to [HEARTBEAT-PMIPV6]. 5.3.1 Sending Heartbeat Request According to [HEARTBEAT-PMIPV6], the MPM sends Heartbeat Request messages to all the MAGs in the MAG list. These MAG addresses are configured in MPM statically. Additionally, there are two extensions to [HEARTBEAT-PMIPV6]: Shi, et al. Expires - Expiration February 2010 [Page 19] Internet Draft PMIPv6 Reliability Protocol September 2009 1. MPM MUST include LMA Address Option in Heartbeat Request message and set the LMA address to ALL_ZERO. 2. If MPM is required to consider load balance, it MUST include Load Information Option in the Heartbeat Request message and set the overhead field to ALL_ZERO. 5.3.2 Receiving Heartbeat Acknowledgement The MPM receives Heartbeat Acknowledgement message from MAG as described in [HEARTBEAT-PMIPV6]. How does MPM determine whether MAG is failed or not is as same as HEARTBEAT-PMIPV6.Additionally, there are several extensions to HEARTBEAT-PMIPV6: 1. If the LMA Address Option is presented in Heartbeat Acknowledgement message and the LMA address field is not ALL_ZERO, MPM MUST record such address in the LMA address field of the MAG list entry of that MAG. 2. If the LMA Address Option is presented in Heartbeat Acknowledgement message and the LMA address field is ALL_ZERO (this means that the MAG does not have any mobility session with any LMA), MPM also set the LMA address field of the corresponding MAG entry in the MAG list to ALL_ZERO.. 3. If the Load Information Option is presented in Heartbeat Acknowledgement message and the Overhead field is not ALL_ZERO, MPM MUST update the MAG_Load field of the corresponding MAG entry in the MAG list to the same as the Overhead field. Additionally, if the 'Overhead' field exceeds a preconfigured parameter MAX_LOAD_ALLOWED, MPM concludes that the MAG is overloaded. Otherwise, MPM concludes that the MAG is active. 4. If the Load Information Option is not presented in heartbeat acknowledgement message, MPM receives such message according to [HEARTBEAT-PMIPV6]. 5.4 MAG Switching Message 5.4.1 Sending MAG Switching Request When MPM detects a MAG failed as described in [HEARTBEAT-PMIPv6] or overloaded as described in Section 5.4.2, it MUST choose a MAG (Takeover-MAG) to take over the mobility service of failed MAG or overloaded MAG. If the MAG Load filed in MAG list is not ALL_ZERO, the MPM SHOULD choose the MAG with the lowest load in MAG List as Takeover-MAG. If MAG Load filed in MAG list is Shi, et al. Expires - Expiration February 2010 [Page 20] Internet Draft PMIPv6 Reliability Protocol September 2009 ALL_ZERO, the MPM SHOULD choose the MAG based on other considerations which is out of the scope of this specification. When MPM detects that one MAG in MAG Pool becomes failed or overloaded, the MPM MUST send a MAG Service Switching message to Takeover-MAG, which is constructed as follows: 1. MPM MUST maintain a valid sequence number. Each time the MPM sends a MAG Switch Request message, it MUST set the Sequence Number field to the sequence number and increase the sequence number to one more. 2. Synchronization Flag (S) bit MUST be set to 0 in this message. 3. The Type field MUST be set to 0, indicating that this message is a MAG Switching Request. 4. The Handoff field SHOULD be set to 1 if MPM detects Previous- MAG Failed or set to 0 if MPM detect Previous-MAG overloaded. 5. The Status field SHOULD be set to ALL_ZERO in this message. 6. Previous-Entity Address field MUST be set to the address of the Previous-MAG. 7. If the LMA address list in the entry correspond to Previous- MAG in the MAG list is not null, the MPM SHOULD include one or more LMA Address Option in the MAG Switching Request message and the LMA address field SHOULD be set to the LMA address(es) in LMA address list. Otherwise, LMA Address Option MUST be not present in this message. 5.4.2 Receiving MAG Switching Acknowledgement Before accepting a MAG Switching Acknowledgement, MPM MUST validate such message according to the following tests: If the Sequence Number value in MAG Switching Acknowledgement message does not equals any number stored in MPM, MPM just ignore this message. If MAG Switching Acknowledgement message is valid according to the tests above, then the message is processed further as follows: 1. MPM MUST apply the below considerations when processes Status filed: Shi, et al. Expires - Expiration February 2010 [Page 21] Internet Draft PMIPv6 Reliability Protocol September 2009 2. If the Status filed in the message is 130, the MPM considers that the service switching operation is successful. 3. If the Status filed in the message is 0, MPM SHOULD select another Takeover-MAG and send MAG Switching Request message as described in section 5.5.1, in order to trigger another MAG service switching procedure. 4. If the Status filed in the message is (exactly number is TBD), means here is no options of Failure-Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) in Handoff Registration Acknowledgement message which Takeover-MAG received, or (exactly number is TBD), means Sequence Number value in Handoff Registration Acknowledgement does not equals any number stored in Takeover-MAG, MPM SHOULD trigger another MAG service switching procedure. 5. All other field SHOULD be ignored by MPM. 6. MAG Operation Based on RFC5213, there are several extensions to MAG in this specification, which is shown as following: 1. All the MAGs in MAG Pool should configure MPM address statically. 2. Support extended heartbeat mechanism, which is shown in 3.2 3. Support MAG Service Switching Mechanism and LMA Service Switching Mechanism. 6.1 Takeover MAG Service In MAG Service Switch Mechanism, MAG provides mobility service for the Failure-Affected-MNs in place of the failed or overloaded MAG. To achieve this, MAG MUST create mobility sessions and set up bi-directional tunnels for the Failure- Affected-MNs as described in [RFC5213]. Then MAG sends Routing Advertisement messages with the same link-local and link-layer address to the Failure-Affected-MNs in order to make takeover procedure transparent to MN. 6.2 Get Failure-Affected-MNs?information When a MPM detected a MAG is failed or overload, it MUST trigger MAG Service Switch Mechanism (3.4). In order to provide mobility Shi, et al. Expires - Expiration February 2010 [Page 22] Internet Draft PMIPv6 Reliability Protocol September 2009 service instead of failed or overloaded MAG, Takeover-MAG MUST get Failure-Affected-MNs?information. In case of MAG failure, Takeover-MAG should takeover mobility service to all MNs attached to failed MAG. Such MNs?information (HNP, MN-ID, MN-LL-IF, etc) can only be transferred to Takeover- MAG from LMAs which have mobility session with failed MAG. To achieve this, the Takeover-LMA sends Handoff Registration Request message to all the LMAs that have mobility session with the failed MAG. In case of MAG failure, Takeover-MAG should takeover mobility service to the part of MNs attached to failed MAG. Such MNs? information (HNP, MN-ID, MN-LL-IF, etc) can be transferred to Takeover-MAG from overloaded MAG. To achieve this, the MPM trigger the overload MAG to synchronize mobility context with the Takeover-MAG. Overload MAG decides whether transfer all the MNs or part of the MNs to the Takeover-MAG. 6.3 Heartbeat Message In this specification, MAG reports its information by sending Heartbeat Acknowledgement message. MAG should process other cases (receiving Heartbeat Acknowledgement and sending Heartbeat Request message) according to [HEARTBEAT-PMIPV6]. When MAG receive heartbeat request message, MAG should send Heartbeat Acknowledgement message to MPM as described in [HEARTBEAT-PMIPV6].There are several extensions to [HEARTBEAT- PMIPV6]: 1. If LMA Address Option is presented in the Heartbeat Request message, MAG MUST include LMA Address Option in the Heartbeat Acknowledgement and set the LMA Address field to the address of LMA which has mobility session with the MAG. If the MAG has mobility several LMAs, multiple LMA Address Options SHOULD be included in such message. If MAG has no mobility session with any LMA, it SHOULD set the LMA Address field to ALL_ZERO. 2. If Load Information Option is presented in the Heartbeat Request message, MAG should include Load Information Option in Heartbeat Acknowledgement message and set the Overhead field to the variable which can represent the load information of the MAG. 6.4 MAG Switching Message 6.4.1 Receiving MAG Switching Request Shi, et al. Expires - Expiration February 2010 [Page 23] Internet Draft PMIPv6 Reliability Protocol September 2009 Before accepting a MAG Switching Request, MAG MUST validate such message according to the following tests: 1. The Previous-Entity Address field MUST be set in this message. If not, MAG SHOULD reply MAG Switching Acknowledgement message to indicate failure with Status code (TBD). 2. If MAG Switching Request message is valid according to the tests above, the MAG SHOULD process the message as follows: 3. The Sequence Number value SHOULD be stored in the local database of MAG in order to identify MAG switch event. 4. If the Synchronization Flag (S) bit is set, MAG processes this field as 6.6.1. 5. The MAG MUST apply the following considerations when processes the Handoff field: If the Handoff field is 0 which means Previous-MAG is overloaded, MAG SHOULD initiate the Context Synchronization procedure with the Previous-MAG which is indicated in Previous-Entity Address field. The specific Context Synchronization procedure is out of this specification scope. After Context Synchronization procedure, whether it is success or failed, MAG MUST send a Handoff Registration message as (6.6.1). 6. If the Handoff field is 1 which means Previous-MAG is failed, MAG SHOULD send Handoff Registration message to LMA as (6.6.1). 7. The Status field SHOULD be processed as 6.6.1. 8. The MAG SHOULD store Previous-Entity Address value temporarily in order to use this address for sending Handoff Registration message (section 6.6.1). 9. If the LMA Address Option is present in MAG Switching Request message, the MAG SHOULD store the LMA address value temporarily in order to use this address for sending Handoff Registration message (section 6.6.1). 10. If the LMA Address Option is not present in MAG Switching Request message, the MAG should send Handoff Registration message to all the LMAs in the PMIPv6 domain (section 6.6.1). 6.4.2 Sending MAG Switching Acknowledgement Shi, et al. Expires - Expiration February 2010 [Page 24] Internet Draft PMIPv6 Reliability Protocol September 2009 After processing the Handoff Registration Acknowledgement message, MAG SHOULD send MAG Switching Acknowledgement message to its MPM. 1. MAG MUST set the Type field to 3, indicating that this message is a MAG Switching Acknowledgement. 2. MAG should apply the following considerations when set Status field: If the flag S in Handoff Registration Acknowledgement message equals to 0 and there is no options of Failure-Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) in Handoff Registration Acknowledgement message, Status code should be set to TBD. If the Sequence Number value in Handoff Registration Acknowledgement message does not equal any number stored in MAG which comes from MAG Switching Request message, Status code should be set to TBD. If MAG starts to provide mobility service for Failure-Affected- MNs, Status field MUST be set to TBD. Otherwise, the Status field MUST be set to TBD. 3. All other fields MUST be set the same as Handoff Registration Acknowledgement message. 6.4.3 Sending MAG Switching Finish Announcement After processing the Handoff Registration Acknowledgement and sending MAG Switching Acknowledgement to MPM (section 6.5.2), if the Status filed In the Handoff Registration Acknowledgement message is TBD(means Switching Success) and the handoff field is 0, MAG MUST send MAG Switching Finish Announcement to Previous- MAG. If the handoff field in the Handoff Registration Acknowledgement is 1, MAG just send MAG Switching Acknowledgement message to MPM (section 6.5.2). 1. MAG MUST set the 'Type' field to 6, indicating that this message is a MAG Switching Finish Announcement. 2. If MAG starts providing mobility service for Failure- Affected-MNs, the Status field MUST be set to 130. Otherwise, the status MUST be set to 0. 3. All other fields MUST be set the same as the received MAG Switching Request message. Shi, et al. Expires - Expiration February 2010 [Page 25] Internet Draft PMIPv6 Reliability Protocol September 2009 6.4.4 Receiving MAG Switching Finish Announcement Before accepting a MAG Switching Finish Announcement, MAG MUST validate such message according to the following tests: If the Sequence Number value in MAG Switching Finish Announcement message does not equal any number stored in MAG, MAG just ignore this message. If MAG Switching Finish Announcement message is valid according to the tests above, then the MAG Switching Finish Announcement message is processed further as follows: 1. MAG MUST apply the following considerations when processes Status filed: If the Status filed in the message is 130, the MAG MUST stop providing mobility service for Failure-Affected-MNs as described in [RFC5213], including deleting BUL of Failure-Affected-MNs and stopping send RA, which include HNP, to such MNs. If the Status filed in the message is 0, MAG SHOULD continues providing mobility service to the Failure-Affected-MNs. 2. All other field should be ignored by MAG 6.5 Handoff Registration Message 6.5.1 Sending Handoff Registration Request After processed MAG Switching Request message successfully, MAG should send Handoff Registration Request message to LMA which is constructed as follows: 1. If the handoff field in MAG Switching Request message is 0 which means Previous-MAG is overloaded, MAG MUST send Handoff Registration Request message to LMA until the Context Synchronization is finished. Otherwise, MAG should send Handoff Registration Request message to LMA after processing the MAG Switching Request message successfully. The specific Context Synchronization procedure is out of this specification scope. 2. The destination address of Handoff Registration Request message comes from the LMA Address Option, if it presents in MAG Switching Request message. Additionally, if there are multiple LMA Address Options present in the MAG Switching Request message, the destination address of Handoff Registration Request message Shi, et al. Expires - Expiration February 2010 [Page 26] Internet Draft PMIPv6 Reliability Protocol September 2009 should be set to one of the LMA address in such LMA Address Options. MAG should send Handoff Registration Request messages to every LMA, whose address is present in LMA Address Options. Apart from the destination address, all fields in these messages are the same. On the other hand, If LMA Address Option is not present in MAG Switching Request message, the destination address of Handoff Registration Request message should be set to any one of LMA addresses in the PMIPv6 domain and MAG MUST send Handoff Registration Request to all LMAs in such domain. 3. The Sequence Number value MUST be set to the corresponding value in MAG switching request message in order to identify the mobility switch event. 4. MAG SHOULD apply the following considerations when processes Synchronization Flag (S) bit: If handoff field in MAG Switching Request message is 0 and the Context Synchronization has been finished successfully, flag S MUST be set to 1. Additionally, MAG MUST include options of Failure-Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) to this message. The content of such options comes from Context Synchronization procedure. If there are lots of Failure- Affected-MNs whose information can not be carried in one request message, MAG SHOULD send multiple request messages to LMA which all contain the same sequence number. If handoff field in MAG Switching Request message is 0 and the Context Synchronization is failed, flag S MUST be set to 0. Options of Failure-Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) MUST NOT be included in Handoff Registration Request message. If handoff field in MAG Switching Request message is 1, flag S MUST be set to 0. Options of Failure-Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) MUST NOT be include in Handoff Registration Request message. 5. MAG MUST set the 'Type' field of Service Switching message (Section 4.1) to 1, indicating that this message is a Handoff Registration Request message. 6. The handoff field should be set to the corresponding value in MAG switching Request message. 7. Previous-Entity Address MUST be set to the corresponding value in MAG switching Request message. Shi, et al. Expires - Expiration February 2010 [Page 27] Internet Draft PMIPv6 Reliability Protocol September 2009 8. Status field should be set to the corresponding value in MAG Switching Request message. 6.5.2 Receiving Handoff Registration Acknowledgement Before accepting a Handoff Registration Acknowledgement, MAG MUST validate it according to the following tests: 1. If the flag S equals to 0 and there is no option of Failure- Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) in Handoff Registration Acknowledgement message, MAG should send MAG Switching Acknowledgement message with Status code (TBD). 2. If the Sequence Number value in Handoff Registration Acknowledgement does not equal any number stored in MAG which comes from MAG Switching Request message, MAG should replay MAG Switching Acknowledgement message with Status code (TBD). If Handoff Registration Acknowledgement message is valid according to the tests above, then the message is processed further as follows: 1. LMA MUST apply the following considerations when processes Synchronization Flag (S) bit: 2. If the Flag S is 0 which means the Takeover-MAG does not get any Failure-Affected-MNs?information, MAG creates Failure- Affected-MNs' PBCE by using options of Failure-Affected-MNs (include HNP Option, MN-LL-ID Option, MN-ID Option) in Handoff Registration Acknowledgement message. 3. If the Flag S is 1 which means the Takeover-MAG gets Failure- Affected-MNs?information by Context Synchronization, MAG creates Failure-Affected-MNs' PBCE by using information which comes from Context Synchronization. 4. If handoff field is set, MAG processes this field as 6.5.2. 5. If status field is set, MAG processes this field as 6.5.2. 6. If Previous-Entity address field is set, MAG processes this field as 6.5.2. 6.6 LMA Switching Message 6.6.1 Receiving LMA Switching Request Shi, et al. Expires - Expiration February 2010 [Page 28] Internet Draft PMIPv6 Reliability Protocol September 2009 Before accepting a LMA Switching Request message, MAG MUST validate the message according to the following tests: 1. If the message includes a Previous-Entity Address field but the address is different from any of the addresses of the LMA that has mobility session with the MAG, the MAG just ignore this message. 2. If the Handoff field is 3 and without a Handoff Condition Option, the MAG MUST reject the request and reply with a LMA Switch Acknowledgement message with the Status field (TBD). 3. If the message does not include a Previous-Entity Address field, the MAG MUST reject the request and reply with a LMA Switching Acknowledgement message with the Status field (TBD). 4. If the Handoff field is set to 2 and include a Handoff Condition Option, the MAG MUST ignore this option. If a LMA Switching Request message is valid according to the tests above, then the message is processed further as follows: 1. The Sequence Number value SHOULD be stored in the local database of MAG in order to identify LMA switch event. 2. If the Handoff field is 2, the MAG should search MNs from BUL by the LMA address in Previous-Entity field of LMA Switching Request message. 3. If the Handoff field is 3, the MAG MUST search MN from BUL by handoff field in the Handoff Condition Option of LMA Switching Request message. 4. If there is any BUL entry matched, MAG MUST send a LMA Switch Acknowledgement message to the LMA as 6.7.2. 5. If there is no BUL entry matched, then the MAG MUST drop the request message silently without a reply. 6. The Status field SHOULD be processed as 6.7.2. 7. The Synchronization Flag (S) SHOULD be processed as 6.7.2. 6.6.2 Sending LMA Switching Acknowledgement Shi, et al. Expires - Expiration February 2010 [Page 29] Internet Draft PMIPv6 Reliability Protocol September 2009 After processing LMA Switch Request message, MAG send a LMA Switching Acknowledgement message to the LMA, which is constructed as follows: 1. The MAG MUST set the Sequence Number field to the same number as in the corresponding LMA Switch Request message. 2. LMA MUST set the 'Type' field of Service Switching message (Section 4.1) to 5, indicating that this is a LMA Switching Acknowledgement message. Other fields of this message MUST be set as follows. 3. The Handoff field SHOULD be set to the corresponding value in the LMA Switch Request message. 4. Synchronization Flag (S) bit SHOULD be set to the corresponding value in the LMA Switch Request message. 5. The Previous-Entity Address field SHOULD be set to the corresponding value in the LMA Switch Request message. 6. The Status field SHOULD be set to the corresponding value in the LMA Switch Request message. 7. MAG MUST carry mobility context (as described in [RFC5213]) of the Failure-Affected-MNs in this message, including HNP Option, MN-LL-ID Option, MN-ID Option. If there are lots of Failure-Affected-MNs whose information can not be carried in one acknowledgement, MAG SHOULD send multiple acknowledgements messages to Takeover-LMA. 6.6.3 Receiving LMA Switching Finish Announcement Before accepting a LMA Switching Finish Announcement, MAG MUST validate the message according to the following tests: 1. If the Sequence Number value in LMA Switching Finish Announcement message does not equal any number stored in MAG, MAG just ignore this message. If LMA Switching Finish Announcement message is valid according to the tests above, then the Handoff Registration Acknowledgement message is processed further as follows: 1. The MAG MUST update the BUL: change the LMA address of the Failure-Affected-MNs to the Previous-Entity address in LMA Switching Finish Announcement message. Shi, et al. Expires - Expiration February 2010 [Page 30] Internet Draft PMIPv6 Reliability Protocol September 2009 2. If the Status filed in the message is TBD, the MPM consider that the service switching operation is successful. 3. The MAG MUST apply the following considerations when choosing the value for the Handoff field. The handoff field MUST be set to 2, MAG do nothing further. The handoff field MUST be set to 3, MAG should transfer LMA Switching Finish Announcement to LMA as 6.7.4. 6. All other fields should be ignored by MAG. 6.6.4 Sending LMA Switching Finish Announcement After processing LMA Switching Finish Announcement message, MAG SHOULD Transfer this message to LMA whose address is present in the Previous-Entity Address field of the message. The purpose of this operation is to notify LMA, which may be overloaded, to stop providing mobility service for the Failure-Affected-MNs. Additionally, MAG MUST include Handoff Condition Option in this message. 7. LMA Operation Based on RFC5213, there are several extensions to LMA in this specification, which is shown as following: 1. Support Supervisor relationship between LMAs. Such Supervisor relationship is statically configured in deployment stage and updated in LMA Service Switching even. 2. Support extended heartbeat mechanism, which is shown in 3.2 3. Support MAG Service Switching Mechanism and LMA Service Switching Mechanism. 7.1 Conceptual Data Structures Every LMA MUST maintain a LMA List in its local database. LMA List is used to store the running status of all LMAs in the PMIPv6 domain. The content of LMA List is updated by LMA when it receives Heartbeat Acknowledgement messages from its supported LMA or detects LMA failure. Shi, et al. Expires - Expiration February 2010 [Page 31] Internet Draft PMIPv6 Reliability Protocol September 2009 For supporting this specification, the LMA List data structure includes following fields. LMA Address Address of LMA in PMIPv6 domain, which is the unique identification of LMA in LMA List. This field must be configured in the deployment stage statically and updated by the LMA control message. Supervisor-LMA Address of Supervisor-LMA. This field must be configured in the deployment stage statically and updated by the LMA control message. LMA Load The load information of LMA, can be the number of PBCE maintained in LMA, or the variable which can represent the real load condition of the LMA. This field is obtained from the Heartbeat Acknowledgement message from other LMA. This field is not necessary in the LMA List because, in some scenarios, load balance is not required. This variable MUST be initialized to a value of ALL_ZERO. LMA Status The status of LMA (Active, Failed or Overloaded), which is correspond to the failed LMA, overloaded LMA or active LMA (not failed and overloaded). Such status must be configured to active in the deployment stage and updated by the LMA control message. This variable MUST be initialized to a value of Active. 7.2 Operation about LMA list LMA MUST statically configured addresses of all the LMAs in the PMIPv6 domain and their Supervisor-LMA address. The other fields in LMA list are configured as section 7.1. LMA detects its Supervisor-LMA failed as described in [HEARTBEAT-PMIPV6]. In this case, LMA MUST change the status of the failed LMA to Failed and initiate the Supervisor-LMA update operation (section 3.4). During such operation, LMA MUST advertise its new Supervisor-LMA address to all the other LMAs in the PMIPv6 domain by Supervisor-LMA Update Announcement messages. Other LMAs MUST update their LMA list according to those messages, including setting the LMA Status field of the Shi, et al. Expires - Expiration February 2010 [Page 32] Internet Draft PMIPv6 Reliability Protocol September 2009 failed LMA entry to Failed and setting the Supervisor-LMA address field of the supported LMA entry to the new Supervisor- LMA address. If a LMA find that the failed LMA is its supervisor LMA, it MUST initiate the Supervisor-LMA update operation (section 3.4). Once load balance is required, each LMA MUST maintain the load information of its Supervisor-LMA in the LMA list. If a LMA is the supervisor of another LMA(s), it MUST maintain the load information of its Supported-LMA(s). This is supported by the Status Detection Mechanism (section 3.2). 7.3 Get Failure-Affected-MNs?information If LMA detected that its supported LMA is failed or overloaded, it MUST initiate LMA Service Switch Mechanism (section 3.4). In case of LMA failure, Supervisor-LMA should take over mobility service to all MNs registered to failed LMA. Such MNs? information (HNP, MN-ID, MN-LL-IF, etc) can only be transferred to Supervisor-LMA from MAGs which have mobility session with failed LMA. To achieve this, the Supervisor-LMA MUST send LMA Switching Request messages to all the MAGs in this PMIPv6 domain. In case of LMA overload, Supervisor-LMA should take over mobility service to part of MNs registered to overloaded LMA. To achieve this, the Takeover-LMA MUST send LMA Switching Request messages to all the MAGs in this PMIPv6 domain. 7.4 Heartbeat Message 7.4.1 Sending Heartbeat Request According to the HEARTBEAT-PMIPV6, Supervisor-LMA sends heartbeat request message to its Supported-LMA. Additionally, there is one extension to HEARTBEAT-PMIPV6: If Supervisor-LMA determines to include load balance function, it MUST include Load Information Option in the heartbeat request message and set the overhead field to the variable which can represent the load information of itself, such as the number of PBCE, CPU utilization and so on. The meaning of overhead field (represent which kind of load information) MUST be configured in both Supported-LMA and Supervisor-LMA statically. Otherwise, Supervisor-LMA set the overhead field to ALL_ZERO. 7.4.2 Receiving Heartbeat Request Shi, et al. Expires - Expiration February 2010 [Page 33] Internet Draft PMIPv6 Reliability Protocol September 2009 According to the HEARTBEAT-PMIPV6, Supported-LMA receives heartbeat request message from its Supervisor-LMA. How does Supported-LMA determine whether Supervisor-LMA is failed or not is as same as HEARTBEAT-PMIPV6.Additionally, there are two extensions to HEARTBEAT-PMIPV6: 1. If Load Information Option is presented in the heartbeat request message and the overhead field is not ALL_ZERO, Supported-LMA MUST add the overhead field value to LMA load field in entry of LMA List whose LMA address equals Supervisor- LMA (source address of heartbeat request message). If the 'Overhead' field exceeds a configurable parameter MAX_LOAD_ALLOWED, Supported-LMA concludes that its Supervisor- LMA is overloaded and set the LMA Status field to overloaded in the entry of LMA List whose LMA address equals Supervisor-LMA. 2. If Load Information Option is presented in the heartbeat request message and the overhead field is ALL_ZERO, Supported- LMA set the LMA load field to ALL_ZERO in entry of LMA List whose LMA address equals Supervisor-LMA. 7.4.3 Sending Heartbeat Acknowledgement According to the HEARTBEAT-PMIPV6, Supported-LMA sends heartbeat acknowledgement message to its Supervisor-LMA. Additionally, there are two extensions to HEARTBEAT-PMIPV6: 1. If Load Information Option is presented in the heartbeat request message and the overhead field is not ALL_ZERO, Supported-LMA MUST include Load Information Option in Heartbeat Acknowledgement and set the overhead field to the variable which can represent the load information of itself, such as the number of PBCE, CPU utilization and so on. 2. If Load Information Option is presented in the heartbeat request message and the overhead field is ALL_ZERO, Supported- LMA MUST include Load Information Option in Heartbeat Acknowledgement and set the overhead field to ALL_ZERO. 7.4.4 Receiving Heartbeat Acknowledgement According to the HEARTBEAT-PMIPV6, Supervisor-LMA receives heartbeat acknowledgement message from its Supported-LMA. How does Supervisor-LMA determine whether Supported-LMA is failed or not is as same as HEARTBEAT-PMIPV6. Additionally, there are two extensions to HEARTBEAT-PMIPV6: Shi, et al. Expires - Expiration February 2010 [Page 34] Internet Draft PMIPv6 Reliability Protocol September 2009 1. If Load Information Option is presented in the heartbeat acknowledgement message and the overhead field is not ALL_ZERO, Supervisor -LMA MUST add the overhead field value to LMA load field in entry of LMA List whose LMA address equals Supported- LMA (source address of heartbeat acknowledgement message). If the 'Overhead' field exceeds a configurable parameter MAX_LOAD_ALLOWED, Supervisor-LMA concludes that its Supported- LMA is overloaded and set the LMA Status field to overloaded in the entry of LMA List whose LMA address equals Supported-LMA. 2. If Load Information Option is presented in the heartbeat request message and the overhead field is ALL_ZERO, Supervisor - LMA MUST set the LMA load field to ALL_ZERO in the entry of LMA List whose LMA address equals Supported-LMA. 7.5 LMA Control Message 7.5.1 Sending Supervisor-LMA Request When the LMA detects its Supervisor-LMA failed (Section 7.2.1) or overloaded (Section 7.4.4), it MUST send Supervisor-LMA Request to LMAs in the PMIPv6 domain, whose status is 0 in LMA list. The LMA SHOULD choose one or multiple LMA based on LMA_Status and LMA_Load field in the LMA List, and send Supervisor-LMA Request message to them separately. Supervisor- LMA Request message is constructed as follows: 1. The LMA MUST maintain a valid sequence number. Each time the LMA send a Supervisor-LMA Request message, it MUST set the Sequence Number field to the sequence number and increase the sequence number to one more. 2. The LMA MUST set the 'Type' field of LMA Control Message (Section 4.2) to 0, indicating that this message is a Supervisor-LMA Request. 3. The Status field should be set to ALL_ZERO in this message. 7.5.2 Receiving Supervisor-LMA Request When the LMA receives Supervisor-LMA Request message, it SHOULD process the message as follows: 1. If LMA decides to be a supervisor LMA, it MUST send a Supervisor-LMA Acknowledgement message with the Status field set to 130 (TBD) and with the Sequence Number field the same as the Supervisor-LMA Request message. Otherwise, LMA just ignore this message. Shi, et al. Expires - Expiration February 2010 [Page 35] Internet Draft PMIPv6 Reliability Protocol September 2009 2. The Status field SHOULD be processed as 7.5.3. 7.5.3 Sending Supervisor-LMA Acknowledgement If LMA decides to be a supervisor LMA after receiving the Supervisor-LMA Request as described in Section 7.5.2, it MUST send Supervisor-LMA Acknowledgement to the sender of Supervisor- LMA Request, which is constructed as follows: 1. The Sequence Number value MUST be set to the corresponding value in Supervisor-LMA Request message in order to identify the supervisor LMA update event. 2. The LMA MUST set the 'Type' field of LMA Control Message to 1, indicating that this message is a Supervisor-LMA Acknowledgement. 3. The Status field should be set to the corresponding value in Supervisor-LMA Request message. 7.5.4 Receiving Supervisor-LMA Acknowledgement Before accepting a Supervisor-LMA Acknowledgement, LMA MUST validate such message according to the following tests: 1. If the Sequence Number value in Supervisor-LMA Acknowledgement does not equals any number stored in local database, LMA just ignore this message. 2. If Supervisor-LMA Acknowledgement is valid according to the tests above, then the the Supervisor-LMA Acknowledgement is processed further as follows: 3. If the LMA receives multiple successful Supervisor-LMA Acknowledgement, the LMA MUST choose one and only one LMA as its Supervisor-LMA. 4. The Status field SHOULD be processed as 7.5.5. 7.5.5 Sending Supervisor-LMA Update Announcement After processed Supervisor-LMA Acknowledgement and get a new LMA to be its supervisor LMA, LMA sends Supervisor-LMA Update Announcement message to all other LMAs in the same PMIPv6 domain, which is constructed as follows: 1. The Sequence Number value MUST be set to the corresponding value in Supervisor-LMA Acknowledgement message in order to identify the supervisor LMA update event. Shi, et al. Expires - Expiration February 2010 [Page 36] Internet Draft PMIPv6 Reliability Protocol September 2009 2. The LMA MUST set the 'Type' field of LMA Control Message to 2, indicating that this message is a Supervisor-LMA Update Announcement. Other fields of this message MUST be set the same as follows. 3. The Status field SHOULD be set to 1 or 2 in this message, which means the LMA, whose address is present in LMA Address Option, is failed or overloaded respectively. 4. LMA Address Options MUST be present in this message with the LMA Address field setting to the new Supervisor-LMA Address. 7.5.6 Receiving Supervisor-LMA Update Announcement Before accepting a Supervisor-LMA Update Announcement, MAG MUST validate such message according to the following tests: If LMA Address Option is not present in Supervisor-LMA Update Announcement, the LMA MUST ignore the message. If Supervisor-LMA Update Announcement is valid according to the tests above, then the Supervisor-LMA Update Announcement is processed further as follows: 1. To the entry whose LMA address is failed or overload Supervisor-LMA Address LMA should update the Status field to 1 or 2 according to Status field in Supervisor-LMA Update Announcement message. 2. To the entry whose LMA address is the source address of the Supervisor-LMA Update Announcement message, LMA should update the Supervisor-LMA field according to LMA Address Option. 7.6 Handoff Registration Message 7.6.1 Receiving Handoff Registration Request Before accepting a Handoff Registration Request, MAG MUST validate such message according to the following tests: 1. The Previous-Entity address MUST be set to NULL_ZERO in this message. If not, LMA should send Handoff Registration Acknowledgement message with status code (TBD). 2. If the flag S is 1 and there is not or not enough related options (include HNP Option, MN-LL-ID Option, MN-ID Option) of Failure-Affected-MNs, LMA should send Handoff Registration Acknowledgement message with status code (TBD). Shi, et al. Expires - Expiration February 2010 [Page 37] Internet Draft PMIPv6 Reliability Protocol September 2009 3. If LMA receive several Handoff Registration Request messages which have same sequence number, LMA MUST process these request as a whole and send only one Handoff Registration Acknowledgement to Takeover-MAG. If Handoff Registration request is valid according to the tests above, then the Handoff Registration Request is processed further as follows: 1. The Sequence Number value should be stored in the local database of LMA in order to identify LMA switch event. 2. LMA MUST apply the following considerations when processes Synchronization Flag (S) bit: If the Flag S is 0 which means the Takeover-MAG does not get any Failure-Affected-MNs?information, LMA updates Failure-Affected- MNs' PBCE whose proxy CoA field equals to Previous-Entity Address field in Handoff Registration request. If the Flag S is 1 which means the Takeover-MAG gets Failure- Affected-MNs?information by Context Synchronization, LMA updates Failure-Affected-MNs' PBCE by mobility options presented in the Handoff Registration Request (include HNP Option, MN-LL- ID Option, MN-ID Option). 3. If handoff field is set, LMA processes this field as 7.6.2. 4. If status field is set , LMA processes this field as 7.6.2. 7.6.2 Sending Handoff Registration Acknowledgement After processed Handoff Registration Request, LMA sends Handoff Registration Acknowledgement to Takeover-MAG, which is constructed as follows: 1. The Sequence Number value MUST be set to the corresponding value in Handoff Registration Request message in order to identify the mobility switch event. 2. Synchronization Flag (S) bit MUST be set to the corresponding value in Handoff Registration Request message. 3. MAG MUST set the 'Type' field to 4, indicating that this message is a Handoff Registration Acknowledgement. Shi, et al. Expires - Expiration February 2010 [Page 38] Internet Draft PMIPv6 Reliability Protocol September 2009 4. The handoff field MUST be set to the corresponding value in Handoff Registration Request message. 5. Previous-Entity Address MUST be set to the corresponding value in Handoff Registration Request message. 6. If flag S is 0 in Handoff Registration Request, LMA MUST include options of Failure-Affected-MNs (include HNP Option, MN- LL-ID Option, MN-ID Option) to this message. Such Failure- Affected-MNs are all MNs which have been attached to the MAG whose address is in the Previous-Entity address field in Handoff Registration Request. If there are lots of Failure-Affected-MNs whose information can not be carried in one acknowledgement, LMA SHOULD send multiple acknowledgements to Takeover-MAG. 7. LMA should apply the below considerations when set Status field: If The Previous-Entity address does not set to NULL_ZERO in Handoff Registration Request message, status code should be set to TBD. If the flag S of Handoff Registration Request is 1 and there is not or not enough related options (include HNP Option, MN-LL-ID Option, MN-ID Option) of Failure-Affected-MNs, status code should be set to TBD. If the LMA create the PBCE for Failure-Affected-MNs successfully, Status field MUST set to (TBD). 7.7 LMA Switching Message 7.7.1 Sending LMA Switching Request When LMA detects its Supported-LMA failed as described in [HEARTBEAT-PMIPv6] or overloaded as described in Section 7.4.4, it MUST send a LMA Switching Request to all the MAGs in the PMIPv6 domain, which is constructed as follows: 1. The destination field should set to MAG address in the same PMIPv6 domain. 2. LMA MUST maintain a valid sequence number. Each time the LMA send a LMA Switch Request message, it MUST set the Sequence Number field to the sequence number and increase the sequence number to one more. Shi, et al. Expires - Expiration February 2010 [Page 39] Internet Draft PMIPv6 Reliability Protocol September 2009 3. LMA MUST set the 'Type' field of Service Switching Message (Section 4.1) to 2, indicating that this message is a LMA Switching Request message. 4. The LMA MUST apply the below considerations when choosing the value for the Handoff field. The handoff field MUST be set to 2 if the LMA, which has mobility session maintained by the Supported-LMA, detects its Supported-LMA failed. The handoff field MUST be set to 3 if the LMA detects its Supported-LMA overloaded. 5. The Status field MUST be set to 0 in this message. 6. Synchronization Flag (S) bit MUST be set to 0 in this message. 7. The Previous-Entity Address field MUST be set as the address of the Supported-LMA of the sender. 8. If the Handoff field is set to 3, the LMA MUST include Handoff Condition Option (Section 4.5) in the message. If the Handoff field is set to 2, the LMA SHOULD NOT include Handoff Condition Option in the message. 7.7.2 Receiving LMA Switching Acknowledgement Before accepting a LMA Switching Acknowledgement, MAG MUST validate such message according to the following tests: 1. If the Sequence Number value in LMA Switching Acknowledgement does not equals any number stored in LMA, LMA just ignore this message. 2. If there is no MN related options, including HNP Option, MN- LL-ID Option, MN-ID Option, in LMA Switching Acknowledgement, the LMA MUST reject the request and restart LMA Service Switching Mechanism. 3. If LMA Switching Acknowledgement is valid according to the tests above, then the LMA Switching Acknowledgement is processed further as follows: The LMA MUST create MN mobility session for MNs by MN related options in LMA Switching Acknowledgement. Then 4. LMA begin to provide mobility service for the Failure- Affected-MNs as described in [RFC5213]. 5. All other fields are processed as 7.7.3. Shi, et al. Expires - Expiration February 2010 [Page 40] Internet Draft PMIPv6 Reliability Protocol September 2009 7.7.3 Sending LMA Switch Finish Announcement After successfully processed the LMA Switch Acknowledgement message, LMA MUST send LMA Switch Finish Announcement to all the MAGs that that successfully transfer MNs information to itself, which is constructed as follows: 1. The MAG MUST set the Sequence Number field to the same number as in the LMA Switch Request message. 2. The LMA MUST set the 'Type' field of Service Switching Message (Section 4.1) to 7, indicating that this message is a LMA Switching Finish Announcement message. 3. If LMA has began to provide mobility service for the Failure- Affected-MNs, the Status field MUST be set to TBD 4. Other field should be set to the corresponding value in the LMA Switching Acknowledgement message. Receiving LMA Switching Finish Announcement Before accepting a LMA Switching Finish Announcement, LMA MUST validate such message according to the following tests: If the Sequence Number value in LMA Switching Finish Announcement does not equals any number stored in LMA, LMA just ignore this message. If LMA Switching Finish Announcement is valid according to the tests above, then the LMA processes Switching Finish Announcement further as follows: 1.LMA MUST stop providing mobility service for the Failure- Affected-MNs by Handoff Condition Option. 2.Other field SHOULD be ignored by the LMA. 8. Security Considerations The Service Switching Message and LMA Control Message introduced in this document should be protected using IPSec using the established security association between MPM, MAGs and LMAs. 9. Protocol Configuration Variables HEARTBEAT_INTERVAL Shi, et al. Expires - Expiration February 2010 [Page 41] Internet Draft PMIPv6 Reliability Protocol September 2009 The same as defined in Section 5 of [HEARTBEAT-PMIPV6], but we suggest that the HEARTBEAT_INTERVAL should not be configured to a big value. MISSING_HEARTBEATS_ALLOWED The same as defined in Section 5 of [HEARTBEAT-PMIPV6]. MAX_LOAD_ALLOWED This variable indicates the maximum value of entity load. Once the 'Overhead' field in Load Information Option exceeds the value, the sender is considered overloaded. The load information may be the number of MN, so this variable must be configured according to the real network. 10. IANA Considerations The Service Switching Message (Section 4.1) and LMA Control Message (Section 4.2) must have the type value allocated from the same space as the 'MH Type' name space in the Mobility Header defined in [RFC3775]. The Load Information Option (Section 4.3), LMA Address Option (Section 4.4) and Handoff Condition Option (Section 4.5) must have the type value allocated from the same name space as the Mobility Options defined in [RFC3775]. 11. Acknowledgements The authors would like to specially thank Chao Ma, Dizhi Zhou and Li Shen for their discussions and edits of this document. 12. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC3775] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6 , RFC3775, June 2004. [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, Proxy Mobile IPv6 , RFC5213, August 2008. Shi, et al. Expires - Expiration February 2010 [Page 42] Internet Draft PMIPv6 Reliability Protocol September 2009 [RFC4830] J. Kempf, roblem Statement for Network-Based Localized Mobility Management (NETLMM) , April 2007. [RFC4831] J. Kempf, Goals for Network-Based Localized Mobility Management (NETLMM) ,April 2007. [HEARTBEAT-PMIPV6] V. Devarapalli, R. Koodli, H. Lim, N. Kant, S. Krishnan, J. Laganier, Heartbeat Mechanism for Proxy Mobile IPv6 , draft-ietf-netlmm-pmipv6- heartbeat-07, April 2009. Authors' Addresses Xiaoyan Shi Huawei Technologies Co.,Ltd C103, Gangwan Building, Zpark, Beijing, China Email: Shi_xyan@huawei.com Shiyong Tan Huawei Technologies Co.,Ltd C103, Gangwan Building, Zpark, Beijing, China Email:tanshiyong@huawei.com Hanwen Zhang Institute of Computing Technology Chinese Academy of Sciences Kexueyuan south road N.6, Haidian District Beijing, China Email:hwzhang@ict.ac.cn Yujun Zhang Institute of Computing Technology Chinese Academy of Sciences Kexueyuan south road N.6, Haidian District Beijing, China Email:zhmj@ict.ac.cn Shi, et al. Expires - Expiration February 2010 [Page 43]