NETLMM WG An-fu Zhou Internet Draft Min Liu Expires: April 2009 Institute of Computing Technology, Chinese Academy of Sciences Hui Deng Gang Chen Dapeng Liu China Mobile October 9, 2008 Load Sharing in Proxy Mobile IPv6 draft-zhou-netlmm-pmipv6-load-sharing-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 9, 2009. Abstract Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within Zhou et al. Expires April 9, 2009 [Page 1] Internet-Draft Load Sharing in PMIPv6 September 2008 the Proxy Mobile IPv6 domain. This document proposes to use multiple LMAs for the consideration of traffic overload, and describes a load sharing mechanism between multiple LMAs. Table of Contents 1. Introduction.................................................2 2. Conventions & Terminology....................................3 2.1. Conventions used in this document.......................3 2.2. Terminology.............................................3 3. Load Sharing Mechanism.......................................5 3.1. set up multiple tunnels................................5 3.2. up forwarding load sharing..............................5 3.3. down forwarding load sharing............................6 4. Security Considerations......................................9 5. IANA Considerations..........................................9 6. Acknowledgments.............................................10 7. References.................................................11 7.1. Normative References..................................11 7.2. Informative References................................11 Author's Addresses.............................................12 Intellectual Property Statement................................12 Copyright Statement............................................13 Zhou et al. Expires April 9, 2009 [Page 2] Internet-Draft Load Sharing in PMIPv6 September 2008 1. Introduction Recently, the ETF NETLMM workgroup proposes the Proxy Mobile IPv6 (PMIPv6) [2] protocol which provides the mobility support for mobile nodes without involvement of mobility signaling. In order to facilitate the network-based mobility, the PMIPv6 protocol defines a Mobility Anchor Gateway (MAG), which acts as a proxy for the Mobile IPv6 [2] signaling, and the Local Mobility Anchor (LMA) which acts similar to a Home Agent, anchoring a Mobile Node's sessions within a Proxy Mobile IPv6 (PMIPv6) domain. The LMA and the MAG establish a bidirectional tunnel for forwarding all data traffic belonging to the Mobile Nodes. In PMIPv6, the LMA is in charge of all the traffic belonging to its PMIPv6 domain. It is clear that the LMA will have high load, and could collapse due to overhead. As wathing movie and video chatting become a popular trend nowdays, it is obviously important to consider the overload problem of the LMA. In this memo, we propose a load sharing mechanism, which introduces multiple LMAs in a PMIPv6 domain, and defines the Route Management Server (RMS) to keep the consistency of route between different LMAs. Through the interaction among LMA, MAG and RMS, our mechansim could achive the dynamic, bi-direction load sharing. 2. Conventions & Terminilogy 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 [1]. 2.2. Terminology All the general mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [5]. This document adopts the terms, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) from the NETLMM Goals document [6]. This document mainly uses the following terms in this document. Proxy Mobile IPv6 Domain (PMIPv6-Domain) Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be setup and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured. Local Mobility Anchor (LMA) Local Mobility Anchor is the home agent for the mobile node in the Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home network prefix and is the entity that manages the mobile node's binding state. The local mobility anchor has the functional capabilities of a home agent as defined in Mobile IPv6 base specification [5] with the additional capabilities required for supporting Proxy Mobile IPv6 protocol as defined in this specification. Zhou, et al. Expires April 9, 2009 [Page 3] Internet-Draft Load Sharing in PMIPv6 September 2008 Mobile Access Gateway (MAG) Mobile Access Gateway is a function that manages the mobility related signaling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signaling the mobile node's local mobility anchor. Mobile Node (MN) Throughout this document, the term mobile node is used to refer to an IP host or router whose mobility is managed by the network. The mobile node may be operating in IPv6 mode, IPv4 mode or inIPv4/IPv6 dual mode. The mobile node is not required to participate in any IP mobility related signaling for achieving mobility for an IP address that is obtained in that Proxy Mobile IPv6 domain. Route Management Server (RMS) RMS is a new element that we introduced in Proxy Mobile IPv6 domain. All LMAs report its load state to RMS periodically, RMS check load state of all LMAs, and pick the lightest-load LMA to take on part traffic of overloaded LMA. In this way, RMS could help to achieve the upforading load sharing. on other hand, when MN performs an handoff, the new MAG send Route_ajust to RMS, the RMS forwards Route_ajust to all LMAs, LMA adjust their routes accordingly. 3. Load Sharing Mechanism We introduce new network entity RMS in a PMIPv6 domain. It is requested that RMS MUST has connexity with MAG and LMA. The load Sharing Mechanism include three key procedures, which are described in section 3.1, 3.2, and 3.3 respectively. 3.1 set up multiple tunnels To achieve load sharing in proxy mobile ipv6,multiple tunnels between LMAs and MAGs need to be estiblished, which can be seen in Figure 1. Concrete steps are as follows: a).When a MAG start, read its profile for LMAs' information (which is entered by the PMIPv6 administrator).Then the MAG sents the tunnel-establishment request Tnl_request to LMAs. b).After receiving a Tnl_request from a MAG, a LMA will establish a tunnel and return the tunnel-establishment acknowledge Tnl_ack. c).Receiving a response Tnl_ack from a LMA,the MAG establishs a ipv6-in-ipv6 tunnel between them. Zhou et al. Expires April 9, 2009 [Page 4] Internet-Draft Load Sharing in PMIPv6 September 2008 Comparing with the standard PMIPv6 protocol, the additional advantage of the establishment of such tunnels in advance is that it is able to benefit MN's handoff among MAGs: When a MN from one MAG to handoff to another MAG, the LMA just need to change the route without having to re-establish tunnel.Thes method save the processing time in MN's handoff,and so lower the packet-loss rate and delay. +--------+ +--------+ +--------+ | MAG1 | | LMA1 | | LMA2 | +--------+ +--------+ +--------+ | | | | Tnl_request1 | | |---------------------->| | | | | | +-----------------+ | | | establish tunnel| | | | MAG1<-->LMA1 | | | +-----------------+ | | Tnl_request2 | | |-----------------------|-------------------->| | | | | | +-----------------+ | Tnl_ack1 | | establish tunnel| |<----------------------| | MAG1<-->LMA2 | | | +-----------------+ +-----------------+ | | | establish tunnel| | | | MAG1<-->LMA1 | | | +-----------------+ | | | | Tnl_ack2 | |<----------------------|---------------------| | | | +-----------------+ | | | establish tunnel| | | | MAG1<-->LMA2 | | | +-----------------+ | | | | | Figure 1.setting up multiple tunnels In the process of setting up multiple tunnels,MAGs and LMAs need to interact with each other with two kinds of message:Tnl_request and Tnl_ack.The format of Tnl_request and Tnl_ack is as follows: Tnl_request's format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MAG address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16. Zhou et al. Expires April 9, 2009 [Page 5] Internet-Draft Load Sharing in PMIPv6 September 2008 MAG address A sixteen-byte field containing the MAG's address. Tnl_ack's format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MAG address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16. MAG address A sixteen-byte field containing the LMA's address. 3.2. up forwarding load sharing The steps of dynamic load sharing on the up forwarding data can be seen in Figure 2.We explain them as follows: a).Each LMA calculate each MAG's packets forwarding number,the total number of up forwarding packets and the CPU utilization rate at another cetain time(we sugest that for 5 minites).And then the LMA sends these results information in Load_info signal to the routing management server RMS. b).Routing management server RMS will write the load information of each LMA into the load list maintained by itself. The load list is showed in Figure 3. c).Routing management server RMS traversal of the load list for a certain period.and then deal with the load sharing with the following rules:A LMA (assumed to be LMA1)' is overload means that its CPU utilization rate are equal or greater than 80%,and forwarding packets number is greater than 60,000;A LMA (assumed to be LMA2) is light load means that its CPU utilization rate are less than 80%.Then,routing management entities RMS send load adjustment signal Load_adjust to MAG1 who has the most data forwarding to the LMA. Zhou et al. Expires April 9, 2009 [Page 6] Internet-Draft Load Sharing in PMIPv6 September 2008 d).Received the load adjustment signal, MAG1 will change its routing based on the signal's content, making the data transmitted to LMA2 which at first is transmitted to LMA1.Then the LMA1's load is reduced. It can be seen that in the above process, each LMA examine its load information and send it to RMS. RMS will adjust the MAG's data forwarding path in real-time based on the LMAs load information.These mechanism achieve dynamic load sharing. +--------+ +--------+ +--------+ +--------+ | LMA1 | | LMA2 | | RMS | | MAG1 | +--------+ +--------+ +--------+ +--------+ | | | | | Load_info1 | | | |----------------|--------------->| | | | | | | | Load_info2 | | | |--------------->| | | | | | | | | Load_adjust | | | |--------------->| | | | | | | | | Figure 2. dynamic load sharing on the up forwarding data +------------------+ +--------+--------+ | LMA1 |----------->| MAG1 | Packets| +------------------+ +--------+--------+ | CPU Rate | | MAG2 | Packets| +------------------+ +--------+--------+ | Total Packets | +------------------+ | | | +------------------+ | LMA1 |-----------> ...... +------------------+ | CPU Rate | +------------------+ | Total Packets | +------------------+ Figure 3. load list In the process of up forwarding load sharing LMAs and the RMS need to interact with each other with two kinds of message:Load_info and Load_adjust.The format of Load_info and Load_adjust is as follows: Zhou et al. Expires April 9, 2009 [Page 7] Internet-Draft Load Sharing in PMIPv6 September 2008 Load_info's format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CPU utilization rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total packets number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MAG1 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packets number form MAG1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MAG2 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packets number form MAG2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MAGn address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packets number form MAGn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 20n+8. CPU utilization 32-bit float number indicating the LMA's CPU utilization rate. Total packets number 32-bit unsigned integer indicating the total packets number from MAGs in the recent 5 minites. MAGi address A sixteen-byte field containing the LMA's address. packets number form MAGi 32-bit unsigned integer indicating the packets number from MAGi in the recent 5 minites. Zhou et al. Expires April 9, 2009 [Page 8] Internet-Draft Load Sharing in PMIPv6 September 2008 Load_adjust's format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + old LMA address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + new LMA address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 32. old LMA address A sixteen-byte field containing the old LMA's address. new LMA address A sixteen-byte field containing the new LMA's address. 3.3. down forwarding load sharing The steps of dynamic load sharing on the down forwarding data can be seen in Figure 3.We explain them as follows: a) When MN performs an handoff (assumed from MAG1 to MAG2), after the normal PBU / PBA exchange, MAG2 send Route_ajust to route management server. b) Received the Route_ajust signal,Routing update entities forward Route_ajust to all LMA, LMA adjust their routes accordingly,so that the data to the MN can forward to MAG2 through the tunnel, so as to make it forward correctly. It can be seen that several LMAs,compared to the single LMA,achieve consistency in the routing of the MN through the RMS.All LMAs can forward downlink data received by MN to the MAG MN attach to correctly and achieve downlink data load balancing. +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ | MN | | MAG1 | | MAG2 | | RMS | | LMA1 | | LMA2 | +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ |Detach from MAG1| | | | | |--------------->| | | | | |Attach to MAG2 | | | | | |----------------|--------------->| | | | | | | PBU/PBA | | | | | |<----------------|-------------->| | | | | Route_adjust | | | | | |---------------->| Route_adjust | | | | | |-------------->| Route_adjust | | | | |---------------|--------------->| figure 3. dynamic load sharing on the down forwarding data Zhou et al. Expires April 9, 2009 [Page 9] Internet-Draft Load Sharing in PMIPv6 September 2008 The format of is Route_ajust as follows: 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MN prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + old MAG address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + new MAG address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 32. MN prefix A sixteen-byte field containing the MN prefix old MAG address A sixteen-byte field containing the old MAG address new MAG address A sixteen-byte field containing the new MAG address 4. Security Considerations The messages use in this memo are just used for checking reachability between the MAG and the LMA, and for achieving load sharing between multiple LMAs. They do not carry information that is useful for eavesdroppers on the path. Therefore, confidentiality protection is not required. Integrity protection using IPsec [3] for the messages MUST be supported on the MAG,LMA and RMS. If dynamic key negotiation between the MAG and RMS, between RMS the LMA is required, IKEv2 [4] should be used. 5. IANA Considerations There are no IANA considerations introduced by this memo currently. Zhou et al. Expires April 9, 2009 [Page 10] Internet-Draft Load Sharing in PMIPv6 September 2008 6. Acknowledgments The authors would like to thank Xue-wu Jiao, Jun Cao (Institue of Computing Technology, Chinese Academy of Sciences) for their valuable comments and suggestions on this memo. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 7.2. Informative References [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] J. Kempf et al., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. Zhou et al. Expires April 9, 2009 [Page 11] Internet-Draft Load Sharing in PMIPv6 September 2008 Authors' Addresses An-fu Zhou Institute of Computing Technology Chinese Academy of Sciences Kexueyuan south road N.6, Haidian District Beijing, China Email: zhouanfu@ict.ac.cn Min Liu Institute of Computing Technology Chinese Academy of Sciences Kexueyuan south road N.6, Haidian District Beijing, China Email: liumin@ict.ac.cn Gang Chen China Mobile Research Institute Unit 2,28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053,China Email: chengang@chinamobile.com Dapeng Liu China Mobile Research Institute Unit 2,28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053,China Email: liudapeng@chinamobile.com Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Zhou et al. Expires April 9, 2009 [Page 12]