Mipshop Working Group X. Cui Internet-Draft huawei Intended status: Experimental September 1 2009 Expires: February 28 2010 Mobility Anchor Point (MAP) Reliability Extension draft-cui-mipshop-map-reliability-01.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 28 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. Abstract This document introduces an extension to allow an adapted multiple binding in hierarchical mobile network. Mobile node registers its RCoA and LCoA in the home agent at same time to get two separate Cui Expires February 28, 2010 [Page 1] Internet-Draft MAP Reliability Extension June 2009 connections between the mobile node and the home agent, or between the mobile node and the correspondent node in Route Optimization scenario. These connections provide robust communication between the mobile node and correspondent nodes and mobile node can overcome the failure on MAP. Requirements Language 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 [RFC-2119]. Cui Expires February 28, 2010 [Page 2] Internet-Draft MAP Reliability Extension June 2009 Table of Contents Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem statement and analysis . . . . . . . . . . . . . . . . 5 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Proposed solution overview . . . . . . . . . . . . . . . . 5 4.2. Adapted multiple binding registration flow . . . . . . . . 5 4.3. MAP failure solution in HA manner . . . . . . . . . . . . 7 4.4. MAP failure solution in Route Optimization . . . . . . . . 8 4.5. Mobile Node operation . . . . . . . . . . . . . . . . . . 8 4.6. Home Agent operation . . . . . . . . . . . . . . . . . . . 9 4.7. Correspondent Node operation . . . . . . . . . . . . . . . 9 4.8. MAP operation . . . . . . . . . . . . . . . . . . . . . . 9 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Cui Expires February 28, 2010 [Page 3] Internet-Draft MAP Reliability Extension June 2009 1. Introduction IETF community defined MIP6 protocol to provide Mobility Support in IPv6 and later HMIP was defined to support Hierarchical Mobile IPv6 Mobility Management. In MIP6 protocol [RFC-3775], Mobile Node (MN) may move within the network. When the MN moves it sends binding update (BU) message to its home agent (HA) or correspondent node (CN) to maintain reachability and ongoing connections between MN and CNs. MIP6 provides the global mobility solution. In HMIP protocol [RFC-5380], MN sends binding update message to its Mobility Anchor Point (MAP) when the MN moves and MAP sends binding updates to MN's HA on behalf of the mobile node. HMIP provides the localized and hierarchical mobility solution. HMIP mechanism allows MN to hide the location and can reduce packet loss when MN is moving by reducing the binding update delay. The advantages of HMIP solution can help improving the security and performance in mobile network. [RFC-5380] also permits that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes. The purpose of this operation is for route optimization. If these nodes are connected to the same link, packets will then be routed directly, without going through the MAP. In fact the multiple binding mechanism may provide an additional path if the mobile node sends a BU containing its LCoA as the CoA to the home agent. The operation MAY be used for MAP reliability. If the MAP gets out of service, packets destined to the MN will be routed by HA directly to MN without involving the failed MAP. This document specifies the adapted multiple binding mechanism to support co-operation on both MIP and HMIP, as a MAP reliability solution. 2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC-3775] and Hierarchical Mobile IPv6 (HMIPv6) Mobility Management specification [RFC-5380]. Cui Expires February 28, 2010 [Page 4] Internet-Draft MAP Reliability Extension June 2009 3. Problem statement and analysis We may notice that in HMIP network MAP is a mandatory hop in the connections between MN and HA or between MN and CNs. If MAP gets out of service the MN would lose connections with HA and CNs, so the reliability of MAP must be considered seriously. Some solutions on Home Agent Reliability have been mentioned in [I-D.ietf-mip6-hareliability]. But we must notice the difference between HA and MAP. HA is a high-level router, acting as the core node for the global mobility, while MAP is in low level, acting as an anchor just for a local scope. The number of MAP may be very large so we have to think over the cost of MAP equipment. The protocol stack and software in MAP should be simple. The operation and maintenance should be easy to handle. In these views the solutions for HA are not really fit for MAP. Reliability solution for MAP should be economical and simple. 4. Proposed Solutions 4.1 Proposed solution overview In order to provide a solution for MAP reliability, an adapted multiple binding mechanism is introduced in the document. Since the global mobility (MIP6) and localized mobility (PMIP6) can work together, there is also some way for MIP and HMIP to co-operate. This document specifies how to implement a simple MAP reliability solution by multiple binding mechanism. This document only specifies MAP reliability. HA reliability is out of scope. 4.2 Adapted multiple binding registration flow In the proposed solution a new registration step is added in the procedure described in [RFC-5380], and in the new step MN sends one more Binding Update to HA. Additionally, some original steps are modified to achieve the solution. The proposed registration is illustrated in Figure 1. Cui Expires February 28, 2010 [Page 5] Internet-Draft MAP Reliability Extension June 2009 MN MAP HA | Binding Update | | (a) |<------------------->| | | Binding Update (RCoA, high priority) | (b) |<----------------------------------------->| | | | | | | | Binding Upadate (LCoA, low priority) | (c) |------------------------------------------>| | | | | Binding Ack (LCoA, low priority) | (d) |<----------------------------------------- | | | | Figure 1. Adapted multiple binding registration flow for MAP reliability The detailed descriptions are as follows: (a) MN sends binding update message (binding RCoA and LCoA) to MAP as described in section 6.1 of [RFC-5380]. MAP sends binding acknowledgement message to MN, indicating the successful registration. (b) MN sends binding update message (binding HoA and RCoA) to HA as described in section 6.1 of [RFC-5380]. MN includes a BID-PRI parameter in the BU message as described in section 5.2.1 of [I-D.ietf-mext-flow-binding] and sets the value of BID-PRI parameter to high priority. HA responds binding acknowledgement message indicating the successful registration. (c) MN sends one more binding update message (binding HoA and LCoA) to HA with a low binding priority indication in the BU message, as described in section 5.2.1 of [I-D.ietf-mext-flow-binding]. The mobile node's home address is used in the Home Address option and the LCoA is used as the care-of address in the source address field. The binding lifetime in the BU message SHOULD be equal to or less than the mobile node's binding lifetime with the MAP, which is received in the binding acknowledgement in step (a). (d) HA sends binding acknowledgement message to MN indicating the successful registration, which means HA has recorded the binding on pair. A bi-directional tunnel between the mobile node and the home agent is established. It should be noted that when MN detects the failure of the MAP, MN MAY send a binding update message to HA and set the lifetime equal to zero in the BU message. Cui Expires February 28, 2010 [Page 6] Internet-Draft MAP Reliability Extension June 2009 When MN detects MAP's recovery after a failure, MN should redo the registration operation as if the mobile node is entering a new MAP domain. After the adapted multiple binding registration, HA gets a whole Binding Cache Entry for the mobile node. One example is illustrated in Figure 2. BIDs BID-PRI HoA CoA Lifetime A/I ---- ------- ----- ---------- -------- ------- 1 10 HoA RCoA x seconds Active 2 20 HoA LCoA x seconds Active N/A N/A NULL NULL NULL Inactive Figure 2. Example of Biding Cache Entry with adapted multiple binding 4.3 MAP failure solution in HA manner In [RFC-5380] all the packets destined to MN are forwarded by MAP. This document provides a supplementary solution to overcome the failure on MAP. The proposed reliability solution in HA manner is illustrated in Figure 3. CN HA MAP AR MN | | | | | (a) |------->| | | | (b) | |------->| | | (c) | | |------->| | (d) | | | |------->| | | | | | | |failure | | | | |detected| | | (e) | |<------>| | | | | | | | (f) |------->| | | | (g) | |---------------->| | (h) | | | |------->| | | | | | Figure 3. Proposed reliability solution in HA manner The detailed descriptions are as follows: (a) CN sends packet to MN. The destination address of the packet is set to HoA and the packet is routed to HA. Cui Expires February 28, 2010 [Page 7] Internet-Draft MAP Reliability Extension June 2009 (b) HA searches the BCE and finds the active binding to RCoA, which is BID 1 in Figure 2. So HA forwards the packet to MAP. (c) MAP also searches the BCE and finds the binding to LCoA. So MAP forwards the packet with the destination set to LCoA. The packet is routed to AR which is the MN's default router. (d) AR routes the packet to MN without any modification. (e) MAP gets out of service for some reason and HA detects the failure of MAP. The method to detect the failure is out of the scope of this document. HA updates the binding cache and BID 1 in BCE of HA is set to Inactive status. BID 2 (HoA, LCoA) becomes the only active item in binding cache. (f) Another packet destined to MN is sent by CN to HA. (g) HA searches the BCE and finds the only active binding to LCoA. So HA sets the destination address of the packet to LCoA and forwards the packet to MN directly. The packet is routed to AR which is the MN's default router. (h) AR routes the packet to MN without any modification. It should be noted that when MN detects the failure of the MAP, MN would set the source address of the packets, which are destined to CN, to LCoA and sends the packets to HA. HA forwards the packets from MN to CN. 4.4 MAP failure solution in Route Optimization In Route Optimization manner, packets between MN and CNs are not routed through HA. The multiple binding in HA is unavailable for route optimization. The binding cache in CN replaces the role of the one in HA. So MN in route optimization may make adapted multiple binding in CNs to implement the MAP reliability instead in HA. MN sends BU message containing its LCoA and low priority indication to correspondent nodes to bind its HoA and its LCoA. Other operation and procedure are similar to the solution in HA manner. 4.5 Mobile Node operation In order to implement the MAP reliability solution MN should send one more binding message with low priority indication to bind its home address and its LCoA. The binding update message is sent to either HA in HA manner or CN in RO manner. Cui Expires February 28, 2010 [Page 8] Internet-Draft MAP Reliability Extension June 2009 The detailed method to implement adapted multiple binding is described in [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding]. 4.6 Home Agent operation Home Agent normally maintains the binding cache with only one item in the list. The home address is usually associated to RCoA in HMIP. This document extends the binding cache in HA to multiple bindings, which permit the home address to be associated to multiple CoAs in sequence. The detailed method to extend the binding cache is described in [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding]. 4.7 Correspondent Node operation The mechanism defined in this document is completely transparent to correspondent nodes in HA manner. In Route Optimization manner the CN maintains the binding cache with multiple binding as HA does in HA manner. 4.8 MAP operation The mechanism defined in this document is completely irrelative to MAP's operation. 5. Conclusion This document specifies a reliability solution for MAP. In the solution an additional binding, which associates HoA and LCoA, is registered in home agent. By this means, the mobile node exposes its location to home agent and gets a redundant connection between mobile node and home agent. Since the location information is not crucial while the reliability is considerable, this solution may be implemented in the mobile network. 6. Security Considerations This document specifies a solution for MAP reliability by an adapted multiple binding mechanism. The solution incorporates the operations specified in [RFC-5380] (registration in MAP), [I-D.ietf-monami6-multiplecoa] (multiple binding operation) and [I-D.ietf-mext-flow-binding] (BID priority registration). This document uses the same security as described in [RFC-5380], [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding]. Cui Expires February 28, 2010 [Page 9] Internet-Draft MAP Reliability Extension June 2009 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgements TBD. 9. References 9.1 Normative References [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-14 (work in progress), May 2009. [I-D.ietf-mext-flow-binding] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., Kuladinithi, K., Flow Bindings in Mobile IPv6 and Nemo Basic Support, draft-ietf-mext-flow-binding-03.txt (work in progress), July 2009 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. 9.2 Informative References [I-D.ietf-mip6-hareliability] Wakikawa, R., "Home Agent Reliability Protocol", draft-ietf-mip6-hareliability-05.txt, July 2009 Author's Address Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Cui Expires February 28, 2010 [Page 10]