Internet DRAFT - draft-liu-dmm-pmip-based-approach
draft-liu-dmm-pmip-based-approach
Network Working Group D. Liu
Internet-Draft China Mobile
Intended status: Experimental J. SONG
Expires: Sep. 13, 2012 W. Luo
ZTE
March 13, 2012
PMIP Based DMM Approaches
draft-liu-dmm-pmip-based-approach-02
Abstract
This draft discusses a pmip based DMM solution
Requirements Language
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].
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 August 27, 2012.
Copyright Notice
Copyright (c) 2012 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
Liu, et al. Expires August 27, 2012 [Page 1]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Overview of Ehanced Porxy Mobile IPv6 . . . . . . . . . . . . 3
3.1. Ehanced PMIP Networking Schematic . . . . . . . . . . . . 4
3.2. Functions of eMAG . . . . . . . . . . . . . . . . . . . . 5
3.3. Functions of eLMA . . . . . . . . . . . . . . . . . . . . 5
4. Overview of ePMIP Approaches . . . . . . . . . . . . . . . . . 6
4.1. Initial Registration . . . . . . . . . . . . . . . . . . . 6
4.2. Optimized Routing . . . . . . . . . . . . . . . . . . . . 7
4.3. Handoff when Optimaized Routing is Established . . . . . . 9
4.4. Multiple eLMAs Consideration . . . . . . . . . . . . . . . 11
4.4.1. Determining eLMA Based on Configuration . . . . . . . 12
4.4.2. Determining eLMA Based on IPv6 Hop-by-Hop Options
Header . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.3. Determining eLMA Based on Interface Between eLMAs . . 14
5. CN Considerations . . . . . . . . . . . . . . . . . . . . . . 14
5.1. CN Which is not Registered with eLMA . . . . . . . . . . . 15
5.2. Routing Optimization Considerations when CN is Fixed
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Handoff between eMAG and MAG . . . . . . . . . . . . . . . . . 17
7. Considerations for Other Implementation . . . . . . . . . . . 17
7.1. One Alternative Implementation . . . . . . . . . . . . . . 17
7.2. Optimized Routing Consideration . . . . . . . . . . . . . 18
7.3. Correspondent Node Consideration . . . . . . . . . . . . . 19
7.4. Location Management Consideration . . . . . . . . . . . . 20
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 21
9. Difference with Localize Routing . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
12. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Liu, et al. Expires August 27, 2012 [Page 2]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
1. Introduction
For supporting Distributed Mobility Management discussed in [I-D
DMM], enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions
is introduced in this draft . (1) Location Management Function (LMF),
maintaining the mappings between IP addresses and location
information of mobile nodes. (2) Distributed Anchoring Function
(DAF), including Distributed Routing sub-Function (DRF) which enables
optimized routing between mobile node and its correspondent node and
Distributed Mobility sub-Function (DMF) which guarantees mobile
node's mobility with minimal packet loss when optimized routing is
established.
DAF can be deployed in RFC[5213] specified MAG to constitute an eMAG,
and LMF can be deployed in RFC[5213] specified LMA to constitute an
eLMA. This draft intends to provide approaches for eliminating non-
optimized routing (section 4.2) which is identified as issues in [I-D
DMM] and dealing with handoff with quite low packet loss when
optimized routing is established (section 4.3). Besides, routing
optimization is considered not only for communication between two
mobile nodes, but also for communication between a mobile node and a
fixed node (section 5.2). Further, an alternative implementation is
also considered in section 7.
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 Ehanced Porxy Mobile IPv6
For supporting Distributed Mobility Management discussed in [I-D
DMM], enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions
is introduced in this draft . (1) Location Management Function (LMF),
maintaining the mappings between IP addresses and location
information of mobile nodes (perhaps location information of fixed
nodes are also included). (2) Distributed Anchoring Function (DAF),
including Distributed Routing sub-Function (DRF) which enables
optimized routing between mobile node and its correspondent node and
Distributed Mobility sub-Function (DMF) which guarantees the mobile
node's mobility when optimized routing is enabled.
Liu, et al. Expires August 27, 2012 [Page 3]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
3.1. Ehanced PMIP Networking Schematic
Prefix A Prefix B Prefix C+D Prefix X
\ | / \ | / \ | / | \ | /
\ | / \ | / \ | / | \ | /
eLMA1 eLMA2 eLMA3 | LMA
|
( )( )( ) ( ) ( )|( )
( area1 )( area2 )( area3 ) ( area4 )...( arean )|( arean+1)
( )( )( ) ( ) ( )|( )
( eMAG1 )( eMAG2 )( eMAG3 ) ( eMAG4 )...( eMAGn )|( MAG )
| |
| | +-----+
| | | CN2 |
MN1 CN1 +-----+
PMIP Domain with ePMIP deployed
Figure 1. RFC[5213] specified PMIP Domain with ePMIP deployed
The ePMIP can be implemented in many ways. One of those
implementations is to deploy LMF in RFC[5213] specified Local
Mobility Anchor (say legacy LMA) and to deploy DAF in RFC[5213]
specified Mobile Access Gateway (say legacy MAG). Legacy LMA with
LMF is called as enhanced local mobility anchor (eLMA), and legacy
MAG with DAF is called as enhanced mobile access gateway (eMAG)
respectively in the context of this draft.
Figure 1 illustrates a possible deployment for ePMIP, in which ePMIP
is deployed within a PMIP domain. Mechanism specified by the ePMIP
is enabled automatically for a mobile node when it attaches to an
eMAG and without any of its awareness, therefore there is no
additional requirement for a IPv6 mobile node. For fixed node
considerations, please refer to section 5.2.
Clear boundary between ePMIP and PMIP is not necessary, however,
deploying ePMIP in a continuous area is preferred. Distributed
mobility management approaches will be applied only when
correspondent node of this mobile node also attaches to an entity
which supports at least DRF (e.g. an eMAG), otherwise RFC[5213]
specified PMIP approaches will be applied (for more details, refer to
section 5). For supporting distributed mobility management
approaches, new signalling messages among the LMFs and DAFs are also
proposed in this draft.
For other implementation considerations, please refer to section 7.
Liu, et al. Expires August 27, 2012 [Page 4]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
3.2. Functions of eMAG
The eMAG is fully compatible with legacy MAG with limited additional
functions which are included in the distributed anchoring function
specified in this draft. The content below in this subsection is
general idea of the eMAG (DAF is a part of eMAG), including
- If eMAG decides to route traffic from its attached mobile node in
an optimized way, it should invoke the Distributed Anchoring Function
(DAF), more specifically, the Distributed Routing Function (DRF), to
enable distributed mobility management approaches.
- Optimized routing specified in this draft is realized by a direct
tunnel between two DRFs of mobile node and its correspondent node.
DRF is responsible for maintaining location information of mobile
node's correspondent node.
- If correspondent node also attaches to an eMAG and is registered
with an eLMA, the direct tunnel is established between two eMAGs and
tunnel endpoints are IP addresses of these two eMAGs (or CoAs of
these two communicating peers). For other scenarios, e.g. the
correspondent node is a fixed node, refer to section 5.
- Optimized routing can only be enabled when location of
correspondent node is determined. In case the location cannot be
determined locally, DRF should initiate a query approach with a
corresponding LMF. In case DRF is informed with the location (could
be CN's new location in handoff scenario), it should update the
location locally and forward any follow-up traffic based on that
location. In case location of correspondent node cannot be
determined by any means, common routing (e.g. PMIP routing)
mechanism should be used.
- For supporting mobile node's handoff from previously attached eMAG
(p-eMAG) to newly attached eMAG (n-eMAG), Distributed Mobility
Function (DMF) of both eMAGs shall be enabled. The responsibility of
n-DMF (n-eMAG) is to inform p-DMF (p-eMAG) with new location of that
mobile node during handoff. The responsibility of p-DMF (p-eMAG ) is
to forward any received traffic which designated to that mobile node
from DRF of correspondent node to n-DMF (n-eMAG ) and to inform the
DRF with new location for session continuity.
3.3. Functions of eLMA
The eLMA is fully compatible with legacy LMA with limited additional
functions which are included in the Location Management Function
specified in this draft. The content below in this subsection is
general idea of the eLMA (LMF is a part of eLMA), including
Liu, et al. Expires August 27, 2012 [Page 5]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
- The responsibility of LMF is to determine the location of a
specified mobile node (perhaps a fixed node, please refer to section
5) identified by its IP address (e.g. HoA) when it is queried by
DRF. Interface between LMFs for determining the location information
is proposed, for other alternatives, please refer to section 4.4.
- The location information of a mobile node can be its CoA, and
mechanisms for maintaining the mapping of mobile node's IP address
and its location information (i.e. HoA-CoA correlation) can be based
on Binding Cache Entry (BCE) which is specified in RFC[5213].
4. Overview of ePMIP Approaches
As described above, one implementation of ePMIP is to deploy LMF with
legacy LMA to constitute an eLMA, and deploy DAF (including DRF and
DMF sub-functions) with legacy MAG to constitute an eMAG. The
sections including section 4 to 6 assumes ePMIP adopts this
implementation. Considerations for other alternative
implementations, please refer to section 7.
The overall assumptions for section 4 are as following:
- The correspondent node is also a mobile node which attaches to an
eMAG and is registered with an eLMA.
For other scenarios, such as correspondent node is a fixed station or
not registered with an eLMA, please refer to section 5.
4.1. Initial Registration
The initial registration procedure for ePMIP is triggered when a
mobile node is initialized and attaches to an access link on which
there is an eMAG. The mostly like is that the procedures for initial
registration are identical with those specified in RFC[5213].
When determining the mobile node is authorized for the network-based
mobility management service, eMAG sends PBU to a selected eLMA for
the mobile node to complete the registration. General, an eLMA is
always preferred for the mobile node, unless there has other
constraints.
For example, If the mobile node's policy profile specified in
RFC[5213] includes a filed of mobile node's IPv6 home network
prefix(es) assigned to the mobile node's connected interface, and if
the HNP(es) is(are) managed by a legacy LMA, the eMAG shall send a
PBU to that LMA. In this case, the eMAG shall act as a legacy MAG
for this mobile node which means the DAF function in this eMAG shall
Liu, et al. Expires August 27, 2012 [Page 6]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
be disabled for this mobile node.
When initial registration with eLMA is completed, the mobile node
gets its HNP(es) and eLMA creates a binding cache entry for this
mobile node to maintain the mapping of this mobile node's HNP(es) and
Proxy-CoA.
4.2. Optimized Routing
As described in section 3.2, ePMIP leverages a direct tunnel between
two eMAGs which are implemented with DRF to realize an optimized
routing between mobile node and its correspond node. The effect is
similar with the MAG-MAG tunnel specified in [I-D Localized Routing
for Proxy Mobile IPv6] but the principle is different, refer to
section 9 for more information.
+-----+ +--------+ +-------+ +--------+ +-----+
| MN1 | | eMAG1 | | eLMA | | eMAG4 | | MN2 |
+-----+ +--------+ +-------+ +--------+ +-----+
| | | | |
| 1.Attach and PMIP Reg. | 1.Attach and PMIP Reg. |
|<------------|----------->|<------------|------------>|
| | | | |
|2.uplink Data| | | |
|============>| 3. PBQR | | |
| |----------->| | |
| | 4. PBQA | | |
| |<-----------| | |
| +------------------+ | | |
| | 5.Record Location| | | |
| | of MN2 | | | |
| +------------------+ | | |
| | 6.uplink data in tunnel | |
| |=========================>| |
| | | |7.uplink data|
| | | |============>|
| | 8. Ongoing traffic | |
|<===========>|<========================>|<===========>|
| | | | |
Figure 2. Optimized Routing
Figure 2 illustrates data delivery approaches of ePMIP for
Distributed Mobility Management. Except for the general assumptions
applied for section 4, two more assumptions are also applied in this
subsection as following:
- Mobile nodes (MN1 and MN2) attach to different eMAGs (eMAG1 and
eMAG4) respectively.
Liu, et al. Expires August 27, 2012 [Page 7]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
- Mobile nodes are registered with a same eLMA.
For other scenarios, such as mobile nodes are registered with
different eLMAs, refer to section 4.4.
After the initial registrations, both mobile nodes get their HNPes.
And eLMA maintains the mappings of HNP(es) and Proxy-CoAs of both
mobile nodes in binding cache entries for them respectively .
The communication between MN1 and MN2 is initiated by MN1 sending IP
packets to MN2 (i.e. uplink traffic). The destination IP address of
the uplink traffic is set to HoA of MN2. Upon receiving the initial
uplink traffic, eMAG1 should determine whether an optimized routing
can be established by the support of DRF on it.
The eMAG1 (DRF) should determine whether it holds the location (i.e.
CoA) of MN2 locally first. If not, eMAG1 (DRF) should determine the
location by initiating a query (i.e. sending a PMIP Binding Query
Request, PBQR) to eLMA (LMF) who holds the BCE for MN2. Based on HNP
of MN2 provided in the PBQR, eLMA (LMF) could derive the location of
MN2 (i.e. CoA) in a corresponding BCE and responses eMAG1 (DRF) with
an answer (i.e. sending a PMIP Binding Query Answer, PBQA) carrying
the location information. Upon receiving the PBQA, eMAG1 (DRF)
records the location of MN2 locally.
Upon the location of MN2 is determined, eMAG1 (DRF) sets up its
endpoint of a tunnel (e.g. IP in IP tunnel) to eMAG2 (DRF). And all
follow-up uplink traffic will be encapsulated by eMAG1 (DRF) and sent
to eMAG4 (DRF) in the established tunnel directly.
Before the optimized routing is established, eMAG1 could forward the
first few packets of the uplink traffic to eLMA via bi-directional
PMIP tunnel between the two as specified in RFC[5213]. In this case,
the routing of the first few packets is non-optimized, and the delay
of those packets may be a litter bit larger than the follow-up
traffic. Another alternative is that eMAG1 buffers those packets
until the optimized routing is set up. In this case, how to
determine capacity of the buffer should be carefully considered.
Upon receiving encapsulated packet in the eMAG-eMAG tunnel, the eMAG4
(DRF) needs to decapsulate the packet and forwards the uplink traffic
to MN2. As an alternative, eMAG4 (DRF) may parse the packet and
record the location of MN1. The location of MN1 can be derived from
the outer IP header of the encapsulated packet (i.e. the IP address
of the tunnel entry point).
Upon receiving downlink traffic from MN2 to MN1, eMAG4 (DRF) should
also set up its endpoint of a tunnel to eMAG1 (DRF) for the downlink
Liu, et al. Expires August 27, 2012 [Page 8]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
traffic when the location of MN1 is determined. At this moment, a
bi-directional tunnel between two eMAGs has been established for all
follow-up uplink and downlink traffic and an optimized routing for
MN1 and MN2 is set.
4.3. Handoff when Optimaized Routing is Established
MN1 may change its point of attachment from previously attached eMAG
(p-eMAG) to newly attached eMAG (n-eMAG) at any time after the
optimized routing has been established as described in section 4.2.
The routing shall still be remained optimized after handoff.
The [I-D Localized Routing for Proxy Mobile IPv6] also specifies a
method for re-establishing optimized routing after the handoff which
leverages another new trigger from LMA to both MAGs involved. The
consequence is to make the routing non-optimized during the handoff,
and optimized again after the handoff. The handoff approaches
specified here is much different from [I-D Localized Routing for
Proxy Mobile IPv6] specified approaches and may provide less latency
and jitter.
Liu, et al. Expires August 27, 2012 [Page 9]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
+---+ +--------+ +--------+ +-------+ +--------+ +---+
|MN1| | p-eMAG | | n-eMAG | | eLMA | | eMAG4 | |MN2|
+---+ +--------+ +--------+ +-------+ +--------+ +---+
| | | | | |
| | 1. Ongoing traffic | |
|<==========>|<==================================>|<=========>|
| | | | | |
| | 2.attach and PMIP Reg. | | |
|<----------------------->|<--------->| | |
| | 3.PBCI | | | |
| |<-----------| | | |
| | 4.PBCA | | | |
| |----------->| | | |
| 5. Uplink traffic | | | |
|========================>| | | |
| | +-----------------+ | | |
| | | 6.Determine the | | | |
| | | Location of MN2 | | | |
| | +-----------------+ | | |
| | | | | |
| | +--------------------------------------------+
| | | 7. Process of uplink traffic is similar |
| | | with the approaches in figure 2 |
| | +--------------------------------------------+
| | | | | |
| | | 8 . Downlink Traffic | |
| |<===================================|<==========|
| |===========>| | | |
|<========================| | | |
| | | 9. PBCI | | |
| |----------------------------------->| |
| | | | +----------------+ |
| | | | | 10. Update | |
| | | | | Location of MN1| |
| | | | +----------------+ |
| | | 11. PBCA | | |
| |<-----------------------------------| |
| | 12. Ongoing Downlink Traffic | |
|<========================|<======================|<==========|
| | | | |
Figure 3. Handoff When Optimized Routing is Established
Figure 3 illustrates approaches for handoff of MN1 from p-eMAG to
n-eMAG. During handoff, RFC[5213] specified procedures is performed
for MN1 to maintain its HNP(es) unchanged. The n-eMAG on new access
link, upon detecting MN1 on the link, assigns a new CoA for MN1 and
generates a PBU message to eLMA for updating the BCE for MN1. In
Liu, et al. Expires August 27, 2012 [Page 10]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
sequence, eLMA responses a PBA message to n-eMAG with one additional
new extension which includes the previous location of MN1 (i.e. CoA
of MN1 assigned by p-eMAG).
Further, n-eMAG (DMF) initiates an inform message (i.e. PMIP Binding
Change Inform, PBCI) to p-eMAG (DMF) with new location of MN1 (i.e.
CoA assigned by n-eMAG) based on the acquired previous location of
MN1. Sequencely, p-eMAG (DMF) updates the location of MN1 and
responses with an acknowledge message (i.e. PMIP Binding Change Ack,
PBCA) with all location information of the MN1's current
correspondent nodes (in figure3, the current correspondent node is
only MN2).
Upon uplink traffic arriving at n-eMAG instead of p-eMAG, n-eMAG
(DRF) can derive the location of MN2 locally and forwards the traffic
in an optimized way of routing (i.e. MN1->n-eMAG->eMAG4->MN2).
The most likely is that downlink traffic during the handoff is still
forwarded by eMAG4 (DRF) to p-eMAG (DRF) before location of MN1
stored in eMAG4 (DRF) locally is updated (i.e. MN2->eMAG4->p-
eMAG->MN1) and be discarded by p-eMAG (DRF).
For reducing packet loss, p-eMAG (DMF) is proposed to establish a
directional tunnel to n-eMAG (DMF) and forward any received downlink
traffic to n-eMAG (DMF) via the tunnel. Meanwhile, p-eMAG (DMF) is
also proposed to update the location of MN1 stored in eMAG4 (DRF) by
initiating a PBCI to eMAG4 (DRF) to indicate eMAG4 (DRF) to forward
follow-up downlink traffic to n-eMAG (DRF) directly: MN2->eMAG4->n-
eMAG->MN1.
4.4. Multiple eLMAs Consideration
As illustrated in figure 1, multiple eLMAs can be deployed. The most
likely is that the mobile node and its correspondent node (i.e.
another mobile node) are registered with different eLMAs. The
approaches described in subsection 4.2 and 4.3 simply assume both
mobile nodes are registered with one same eLMA (the same assumption
applied to [I-D Localized Routing for Proxy Mobile IPv6]), and this
section considers multiple eLMAs.
Liu, et al. Expires August 27, 2012 [Page 11]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Announce PA Announce PB Announce PC and PD
\ | / \ | / \ | /
\ | / \ | / \ | /
+--------+ +--------+ +--------+
| eLMA1 | | eLMA2 | | eLMA3 |
+-----+--+ +--------+ +---+----+
| _______________|
/ |
+---+----+ +----+---+
| eMAG1 | | eMAG2 |
+---+----+ +---+----+
| |
+--+-+ +-+--+
| MN1| | MN2|
+----+ +----+
Figure 4. Mobile node and its Correspondent Node are Registered with
Different eLMAs
As illustrated in figure 4, MN1 is registered with eLMA1 by eMAG1,
and MN2 is registered with eLMA3 by eMAG2 respectively. Based on
RFC[5213], only the LMA which is involved in PMIP registration for a
mobile node holds this mobile node's Binding Cache Entry. Therefore,
in figure 4, only eLMA1 holds the location information of MN1 and
only eLMA3 holds the location information of MN2.
As described in section 4.2, before establishing optimized routing
for the traffic, eMAG1 shall determine the location of MN2. In case
the location can not be determined locally, eMAG1 shall determine to
which eLMA it should send a PBQR message.
4.4.1. Determining eLMA Based on Configuration
As illustrated in figure 4, each eLMA manages a set of IPv6 prefixes
with which it uses to allocate home network prefixes or HoAs to the
MNs registered to that eLMA. For example, eLMA1 announces prefixes
PA to routing system and eLMA3 announces prefixes PC+PD.
If eMAGs could be aware of the IPv6 prefixes configurations of each
eLMA, e.g. from operator's management plane since they are in a same
administrative domain. The eMAG (DRF) can determine the
corresponding eLMA (LMF) to which it should send the PBQR, based on
the destination IPv6 address of the traffic and the configured
information.
For example, the destination IP address of the traffic from MN1 to
MN2 is MN2's HoA. Based on configuration information, eMAG1 (DRF)
can determine the HNP of MN2 is prefix PC and is managed by eLMA3.
Liu, et al. Expires August 27, 2012 [Page 12]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Therefore, eMAG1 (DRF) can determine the eLMA3 (LMF) should be
queried when it wants to determine the location of MN2.
This solution looks simple, but it depends on static configured
information on every eMAGs. If configuration of a eLMA is changed
(e.g. add a prefix PE into eLMA1's IPv6 prefix set), the most likely
is that the configured information in all eMAGs in same
administrative domain needs update. It seems like that this solution
works well for a administrative domain with small number of eMAGs.
4.4.2. Determining eLMA Based on IPv6 Hop-by-Hop Options Header
Announce PA Announce PB Announce PC and PD
\ | / \ | / \ | /
\ | / \ | / \ | /
eLMA1 eLMA2 eLMA3
+
/!\
,------- Router1-------- Router2 .|
|
|
eMAG1
eMAG1 initiates a query message (PBQR) carried in a IP
packet whose destination IP address is HoA of MN2.
The packet will be intercepted, processed and terminated by
eLMA3 who manages the prefix of the MN2's HoA based on
the mechanism of the Hop-by-Hop Option Header.
Figure 5. Determining eLMA Based on Hop-by-Hop Options Header
When constructing a PBQR message, eMAG1 can use HoA of MN2 as
destination IP address of this message and construct an appropriate
IPv6 Hop-by-Hop Option Header as extension header. The HoA of MN2 is
the destination IP address of the uplink traffic.
When IP packet which includes the PBQR message is sent into the
routing system, standard routing mechanism ensures the packet can
reach eLMA3 which manages the prefix of MN2's HoA. Depending on the
mechanism of the Hop-by-Hop Option Header, each router including
eLMA3 on the routing pass of this packet will intercept the packet
and check the Hop-by-Hop Option Header.
Based on the indication carried by the options in Hop-by-Hop Option
Header, eLMA3 determines whether the prefix of destination IP address
belongs to its management. If it does, eLMA3 shall treat itself as
destination of this message and let the LMF on it process the
message.
Liu, et al. Expires August 27, 2012 [Page 13]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
It seems like that, all common routers on the routing pass of this
packet will check the Hop-by-Hop Option Header and may cause some
delay. Another disadvantage is that it will take relative longer
time to make sure no location information of correspondent node can
not be determined (refer to section 5.1 for more details).
4.4.3. Determining eLMA Based on Interface Between eLMAs
+-----------------------------+
| eLMA2 |
| |
| eLMA1--------------> eLMA3 |
| /|\ further query |
+-----+-----------------------+
|
query |
|
eMAG1
Figure 6. Determining eLMA Based on Interface Between eLMAs
Interface between eLMAs which are located in a same administrative
domain is introduced for determining location information of a
particular mobile node.
When determining location of correspondent node, eMAG1 (DRF), in
figure 6, could simply send a PBRQ message to any random eLMA (LMF)
it considers convenient (e.g. eLMA1). The most likely is that the
eLMA (LMF) queried does not hold the relevant location information.
But the eLMA (LMF) can determine which eLMA (LMF) holds the
information (e.g. eLMA3).
For example, if IPv6 prefixes managed by each eLMA are awared of, the
eLMA1 (LMF) can determine which eLMA (LMF) should be queried further
and query it. It can be expected that the number of eLMA deployed in
a administrative domain will not be large (as illustrated in figure
1), therefore, depending on configuration is applicable.
5. CN Considerations
The assumption of section 4 is that the correspondent node is also a
mobile mode and is registered with eLMA by eMAG. Other scenarios,
such as correspondent node is a fixed node, or a mobile node but is
not registered with eLMA, are considered in this section.
Liu, et al. Expires August 27, 2012 [Page 14]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
5.1. CN Which is not Registered with eLMA
This section considers scenario that the correspondent node (e.g.
CN2 in figure 1) is a mobile node but not registered with eLMA. For
example, CN2 is registered with a legacy LMA by attaching to a legacy
MAG. For another example, CN2 just locates in common IPv6
environment.
When mobile node (MN1 in figure 1) initiates uplink traffic to
correspondent node (CN2 in figure 1), eMAG1 (DRF) to which MN1
attaches should initiate a query for determining location of CN2 as
described in section 4.2.
According to section 4.4.1, eMAG1 (DRF) can not determine to which
eLMA (LMF) it should send the query message, because CN2's prefix is
out of the management of any eLMA. In this case, eMAG1 (DRF) can
make sure no location information can be determined.
According to section 4.4.2, eMAG1 (DRF) should construct a query
message and set message's destination to IP address of CN2. The
query message will be routed to CN2 based on common routing mechanism
and no response is excepted. The eMAG1 (DRF) should wait for the
response until the related timer is timeout. Before eMAG1 (DRF) can
make sure no location information can be determined, one or more
query message may be re-sent by eMAG1 (DRF). Thus, it will take a
relative longer time to make sure no location information can be
determined.
According to section 4.4.3, eMAG1 (DRF) can send a query message to
any one of those eLMAs (LMF) and the eLMA (LMF) queried performs the
query among those eLMAs (LMF). In this case, eMAG1 (DRF) can make
sure no location information can be determined.
As described above, the failed queries are excepted and location
information of CN2 can not be determined by eMAG1 (DRF). In this
case, eMAG1 should behavior as a legacy MAG for this session and PMIP
specified routing mechanism shall be applied for the uplink traffic
(i.e. no optimized routing), e.g. MN->eMAG1->E-LMA->common
router->CN.
Of course, if the correspondent node itself is a fixed node, same
rules described above are also applicable.
5.2. Routing Optimization Considerations when CN is Fixed Node
As described above, if correspondent node is a fixed node, eMAG1 will
behavior as a legacy MAG and no optimized routing is enabled.
Liu, et al. Expires August 27, 2012 [Page 15]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Most of correspondent nodes which are fixed nodes are deployed in a
centralized manner in most deployment, e.g. CDN/IDC/Web Servers and
etc. Those fixed nodes are generally converged by a couple of access
routers, although the topology within those fixed nodes may be very
complicate, to access operator's IP bearer network which is
illustrated in figure 7. If mechanism which providing optimized
routing cannot be applied when correspondent node are fixed nodes of
these kind, effect of this mechanism will be very limited.
__________
/ CN \ ,--------.
((CDN\IDC\Web )---Access Router `. _.----------.
( Server) ) ,--' `-'' eLMA :
\___________/ \ _.-------. ,--'
'-- eMAG-----'' `---'
|
|
MN1
Figure7. Correspondent Nodes are Fixed Nodes Cause Non-optimized
Routing
Refer to figure 7, it seems like that non-optimized routing (e.g.
between MN1 and CDN) will be a problem for this deployment as
discussed in [I-D DMM Problem Statement]. For purpose of eliminating
non-optimized routing, one implementation is to replace those common
access routers in figure 7 with routers which are implemented with
Distributed Routing Function (DRF). No Distributed Mobility Function
(DMF) is needed, since nodes attached are all fixed nodes.
,-------.
,' `-.
( CDN\IDC\Web )-. _.----.
( Server ) \ ,--_.--'' `-.
\____________' AR+DRF-' `-------.
,-----------. / -. \
; Fixed User : ,' `- \
: Equipments ;---AR+DRF ----LMF eLMA :
`-----------' \ ,- ;
AR+DRF--' ,----. ;
,-----------. / `\ eMAG `--. ;
; Fixed User : / -------------' | `-----'
: Equipments ;/ |
`-----------' |
|
MN1
Figure 8. Applying Optimized Routing when Correspondent Nodes are
fixed nodes
Liu, et al. Expires August 27, 2012 [Page 16]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Additionally, one more LMF needs deployed as illustrated in figure 8.
The responsibility of that LMF is to response any received PBRQ
message with location of queried fixed node (e.g. IP address of one
of those AR+DRF). Method specified in section 4.2.2 may not be
applicable, because PBRQ will be routed to one of those AR+DRF
directly. No response will be expected, except that the AR+DRF is
also co-located with a LMF.
6. Handoff between eMAG and MAG
As illustrated in figure 1, ePMIP is deployed in PMIP domain (no
clear boundary), and belongs to a same administrative domain, e.g. a
same operator. The mobile node which is initial registered with eLMA
by attaching a eMAG may handoff to a legacy MAG and vice versa. By
supporting the handoff between eMAG and MAG , ePMIP can be deployed
in manner of incremental when assuming PMIP is well deployed.
As described above, eLMA is a legacy LMA implemented with LMF, and
eMAG is a legacy MAG implemented DAF (DRF+DMF). When a mobile node
which attaches to an eMAG handoff to a legacy MAG, the legacy MAG
will perform PMIP registration to the eLMA and establish a bi-
directional tunnel with the eLMA. In this case, PMIP routing
mechanism will be applied (i.e. no routing optimization). On the
other hand, when a mobile node which attaches to a legacy MAG handoff
to an eMAG, the eMAG will perform PMIP registration to the legacy LMA
and establish a bi-directional tunnel with the legacy LMA. In this
case, PMIP routing mechanism will also be applied (i.e. no routing
optimization).
7. Considerations for Other Implementation
As described in section 3.1, ePMIP can be implemented in many ways.
Section 3.1 also indicates one of those implementations, i.e.
deploying LMF in legacy LMA, and DAF in legacy MAG. This section
considers one alternative implementation.
7.1. One Alternative Implementation
One alternative implementation is to deploy DAF in legacy LMA, and
deploy LMF independently. When multiple LMFs are deployed,
interfaces between those LMFs are necessary as illustrated in figure
10.
Liu, et al. Expires August 27, 2012 [Page 17]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
_.---------------------.
,---'' LMF2 `--- ,
,' _..-'' ``-.._ ;
,-' LMF1 --------- LMF3 \
/ : Prefix ePMIP
/ ( area1 )( area2 )( area3 )...( arean ) | /
| ( )( )( ) ( ) ; / ( arean+1)
: ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) BG+DRF --- ( )
\ | | | / \ ( LMA )
`-----+. | _.----+--ePIMP Area-----' \ |
| `------|' | |
| | | |
MAG1 MAG2 MAG3 MAG
| |
MN1 CN1
Figure 10. One Alternative Implementation of ePMIP
For routing consideration, a clear boundary seems necessary if ePMIP
takes this kind of implementation. A set of IPv6 prefixes which are
used for allocating HNP(es) or HoA(s) to mobile nodes should be
assigned to ePMIP area and each LMA manages part of them. The eLMAs
don't announce any IPv6 prefix to routing system. Instead, a border
gateway implemented with DRF (BG+DRF) which is located at the
boundary of this ePMIP area announces those set IPv6 prefix(es) to
outside as illustrated in figure 10.
The node inside ePMIP area could be a mobile node or a fixed node.
When a correspondent node located outside of ePMIP area sends IP
traffic to a node located inside ePMIP area, traffic will be routed
to BG+DRF which announces the management of the prefix of the
traffic's destination IP address.
7.2. Optimized Routing Consideration
Consider that a mobile node (MN1) is initiated in ePMIP area and
attaches to a legacy MAG, RFC[5213] specified PMIP registration
procedures will be performed. The MAG will select a local mobility
anchor (e.g. eLMA1) for MN1 and send a PBU to it. Note that, the LMA
selected by the MAG is actually an eLMA. MAGs cannot tell the
distinguishes between LMAs and eLMAs.
After successful PMIP registration, MN1 acquires its HNP(es) and
eLMA1 manages a binding cache entry for MN1 as specified in
RFC[5213]. Further, eLMA1 (DRF) has to inform a corresponding LMF
with the HNP(es) and location information of MN1 (i.e. IP address of
eLMA1 itself). LMF will manage the mapping between HNP(es) and
location. How to determine which LMF the eLMA1 (DRF) should inform,
refer to section 7.4.
Liu, et al. Expires August 27, 2012 [Page 18]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Consider that correspondent node (CN1) of MN1 is also a mobile node
and is located in same ePMIP area (refer to section 7.3 for other
scenarios).
Upon receiving uplink traffic from MN1 to CN1 via the bi-directional
PMIP tunnel, eLMA1 (DRF) should determine whether it holds location
information of CN1 locally. If not, a corresponding LMF should be
queried by eLMA1 (DRF), and the required location (e.g. IP address
of eLMA3) should be stored by eLMA1 (DRF) locally. Upon determining
the location, eLMA1 (DRF) sets up a tunnel to eLMA3 (DRF) by using
the location of CN1 as tunnel endpoint, and forwards uplink traffic
to eLMA3 (DRF) directly.
Upon movement of MN1, a PMIP handoff from pMAG to nMAG will be
triggered. RFC[6097] provides a mechanism for LMA discovery, and
requires nMAG of a mobile node should discovery a same LMA with which
the pMAG has discovered for that mobile node. The nMAG in this draft
does not have to discover a same eLMA (i.e. eLMA1) but a best eLMA
(e.g. eLMA2) for MN1 and performs PMIP registration. The
implementation can take any method specified in RFC[6097] for
discovering the best eLMA.
The eLMA2 (DRF) should update LMF with new location information of
MN1 (e.g. IP address of eLMA2 itself) and eLMA2 (DMF) should also
inform eLMA1 with the new location. The approaches are quite similar
with those described in section 4.3.
7.3. Correspondent Node Consideration
Consider that correspondent node is located outside of ePMIP area
(could be a mobile node or a fixed node). In this case, the prefixes
of IP address of CN are not managed by ePMIP. Actually, the set of
IPv6 prefixes which are assigned to ePMIP can be configured in LMF.
In this case, when eLMA1 (DRF) queries LMF CN's location, the LMF
will response with IP address of BG+DRF. The routing will be: MN1
<-> MAG <-> eLMA <->BR+DRF <-> CN.
Consider that the correspondent node is a fixed node and is located
inside ePMIP area. It seems like that the traffic from CN to MN1
cannot be routed correctly, because CN doesn't have any idea of MN1's
location.
A simple approach is to let BG+DRF also announce the set of prefixes
which are assigned to ePMIP to routing system inside ePMIP area. In
this case, traffic will be routed to BG+DRF and further forwarded by
BG+DRF. But it seems that the BG+DRF could be overloaded easily and
routing will be no-optimal.
Liu, et al. Expires August 27, 2012 [Page 19]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Another approach is to deploy multiple routers implemented with DRF
inside ePMIP area and let them announce same set of prefix(es) which
are assigned to ePMIP to routing system (as illustrated in figure
11). In this case, the anycast mechanism is used for attract traffic
from CN and optimized routing is enabled: CN <->Access Router <->
Router+DRF <-> eLMA <-> MAG <-> MN
,--------------
/ CN `------------.
,' | LMF2 `---.
/ | _..-'' ``-.._ `.
; Access LMF1 --------- LMF3 `.
+ Router `.
| \
| \ | / Prefix ePMIP \ | / \
| \ | / \ | / \
: router+DRF router+DRF :
: / | \ / | \ | Prefix ePMIP
| / | \ / | \ | /
| | /
+ ( area1 )( area2 )( area3 )...( arean ) BG+DRF---
\ ( )( )( ) ( ) | \
\ ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) | \
` --------------------------------------------;
Figure 11. Anycast Mechanism for Attracting Traffic From CN
7.4. Location Management Consideration
As illustrated in figure 11, multiple LMFs can be deployed in ePMIP
area. When a mobile node is registered with an eLMA, the eLMA (DRF)
needs to update location of this mobile node in a corresponding LMF.
And when eLMA (DRF) want to determine location information of a
mobile node, it need to query a corresponding LMF.
Interface between those LMFs is proposed in this draft. One
preferred LMF can be configured in every specific eLMAs (DRF). If
eLMA (DRF) need to update or query location of a mobile node (or
correspondent node), it can always sends a corresponding message to
that preferred LMF. Upon receiving the message, that preferred LMF
should determine which LMF is responsible for managing the location
for that mobile (or correspondent node) and relay the message to that
determined LMF.
Many methods can be used by preferred LMF for determining to which
LMF it should relay the message. For example, Hash algorithm
(hashing the HNP(es)), DHT algorithm and etc.
Liu, et al. Expires August 27, 2012 [Page 20]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
8. Security Consideration
9. Difference with Localize Routing
10. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
11. References
11.1. Normative References
RFC5213
RFC6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6
11.2. Informative References
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Dapeng Liu
China Mobile
Jun Song
ZTE
No.68,Zijinghua Road,
Nanjing, Yuhuatai District 210012
China
Phone:
Fax:
Email: song.jun@zte.com.cn
URI:
Liu, et al. Expires August 27, 2012 [Page 21]
Internet-Draft draft-liu-dmm-pmip-based-approach-02 February 2012
Wen Luo
ZTE
No.68,Zijinghua Road
Nanjing, Yuhuatai District 210012
China
Phone:
Fax:
Email: luo.wen@zte.com.cn
URI:
Liu, et al. Expires August 27, 2012 [Page 22]
