One document matched: draft-liu-dmm-pmip-based-approach-00.txt
Network Working Group D.Liu
Internet Draft China Mobile
Intended status: Standards Track J.SONG
Expires: January 5, 2012 W.LUO
ZTE
July 3, 2011
PMIP Based Distributed Mobility Management Approach
draft-liu-dmm-pmip-based-approach-00.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 January 4, 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 January 4, 2012 [Page 1]
Internet-Draft Requirements of DMM July 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 ........................................ 4
3.3. Local Mobility Anchor Locating Considerations ............. 6
4. Mobile Access Gateway Operation ................................ 6
4.1. Extensions to Binding Update List Entry Data Structure .... 6
4.2. Extended Operations for Mobile Access Gateway ............. 7
4.2.1. Receiving traffic generated by attached mobile node .. 7
4.2.2. Receiving traffic designated to attached mobile node . 7
5. Local Mobility Anchor Operation ................................ 8
5.1. Extensions to Binding Cache Entry Data Structure .......... 8
5.2. Extended Operations of Local Mobility Anchor .............. 8
6. Security Considerations ........................................ 8
7. IANA Considerations ............................................ 8
8. References ..................................................... 8
8.1. Normative References ...................................... 8
8.2. Informative References .................................... 8
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 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 IP address.
Furthermore, this draft also considers the approaches in handoff
scenario to guarantee the session continuity.
Liu, et. al Expires January 4, 2012 [Page 2]
Internet-Draft Requirements of DMM July 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.uplink data|
| | | |============>|
| | 8. Ongoing traffic | |
|<===========>|<========================>|<===========>|
| | | | |
Figure1. Basic Data Delivery Approaches
Figure1 shows basic data delivery approaches of PMIP based
Distributed Mobility Management approaches specified in this draft.
Liu, et. al Expires January 4, 2012 [Page 3]
Internet-Draft Requirements of DMM July 2011
In this section, assuming both communication peers are mobile nodes
denoted as MN1 and MN2 respectively.
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 both MN1 and MN2 to provide home prefixes
for them respectively.
When MN1 tries to establish a session with MN2, it sends IP packets
denoted as uplink traffic to MN2, and the traffic will first arrive
at MN1's mobile access gateway (MAG1). According to PMIP protocol
specified in [RFC5213], MAG1 will forward the 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 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 IP address which is the destination IP address of the
traffic. For achieving this, MAG1 sends a PMIP Binding Query Request
(PBQR) message to related LMA who holds the Binding Cache Entry (BCE)
for MN2. Based on the IP address (i.e. HoA) of MN2, the LMA could
derive 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 will record PMIP Binding information of
MN2 including MN2's IP address (HoA) and MAG2's IP address (CoA)
locally and set up its endpoint of a tunnel (e.g. IP in IP tunnel) to
MAG2 and forward all follow-up traffic to MAG2 via the tunnel
directly to bypass the LMA.
When receiving encapsulated packet contains the traffic from MN1 in
the tunnel, MAG2 will decapsulate the packet and forward the traffic
to MN2 in access link.
Note that, the date deliver approaches described above is only an
specific example.
3.2. Handoff Approaches
+---+ +----+ +----+ +---+ +----+ +---+
|MN1| |MAG1| |MAG3| |LMA| |MAG2| |MN2|
+---+ +----+ +----+ +---+ +----+ +---+
Liu, et. al Expires January 4, 2012 [Page 4]
Internet-Draft Requirements of DMM July 2011
| | | | | |
| | 1. Ongoing traffic | |
|<==========>|<==================================>|<==========>|
| | | | | |
| | 2.attach and PMIP Reg. | | |
|<----------------------->|<--------->| | |
| | | 3. Uplink traffic | |
|========================>|======================>|===========>|
| | | 4. Downlink Traffic | |
| |<===================================|<===========|
| |===========>| | | |
|<========================| | | |
| | | 5. PBCI | | |
| |----------------------------------->| |
| | | 6. PBCA | | |
| |<-----------------------------------| |
| | 7. Ongoing Downlink Traffic | |
|<========================|<======================|<===========|
| | | | |
Figure 2. Handoff Approaches
Figure 2 shows the signaling call flow for the MN1's handoff from the
previously attached mobile access gateway (MAG1) to the newly
attached mobile access gateway (MAG3).
Before the HO, MN1 may have already established a session with its
correspondent node (MN2). During the handoff, the network performs
PMIP 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].
If MN1 has active session with MN2 before the handoff, the downlink
traffic from MN2 to MN1 may still be forwarded to MAG1 by MAG2 in the
tunnel between the two. MAG1 may send a PMIP Binding Change Inform
(PBCI) message to MAG2 with IP address of target mobile access
gateway (MAG3) to update the IP address of MN1's mobile access
gateway stored in MAG2 locally in order to prevent MAG2 from
forwarding upcoming traffic to MAG1 but to MAG3 directly.
Note that, the handoff approaches described above is only an specific
example.
Liu, et. al Expires January 4, 2012 [Page 5]
Internet-Draft Requirements of DMM July 2011
3.3. Local Mobility Anchor Locating Considerations
According to [RFC5213], only the local mobility anchor which is
involved in PMIP registration for MN2 holds the MN2's Binding Cache
Entry. MAG1 should determine to which local mobility anchor it should
send a PBQR message.
Every local mobility anchor is configured to hold one or more IPv6
prefix pools. In case MAG1 is aware of this IPv6 prefix pool
configuration, e.g. from management plane, it could determine the
corresponding local mobility anchor to which it should send the PBRQ
message, according to the IP address of MN2.
4. Mobile Access Gateway Operation
The 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 the mobile access gateway to which
the correspondent node attaches currently together with IP address of
this correspondent node. This field enables the mobile access gateway
to determine the location of correspondent node locally according to
its IP address. Generally, one Binding Update List entry may have
multiple CN-location fields depends on how many correspondent node
the mobile node has.
Liu, et. al Expires January 4, 2012 [Page 6]
Internet-Draft Requirements of DMM July 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 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. If this information cannot be determined locally,
the mobile access gateway should query a corresponding LMA by sending
a PBQR message with IP address of the correspondent node.
When the mobile access gateway gets the IP address of the
correspondent node's mobile access gateway in a PBQA message from the
local mobility anchor, it should record the information into the CN-
Location field of the corresponding Binding Update List entry for the
mobile node.
After the IP address of the correspondent node's mobile access
gateway is determined, the mobile access gateway should set up a
tunnel by using this IP address 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.
When the 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 mobile access gateway receives traffic designated to its
attached mobile node which is the traffic receiver in a tunnel from
correspondent node's mobile access gateway, the mobile access gateway
should decapsulate the tunneled packet and send the traffic to the
designated mobile node.
In handoff scenario, mobile access gateway who plays the role of
source mobile access gateway may inform IP address of the target
mobile access gateway to the correspond mobile node's mobile access
gateway by sending a PBCI message.
Liu, et. al Expires January 4, 2012 [Page 7]
Internet-Draft Requirements of DMM July 2011
5. Local Mobility Anchor Operation
The 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 local mobility anchor defined in this draft
supports the query for IP address of a mobile node's mobile access
gateway based on this mobile node's IP address (HoA).
To support these 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 local mobility anchor are defined in this
section as extensions to [RFC5213].
In case the local mobility anchor accepts a PBQR message from a
mobile access gateway, it should locate the binding cache entry of
mobile node which is identified by this mobile node's IP address
carried in the PBQR message to acquire the IP address of this mobile
node's mobile access gateway.
6. Security Considerations
None.
7. IANA Considerations
TBD
8. References
8.1. Normative References
8.2. Informative References
[I-D. DMM-PS]
Liu, et. al Expires January 4, 2012 [Page 8]
Internet-Draft Requirements of DMM July 2011
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
No.68,Zijinghua Road, Yuhuatai District
Nanjing 210012
China
Email: luo.wen@zte.com.cn
Liu, et. al Expires January 4, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:41 |