Network Working Group D. Liu
Internet-Draft H. Deng
Intended status: Standards Track China Mobile
Expires: September 13, 2012 J. Liu
ZTE
March 12, 2012
Address Selection for DMM
draft-liu-dmm-address-selection-01
Abstract
In DMM scenario, it is possible for the MN to have multiple mobility
anchor points and corresponding prefixes. In that case, MN needs to
know the type of the addresses then it can select the right one for
application to use. This document describes a mechnism to extend RA
message to carry a flag which can be used to identify the nature of
the prefix.
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 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires September 13, 2012 [Page 1]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
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 address selection for DMM . . . . . . . . . . . . . 3
2. Extension to Router Advertisment . . . . . . . . . . . . . . . 3
3. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 4
4. An Example of How This Draft Works . . . . . . . . . . . . . . 4
4.1. MN Handoffs From MAR to a Next MAR . . . . . . . . . . . . 5
4.2. MN Handoffs From MAR Back to Its Previous MAR . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Liu, et al. Expires September 13, 2012 [Page 2]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
1. Problem of address selection for DMM
As draft-liu-dmm-dynamic-anchor-discussion-00 introduced, there is a
address selection problem for DMM dynamic anchor solution. The
difficulty of this problem is: the MN does not know the difference
between the multiple prefixes. There is no way for the network to
tell the MN the nature of the different prefixes and there is no
standard mechnism for the MN to select the right prefix.
2. Extension to Router Advertisment
Mobile IPv6 [RFC3775] extend IPv6 router advertisement message for
movement detection and home agent information broadcasting. This
document proposes to further extend the IPv6 router advertisement
message to carry a flag to identify the nature of the prefix that it
is advertising.
+----------+---------+-------------------+
| Type | Code | Checksum |
+----------+-+-+-+---+-------------------+
|Hop Limit |M|O|H|Re-| Router Lifetime|
+----------+-+-+-+---+-------------------+
| Reachable Time |
+----------------------------------------+
| Retrans Timer |
+----------------------------------------+
| Options |
+----------------------------------------+
The H bit is used for indentify that the router advertisment is sent
by a home agent.
+-------------+------------+------------+-+-+-+--+---+
| Type | Length |PrefixLength|L|A|R|T |R- |
+-------------+------------+------------+-+-+-+--+---+
| Valid Lifetime |
+----------------------------------------------------+
| Preferred Lifetime |
+----------------------------------------------------+
| Reserved |
+----------------------------------------------------+
| |
| Prefix |
+----------------------------------------------------+
Liu, et al. Expires September 13, 2012 [Page 3]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
This document proposes to extend the prefix information option to add
a 'T' flag, its definition is as follows:
T (Type):
Type flag. This is a 2 bits flag indentifies the types of the
advertising prefix. The value of this flag could be:
00: Local home network prefix. It means that this prefix is
allocated and advertised by current router which the MN attaches to.
01 : Remote home network prefix. It means that this prefix is
allocated by another router instead of the router that the MN
currently attaches to.
10: Reserved.
11: Reserved.
The mechanism that used for the router to identify the types of the
prefix is out the scope of this document. As an example, the router
can query the policy server to know which router allocates a
particular prefix.
3. Mobile Node Operation
The mobile node knows the types of the prefixes from the T flag of
the router advertisment message. The applications on the mobile node
can use this information to select the right IP address. 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 T flag specified above solves the
source address selection. Two different use cases are presented
below.
Liu, et al. Expires September 13, 2012 [Page 4]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
4.1. MN Handoffs From MAR to a Next MAR
_______ _______ _______
| | | | | |
| CN1 | | CN2 | | CN3 |
|_______| |_______| |_______|
' . .
Flow#1 ' Flow#2 . | Flow#3
' ...'''''.'''''''.... .
..''' . '''..
.' ' IP network . '.
: ' . | :
'..' +-------+ . ..'
'''... | |.......'''
' | MAR2 | \ .
' | |. \ |
' | | . \ .
' +-------+\ .\ |
+-------+ HNP2(T=00) \ + ------+
| | HNP1(T=01) \ | | HNP3(T=00)
| MAR1 |-----------------| MAR3 | HNP2(T=01)
| | ''''''''''''''''| | HNP1(T=01)
| |-----------------| |
+-------+ +-------+
HNP1(T=00) ' . |
Flow#1 ' . . Flow#3
' . |
+-----+ Flow#2 +-----+
| MN | -----move-------> | MN |
+-----+ +-----+
T=00: Local home network prefix
using common IP forwarding and routing mechanisms
T=01: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 the Type flag (T) bit set to 00 as specified
in section 2. 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
Liu, et al. Expires September 13, 2012 [Page 5]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
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 the Type flag (T) bit set to 00 together with
old prefix (i.e. HNP1) with the Type flag (T) bit set to 01. 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 the Type flag (T) bit set to 00 for HNP3 and 01 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 the
Type flag (T) bit set to 00 for HNP2 and 01 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. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
Liu, et al. Expires September 13, 2012 [Page 6]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
RFC.
6. Security Considerations
TBD
7. Acknowledgements
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.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 100053
China
Email: denghui@chinamobile.com
Liu, et al. Expires September 13, 2012 [Page 7]
Internet-Draft draft-liu-dmm-address-selection-00 March 2012
Juan Liu
ZTE
No.68, Zijinhua RD,Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: liu.juan45@zte.com.cn
Liu, et al. Expires September 13, 2012 [Page 8]