One document matched: draft-jaehwoon-dmm-pmipv6-03.txt
Differences from draft-jaehwoon-dmm-pmipv6-02.txt
DMM Working Group Jaehwoon Lee
Internet-Draft Dongguk University
Intended status: Informational Younghan Kim
Expires: April 4, 2015 Soongsil University
October 5, 2014
PMIPv6-based Distributed Mobility Management
draft-jaehwoon-dmm-pmipv6-03
Abstract
Proxy Mobile IPv6 (PMIPv6) is the network-based mobility management
protocol where access network supports the mobility of a mobile node
on behalf of the MN. In PMIPv6, the location information of the MN
should be registered to Localized Mobility Anchor and communication
must be established via the LMA. Therefore, the performance can be
degraded due to traffic concentration and congestion possibility.
One method to overcome the above problems is to exploit the
distributed mobility management (DMM) mechanism to distribute the
LMA function to all access routers within the PMIPv6 domain. This
letter proposes the fully distributed mobility management mechanism
in PMIPv6-based network. In this mechanism, there is no need for
the location management function to register the location of the MN.
Therefore, the performance is not degraded due to the overhead to
query the location of the MN.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 4, 2015.
Jaehwoon Lee Expires Apr. 4, 2015 [Page 1]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction.................................................3
2. Conventions and Terminology..................................4
2.1. Conventions used in this document........................4
2.2. Terminology ............................................4
3. Protocol Operation...........................................5
4. Security Considerations......................................8
5. IANA Considerations..........................................8
6. References....................................................8
Author's Address.................................................9
Jaehwoon Lee Expires Apr. 4, 2015 [Page 2]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
1. Introduction
Mobile IPv6 (MIPv6) defines a protocol that allows a mobile node (MN)
to maintain connectivity with a correspondent node (CN) within the
Internet while changing its point of attachment [1]. In MIPv6, an MN
is assigned with an IPv6 address as the home address, and a home
agent (HA) is defined as the mobility agent that has the same
network address as that of the home address of the MN. Whenever an
MN visits a foreign network, it is assigned with a care-of address
(CoA) and registers its home address and the CoA to its HA by using
the Binding Update (BU) message. After that, the tunnel is
established between the MN and the HA, and the MN can communicate
with any host within the Internet. MIPv6 is considered as the host-
based mobility management protocol that an MN initiates the
operation defined in the MIPv6 whenever the MN detects that it
changes the point of attachment.
Even though the MIPv6 is defined as the Internet standard, the
overhead to run the MIPv6 in an MN is not small. Proxy MIPv6 (PMIPv6)
is standardized as an Internet standard where access networks within
the PMIPv6 domain support the mobility of an MN on behalf of the MN
[2]. In PMIPv6, a Mobile Access Gateway (MAG) is defined to support
the mobility of an MN. The MAG acts as the default gateway of the
access link to which an MN is connected. Moreover, the Localized
Mobility Anchor (LMA) is defined as the home agent of an MN within
the PMIPv6 domain. In PMIPv6, every MAG advertises the same network
prefix to an MN so that the MN considers that it connects to the
same network while the MN moves one network to another. The MAG that
the MN connects transmits the Proxy BU (PBU) message with its
address (that is, Proxy-CoA) and the information of the MN to the
LMA and establishes the tunnel between itself and the LMA in order
for the MN to maintain the pre-established session.
MIPv6 and PMIPv6 use one centralized agent such as HA and LMA,
respectively. Such centralized functions have several problems such
as single-node failure, congestion possibility, scalability issues
and non-optimal routes [3]. One method to resolve such problems is
to use the dynamic mobility management (DMM) mechanism to distribute
mobile agent function to access routers [4]. Especially, in PMIPv6,
access networks need to support the mobility of MNs in order for an
MN to use the pre-assigned address and to maintain the pre-
established session. One method to provide the DMM in PMIPv6 domain
is to distribute the LMA function to every MAG. Here, a MAG that an
MN enters the PMIPv6 domain and firstly connects becomes the LMA for
the MN. Moreover, the MAG becomes the default gateway for the MN.
That is, LMA function can be distributed because different MNs
firstly connect to different MAGs and different MAGs become different
LMAs for different MNs. Moreover, because the access router to which
Jaehwoon Lee Expires Apr. 4, 2015 [Page 3]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
an MN firstly connects provides the MAG and LMA functions, optimal
path can be established between the MN and a CN. However, PMIPv6
domain should support the mobility of an MN on behalf of the MN. When
an MN moves one network to another, a new access router that the MN
moves and connects should know (1) whether the MN firstly enters the
PMIPv6 domain and (2) the address information of the LMA for the MN
when the access router knows that the MN moves from another network.
One way to do it is to use the partial DMM mechanism [5-7]. The
partial DMM mechanism in PMIPv6 environment defines a Location
Management Function (LMF). A MAG that an MN firstly enters the PMIPv6
domain and firstly connects becomes the LMA for the MN. The LMA
registers its address and MN's ID with the LMF. When the MN moves and
connects to a different MAG, the MAG queries the address information
of the MN and LMA, and establishes the tunnel with the LMA. After
that, the MN can continue to communicate any host within the
Internet. However, there can also occur single-node failure problem.
Moreover, control messages to query the LMA address information for
MNs are concentrated to the LMF, which occurs the congestion
possibility.
In this draft, we propose the fully distributed mobility management
mechanism. The proposed mechanism does not need the control function
such as LMF. Therefore, it does not occur the single-node failure
problem. Moreover, the performance degradation does not occur due to
the overhead to register and query the LMA address information for
an MN. Packet loss and/or packet's out-of-order transmission can be
avoided by using the proposed mechanism.
2. Conventions and Terminology
2.1. Conventions
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 [8].
2.2 Terminology
TBD.
Jaehwoon Lee Expires Apr. 4, 2015 [Page 4]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
3. Protocol Operation
MN MAG1 MAG2 MAG3 CN
| | | | |
|*** L2 attachment ***>| | | |
|<----- RA(PREF) ------| | | |
|---DHCP request msg-->| | | |
|<--DHCP reponse msg---| | | |
| (MN's address) | | | |
(Configure IPv6 address) | | | |
|<-------------------- exchange IP traffic ------------------->|
(Move from MAG1 to MAG2) | | | |
|************ L2 attachment **************>| | |
|<-------------- RA(PREF) -----------------| | |
|--------------- IP packet --------------->| | |
| | (packet buffering) | |
| |<----DPBU msg------| | |
| (create BCE and est. tunnel) | | |
| |-----DPBA msg----->| | |
| | (create BUL and est. tunnel)| |
| |<====IP packet=====| | |
| |--------------- IP packet ------------>|
(Move from MAG2 to MAG3) | | | |
| | (packet buffering) | |
| |<----DPBRU msg-----| | |
| |----DPBRA msg----->| | |
|****************** L2 attachment ******************>| |
|<------------------- RA (PREF) ---------------------| |
|------------------- IP pkt ------------------------>| |
| | (pkt bufferring) |
| |<-- exchange DPBU/DPBA msg ->| |
| |<========= IP packet ========| |
| |-------------- IP packet ------------->|
(a) MN to CN packet transmission scenario
Jaehwoon Lee Expires Apr. 4, 2015 [Page 5]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
MN MAG1 MAG2 MAG3 CN
| | | | |
|*** L2 attachment ***>| | | |
|<----- RA(PREF) ------| | | |
|---DHCP request msg-->| | | |
|<--DHCP reponse msg---| | | |
| (MN's address) | | | |
(Configure IPv6 address) | | | |
|<-------------------- exchange IP traffic ------------------->|
(Move from MAG1 to MAG2) | | | |
| |<----------- IP packet ----------------|
| (packet buffering) | | |
|************ L2 attachment **************>| | |
|<-------------- RA(PREF) -----------------| | |
| |<----DPBU msg------| | |
| (create BCE and est. tunnel) | | |
| |-----DPBA msg----->| | |
| | (create BUL and est. tunnel)| |
| |=====IP packet====>| | |
|<--------------- IP packet ---------------| | |
(Move from MAG2 to MAG3) | | | |
| | (packet buffering) | |
| |<----DPBRU msg-----| | |
| |<= Buffered IP pkt=| | |
| (packet bufffering) | | |
| |<--- FLUSH msg --->| | |
| |----DPBRA msg----->| | |
|****************** L2 attachment ******************>| |
|<------------------- RA (PREF) ---------------------| |
| |<-- exchange DPBU/DPBA msg ->| |
| |==== buffered IP packet ====>| |
| |====== IP packet ===========>| |
|<----------------- IP packet -----------------------| |
(b) CN to MN packet transmission scenario
Figure 1: Message exchange scenario
The message exchange procedure between network entities to provide
fully distributed mobility management in PMIPv6 environment proposed
in this draft is presented in Figure 1. A network prefix "PREF" is
allocated to the PMIPv6 domain. However, a different sub-network
prefix belonging to the same network prefix "PREF" is allocated to
a different MAG in PMIPv6 domain. In the example of Fig. 1, a sub-
network prefix "PREF1" belonging to "PREF" is allocated to MAG1
and a different sub-network prefix "PREF2" belonging to the same
"PREF" is allocated to MAG2. Even though a different sub-network
prefix is allocated to a different MAG, all MAGs advertise the same
network prefix "PREF" through the interfaces providing PMIPv6
service.
Jaehwoon Lee Expires Apr. 4, 2015 [Page 6]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
When an MN firstly enters the PMIPv6 domain and connects to a MAG
(say, MAG1), MAG1 transmits to the MN a Router Advertisement (RA)
message by setting "M (Managed address configuration)" flag in
order to configure an address to the MN by using the stateful
address configuration method [9]. The network prefix "PREF" is set
to the prefix option information field in the RA message. The MN
having received the RA message transmits the dynamic host
configuration protocol (DHCP) request message to the MAG1 [10]. The
MAG1 considers that the MN firstly connects to the PMIPv6 domain and
transmits the DHCP response message containing an address belonging
to the "PREF1" to the MN. The MN sets the address contained in the
DHCP response message to its interface. After that, the MN can
communicate to a CN within the Internet.
When the MN moves MAG1 to MAG2 while communicating with a CN, the
MAG1 begins to perform the LMA function for the MN and stores
packets sent from the CN into the buffer. The MAG1 stores the MM's
information into its Binding Cache Entry (BCE). When the MN connects
to MAG2, the MAG2 transmits the RA message containing network prefix
set to "PREF" to the MN. The MN having received the RA message
considers that it connects to the same network by using the "PREF"
network prefix in prefix information option of RA message. It
continues to use the address configured previously and transmits IP
packets as usual. MAG2 checks the first packet transmitted by the MN.
If the first packet contains the DHCP request packet, then MAG2
considers that the MN firstly connects to the PMIPv6 domain.
Otherwise, MAG2 considers that the MN moves from another MAG area and
creates the Binding Update List (BUL) for the MN. And then, MAG2
transmits the Distributed Proxy Binding Update (DPBU) message. The
source address of the packet containing the DPBU message is set to
the address of the MAG2 (say, Proxy-CoA2) and the destination address
is set to the address of the MN. Here, MAG2 can know the address of
the MN by using the source address of the IP packet sent by the MN.
Moreover, MAG2 stores packets sent by the MN. DPBU message is
transmitted to the MAG1 through the Internet topologically correct
routing path. MAG1 having received the DPBU message stores the
Proxy-CoA2 address to its BCE for the MN, establishes the tunnel with
MAG2, and transmits the Distributed Proxy Binding Acknowledgement
(DPBA) message to MAG2. The source and destination addresses of the
packet containing the DPBA message are set to the address of MAG1
(say, Proxy-CoA1) and Proxy-CoA2, respectively. The DPBA message
contains the address of the MN in its option field. MAG2 receiving
the PBA message stores the Proxy-CoA1 address to its BUL and
establishes the tunnel with MAG1. And then, MAG1 transmits the
packets stored in the buffer to MAG2, and MAG2 would the received
packets to the MN. After that, the MN continues to communicate with
the CN.
Jaehwoon Lee Expires Apr. 4, 2015 [Page 7]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
Packets sent from MAG1 to MAG2 might be lost if the MN moves from
MAG2 to another MAG (MAG3 for example in this draft). It is because
MAG1 cannot know the fact that the MN moves and connects to MAG3.
In order to avoid the packet loss, When MAG2 knows to disconnect to
the MN, MAG2 transmits the Distributed Proxy Binding Release Update
(DPBRU) message to MAG1. Moreover, MAG2 transmits packets for the MN
to MAG1 again. When MAG1 receives the DPBRU message, MAG1 transmits
FLUSH message to the MAG2 and stores packets sent from the CN in its
buffer. MAG2 having received the FLUSH message considers that the
message is the final packet sent from the MAG1 and retransmits the
FLUSH message. And then, MAG2 removes the entry related the MN in the
BUL. MAG1 having received the FLUSH message having sent from MAG2
considers that themessage is the final packet sent from MAG2. MAG1
transmits the Distributed Proxy Binding Release Acknowledgement
(DPBRA) message to MAG2. When MAG1 receives the DPBU message from
MAG3, MAG1 transmits the DPBA message to MAG3, update its BCE related
to the MN, transmits the stored packets sent from MAG2, and then
transmits packets sent from the CN.
4. Security Considerations
TBD
5. IANA Considerations
TBD
6. References
[1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in
IPv6", IETF RFC 3775, June 2004.
[2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and
B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008.
[3] H. Chan, D. Liu, P. Seite, H. Yokota and J. Korhonen,
"Requirements for Distributed Mobility Management",
draft-ietf-dmm-requirements-03 (work in progress), Dec. 2012.
[4] IETF dmm working group,
http://datatracker.ietf.org/wg/dmm/charter.
[5] CJ. Bernardos, A. de la Oliva, F. Giust, T. Melia and R. Costa,
"A PMIPv6-based solution for Distributed Mobility Management",
draft-bernardos-dmm-pmip-01 (work in progress), Mar. 2012.
Jaehwoon Lee Expires Apr. 4, 2015 [Page 8]
Internet-Draft PMIPv6-based DMM Oct. 5, 2014
[6] W. Luo and S. Tricci, "Distributed Mobility Management
Approaches with IPv6 Prefix Properties",
draft-luo-dmm-with-ipv6-prefix-properties-00 (work in progress),
Oct. 2012.
[7] P. Seite, P. Bertin and Jh. Lee, "Distributed Mobility
Anchoring", draft-seite-dmm-dma-06 (work in progress),
Jan. 2013.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] T. Narten, E. Nordmark, W. Sompson and H. Soliman, "Neighbor
Discovery for IP version 6 (IPv6), IETF RFC 4861, Sep. 2007.
[10] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
IETF RFC 3315, July 2003.
Author's Address
Jaehwoon Lee
Dongguk University
26, 3-ga Pil-dong, Chung-gu
Seoul 100-715, KOREA
Email: jaehwoon@dongguk.edu
Younghan Kim
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: younghak@ssu.ac.kr
Jaehwoon Lee Expires Apr. 4, 2015 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:49:59 |