Internet DRAFT - draft-liu-dmm-address-selection
draft-liu-dmm-address-selection
Network Working Group V.Liu
Internet Draft H.Deng
Intended status: Standards Track China Mobile
Expires: Nov 15, 2015 D.Liu
Alibaba
X.Wei
Huawei
J.Liu
ZTE
July 6, 2015
Address Selection for DMM
draft-liu-dmm-address-selection-02
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 November 6, 2015.
Copyright Notice
Copyright (c) 2015 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.
Liu, et al. Expires Nov 15, 2015 [Page 1]
Internet-Draft liu-dmm-address-selection July 2015
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.
Abstract
In DMM scenario, it is possible for the MN to use multiple mobility
anchor points and corresponding prefixes. In that case, MN needs to
know the property of the addresses then it can select the optimized
one for application to use. This document defines new IP network
prefix types to assist address selection for applications.
Table of Contents
1. Introduction ................................................ 2
2. Definition of New Prefix Types ............................... 3
3. Mobile Node Operation ........................................ 3
4. An Example of How This Draft Works ........................... 3
4.1. MN Handoffs From MAR to a Next MAR ...................... 3
4.2. MN Handoffs From MAR Back to Its Previous MAR ........... 5
5. Security Considerations ...................................... 6
6. IANA Considerations ......................................... 6
7. References .................................................. 6
7.1. Normative References .................................... 6
7.2. Informative References .................................. 6
1. Introduction
In DMM scenario, mobility anchors would be deployed in a distributed
manner, and as specified in RFC7333 [RFC7333], one of the aims of DMM
is to reduce the routing redundancy between mobile node and
correspondent node, which means providing a more optimal
communication path for application traffic between mobile node and
correspondent node. To achieve routing optimization for specific
application traffic, the basic idea is to make the traffic using IP
address(s) anchored at current anchor, so that downlink traffic from
correspondent node to mobile node will go directly to mobile node.
Different application sessions could require different IP address
consistency support from network layer, for example, if the
application layer cannot bear the IP address to be changed during the
session, then the IP address for the session should be kept unchanged;
but if the application layer could provide mechanism to deal with IP
Liu, et al. Expires Nov 15, 2015 [Page 2]
Internet-Draft liu-dmm-address-selection July 2015
address change, then the application could choose select a new
optimal address during the session, to get reduce routing redundancy.
This document defines new IP network prefix types to assist address
selection for applications.
2. Definition of New Prefix Types
Two types of IP network prefix are defined in this section. The
extension of specific protocol to convey the defined new types of IP
network prefix to MN is out of scope of this document.
Local home network prefix. It means that this prefix is allocated
and advertised by current router which the MN attaches to. Remote
home network prefix. It means that this prefix is allocated by
another router instead of the router that the MN currently attaches
to.
3. Mobile Node Operation
This section describes how the applications on the mobile node could
select the optimal IP address based on different types of prefixes.
For example, for on-going session, application always choose to use
the prefix that it used before it handovers to a new location. For
the newly initiate application, it will use the prefix that allocated
by current router, e.g. local home network prefix. The mobile node
can use advanced socket API to select the proper prefix, for example,
extension to RFC 5014.The detail mechanism is out the scope of this
document.
4. An Example of How This Draft Works
This section describes how the prefix types defined above solves the
source address selection. Two different use cases are presented below.
We assume a new Type flag "T" in Prefix Information option is used to
indicate the new defined prefix type.
4.1. MN Handoffs From MAR to a Next MAR
Liu, et al. Expires Nov 15, 2015 [Page 3]
Internet-Draft liu-dmm-address-selection July 2015
_______ _______ _______
| | | | | |
| CN1 | | CN2 | | CN3 |
|_______| |_______| |_______|
' . .
Flow#1 ' Flow#2 . | Flow#3
' ...'''''.'''''''.... .
..''' . '''..
.' ' IP network . '.
: ' . | :
'..' +-------+ . ..'
'''... | |.......'''
' | MAR2 | \ .
' | |. \ |
' | | . \ .
' +-------+\ .\ |
+-------+ HNP2(L) \ + ------+
| | HNP1(R) \ | | HNP3(L)
| MAR1 |-----------------| MAR3 | HNP2(R)
| | ''''''''''''''''| | HNP1(R)
| |-----------------| |
+-------+ +-------+
HNP1(L) ' . |
Flow#1 ' . . Flow#3
' . |
+-----+ Flow#2 +-----+
| MN | -----move-------> | MN |
+-----+ +-----+
Liu, et al. Expires Nov 15, 2015 [Page 4]
Internet-Draft liu-dmm-address-selection July 2015
T=L: Local home network prefix using common IP forwarding and routing
mechanisms
T=R: Remote home network prefix using mobility anchoring and
tunneling to maintain communications
Figure 1: Source address selection in DMM
As shown in figure1, flow#1, flow#2 and flow#3 are initiated and
anchored at MAR1, MAR2 and MAR3 respectively.
When MN attaches to MAR1, MAR1 sends Router Advertisement
messages(RA) containing MN's home network prefix(HNP1) in Prefix
Information option with T=L. This indicates that HNP1 is local home
network prefix which is allocated and advertised by current
router(MAR1). MN can initiate a session with CN1 (i.e. flow#1 in
figure1) by using IPv6 addresses derived from HNP1. Common IPv6
routing mechanism will be applied for flow#1 as long as MN remains
attached to MAR1.
When MN handoffs to MAR2(flow#1 continues while MN handoffs), MAR2
sends RA messages containing MN's new prefix(HNP2) in Prefix
Information option with T=L together with old prefix (i.e. HNP1) with
T=R. MN will learn that HNP2 is local home network prefix and HNP1 is
remote home network prefix. At this moment, MN can initiate a new
sessions with CN2 (i.e. flow#2 in the figure1) by using IPv6
addresses derived from HNP2 as its source address. Because this IPv6
address is derived from a local home network prefix (i.e. HNP2),
common IPv6 routing mechanism will be applied for flow#2. For flow#1,
MAR1 plays role of LMA and MAR2 plays role of MAG. When MN handoffs
to MAR3(flow#1 and flow#2 continue while MN handoffs), MAR3 sends
RA messages containing MN's new prefix(HNP3) and previous prefixes
(HNP1 and HNP2) in Prefix Information option with T=L for HNP3 and
T=R for HNP1 and HNP2. This indicates HNP3 is local home network
prefix, and HNP1 and HNP2 are remote home network prefixes. At this
moment, MN can initiates new sessions with CN3 (i.e. flow#3 in
figure1) by using IPv6 addresses derived from HNP3 as its source
address. And Common IPv6 routing mechanism will be applied for
flow#3.
4.2. MN Handoffs From MAR Back to Its Previous MAR
MN could also handoff back from MAR3 to MAR2 again (assuming flow#1,
flow#2 and flow#3 continue while MN handoffs).
In this case, as described above, MAR2 will send RA messages
containing HNP1, HNP2 and HNP3 in Prefix Information option with T=L
Liu, et al. Expires Nov 15, 2015 [Page 5]
Internet-Draft liu-dmm-address-selection July 2015
for HNP2 and T=R for HNP1 and HNP3. This indicates HNP2 is local home
network prefix; HNP1 and HNP3 are remote home network prefixes.
Assuming that MN initiates a new sessions with a new communication
node (e.g. with CN4 which is not shown in figure1) by using IPv6
addresses derived from HNP2 as its source address. Because this IPv6
address is derived from a local home network prefix (i.e. HNP2),
common IPv6 routing mechanism will be applied for this session.
5. Security Considerations
TBD
6. IANA Considerations
This document makes no request of IANA.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
7.2. Informative References
[3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583.
[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp.
1573-1583.
[I-D.draft-seite-dmm-dma-00] Seite, P. and P. Bertin, "Distributed
Mobility Anchoring,draft-seite-dmm-dma-00", February 2012.
Liu, et al. Expires Nov 15, 2015 [Page 6]
Internet-Draft liu-dmm-address-selection July 2015
Authors' Addresses
Vic Liu
China Mobile
32 Xuanwumen West AVE, Xicheng, Beijing
Email: liuzhiheng@chinamobile.com
Hui Deng
China Mobile
32 Xuanwumen West AVE, Xicheng, Beijing
Email: denglingli@chinamobile.com
Dapeng Liu
Alibaba
Email: max@dotalks.com
Xinpeng Wei
Huawei
Email: Weixinpeng@huawei.com
Juan Liu
ZTE
No.68, Zijinhua RD,Yuhuatai District,Nanjing
Email: liu.juan45@zte.com.cn
Liu, et al. Expires Nov 15, 2015 [Page 7]
