Internet Area M.Hui
Internet Draft H.Deng
Intended status: Informational China Mobile
Expires: April 19, 2010 October 19, 2009
PMIPv6 Multihoming Extension and Synchronization in LMA and MAG
draft-hui-netext-multihoming-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 April 19, 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.
Hui&Deng Expire April, 2010 [Page 1]
Internet-Draft PMIP multihoming extension October 2009
Abstract
Proxy Mobile IPv6 is standardized to provide network-based mobility
management for a regular IPv6 mobile node. This document introduces
an extension to Proxy Mobile IPv6 for multihoming MN. Through
extending the binding relationship between HNP and MAG in BCE, and
synchronizing this information between LMA and MAGs, LMA can deliver
data having the same HNP through multiple MAGs. Thus the MN attaching
in a PMIPv6 domain can receive data packets with the same destination
through its multiple network interfaces attaching to different MAGs
simultaneously.
Hui&Deng Expire April, 2010 [Page 2]
Internet-Draft PMIP multihoming extension October 2009
Table of Contents
1. Problem Statement ........................................... 4
2. Scenario of the multihoming extension ........................6
3. Protocol Operation .......................................... 7
4. PMIPv6 Multihoming Extension................................. 9
4.1. Binding Cache and Binding Update list Extension..........9
4.2. Data Forwarding Operation.............................. 10
5. Security Considerations..................................... 12
6. IANA Considerations ........................................ 12
7. References ................................................. 12
7.1. Normative References................................... 12
7.2. Informative References................................. 12
Author's Addresses ............................................ 13
Hui&Deng Expire April, 2010 [Page 3]
Internet-Draft PMIP multihoming extension October 2009
1. Problem Statement
Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
MN without requiring its participation in any mobility-related
signaling [1]. If the MN has multiple interfaces, it is hoped that
these interface can work coordinately, so that a proper interface can
be chosen to deliver the data.
In PMIP domain, the LMA is responsible for assigning the MN's home
network prefix(es) and managing the MN's binding state. LMA will
assign different HNPs to multiple interfaces of the MN, and it will
be several Binding Cache Entries for the MN based on the HNPs in LMA.
The problem is if LMA receives data with HNP1 as the destination,
according to the BCE of HNP1, it will send the data to IF1 through
MAG1, although IF2 of MN can also deliver the data, see figure 1. In
that case, the multihoming MN cannot benefit from its multiple
interfaces.
+-----+
| CN |
+-----+
| LMA Binding Cache
| =====================
| MN: HNP1 ---> MAG1
+-----+ : HNP2 ---> MAG2
| LMA |
+-----+
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| IF1 IF2 |
+------[MN]------+
Figure 1 Multihoming Scenario
Hui&Deng Expire April, 2010 [Page 4]
Internet-Draft PMIP multihoming extension October 2009
To solve this problem, it is proposed to extend BCE to bind the HNP
to several proxy-CoA related to the same MN, and synchronize this
information between LMA and MAGs, then the data can be transferred
through all of the interfaces. Several benefits can be achieved by
doing that multihoming extension:
1) Enable the flow mobility. That means the flow aiming a certain IF
can be transferred to other IFs because of the user preference,
operator policy, network load, etc.
2) Enable the load sharing. The traffic to a certain IF of MN can be
separated among different Ifs, and less loaded IFs can be selected.
And when the bandwidth of an IF is limited, other IFs can be used
to help deliver the data together.
Hui&Deng Expire April, 2010 [Page 5]
Internet-Draft PMIP multihoming extension October 2009
2. Scenario of the multihoming extension
As shown in Figure 2, the multihoming MN has two network interfaces
IF1 and IF2, attaching to the MAG1 (IF1) and MAG2 (IF2) respectively.
+-----+
| CN |
+-----+
| LMA Binding Cache
| =====================
| MN: HNP1 ---> {MAG1, MAG2}
+-----+ : HNP2 ---> MAG2
| LMA |
+-----+
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| IF1 IF2 |
+------[MN]------+
Figure 2 Scenario of the multihoming extension
Assuming the IF1 of the MN which attaches to MAG1 turns on first, the
LMA assigns the HNP1 to the IF1. The MN initiates a video telephony
call with the CN, sending and receiving traffic addressed to HNP1 via
IF1. Then the performance of IF1 degrades significantly, and the IF2
becomes available which attaches to MAG2.
The bandwidth of any of IF1 or IF2 is not enough to maintain the
video telephony traffic, so a possible solution is to enable the MN
to send and receive the traffic addressed to HNP1 via IF1 and IF2
simultaneously. Such a solution would make best use of the multiple
interfaces of the MN and improve the user's experience.
Hui&Deng Expire April, 2010 [Page 6]
Internet-Draft PMIP multihoming extension October 2009
3. Protocol Operation
This section introduces the multiple interface attach procedures for
multi-homing MN with two interfaces (IF1 and IF2) in a PMIPv6 domain
with extended BCE .
+-----+ +-----+ +-----+ +-----+
| MN | | MAG1| | LMA | | MAG2|
+-----+ +-----+ +-----+ +-----+
IF1 IF2 | | |
| | | | |
| | | | |
1) |----- Rtr Sol------->| | |
| (IF1 attachment) |------- PBU ----->| |
| | | | |
| | | | |
2) | | | Accept PBU |
| | | (Allocate HNP1, Setup BCE and Tunnel1)
| | | | |
| | | | |
| | |<------ PBA ------| |
3) |<------ Rtr Adv -----| (MN-HNP1) | |
| | | | |
| | | | |
|<========data========|<=====data========| |
| | | | |
| | | | |
4) | |------------- Rtr Sol ( IF2 attachment) --------------->|
| | | |<----- PBU -------|
| | | | |
| | | | |
5) | | | Accept PBU |
| | (Allocate HNP2, Create and Update BCE and Setup Tunnel2)
| | | | |
| | | | |
6) | | | |------- PBA ----->|
| | | | (HNP1 & HNP2) |
| |<-------------------- Rtr Adv ------------------------- |
| | | | |
| | | | |
7) |<=================data(HNP1)============|======data=======>|
| |<============================data(HNP1 & HNP2)==========|
| | | | |
Figure 3 Multiple Interfaces Attach Procedure
Hui&Deng Expire April, 2010 [Page 7]
Internet-Draft PMIP multihoming extension October 2009
Figure 2 shows the signaling call flow of the multiple interface
attach procedures. The detailed explanations of the signaling
procedures are as follows.
1)-4) It is the standard procedure defined in RFC5213.
5) Upon receiving the PBU message from the MAG2, the LMA does a
lookup in MN's the binding cache. If a binding cache entry exists
with MN-ID field matching the identifier in the received MN-ID
option, MN-LL-ID field not matching the identifier in the received
MN-LL-ID option, the LMA will assign the new HNP2 to the IF2.The
LMA creates the new binding cache entry including the MN-ID, MN-
LL-ID (for IF2), HNP2 field with additional "Quantity of MAG"
field set to 1.The LMA also updates the existing binding cache
entry of HNP1 with "Quantity of MAG" field increased to 2, default
Proxy-CoA for MAG1 and standby Proxy-CoA for MAG2.
6) The LMA returns a PBA message including HNP1 and HNP2 for IF2 to
the MAG2.
7) The bi-directional tunnel2 between MAG2 and LMA is set up to
forward the traffic addressed to HNP1 and HNP2.
Thus, the MN could receive the traffic addressed to HNP1 via IF1 and
IF2, and only receive the traffic addressed to HNP2 via IF2.
The mapping between IP flow and MAG can be based on Service Flow
Identifier specified in draft-hui-netext-service-flow-identifier ,
and the binding policy is out of the scope of this document.
Hui&Deng Expire April, 2010 [Page 8]
Internet-Draft PMIP multihoming extension October 2009
4. PMIPv6 Multihoming Extension
This section introduces PMIPv6 multihoming extensions that are
necessary for supporting data transmission through multiple MAGs, and
then interfaces, simultaneously.
4.1. Binding Cache and Binding Update list Extension
The binding is conceptually stored in the binding cache entry and
binding update list entry of the local mobility anchor and mobile
access gateway. Besides the standard field (HNP, MN-ID, etc), it
should be extended to include the following parameters:
O Quantity of MAG: an additional field, an integer indicating the
number of the MAGs that the home network prefix is associated with.
O MAG Parameter Sets: modified field sets, each of which is
associated with a MAG that the home network prefix is associated with.
The following parameters are included in a set:
1) Service Flow Identifier, an additional sub-field. A service
flow identifier is used to indicate one of the flows binding to the
MAG associated with the set. When flows are binding to the MAG, the
sub-field would include multiple flow identifiers. The detailed
format of service flow Identifier is out of the scope of this
document, more information can be found in [draft-hui-netext-service-
flow-identifier].
2) The link-layer identifier of the mobile node's connected
interface on the access link, described in Section 5.1 of [RFC5213].
3) The link-local address of the mobile access gateway on the
point-to-point link shared with the mobile node, described in Section
5.1 of [RFC5213].
4) The tunnel interface identifier (tunnel-if-id) of the bi-
directional tunnel between the local mobility anchor and the mobile
access gateway where the mobile node is currently anchored, described
in Section 5.1 of [RFC5213].
5) The access technology type, by which the mobile node is
currently attached, described in Section 5.1 of [RFC5213].
Hui&Deng Expire April, 2010 [Page 9]
Internet-Draft PMIP multihoming extension October 2009
6) The 64-bit timestamp value of the most recently accepted Proxy
Binding Update message sent for this mobile node, described in
Section 5.1 of [RFC5213].
4.2. Data Forwarding Operation
In order to receive the traffic addressed to specific interface at
any other interfaces, the MN MUST follows the Weak host model [2].
LMA lookup:
When the LMA receives data packet from a CN, it makes a lookup in
its binding cache with the lookup key - the destination address
of the data packet.
Case 1. If there exists a binding cache entry, with the HNP field
matching the destination address, and the Quantity of MAG is set
to 1, then the corresponding bi-directional tunnel will be used
to forward the data packets to the MAG.
Case 2. If there exists a binding cache entry, with the HNP field
matching the destination address, and the Quantity of MAG is
greater than 1, then the LMA will select the most suitable MAG
based on service flow identifier which is binding to the MAG and
matches the data packet.
If there doesn't exist such a service flow identifier, the LMA
should select the MAG corresponding to the first parameter set
in the entity, which is named as preferred MAG and the others
as reserved MAG(s).
In both cases, the corresponding bi-directional tunnel will be
used to forward the data packets to the selected MAG.
Synchronization of binding status between LMA and MAG
The extend BCE in LMA stores the information binding the HNP to
several proxy-CoAs related to the same MN. And according to RFC
5213, LMA sends one HNP or multiple HNPs in a PBA message to MAG.
Thus LMA can insert HNP(s) into PBA message to indicate that the
data packets with any of the HNPs should be forwarded to the MN
through the MAG.
Hui&Deng Expire April, 2010 [Page 10]
Internet-Draft PMIP multihoming extension October 2009
The MAGs do not need to perceive the existence of the multihoming
extension of PMIPv6 and the detailed information of binding status
about any of HNPs and MAGs. The MAGs make all the operations based
on RFC 5213 when receiving a PBA message.
MAG operation of data forwarding
There is no changes for MAGs when to forward data packets. The
detailed process of forwarding data in MAG can be found in Section
6.10.5 of [RFC5213].
Hui&Deng Expire April, 2010 [Page 11]
Internet-Draft PMIP multihoming extension October 2009
5. Security Considerations
Since this document doesn't propose any new protocol, it uses the
same security as the proxy binding update operation in RFC 5213.
6. IANA Considerations
This document makes no request of IANA.
7. References
7.1. Normative References
[1] S. Gundavelli, Ed., "Proxy Mobile IPv6", RFC 5213, August 2008.
[2] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[3] M.Hui,"Service Flow Identifier in Proxy Mobile IPv6", draft-hui-
netext-service-flow-identifier(work in progress), June 2009.
7.2. Informative References
Hui&Deng Expire April, 2010 [Page 12]
Internet-Draft PMIP multihoming extension October 2009
Author's Addresses
Min Hui
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: huimin.cmcc@gmail.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui02@gmail.com
Hui&Deng Expire April, 2010 [Page 13]