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
<IANA>
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
<IANA>
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
<IANA>
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
<IANA>
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
<IANA>
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]