PMIP Based Distributed Mobility Management Approach
draft-liu-dmm-pmip-based-approach-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Dapeng Liu | ||
| Last updated | 2011-12-01 (Latest revision 2011-07-04) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-dmm-pmip-based-approach-01
Network Working Group D.Liu
Internet Draft China Mobile
Intended status: Standards Track J.SONG
Expires: May 31, 2012 W.LUO
ZTE
December 1, 2011
PMIP Based Distributed Mobility Management Approach
draft-liu-dmm-pmip-based-approach-01.txt
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), 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 31, 2012.
Copyright Notice
Copyright (c) 2011 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.
Abstract
Distributed mobility management (DMM) approach is needed, because the
mobile networks are moving towards flat architectures. This document
defines a PMIPv6 based distributed mobility management protocol.
Liu, et. al Expires May 31, 2012 [Page 1]
Internet-Draft Requirements of DMM December 2011
Table of Contents
1. Introduction ................................................... 2
2. Conventions used in this document .............................. 3
3. Overview of PMIP Based Distributed Mobility Management Approach .3
3.1. Basic Data Deliver Approaches ............................. 3
3.2. Handoff Approaches ........................................ 5
3.3. Locate Mobility Anchor Locating Considerations ............ 6
3.3.1. Depend on Configuration .............................. 7
4. Mobile Access Gateway Operation ................................ 7
4.1. Extensions to Binding Update List Entry Data Structure .... 7
4.2. Extended Operations for Mobile Access Gateway ............. 8
4.2.1. Receiving traffic generated by attached mobile node .. 8
4.2.2. Receiving traffic designated to attached mobile node . 8
5. Local Mobility Anchor Operation ................................ 9
5.1. Extensions to Binding Cache Entry Data Structure ........ 9
5.2. Extended Operations of Local Mobility Anchor ............ 9
6. Security Considerations ....................................... 10
7. IANA Considerations ........................................... 10
8. References .................................................... 10
8.1. Normative References ..................................... 10
8.2. Informative References ................................... 10
1. Introduction
As the mobile networks are moving towards flat architectures, the
distributed mobility management (DMM) approaches are needed to
relieve many disadvantages of using centralized mobility management
in a flatten network described in [DMM-PS].
Both mobile access gateway and local mobility anchor specified in
this draft are fully compatible with [RFC5213] only with limited
extensions to enable PMIP based distributed mobility management
approaches.
The enhanced mobile access gateway specified in this draft is
extended to support determining of IP address of correspondent node's
mobile access gateway when receiving traffic from its attached mobile
node to enable a optimized routing between two communicating parties.
Meanwhile, the local mobility anchor specified in this draft is
extended to support the query of IP address of mobile node's mobile
access gateway according to mobile node's HoA.
Furthermore, this draft also considers the approaches in handoff
scenario to guarantee the session continuity.
Liu, et. al Expires May 31, 2012 [Page 2]
Internet-Draft Requirements of DMM December 2011
2. 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 [RFC2119].
3. Overview of PMIP Based Distributed Mobility Management Approach
PMIP based Distributed Mobility Management approach does not change
basic PMIP architecture defined in [RFC5213], only with limited
extension to both mobile access gateway and local mobility anchor to
support distributed approaches.
3.1. Basic Data Deliver Approaches
+-----+ +------+ +-----+ +------+ +-----+
| MN1 | | MAG1 | | LMA | | MAG2 | | MN2 |
+-----+ +------+ +-----+ +------+ +-----+
| | | | |
| 1.attach and PMIP Reg. | 1.attach and PMIP Reg. |
|<------------|----------->|<------------|------------>|
| | | | |
|2.uplink Data| | | |
|============>| 3. PBQR | | |
| |----------->| | |
| | 4. PBQA | | |
| |<-----------| | |
| +----------------+ | | |
| | 5.Recording PB | | | |
| | of the MN2 | | | |
| +----------------+ | | |
| | 6.uplink data | |
| |=========================>| |
| | | +---------------+ |
| | | | 7.Recording PB| |
| | | | of MN1 | |
| | | +---------------+ |
| | | |8.uplink data|
| | | |============>|
| | 9. Ongoing traffic | |
|<===========>|<========================>|<===========>|
| | | | |
Figure1. Basic Data Delivery Approaches
Liu, et. al Expires May 31, 2012 [Page 3]
Internet-Draft Requirements of DMM December 2011
Figure1 shows basic data delivery approaches of PMIP based
Distributed Mobility Management approaches specified in this draft.
In the beginning, when mobile nodes enter Proxy Mobile IPv6 domain
and attach to the access link, and if determines that the mobile
nodes are authorized for network-based mobility service, the network
performs standard PMIP approaches according to [RFC5213], i.e. PBU
and PBA transaction, for mobile nodes to provide home prefixes for
them.
Some assumptions list as following:
- Both communicating peers are mobile nodes, denoted as MN1 and MN2
respectively.
- Both communicating peers have already attached to their mobile
access gateways denoted as MAG1 and MAG2 respectively.
When MN1 tries to establish a session with MN2, it sends IP packets
denoted as uplink traffic to MN2. The uplink traffic will first
arrive at MN1's MAG1. According to PMIP protocol [RFC5213], MAG1 will
forward the uplink traffic to MN1's local mobility anchor (LMA) via a
bi-directional tunnel between the two.
In additional, as specified in this draft, MAG1 needs to determine
how to forward the uplink traffic in a optimized way to enable
distributed approaches by querying LMA the IP address of the mobile
access gateway to which the MN2 attaches currently (i.e. MAG2)
according to the MN2's HoA which is the destination IP address of the
uplink traffic.
For achieving this, MAG1 sends a PMIP Binding Query Request (PBQR)
message which is a new message specified in this draft to related LMA
who holds the Binding Cache Entry (BCE) for MN2. Based on the HoA of
MN2, the LMA could derive the IP address of MAG2 in corresponding BCE.
Then the LMA sends a PMIP Binding Query Answer (PBQA) message with
the IP address as a response to MAG1.
Upon receiving the PBQA, MAG1 records PMIP Binding information of MN2
including MN2's HoA and MAG2's IP address (CoA) locally and sets up
its endpoint of a tunnel (e.g. IP in IP tunnel) to MAG2 and forward
all follow-up uplink traffic to MAG2 via the tunnel directly to
bypass the LMA.
When receiving encapsulated packet contains the uplink traffic from
MN1 in the tunnel, MAG2 parses the packet and records PMIP Binding
information of MN1 including MN1's HoA and MAG1's IP address (CoA)
Liu, et. al Expires May 31, 2012 [Page 4]
Internet-Draft Requirements of DMM December 2011
which can be derived from the inner IP header and outer IP header of
the encapsulated packet respectively.
Then MAG2 decapsulates the packet and forwards the uplink traffic to
MN2 in access link and sets up its endpoint of a tunnel to MAG1 for
any follow-up IP packet form MN2 to MN1 denoted as downlink traffic.
At this moment, a bi-directional tunnel between MAG1 and MAG2 has
been established for all uplink and downlink traffic between the two
mobile nodes.
3.2. Handoff Approaches
+---+ +----+ +----+ +---+ +----+ +---+
|MN1| |MAG1| |MAG3| |LMA| |MAG2| |MN2|
+---+ +----+ +----+ +---+ +----+ +---+
| | | | | |
| | 1. Ongoing traffic | |
|<==========>|<==================================>|<==========>|
| | | | | |
| | 2.attach and PMIP Reg. | | |
|<----------------------->|<--------->| | |
| | 3.PBCI | | | |
| |<-----------| | | |
| | 4.PBCA | | | |
| |----------->| | | |
| 5. Uplink traffic | | | |
|========================>| | | |
| | +--------------------------------------------+
| | | 6. Process of uplink traffic is similar |
| | | with the approaches in figure 1 |
| | +--------------------------------------------+
| | | 7. Downlink Traffic | |
| |<===================================|<===========|
| |===========>| | | |
|<========================| | | |
| | | 8. PBCI | | |
| |----------------------------------->| |
| | | | +--------------+ |
| | | | | 9. Update PB | |
| | | | | of MN1 | |
| | | | +--------------+ |
| | | 10. PBCA | | |
Liu, et. al Expires May 31, 2012 [Page 5]
Internet-Draft Requirements of DMM December 2011
| |<-----------------------------------| |
| | 11. Ongoing Downlink Traffic | |
|<========================|<======================|<===========|
| | | | |
Figure 2. Handoff Approaches
Figure 2 shows approaches for the MN1's handoff from the previously
attached mobile access gateway (MAG1) to the newly attached mobile
access gateway (MAG3).
During the handoff, the network performs PMIP [RFC5213] specified
procedures for MN1 to maintain its HoA unchanged. The MAG3 on the new
access link, upon detecting the MN1 on its access link, assigns a new
CoA for MN1 and send PBU message to LMA for updating binding state.
The LMA responses MAG3 with a PBA message in sequence according to
[RFC5213].
In additional, as specified in this draft, the PBA message from LMA
to MAG3 (n-MAG) should carry IP address of MAG1 which plays the role
of p-MAG. Upon receiving the PBA, MAG3 sends a PMIP Binding Change
Inform (PBCI) message with its IP address to MAG1. MAG1 records the
information provided in PBCI and may response MAG3 with a PMIP
Binding Change Ack (PBCA) message.
At this moment, the uplink traffic from MN1 to MN2 will first arrival
at MAG3 instead of MAG1. And the process of the uplink traffic is
quite similar with the approaches described in section 3.1. The route
of the uplink traffic becomes: MN1->MAG3->MAG2->MN2.
In case MN1 has active session with MN2 before the handoff, then
after the handoff, the downlink traffic from MN2 to MN1 may still be
forwarded to MAG1 by MAG2 in the tunnel between the two.
To ensure the session continuity, when receiving the downlink traffic,
MAG1 can forward the received traffic to MAG3 and send back a PBCI
message to MAG2 with IP address of MAG3 to update the PMIP Binding
information of MN1 stored in MAG2 locally in order to prevent MAG2
from forwarding upcoming downlink traffic to MAG1 but to MAG3
directly.
3.3. Locate Mobility Anchor Locating Considerations
According to [RFC5213], only the local mobility anchor which is
involved in PMIP registration for a mobile node holds this mobile
node's Binding Cache Entry.
Liu, et. al Expires May 31, 2012 [Page 6]
Internet-Draft Requirements of DMM December 2011
If the MN1 and MN2 have different LMA, then in section 3.1, the MAG1
should determine to which local mobility anchor it should send a PBQR
message.
3.3.1. Depend on Configuration
Every local mobility anchor is configured to hold one or more IPv6
prefix pools. In case MAG is aware of the configuration, e.g. via
management plane, it could determine the corresponding local mobility
anchor to which it should send the PBRQ message, according to the
mobile node's HoA.
4. Mobile Access Gateway Operation
The enhanced mobile access gateway specified in this draft is fully
compatible with the mobile access gateway defined in [RFC5213] only
with limited additional functions.
To support these additional functions, four new messages named PMIP
Binding Query Request (PBQR), PMIP Binding Query Answer (PBQA), PMIP
Binding Change Inform (PBCI) and PIMP Binding Change
Acknowledgement(PBCA) for mobile access gateway are defined in this
draft as extensions to [RFC5213].
4.1. Extensions to Binding Update List Entry Data Structure
As specified in section 6.1 of [RFC5213], every mobile access gateway
MUST maintain a Binding Update List, and each entry in the Binding
Update List represents a mobile node's mobility binding with its
local mobility anchor. In this draft, the concept Binding Update List
entry data structure needs to be extends with one additional field as
following:
* CN-Location, the IP address of a mobile access gateway to which the
correspondent node attaches currently together with HoA of this
correspondent node.
This field enables the enhanced mobile access gateway to determine
the location of correspondent node locally according to its HoA.
Generally, one Binding Update List entry may have multiple CN-
location fields depends on how many correspondent nodes the mobile
node has.
Liu, et. al Expires May 31, 2012 [Page 7]
Internet-Draft Requirements of DMM December 2011
4.2. Extended Operations for Mobile Access Gateway
4.2.1. Receiving traffic generated by attached mobile node
According to [RFC5213], whenever a mobile access gateway intercepts
traffic generated by its attached mobile node which is a traffic
sender, it shall check the corresponding Binding Update List entry to
determine the local mobility anchor to which it should forward the
traffic for that mobile node.
As extensions in this draft, the enhanced mobile access gateway
should also check CN-Location field in the corresponding Binding
Update List entry locally to determine the IP address of
correspondent node's mobile access gateway by using destination IP
address of the traffic as input parameter.
In case the IP address cannot be determined locally, the enhanced
mobile access gateway should query a corresponding LMA by sending a
PBQR message with IP address of the correspondent node to request the
information.
If the enhanced MAG acquires the IP address in a PBQA message, it
shall record the information locally.
In case the IP address can be determined either locally or from the
LMA, the enhance mobile access gateway should set up a tunnel by
using the IP address of correspondent node's MAG as endpoint and
forward any follow-up traffic generated by the mobile node via the
tunnel to the correspondent node's mobile access gateway directly.
In case the IP address cannot be determined anyway, the enhanced MAG
will forward all follow-up traffic to mobile node's LMA according to
[RFC5213].
In case when the enhanced mobile access gateway receives a PBCI
message with IP address of correspondent node's mobile access gateway,
it should update the CN-Location filed of corresponding Binding
Update List entry.
4.2.2. Receiving traffic designated to attached mobile node
Whenever a enhanced mobile access gateway receives traffic designated
to its attached mobile node which is the traffic receiver in a tunnel,
it should determine the tunnel is originated by a LMA or another MAG
to which the correspondent node which is traffic sender attached.
Liu, et. al Expires May 31, 2012 [Page 8]
Internet-Draft Requirements of DMM December 2011
The mobile access gateway should decapsulate the tunneled packet and
send the traffic to the designated mobile node.
In case the traffic is from the correspondent node's MAG, the
enhanced MAG who receives the traffic should:
* If it is a handoff scenario, the enhanced mobile access gateway who
plays the role of p-MAG should forward any received traffic towards
to the mobile node to the n-MAG and inform IP address of the n-MAG to
the correspond mobile node's mobile access gateway by sending a PBCI
message.
* Otherwise, the enhanced MAG should update the CN-Location field in
corresponding Binding Update List entry for the mobile node who is
the traffic receiver with new IP address of the correspondent node's
MAG if changes.
5. Local Mobility Anchor Operation
The enhanced local mobility anchor specified in this draft is fully
compatible with the local mobility anchor defined in [RFC5213] only
with limited additional functions.
The only extension is the enhanced local mobility anchor specified in
this draft supports the query for IP address of a mobile node's
mobile access gateway based on this mobile node's HoA.
To support the additional function, two new messages named PMIP
Binding Query Request (PBQR) and PMIP Binding Query Answer (PBQA) for
the local mobility anchor are defined in this draft as extensions to
[RFC5213].
5.1. Extensions to Binding Cache Entry Data Structure
No extension to binding cache entry data structure for the local
mobility anchor is needed in this draft.
5.2. Extended Operations of Local Mobility Anchor
Extended operations of enhanced local mobility anchor are defined in
this section as extensions to [RFC5213].
In case the enhanced local mobility anchor accepts a PBQR message
from a enhanced mobile access gateway, it should locate the binding
cache entry of mobile node which is identified by the IP address
carried in the PBQR message to acquire the IP address of this mobile
node's mobile access gateway.
Liu, et. al Expires May 31, 2012 [Page 9]
Internet-Draft Requirements of DMM December 2011
In case when getting the IP address of the mobile node's MAG, the
enhanced LMA should response a PBQA message with the IP address
acquired.
6. Security Considerations
None.
7. IANA Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[I-D. DMM-PS] D. Liu, " Distributed mobility management", draft-liu-
distributed-mobility-02 (work in progress), July 10, 2010.
Authors' Addresses
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Jun Song
ZTE
No.68,Zijinghua Road, Yuhuatai District
Nanjing 210012
China
Email: song.jun@zte.com.cn
Wen Luo
ZTE
Liu, et. al Expires May 31, 2012 [Page 10]
Internet-Draft Requirements of DMM December 2011
No.68,Zijinghua Road, Yuhuatai District
Nanjing 210012
China
Email: luo.wen@zte.com.cn
Liu, et. al Expires May 31, 2012 [Page 11]