Internet DRAFT - draft-xue-dmm-routing-optimization
draft-xue-dmm-routing-optimization
DMM K. Xue
Internet-Draft L. Li
Intended status: Standards Track P. Hong
Expires: December 22, 2013 USTC
P. McCann
Huawei
June 20, 2013
Routing optimization in DMM
draft-xue-dmm-routing-optimization-02.txt
Abstract
This draft proposes a PMIP-based routing optimization method in
distributed anchor architecture. The anchor of the mobile node is
able to communicate with the anchor of corresponding node directly
using optimized routing. In this draft, there are two modes for the
setup of routing optimization: the direct mode and the relay mode.
The difference between them lies in that whether the routing
optimization is set up directly or under the assistance of a third
anchor. The situation that Communication Node(CN) is a fixed
terminal or a content server is also considered and 3 solutions are
provided correspondingly. The method proposed in this draft can
reduce the delay and save signaling overhead in the current scheme.
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 December 22, 2013.
Xue, et al. Expires December 22, 2013 [Page 1]
Internet-Draft Routing optimization in DMM June 2013
Copyright Notice
Copyright (c) 2013 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Long Routing in Current Distributed Anchor Scenario . . . 4
3.2. Signaling Overhead Analysis . . . . . . . . . . . . . . . 5
4. The Function of D-MAG . . . . . . . . . . . . . . . . . . . . 6
5. Overview of the Proposed Protocol . . . . . . . . . . . . . . 6
5.1. The Direct Mode . . . . . . . . . . . . . . . . . . . . . 7
5.2. The Relay Mode . . . . . . . . . . . . . . . . . . . . . 9
6. CN considerations . . . . . . . . . . . . . . . . . . . . . . 11
6.1. The Direct Mode . . . . . . . . . . . . . . . . . . . . . 11
6.2. The Relay Mode . . . . . . . . . . . . . . . . . . . . . 13
6.2.1. P-D-MAG as A Relay . . . . . . . . . . . . . . . . . 13
6.2.2. F-D-MAG as A Relay . . . . . . . . . . . . . . . . . 14
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Enhanced Proxy Binding Update Message . . . . . . . . . . 16
7.2. Enhanced Proxy Binding Acknowledgement Message . . . . . 17
Xue, et al. Expires December 22, 2013 [Page 2]
Internet-Draft Routing optimization in DMM June 2013
7.3. Mobility option . . . . . . . . . . . . . . . . . . . . . 18
7.3.1. Corresponding node address option . . . . . . . . . . 18
7.3.2. D-MAG address option . . . . . . . . . . . . . . . . 19
7.3.3. Former tunnels information option . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 22
11.2. Informative Reference . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
The original centralized mobility management methods (such as the
Mobile IPv6, 3GPP EPS etc.) have many drawbacks including the long
routing problem, non- optimal architecture, heavy signaling overhead
etc. Therefore, distributed mobility managements are discussed and
studied widely.
In the current research of distributed mobility management (DMM), the
method that the anchor undertakes the role of both LMA and MAG
simultaneously is called the fully distributed mobility management
scheme. The distributed anchor
[I-D.bernardos-dmm-distributed-anchoring] is one of the fully
distributed mobility management methods. The distributed anchor
means that the newly generated communication sessions are anchored by
mobile node's current anchor. For example, when the mobile node
moves from one anchor to another anchor (handover), the communication
sessions generated after the handover are anchored by the new anchor.
Under the current distributed anchor schemes, when mobile node moves
to a new anchor, the former flow is forwarded by the former anchor to
the new anchor. Therefore, the long routing problem still exists.
In the existing work of PMIPv6 as [I-D.ietf-netext-pmip-lr], the
communication between LMAs is not involved since it assumes the
mobility management function should be accomplished under the
centralized architecture. However, in the distributed architecture
aforementioned, each distributed anchor could be regarded as the LMA
for the communication session generated on it. Therefore, it is
necessary to have communications between distributed anchors but
current schemes in PMIPv6 do not support such scenario. In this
draft, we propose a routing optimization scheme in distributed anchor
scenario based on PMIPv6 to solve the non-optimization routing
problem in the current work.
2. Conventions and Terminology
Xue, et al. Expires December 22, 2013 [Page 3]
Internet-Draft Routing optimization in DMM June 2013
2.1. 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 [RFC2119].
2.2. Terminology
The following terms are defined and used in this document:
Distributed MAG (D-MAG). It is the distributed anchor in our method
and it provides mobility management function.
First D-MAG (F-D-MAG). It is the first hop D-MAG where the sessions
firstly start. F-D-MAG assigns IPv6 prefixes and provides mobility
management function for the registered mobile node.
Previous D-MAG (P-D-MAG). It is the D-MAG that mobile node attaches
before handover.
New D-MAG (N-D-MAG). It is the D-MAG that mobile node attaches
currently.
Enhanced Proxy Binding Update (ePBU). It is the enhanced PBU
designed for optimized routing tunnel setup, state update, etc. It
contains Routing Optimization Indicator (ROI) as a 2-bit state flag
Enhanced Proxy Binding Acknowledge (ePBA). It is the enhanced PBA
designed for optimized routing tunnel setup, state update, etc. It
contains Routing Optimization Indicator (ROI) as a 2-bit state flag
3. Motivations
3.1. Long Routing in Current Distributed Anchor Scenario
In current DMM approaches, when the mobile node moves to a new
anchor, the communication session generated before MUST be forwarded
to the new D-MAG by the original anchor. Therefore, there is still a
long routing problem in such schemes and it MAY bring in delay and
jitter. As Figure.1 shows, in the current approaches, when the
mobile node (MN) moves from P-Anchor(the previous anchor) to
N-Anchor(the new anchor), the communication session generated before
handover (On P-Anchor) will be forwarded to the new anchor (N-Anchor
in Figure.1) by the previous anchor (P-Anchor). The problem would
become more severe when the mobile node (MN) moves across multiple
anchors with the original communication sessions still going. It is
because the distance between the original anchor and the new anchor
MAY be rather long for a certain communication session.
Xue, et al. Expires December 22, 2013 [Page 4]
Internet-Draft Routing optimization in DMM June 2013
+----------+ +----------+
| CN | | CN |
| | | |
+----/-----+ +----/-----+
| |
| _,,,.-----..,,|
,-|` |``-.
/ | Core Network | \
\ | | /
'-|, |_,-'
Old session | ``''''----'''`| New session
| |
| |
+----|-----+ +----------+
| +-----------+ |
| P-Anchor | || N-Anchor|
+----------+ +|---|-----+
| |
| |
+------+
---Move--> | MN |
+------+
Figure 1: Data flow in the current DMM approaches
3.2. Signaling Overhead Analysis
In this section, the analysis of the signaling overhead by simply
adopting current routing optimization schemes in PMIPv6 is given
briefly.
The routing optimization or local routing schemes in current PMIPv6
MAY bring in much more signaling overhead when applied in the
distributed anchor scenario. The procedure of local routing is
showed in Figure.2. The LMA (Local Mobility Anchor) of MN sends
routing optimization trigger to the LMA of CN to start the routing
optimization. The LMA of MN also needs to send the address of MN's
MAG to the LMA of CN. Afterwards, the LMA of CN sends routing
optimization initiation command to the MAG of CN. Then the MAG of CN
sets up tunnel with the MAG of MN and the routing optimization is
established [I-D.loureiro-netext-pmipv6-ro].
Xue, et al. Expires December 22, 2013 [Page 5]
Internet-Draft Routing optimization in DMM June 2013
+-------+ +-------+ +-------+ +-------+
|MAG(MN)| |LMA(MN)| |LMA(CN)| |MAG(CN)|
+---/---+ +---/---+ +---/---+ +---/---+
| | | |
| | | |
| |-1.RO Trigger----->| |
| | | |
| | |-2.RO Init----->|
| | | |
|<-------------3.RO Setup----------------------|
| | | |
|--------------4.RO Setup Ack----------------->|
| | | |
| | |<-5.RO Init Ack-|
| | | |
| |<-6.RO Trigger Ack-| |
| | | |
Figure 2: The procedure of local routing in PMIPv6
If it is adopted in the distributed anchor scenario, each anchor
could be regarded as a LMA for the communication sessions generated
on it. The mobile node MAY have multiple communication sessions
generated on different anchors. When the mobile node moves, each
anchor of MN needs to send messages to each CN's anchor. Since the
mobile node moves across multiple anchors, there would be multiple
LMAs of MN and multiple LMAs of CN. Therefore, the signaling
overhead is large. Secondly, these signalings are distributed across
the Internet, so the delay would be longer for all of these messages.
4. The Function of D-MAG
D-MAG(Distributed MAG) is the distributed anchor in this draft. It
is in charge of the prefix allocation and the mobility management for
a specific communication session generated on it. It runs the
functionalities of PMIP's MAG and LMA based on communication
sessions. It is a logical entity that could be integrated into the
access router.
5. Overview of the Proposed Protocol
We propose two solutions to optimize the routing. The first solution
is the Direct Mode which means that the routing optimization is set
up between the MN's D-MAG and CN's D-MAG by exchanging messages
between the two entities directly. The second solution is the Relay
Mode which means that the routing optimization between the MN's D-MAG
and CN's D-MAG SHALL be set up under the assistance of a third D-MAG.
There are two stages in our protocol. The first stage is the
initiation of the routing optimization and the second stage is the
maintenance of the routing optimization. The initiation is the setup
procedure of the routing optimization when mobile node moves to a new
Xue, et al. Expires December 22, 2013 [Page 6]
Internet-Draft Routing optimization in DMM June 2013
anchor from the first anchor. The maintenance stage is the
maintenance of routing optimization when the mobile node moves from
the previous anchor to the new anchor after the setup of routing
optimization.
5.1. The Direct Mode
(a)Initiation of Routing Optimization
Figure 3 illustrates the initiation of routing optimization. The
original communication session for MN is generated in F-D-MAG and
uses the prefix it assigns. The F-D-MAG is the first hop D-MAG where
the session firstly starts.
When MN moves to its N-D-MAG, MN's N-D-MAG sends enhanced PBU (ePBU)
with ROI (Routing Optimization Indicator) = 01 to its F-D-MAG to
inform that the prefixes it assigns are still being used. ePBU is an
enhanced proxy binding update (ePBU) with a 2-bit state flag ROI.
This message is OPTIONAL because there is already a prefix lifetime
extension message in the protocol of PMIPv6 as [RFC5213].
MN's N-D-MAG sends ePBU with ROI= 10 to CN's F-D-MAG to query the
address of CN's current D-MAG. We MAY assume the address of CN's
F-D-MAG is known to MN's N-D-MAG. Even if it is unknown to MN's
N-D-MAG, the ePBU to CN's F-D-MAG could be delivered in the following
way. Firstly, MN's D-MAG intercepts the first uplink packet of MN
and gets the address of CN which is the destination address of the
packet. Then, it sends ePBU to the address of CN and the ePBU would
be intercepted by CN's F-D-MAG. Afterwards, CN's F-D-MAG would
recognize the ePBU and sends back enhanced PBA (ePBA) which includes
the address of CN's current D-MAG.
MN's N-D-MAG sends ePBU with ROI=11 to CN's current D-MAG to execute
the routing optimization. Under this circumstance, a bi-directional
tunnel will be established between MN's N-D-MAG and CN's D-MAG.
Xue, et al. Expires December 22, 2013 [Page 7]
Internet-Draft Routing optimization in DMM June 2013
+------+ +---------+ +---------++---------++---------+ +------+
| MN | | N-D-MAG | | F-D-MAG || F-D-MAG || D-MAG | | CN |
| | | (MN) | | (MN) || (CN) || (CN) | | |
+--/---+ +----/----+ +----/----++----/----++----/----+ +--/---+
| | | | | |
|<-1.Attach-| | | | |
| /RS | | | | |
| 2.Registration | | | |
| | | | | |
| |-3.ePBU(ROI)->| | | |
| | | | | |
| |<-4.ePBA(ROI)-| | | |
| | | | | |
| |-----5.ePBU(ROI)-------->| | |
| | | | | |
| |<----6.ePBA(ROI)---------| | |
| | | | | |
| |-----------7.ePBU(ROI)------------->| |
| | | | | |
| |<----------8.ePBA(ROI)--------------| |
| | | | | |
|<-9.RA-----| | | | |
| | | | | |
|<-10A.IP-->|<---------10B.IP Packet------------>|<-10A.IP->|
| packet | | | | packet |
Figure 3: The initiation of routing optimization for DM
(b)Maintenance of routing optimization
Figure 4 illustrates procedure of the maintenance for routing
optimization
When MN moves from previous D-MAG(P-D-MAG) to another new D-MAG
(N-D-MAG in Figure 4), N-D-MAG sends ePBU with ROI = 01 to F-D-MAG in
order to announce the prefixes that F-D-MAG assigns are still being
used. It is also OPTIONAL and the reason is the same with that in
section 5.1(a).
N-D-MAG sends ePBU with ROI=00 to P-D-MAG to request former tunnel
information on P-D-MAG. The tunnel information contains all the
addresses of CNs' current D-MAGs. P-D-MAG sends back ePBA with
ROI=00 which includes the former tunnel information. The mobile node
MAY move across multiple D-MAGs, therefore, it could have multiple
routing optimization tunnels on P-D-MAG. The information of all the
tunnels could be obtained through one exchange of message (message 6
and 7 in Figure 4). In this way, the signaling overhead mentioned in
Section 3.2 can be reduced. The former tunnels on P-D-MAG could be
deleted explicitly through the exchange of ePBU/ePBA between N-D-MAG
and P-D-MAG, or they would be deleted upon timer expiration.
Then N-D-MAG of MN sends ePBU with ROI=11 to each CN's D-MAG of CN to
maintain routing optimization. Under this circumstance, a bi-
directional tunnel would be established between the N-D-MAG(MN) and
each D-MAG(CN). Consequently, the routing optimization could be
continued.
Xue, et al. Expires December 22, 2013 [Page 8]
Internet-Draft Routing optimization in DMM June 2013
+------+ +---------+ +---------++---------++---------+ +------+
| MN | | N-D-MAG | | F-D-MAG || P-D-MAG || D-MAG | | CN |
| | | (MN) | | (MN) || (MN) || (CN) | | |
+--/---+ +----/----+ +----/----++----/----++----/----+ +--/---+
|<----------1A.IP packet------------->|<-1B.IP-->|<-1C.IP-->|
|<-2.Attach-| | | packet | packet |
| /RS | | | | |
| 3.Registration | | | |
| | | | | |
| |-4.ePBU(ROI)->| | | |
| | | | | |
| |<-5.ePBA(ROI)-| | | |
| | | | | |
| |-----6.ePBU(ROI)-------->| | |
| | | | | |
| |<----7.ePBA(ROI)---------| | |
| | | | | |
| |-----------8.ePBU(ROI)------------->| |
| | | | | |
| |<----------9.ePBA(ROI)--------------| |
| | | | | |
|<-10.RA----| | | | |
| | | | | |
|<-11A.IP-->|<---------11B.IP packet------------>|<-11A.IP->|
| packet | | | | packet |
Figure 4: The maintenance of routing optimization for direct mode
5.2. The Relay Mode
(a)Initiation of routing optimization
In relay mode, the initiation of routing optimization is the same
with that in the direct mode described in section 5.1(a).
(b)Maintenance of routing optimization
Figure 5 illustrates the procedure of maintenance stage for relay
mode.
Xue, et al. Expires December 22, 2013 [Page 9]
Internet-Draft Routing optimization in DMM June 2013
+------+ +---------+ +---------++---------++---------+ +-----+
| MN | | N-D-MAG | | F-D-MAG || P-D-MAG || D-MAG | | CN |
| | | (MN) | | (MN) || (MN) || (CN) | | |
+--/---+ +----/----+ +----/----++----/----++----/----+ +--/--+
|<----------1A.IP packet------------->|<-1B.IP-->|<-1C.IP-->|
|<-2.Attach-| | | packet | packet |
| /RS | | | | |
| 3.Registration | | | |
| | | | | |
| |-4.ePBU(ROI)->| | | |
| | | | | |
| |<-5.ePBA(ROI)-| | | |
| | | | | |
| |-----6.ePBU(ROI)-------->| | |
| | | |-7.ePBU-->| |
| | | | (ROI) | |
| | | |<-8.ePBA--| |
| | | | (ROI) | |
| |<----9.ePBA(ROI)---------| | |
| | | | | |
|<-10.RA----| | | | |
| | | | | |
|<-11A.IP-->|<---------11B.IP Packet------------>|<-11A.IP->|
| packet | | | | packet |
Figure 5: The maintenance of routing optimization for relay mode
When MN moves from previous D-MAG(P-D-MAG) to another new
D-MAG(N-D-MAG), namely the N-D-MAG in Figure 5, N-D-MAG sends ePBU
with ROI = 01 to F-D-MAG in order to announce the prefixes that
F-D-MAG assigns are still being used. It is also OPTIONAL and the
reason is the same with that in section 5.1(a).
N-D-MAG of MN sends ePBU with ROI=00 to P-D-MAG of MN to request the
context transfer of routing optimization.
P-D-MAG of MN sends ePBU with ROI=11 to each D-MAG of CN to maintain
routing optimization. P-D-MAG of MN works as a relay for the request
of routing optimization maintenance.
Finally, P-D-MAG of MN sends back the ePBA to MN's N-D-MAG. The ePBA
contains the address of CN's D-MAG. Therefore, the data could be
transmitted using optimized routing.
Xue, et al. Expires December 22, 2013 [Page 10]
Internet-Draft Routing optimization in DMM June 2013
When there are multiple tunnels established in the P-D-MAG, only one
pair of ePBU/ePBA (message 6 and 9) exchange between the N-D-MAG (MN)
and P-D-MAG (MN) is needed to acquire all the tunnel information. In
this way, we save the signaling overhead. Besides, the message
querying for the tunnel information from N-D-MAG to P-D-MAG does not
need to be delivered through the Internet, which would reduce the
signaling delay than querying from the F-D-MAG of CN over the
Internet.
6. CN considerations
CN could also be a fixed terminal or a content server and it is
capable to set up tunnels with the MN's D-MAG. For such CN, we also
provide two modes, the direct mode and the relay mode. Likewise,
there are also two stages. The first one is the initiation stage and
the other one is the maintenance stage. This consideration requires
CN to support the ability of tunnel setup like exchanging message
with D-MAG.
6.1. The Direct Mode
(a) Initiation of routing optimization
+------+ +---------+ +---------+ +-----+
| MN | | N-D-MAG | | F-D-MAG | | CN |
| | | (MN) | | (MN) | | |
+--/---+ +----/----+ +----/----+ +--/--+
| | | |
|<-1.Attach-| | |
| /RS | | |
| 2.Registration | |
| | | |
| |-3.ePBU(ROI)->| |
| | | |
| |<-4.ePBA(ROI)-| |
| | | |
| |-----5.ePBU(ROI)------->|
| | | |
| |<----6.ePBA(ROI)--------|
| | | |
|<-7.RA-----| | |
| | | |
|<--8A.IP-->|<---8B.IP packet------->|
| packet | | |
Figure 6: The initiation stage for direct mode
Xue, et al. Expires December 22, 2013 [Page 11]
Internet-Draft Routing optimization in DMM June 2013
Figure 6 illustrates the initiation stage for these special CNs in
the direct mode.
The original session is generated in F-D-MAG and uses the prefixes it
assigns. When MN moves, N-D-MAG sends ePBU (set ROI = 01) to F-D-MAG
to inform that the prefixes it assigns are still being used. This
step is optional and the reason is the same with that in section
5.1(a).
N-D-MAG sends ePBU (set ROI = 11) to all CNs to inform of the
execution of routing optimization. Under this circumstance, a bi-
directional tunnel will be established between N-D-MAG and CN.
(b) Maintenance of routing optimization
+------+ +---------+ +---------++---------+ +-----+
| MN | | N-D-MAG | | F-D-MAG || P-D-MAG | | CN |
| | | (MN) | | (MN) || (MN) | | |
+--/---+ +----/----+ +----/----++----/----+ +--/--+
|<----------1A.IP packet------------->|<-1B.IP-->|
|<-2.Attach-| | | packet |
| /RS | | | |
| 3.Registration | | |
| | | | |
| |-4.ePBU(ROI)->| | |
| | | | |
| |<-5.ePBA(ROI)-| | |
| | | | |
| |-----6.ePBU(ROI)-------->| |
| | | | |
| |<----7.ePBA(ROI)---------| |
| | | | |
| |----------8.ePBU(ROI)-------------->|
| |<---------9.ePBA(ROI)---------------|
|<-10.RA----| | | |
| | | | |
|<-11A.IP-->|<---------11B.IP Packet------------>|
| packet | | | |
Figure 7: The maintenance stage for direct mode
Figure 7 illustrates the maintenance stage for these special CNs in
direct mode.
The original session is generated in F-D-MAG and uses the prefixes
F-D-MAG assigns.
Xue, et al. Expires December 22, 2013 [Page 12]
Internet-Draft Routing optimization in DMM June 2013
When MN moves from P-D-MAG to N-D-MAG, N-D-MAG sends ePBU (set ROI =
01) to F-D-MAG to inform that the prefixes it assigns are still being
used. This step is optional and the reason is the same with that in
section 5.1(a).
N-D-MAG optionally sends ePBU (set ROI = 00) to P-D-MAG to delete all
the former tunnels related to that MN explicitly. For multiple
tunnels related to the MN，only one pair of ePBU/ePBA is
required.
N-D-MAG sends ePBU (set ROI = 11) to all CNs to inform of the
execution of routing optimization. Under this circumstance, a bi-
directional tunnel will be established between N-D-MAG and CNs.
6.2. The Relay Mode
There are two types of relays, the first type is the P-D-MAG relay
and the other one is the F-D-MAG relay. The difference lies in that
the routing optimization request is relayed by different D-MAGs.
6.2.1. P-D-MAG as A Relay
+------+ +---------+ +---------++---------+ +-----+
| MN | | N-D-MAG | | F-D-MAG || P-D-MAG | | CN |
| | | (MN) | | (MN) || (MN) | | |
+--/---+ +----/----+ +----/----++----/----+ +--/--+
|<----------1A.IP packet------------->|<-1B.IP-->|
|<-2.Attach-| | | packet |
| /RS | | | |
| 3.Registration | | |
| | | | |
| |-4.ePBU(ROI)->| | |
| | | | |
| |<-5.ePBA(ROI)-| | |
| | | | |
| |-----6.ePBU(ROI)-------->| |
| | | |-7.ePBU-->|
| | | | (ROI) |
| | | | |
| | | |<-8.ePBA--|
| |<----9.ePBA(ROI)---------| (ROI) |
|<-10.RA----| | | |
| | | | |
|<-11A.IP-->|<---------11B.IP Packet------------>|
| packet | | | |
Xue, et al. Expires December 22, 2013 [Page 13]
Internet-Draft Routing optimization in DMM June 2013
Figure 8: The maintenance stage for P-D-MAG relay.
Like the relay mode described in section 5.2, the P-D-MAG works as a
relay in the stage of routing optimization maintenance.
(a) Initiation of routing optimization
The initiation stage is the same with that in direct mode of section
6.1(a).
(b) Maintenance of routing optimization
Figure 8 illustrates the procedure of maintenance stage for P-D-MAG
relay.
When MN moves, N-D-MAG sends ePBU with ROI=01 to F-D-MAG to inform
that the prefixes it assigns are still being used. This step is
optional and the reason is the same with that in section 5.1(a).
N-D-MAG sends ePBU to P-D-MAG with ROI=00 to request the transferring
of former tunnels. P-D-MAG sends ePBU with ROI = 11 to CNs to inform
of the execution of routing optimization. The address of N-D-MAG is
included in this ePBU (message 7). In this way, P-D-MAG works as a
relay. P-D-MAG deletes the former tunnels and sends ePBA with ROI =
11 back to N-D-MAG. Under this circumstance, a bi-directional tunnel
will be established between N-D-MAG and CNs and data is transmitted
in optimized routing.
6.2.2. F-D-MAG as A Relay
In this section, the F-D-MAG works as the relay for both the
initiation and maintenance stage of routing optimization.
(a) Initiation of routing optimization
Xue, et al. Expires December 22, 2013 [Page 14]
Internet-Draft Routing optimization in DMM June 2013
+------+ +---------+ +---------+ +-----+
| MN | | N-D-MAG | | F-D-MAG | | CN |
| | | (MN) | | (MN) | | |
+--/---+ +----/----+ +----/----+ +--/--+
| | | |
|<-1.Attach-| | |
| /RS | | |
| 2.Registration | |
| |-3.ePBU(ROI)->| |
| | | |
| | |-4.ePBU->|
| | | (ROI) |
| | | |
| | |<-5.ePBA-|
| |<-6.ePBA(ROI)-| (ROI) |
|<-7.RA-----| | |
| | | |
|<--8A.IP-->|<---8B.IP packet------->|
| packet | | |
Figure 9: The initiation stage of F-D-MAG relay
Figure 9 illustrates the initiation stage of F-D-MAG relay.
The original session is generated in F-D-MAG and uses the prefixes
F-D-MAG assigns. When MN moves, N-D-MAG sends ePBU with ROI = 01 to
F-D-MAG to inform that the prefixes it assigns are still being used
and that the Routing Optimization Communication mode is used.
F-D-MAG sends ePBU with set ROI = 11 to CN to inform the execution of
routing optimization. In this message (message 4), it tells CN the
address of N-D-MAG which is the new care of address of MN. In this
way, F-D-MAG works as a relay for the request of routing optimization
for N-D-MAG. Afterwards, the data could be transmitted between
N-D-MAG and CN using optimized routing.
(b) Maintenance of routing optimization
Figure 10 illustrates the maintenance stage when F-D-MAG works as a
relay. When MN moves from P-D-MAG to N-D-MAG, N-D-MAG sends ePBU
with ROI =01 to F-D-MAG to inform that the prefixes it assigns are
still being used and inform to keep using the Routing Optimization
Communication mode.
Xue, et al. Expires December 22, 2013 [Page 15]
Internet-Draft Routing optimization in DMM June 2013
+------+ +---------+ +---------++---------+ +-----+
| MN | | N-D-MAG | | F-D-MAG || P-D-MAG | | CN |
| | | (MN) | | (MN) || (MN) | | |
+--/---+ +----/----+ +----/----++----/----+ +--/--+
|<----------1A.IP packet------------->|<-1B.IP-->|
|<-2.Attach-| | | packet |
| /RS | | | |
| 3.Registration | | |
| |-4.ePBU(ROI)->| | |
| | |----5.ePBU(ROI)----->|
| | |<---6.ePBA(ROI)------|
| |<-7.ePBA(ROI)-| | |
| | | | |
|<-10.RA----| | | |
| |-----9.ePBU(ROI)-------->| |
| |<---10.ePBA(ROI)---------| |
| | | | |
| | | | |
|<-11A.IP-->|<---------11B.IP Packet------------>|
| packet | | | |
Figure 10: The maintenance stage for F-D-MAG relay
F-D-MAG sends ePBU with set ROI = 11 to CN to inform the execution of
routing optimization. In this message (message 5), it tells CN the
address of N-D-MAG which is the new care of address of MN. In this
way, F-D-MAG works as a relay for the request of routing optimization
for N-D-MAG.
N-D-MAG optionally informs P-D-MAG to delete the former tunnel
explicitly or wait upon timer expiration. For multiple sessions
related to the MN，only one pair of ePBU/ePBA is required. So
it MAY save the signaling overhead.
7. Message Format
7.1. Enhanced Proxy Binding Update Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|ROI| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The enhanced PBU (ePBU) is the original proxy binding update added
with 2-bit ROI state flag.
ROI:
Xue, et al. Expires December 22, 2013 [Page 16]
Internet-Draft Routing optimization in DMM June 2013
2-bit state flag.
Mobility options:
A variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field contains
zero or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2 of [RFC6275]. The
distributed mobile access gateway MUST ignore and skip any options
that it does not understand.
As per this specification, the following mobility options are valid
in an Enhanced Proxy Binding Update message. These options can be
present in the message in any order. There cannot be more than one
instance of any of the following options:
Corresponding node's address option
D-MAG address option
Former tunnels information option
7.2. Enhanced Proxy Binding Acknowledgement Message
The enhanced PBA (ePBA) is the original proxy binding acknowledgement
added with 2-bit ROI state flag.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|ROI| Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ROI:
2-bit state flag.
Mobility options:
Xue, et al. Expires December 22, 2013 [Page 17]
Internet-Draft Routing optimization in DMM June 2013
A variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field contains
zero or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2 of [RFC6275]. The
distributed mobile access gateway MUST ignore and skip any options
that it does not understand.
As per this specification, the following mobility options are valid
in an Enhanced Proxy Binding Acknowledgement message. These options
can be present in the message in any order. There cannot be more
than one instance of any of the following options:
Corresponding node address option
D-MAG address option
Former tunnels information option
7.3. Mobility option
7.3.1. Corresponding node address option
A new option, corresponding node address option is defined for use
with the Enhanced Proxy Binding Update and Enhanced Proxy Binding
Acknowledgement messages exchanged between the distributed mobile
access gateways. This option is used for exchanging the
corresponding node's address.
The format of the corresponding node address option is shown below.
Based on the size of the identifier, the option MUST be aligned
appropriately, as per mobility option alignment requirements
specified in [RFC6275].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Corresponding Node's Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Xue, et al. Expires December 22, 2013 [Page 18]
Internet-Draft Routing optimization in DMM June 2013
Approval of new corresponding node address option type value is to be
made through IANA Expert Review.
Length:
8-bit unsigned integer, representing the length in octets of the
mobility option, not including the Option Type and Option Length
fields.
Corresponding Node's Address:
A variable length field containing the corresponding node's address.
7.3.2. D-MAG address option
A new option, D-MAG address option is defined for use with the
Enhanced Proxy Binding Acknowledgement messages exchanged between the
distributed mobile access gateways. This option is used for
exchanging current D-MAG address of the corresponding node.
The format of the D-MAG address option is shown below. Based on the
size of the identifier, the option MUST be aligned appropriately, as
per mobility option alignment requirements specified in [RFC6275].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ D-MAG's Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Approval of new D-MAG address option value is to be made through IANA
Expert Review.
Length:
8-bit unsigned integer, representing the length in octets of the
mobility option, not including the Option Type and Option Length
fields.
D-MAG's Address:
Xue, et al. Expires December 22, 2013 [Page 19]
Internet-Draft Routing optimization in DMM June 2013
A variable length field containing the D-MAG's address.
7.3.3. Former tunnels information option
A new option, former tunnels information option is defined for use
with the Enhanced Proxy Binding Update and Enhanced Proxy Binding
Acknowledgement messages exchanged between the distributed mobile
access gateways. This option is used for exchanging the information
of former tunnels.
The format of the former tunnels information option is shown below.
Based on the size of the identifier, the option MUST be aligned
appropriately, as per mobility option alignment requirements
specified in [RFC6275].
Type:
Approval of former tunnels information option type value is to be
made through IANA Expert Review.
Length:
8-bit unsigned integer, representing the length in octets of the
mobility option, not including the Option Type and Option Length
fields. This field can also indicate the number of former tunnels
listed in the option.
The Destination Address of The Xth Tunnel:
It indicates the address of the Xth tunnel.
The SPI value of The Xth Tunnel:
It indicates the SPI value of the Xth tunnel.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| The Destination Address of The 1st Tunnel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| The SPI value of The 1st Tunnel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| The Destination Address of The 2nd Tunnel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| The SPI value of The 2nd Tunnel |
Xue, et al. Expires December 22, 2013 [Page 20]
Internet-Draft Routing optimization in DMM June 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....... |
. ....... .
. ....... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. Security Considerations
Security threats for routing optimization in network-based
distributed mobility management comprise the danger of unauthorized
set up or redirect of an established forwarding path by a malicious
node. Signaling messages of this protocol between D-MAGs must be
authenticated by means of IPsec [RFC4301].
Protection of signaling messages between D-MAGs uses the mechanisms
of Encapsulating Security Payload (ESP) [RFC4301] in transport mode
with mandatory data origin authentication by means of a non-null
payload authentication algorithm. The use of encryption is optional.
In particular, if the network which interconnects two D-MAGs is not
trusted, the use of encryption is recommended to support
confidentiality protection between MAGs respectively.
9. IANA Considerations
This document defines three new Mobility Header options, the
Corresponding Node Address option, the D-MAG Address option, the
Former Tunnels Information option. These options are described in
Section 7.3 The new Mobility Header Type values for the ePBU/ePBA
should be allocated and the approval of new type values is to be made
through IANA Expert Review.
The Corresponding Node Address option, defined in Section 7.3.1, is
used to exchange Corresponding Node Address between distributed
mobile access gateways. The approval of new type value is to be made
through IANA Expert Review.
The D-MAG Address option, defined in Section 7.3.2, is used to
exchange the current D-MAG address of the corresponding node between
distributed mobile access gateways. The approval of new type value
is to be made through IANA Expert Review.
The Former Tunnels Information option, defined in Section 7.3.3, is
used to exchange Former Tunnels Information between distributed
mobile access gateways. The approval of new type value is to be made
through IANA Expert Review.
Xue, et al. Expires December 22, 2013 [Page 21]
Internet-Draft Routing optimization in DMM June 2013
This document also creates a 2-bit status flag in the Proxy Binding
Update/Proxy Binding Acknowledgement message called the "Routing
Optimization Indicator" in Section 7.
10. Acknowledgements
The authors would like to specially thank Peter J. McCann for his
thorough reviews of this document.The authors would also like to
thank Lei Zhu, Ning He and Dan Ni for all the discussions on this
topic.
11. References
11.1. Normative Reference
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
11.2. Informative Reference
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos, C. and J. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-02
(work in progress), April 2013.
[I-D.chan-dmm-architecture]
Chan, A., "A architecture of distributed mobility
management using mip and pmip", draft-chan-dmm-
architecture-00 (work in progress), March 2012.
[I-D.ietf-netext-pmip-lr]
Krishnan, S., Koodli, R., Loureiro, P., Wu, W., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6", draft-
ietf-netext-pmip-lr-10 (work in progress), May 2012.
[I-D.loureiro-netext-pmipv6-ro]
Loureiro, P. and M. Liebsch, "Proxy Mobile IPv6 Localized
Routing", draft-loureiro-netext-pmipv6-ro-02 (work in
progress), March 2010.
Authors' Addresses
Xue, et al. Expires December 22, 2013 [Page 22]
Internet-Draft Routing optimization in DMM June 2013
Kaiping Xue
USTC
Room 305, EEIS Department, USTC West Campus
Shushan District, Hefei , Anhui 230027
P. R. China
Phone: +86-551-3601334
Email: kpxue@ustc.edu.cn
Lin Li
USTC
Room 305, EEIS Department, USTC West Campus
Shushan District, Hefei , Anhui 230027
P. R. China
Phone: +86-551-3601334
Email: linl@mail.ustc.edu.cn
Peilin Hong
USTC
Room 305, EEIS Department, USTC West Campus
Shushan Distric, Hefei , Anhui 230027
P. R. China
Phone: +86-551-3601334
Email: plhong@ustc.edu.cn
Peter J. McCann
Huawei
400 Crossing Blvd, 2nd Floor
Bridgewater , NJ 08807
USA
Phone: +1-908-541-3563
Email: peter.mccann@huawei.com
Xue, et al. Expires December 22, 2013 [Page 23]
