NETLMM Working Group Y. Cui
Internet Draft Y. Liu
Intended status: Standards Track Y. Sun
Expires: DEC 2010 Tsinghua University
D. Liu
H. Deng
China Mobile
November 23, 2009
Interactions between PMIPv6 and DSMIPv6: a scenario while HA and LMA
are separate deployment
draft-cui-netlmm-mip-interactions-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 May 23, 2009.
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.
Cui, et al. Expires May 23, 2010 [Page 1]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
Abstract
Home Agent and Local Mobility Anchor are separately deployed is one
scene of the interactions between Proxy Mobile IPv6 (PMIPv6) and Dual
stack Mobile IPv6 (DSMIPv6). In view of this scenario this document
proposes two detailed solutions for a mobile node which is roaming
between PMIPv6 and DSMIPv6.
Table of Contents
1. Introduction.....................................................3
2. Requirements Terminology.........................................3
3. Scenario Description.............................................4
4. Solution One - simple interaction................................5
5. Solution Two - complex interaction...............................6
5.1. Extension of Proxy Binding Update...........................6
5.2. Messaging Mechanism for PMIPv6-DSMIPv6 Interactions.........7
5.2.1. Roaming from DSIMPv6 to PMIPv6.........................7
5.2.2. Roaming from PMIPv6 to DSIMPv6.........................9
5.3. Mobility Agent Considerations...............................9
5.3.1. Mobile Node Considerations.............................9
5.3.2. Mobility Access Gateway Considerations.................9
5.3.3. Local Mobile Anchor Considerations.....................9
6. Security Considerations..........................................9
7. IANA Considerations..............................................9
8. References......................................................10
8.1. Normative References.......................................10
8.2. Informative References.....................................10
9. Acknowledgments.................................................10
Author's Addresses.................................................10
Cui, et al. Expires May 23, 2010 [Page 2]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
1. Introduction
This document proposes two detailed solutions for a mobile node which
is roaming between PMIPv6 and DSMIPv6. In this scenario the HA and
LMA are separately deployed in different networks.
When a mobile node is roaming from DSMIPv6 domain to PMIPv6 domain,
in order to ensure the connectivity of MN's communications, the
mobile node must re-register to the HA with a new care-of-address.
There are two ways to resolve the problem. One way is that when the
MN gets the PMIPv6-HoA from the MAG, it re-registers to the HA with
the PMIPv6-HoA as a CoA. The other way is that the LMA will register
to the HA with one of its own addresses instead of the attached
mobile node.
This document also defines some option and mechanisms for use in the
solutions. These extensions are optional extensions, but they can
help to implement the interaction system.
2. Requirements Terminology
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.
The Mobile-IP-related and Proxy-Mobile-IP-related terminology used in
this document are described in RFC 3344 [3] and RFC 5213 [2]. The
dynamics home agent assignment related terminology used in this
document are described in RFC 4433[4]. In addition, the following
terms are used:
DSMIPV6: dual stack mobile IPv6
DSMIPv6-HoA: the Home Address the MN includes in DSMIPv6 binding
update messages
PMIPv6-HoA: the Home Address assigned by the LMA, in our scenario
PMIPv6-HoA is equal to DSMIPv6-HoA
LMAA: the address of LMA
Cui, et al. Expires May 23, 2010 [Page 3]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
3. Scenario Description
There are three scenarios described in [6]. Scenario A is that the
Mobile IPv6 Home Agent (HA) and Proxy Mobile IPv6 (LMA) are separate
and the whole network is made up of PMIPv6 domains. Scenario B and C
is that the HA and LMA are merged as a common mobility anchor, and
the difference between the two scenarios is scenario B including only
PMIPv6 domain but scenario C with Non-PMIPv6 domain. However, in our
opinion, there should be four scenarios base on whether the HA and
LMA are separate or merged and whether the Non-PMIPv6 domain is
included. So besides the above-mentioned three scenarios, there must
be another scenario D which is the HA and LMA is separate and the
network is made up of PMIPv6 domain and Non-PMIPv6 domain.
We believe scenario D is more reasonable and practical. The MIPv6
should be deployed in the whole network and the PMIPv6 locally
deployed. This scenario is easy to deploy and convenient to manage.
Because the MAG can't be deployed everywhere, the request in scenario
A which the whole network is only made up of PMIPv6 domain is not
practical. It requires the whole network should consist of PMIPv6
domain and Non-PMIPv6 domain. So scenario D is reasonable and used as
our scenario.
The figure 1 illustrates our scenario. In this scenario the HA and
LMA are separately deployed, in other words HA and LMA are belongs
to different networks. The interaction is similar to HIMIPv6; DSMIPv6
is used as a global mobility management whereas PMIPv6 is used as
local mobility management. The Non-PMIPv6 domain is also included in
our scenario. When a mobile node is roaming in DSMIPv6 domain, it
uses the protocol of the DSMIPv6. The same mechanism is used when the
mobile node is roaming only in the PMIPv6 domain. But when the mobile
node is roaming from DSMIPv6 domain to PMIPv6 domain, the two
solutions described in this document can be used to re-register to
the HA.
Cui, et al. Expires May 23, 2010 [Page 4]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
+----+
| HA | DSMIPv6-HoA -> LMAA
+----+
/\
/ \
/ \
/ \
/ \
/ \
/ \
/ \
PMIPv6-HoA -> MAG +-----+ +---------+
| LMA | ( ) DSMIPv6 Network
+-----+ ( )
|| +---------+
+----||-----+ |
PMIPv6 Domain ( || ) |
( || ) |
+----||-----+ |
+-----+ +----+
| MAG | | AR |
+-----+ +----+
| |
[MN]
Figure 1 - Scenario
4. Solution One - simple interaction
This solution is much like the one proposed in [6] related to
scenario A. The difference between the two solutions is that the Non-
PMIPv6 domain is introduce into our scenario. In this simple
interaction solution, the mobile node is managed by DSMIPv6 protocol
when it is roaming only in the Non-PMIPv6 domain (DSMIPv6 domain) and
the same to the PMIPv6 domain. However, when the mobile node is
roaming from Non-PMIPv6 domain to PMIPv6 domain or from one PMIPv6
domain to another, the mobile node should re-register to the HA. The
re-register process should be performed as the figure for global
mobility message flow which is defined in [6]. When the mobile node
is roaming from PMIPv6 domain to Non-PMIPv6 domain, the message flow
is shown as figure 2.
Cui, et al. Expires May 23, 2010 [Page 5]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
MN RA HA(DSIMPv6) MAG LMA(PMIPv6)
| | | |------1-----> |
| | | |<-----2------ |
|----3---> | | | |
|<---4---- | | | |
| | | | |
|-----------5----------> | | |
|<----------6----------- | | |
|<---------------------> | | |
Figure 2: Message Flow for MN's roaming from PMIPv6 to Non-PMIPv6
Firstly, as the step 1 and 2 shown, the MAG will discover that the MN
has been gone, and it will send a PBU to revoke the binding for MN at
the LMA. The LMA will send a PBA to confirm the revocation. The step
from 3 to 6 describe the process of the re-register to HA as the
MIPv6[5] defines.
5. Solution Two - complex interaction
In this complex interaction solution, when a mobile node is roaming
from DSMIPv6 domain to PMIPv6 domain using DSMIPv6-HoA, LMA should
receive all the packets sent to MN and then forward them to MN via
MAG. When the MN attach to the MAG, the registration to HA will be
accomplished by the LMA instead of MN, and the care-of-address option
includes in the Binding Update will be filled with the LMAA. Then a
tunnel between the LMA and HA will be established. All the packets
sent to MN will be forwarded through the tunnel.
5.1. Extension of Proxy Binding Update
The HA Address Option, shown in Figure 2, contains the address of the
HA. This extension is used in PBU to tell LMA who is the MN's HA. It
MAY be an optional extension.
Cui, et al. Expires May 23, 2010 [Page 6]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
0 1 2 30
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The HA Address Option
Type specifies the HA address option
Length Indicates the length of the extension not including
the type, reserved and length fields.
HA-Address Address of the HA.
5.2. Messaging Mechanism for PMIPv6-DSMIPv6 Interactions
This specification presents the messaging mechanism for MN's roaming
from DSMIPv6 domain to the PMIPv6 domain and the opposite direction.
5.2.1. Roaming from DSIMPv6 to PMIPv6
Detailed explanation of the process is best described with the help
of a message flow diagram and description. Figure 3 shows the process
of a MN roams from DSMIPv6 to PMIPv6.
Cui, et al. Expires May 23, 2010 [Page 7]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
MN HA(DSIMPv6) MAG LMA(PMIPv6)
|------1----->| | |
|<-----2------| | |
|---------------3------------->| |
| | |-------4----->|
| | |<------5------|
| | |<------------>|
| |<---------------6--------------|
| |----------------7------------->|
| |<----------------------------->|
Figure 4: Message Flow for MN's roaming from DSMIPv6 to PMIPv6
1. Firstly the MN sends BU and revokes the binding by setting the
lifetime field to 0 and by setting the care-of address equal to the
home address
2. The HA receives the binding revocation and knows that the MN has
left then HA will delete all the resources related to the MN.
3. The MN entered the PMIPv6 domain and MAY send a Router
Solicitation to the MAG if it does not receive any Router
Advertisements for certain time.
4. The MAG will send PBU to the LMA for MN while it detects the MN's
enter.
5. The LMA will send back a PBA once the PBU is accepted and a bi-
directional tunnel between MAG and LMA is also established.
6. At the same time the LMA will send a BU to the HA for MN and
register the LMAA as MN's new CoA.
7. The HA will send back BA if the BU is accepted and a bi-
directional tunnel will be established between LMA and HA.
Cui, et al. Expires May 23, 2010 [Page 8]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
5.2.2. Roaming from PMIPv6 to DSIMPv6
The process of a MN roams from PMIPv6 to DSMIPv6 is the same as the
figure 2 shown in 3.2.
5.3. Mobility Agent Considerations
The following sections describe the behavior of each mobility agent
in detail.
5.3.1. Mobile Node Considerations
The mobile node does not have any special behavior beyond a dual
stack mobile node.
5.3.2. Mobility Access Gateway Considerations
The MAG MAY get the HA address of attached MN, the method may be a
static way such as reading from a Strategy Document and this is out
the scope of this document.
The MAG can send the HA address to the LMA used HA Address Option
while registering to LMA and LMA can also reject this option.
5.3.3. Local Mobile Anchor Considerations
The LMA MUST be able to send binding update to the HA for MN.
The MAG may include the HA address option in the proxy binding update
while it Registers to the LMA for MN. A valid unicast IPv6 address
MUST be used as LMA address in this extension. The LMA will registers
to the HA for MN while it accepts the PBU from MAG, so the LMA must
be able to generate and send the binding update packet to the HA
specified by MAG.
6. Security Considerations
This specification assumes that a security configuration has been
preconfigured between the LMA and the MAG. The Assigned LMA
authenticates each Proxy Binding Update from the MAG. The MAG also
authenticates the Proxy Binding Apply from the Assigned LMA.
7. IANA Considerations
The HA Address Option is a new defined extension.
Cui, et al. Expires May 23, 2010 [Page 9]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
8. References
8.1. Normative References
[1] H. Soliman, Ed., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009
[2] K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy
Mobile IPv6", RFC 5213, August 2008.
[3] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[4] M. Kulkarni, A. Patel, K. Leung, "Mobile IPv4 Dynamic Home
Agent (HA) Assignment", RFC 4433, March 2006.
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[6] G. Giaretta, Ed., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues", Internet Draft, June, 2009.
9. Acknowledgments
The authors would like to thank Tianze Ma for discussions on the
topic.
This document was prepared using 2-Word-v2.0.template.dot.
Author's Addresses
Yong Cui
Tsinghua University
Tsinghua University FIT Building 4-104
Beijing 100084
P.R.China
Email: cuiyong@tsinghua.edu.cn
Cui, et al. Expires May 23, 2010 [Page 10]
Internet-Draft Interactions between PMIPv6 and DSMIPv6 November 2009
Yin Liu
Tsinghua University
Tsinghua University FIT Building 4-104
Beijing 100084
P.R.China
Email: liuyin08@gmail.com
Yonghao Sun
Tsinghua University
Tsinghua University FIT Building 4-103
Beijing 100084
P.R.China
Email: yonghaosun@gmail.com
Dapeng Liu
China Mobile research institute
Unit2, 28 Xuanwumenxi Ave,Xuanwu District,
Beijing 100053, China
Email: liudapeng@chinamobile.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui02@gmail.com
Cui, et al. Expires May 23, 2010 [Page 11]