Internet DRAFT - draft-liu-dmm-dynamic-anchor-discussion
draft-liu-dmm-dynamic-anchor-discussion
Network Working Group D. Liu
Internet-Draft H. Deng
Intended status: Standards Track China Mobile
Expires: September 6, 2012 W. Luo
ZTE
March 5, 2012
DMM Dynamic Anchor Discussion
draft-liu-dmm-dynamic-anchor-discussion-00
Abstract
Distributed mobility management aims to distribute the mobility
anchor to the access network level to avoid the centralized mobility
anchor problem. By distributing the mobility anchor, the traffic can
be distributed in an optimal way. There are many different proposals
for DMM solution, one of those types of solution is called "dynamic
anchor". This document analyses the limitations of current dynamic
anchor solution and discusses the possible solution to overcome those
limitations.
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 September 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Liu, et al. Expires September 6, 2012 [Page 1]
Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Problem of dynamic anchor and potential solution . . . . . . . 3
1.1. Active session managment . . . . . . . . . . . . . . . . . 3
1.2. Soure address selection . . . . . . . . . . . . . . . . . . 4
1.3. CN address selection . . . . . . . . . . . . . . . . . . . 4
1.4. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Resource consumption consideration . . . . . . . . . . . . 5
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Liu, et al. Expires September 6, 2012 [Page 2]
Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012
1. Problem of dynamic anchor and potential solution
As draft [I-D.draft-seite-dmm-dma-00] introduced, the main idea of
dynamic anchor is distributing the mobility anchor function in the
access router (MAR). The newly initiated session is routed through
the current MAR, only the original sessions that established before
handover will be maintained at the previous anchor. As the following
figure shows, flow1 is anchored to MAR1, flow2 is anchored to MAR2.
Two different prefixes are assigned to the MN.
+--------------+
| Policy Server|
+-.-'--+-----`.+
+---+ .' | `. flow2 +----+
|CN1| .-' | `.____,| CN2|
++--+ .' | ,-'''' `. +----+
flow1\ +-----.-'--+ +----+--.'-+ +---`.-----+
+-------. | | | | | |
| MAR1 `-+-'''''-..MAR2.'| | MRA3 |
+----------+ +----+-+---+ +----------+
| |
HNP1 | | HNP2
+--`-+-+
| MN |
+------+
Figure 1 There are several potential problems for this solution
1.1. Active session managment
In this dynamic anchor solution, the MAR needs to know whether a
prefix is active, if not, the MAR need to release the mobility
binding. For instance, when the MN attach to MAR1, MAR1 detects the
attachment of MN and allocate HNP1 to the MN. When the MN moves to
MAR2, MAR2 needs to know that there is one on-going session in the MN
and needs to trigger mobility binding update to MAR1 to update the
binding.
The question is how MAR2 know that there is an active session for
HNP1 in MN? The first approach is to use policy server to store the
MN-ID and corresponding home network prefix that allocate to the MN.
When MN moves to MAR2, as mentioned in [I-D.draft-seite-dmm-dma-00],
MAR2 first check the policy server and find that MN is anchored to
MAR1, then it can send binding update message to MAR1. But only that
is not enough. MAR2/MAR1 has to have some mechanism to trigger the
release HNP1, otherwise the MAR1 will always be occupied by the MN as
one of its anchor point. This will lead system capacity waste. For
example, after the on-going session is terminated, the MAR2 need to
release the HNP1.
Liu, et al. Expires September 6, 2012 [Page 3]
Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012
The question is that the policy server does not know when to release
HNP1. One of possible solution is that MAR2 can inspect the traffic
that has the source address prefix equals to HNP1. When MAR2 finds
that there is no traffic sourced from HNP1 for a certain time, it can
send deregistration binding update to MAR1 and release the binding
state for HNP1. It seems that MAR2 needs a certain kind of timer to
support the inspection for each sessions. If in this way, system
capacity consumed by those timers can not be ignored since the
traffic from hundreds of mobile nodes which are in a same MAR may
have many thousands of sessions.
1.2. Soure address selection
MN may be configured with multiple addresses. For example, MN can
have HNP1 and HNP2 at the same time. In this case, the MN's
application need to select the correct source address. For example,
there maybe a VoIP session running using HNP1 when MN attaches to
MAR1. When MN moves to MAR2 , the VoIP session need to continue.
When the user start a web browser, MAR2 will allocate a new perfix:
HNP2. The VoIP software need to select HNP1 as the source address
and the web browser need to select HNP2 as source address. RFC3484
specifies the source address selection rules for IPv6 but RFC3484 is
not enough to cope with this situation since RFC3284 does not specify
how to select source address for a particular application.
To solve this problem, the host may use the following rules for
source address selection:
a. For any on-going session, keep to use the original address even
there is a newly address been configured for the same interface.
b. For any new session, always choose to use the newly allocated
address. The new MAR need to advertise the newly allocated
prefix as the highest priority.
1.3. CN address selection
From the CN's perspective, the MN has multiple addresses, the CN
needs to know which one it should use when it wants to initiate a
session to MN.
1.4. IPv4 support
It will worse the IPv4 address depletion problem if use the dynamic
anchor solution for IPv4 since each MN will need multiple IP
addresses in that case.
Liu, et al. Expires September 6, 2012 [Page 4]
Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012
1.5. Resource consumption consideration
_.------.
,---'' `------------------.
,' +----------+ `-.
/ |Session DB| :
( +----------+ MARn
\ / ``---MN
`. _.----'(HoA1,HoA2,HoA3,..,HoAn)
'MAR1----MAR2------------MAR3' ..+
.' \ move _..-'/
.' move \ move __..--''
MN --------> MN --------> MN
(HoA1) (HoA1,HoA2) (HoA1,HoA2,HoA3)
Figure2. Resource consumption
As illustrated in figure2, during the movement, mobile node gets more
and more HoAs and more and more MARs will be occupied by this mobile
node as its anchor points. The mobile node could maintain its HoAs
by keep on sending packets at very low data rate for each sessions.
In this way, capacity of the network will be consumed, e.g. many
tunnels should be maintained among those MARs, many mobility contexts
for this mobile node should be maintained among those MARs, and the
operator will gain almost nothing from this mobile node.
Additionally, the scenario described above provides a possibility for
attackers to consume network resource maliciously.
2. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
3. Security Considerations
TBD
4. Acknowledgements
TBD
5. References
Liu, et al. Expires September 6, 2012 [Page 5]
Internet-Draft draft-liu-dmm-dynamic-discussion-00 March 2012
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[I-D.draft-seite-dmm-dma-00]
Seite , P. and P. Bertin, "Distributed Mobility Anchoring,
draft-seite-dmm-dma-00", February 2012.
Authors' Addresses
Dapeng Liu
China Mobile
32 Xuanwumen West Street
Beijng, Xicheng District, 100053
China
Phone: +86-13911788933
Email: liudapeng@chinamobile.com
Hui Deng
China Mobile
32 Xuanwumen West Street
Beijng, Xicheng District, 100053
China
Phone: +86-13911788933
Email: denghui@chinamobile.com
Wen Luo
ZTE
No.68, Zijinhua RD,Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: luo.wen@zte.com.cn
Liu, et al. Expires September 6, 2012 [Page 6]
