Internet DRAFT - draft-wei-dmm-address-management
draft-wei-dmm-address-management
INTERNET-DRAFT X. Wei
Intended Status: Standards Track Huawei Technologies
Expires: April 30, 2015 October 27, 2014
IP Address Management in DMM
draft-wei-dmm-address-management-00
Abstract
This document provides an IP address management solution for DMM
network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 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
X. Wei Expires April 30, 2015 [Page 1]
INTERNET DRAFT IP Address Management in DMM October 27, 2014
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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 IP Address Management . . . . . . . . . . . . . . . . . . . . . 3
2.1 All application sessions prefer IP address consistency . . . 3
2.2 Address Management model . . . . . . . . . . . . . . . . . 4
2.2.1 Design Principles . . . . . . . . . . . . . . . . . . . 4
2.2.2 Anchor Deployment . . . . . . . . . . . . . . . . . . . 5
2.2.3 Prefix Category . . . . . . . . . . . . . . . . . . . . 5
2.2.4 Anchor Action . . . . . . . . . . . . . . . . . . . . . 5
2.2.5 IP Address Release . . . . . . . . . . . . . . . . . . . 6
3 Source Address selection . . . . . . . . . . . . . . . . . . . . 6
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Normative References . . . . . . . . . . . . . . . . . . . 7
6.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
X. Wei Expires April 30, 2015 [Page 2]
INTERNET DRAFT IP Address Management in DMM October 27, 2014
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,
but this routing optimization requirement brings a fact that mobile
node has to change its IP address as it moving to a new anchor. Some
application sessions can cope with the change of IP address either by
application layer itself or by the function provided by other layers,
e.g. transport layer; but for other application sessions, after IP
address changed, the application session would be broken off totally.
So it's reasonable to provide different network layer mobility
support according to the need of application. This document provides
a discussion on IP address management in DMM domain, which gives
support to source IP address selection on mobile node side. A brief
discussion of how end host chooses to use the IP address provided by
network is also involved. Currently, the address management described
in this document is not specific to certain DMM framework.
1.1 Terminology
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].
2 IP Address Management
2.1 All application sessions prefer IP address consistency
In IP network, the nature of IP address acting as both "locator" and
"identifier" results that the change of "location" would inevitably
interrupt continuity of ongoing application session, no matter short-
lived or long last one. There are mainly two different technical
routes to eliminate the impacts of IP address change on application
session continuity, the first one is keeping IP address unchanged
during movement of host; the second one is allowing IP address change
to happen and then using other methods to make the application
session correctly finished, here are some examples of these methods:
(1) Deal with IP address change in process of a session Mobility
X. Wei Expires April 30, 2015 [Page 3]
INTERNET DRAFT IP Address Management in DMM October 27, 2014
support could be provided by application layer or transport layer.
When IP address change happens, specific signaling of application
layer or transport layer could be used to add new IP address to the
session and at the same time removing old IP address from the
session.
(2) Restart a new session If there is no specific application layer
signaling to deal with the change of IP address, the application
could choose to restart a session when it finds the previous session
failed. This method would only be used for short-lived session, e.g.
DNS query/response session. Although, as discussed above, there are
methods to cope with IP address change for application session, but
from application's perspective, all these methods will bring in
certain amount of "cost", and may import other negative impacts, e.g.
signaling latency, packet losing, TCP slow start etc, in order to
deal with the impact of IP address change. So we have to say that,
all application sessions prefer to not change their IP address, the
reason why they provide mechanisms to deal with IP address change is
they have to do that, but not they willing to do that.
Another issue is that if application wants to make their traffic pass
through an optimal path between MN and CN, it has to use an IP
address anchored on the optimal path. So in order to get an overall
good performance for application, there should be a tradeoff on
whether to use a new IP address or not.
2.2 Address Management model
This sub-section provides a detailed description of suggested address
management model to satisfy the requirement of analysis result in
sub-section 2.1.
2.2.1 Design Principles
The following are some design principles considered in design process
of the address management model:
P1. Network SHOULD provide IP address consistency during the whole
session lifetime for application that cannot bear IP address change.
P2. Providing opportunity for application session to use the new IP
address after mobile node handover to a new anchor, but in order to
limit IP address change frequency, application session SHOULD NOT
changes its IP address each time after handover to a new anchor.
P3. Less IP addresses maintained by mobile node is preferred.
P4. Less requirements on mobile node side is preferred.
X. Wei Expires April 30, 2015 [Page 4]
INTERNET DRAFT IP Address Management in DMM October 27, 2014
2.2.2 Anchor Deployment
Anchors are deployed in a distributed manner, and each one could
assign its own prefix to mobile node.
Home anchor: A prefix's home anchor refers to the anchor which the
prefix belongs to.
Foreign anchor: A prefix's foreign anchor refers to all of the other
anchors that are not home anchor.
Current anchor: The anchor that mobile node currently attaches to.
2.2.3 Prefix Category
There are two kinds of prefixes: stable prefix and temporary prefix.
DMM network will provide mobility support for both of these two kinds
of prefix.
Stable prefix: Assigned by its home anchor, when mobile node hands
over to a foreign anchor the stable prefix will be maintained by
foreign anchors as long as the prefix is still being used by
application.
Temporary prefix: Assigned by its home anchor, temporary prefix
usually has different valid lifetime values in home anchor's network
and in foreign anchor's network (more shorter in foreign anchor's
network), a foreign anchor only provide mobility support for
temporary prefix for a specific period of time after which the
temporary prefix will become invalid. In DMM domain, the anchors
could set the valid lifetime of other anchors' temporary prefix to a
predefined value.
Each anchor maintains at least one stable prefix and one temporary
prefix for mobile node.
2.2.4 Anchor Action
Anchor advertises its own stable prefix and temporary prefix to the
mobile node, and sets them as preferred prefix. If mobile node is
hands over to current anchor from a previous anchor if prefix(es) of
previous anchor is still used by application session of mobile node,
then the current anchor will also advertise these prefixes from
previous anchor, but set them as deprecated prefix. Current anchor
sets valid lifetime value of temporary prefix of previous anchor to a
specific value after which the prefix becomes invalid. When the cost
of using previous temporary prefix is beyond a certain threshold
(e.g. current anchor is certain hops away from home anchor), current
X. Wei Expires April 30, 2015 [Page 5]
INTERNET DRAFT IP Address Management in DMM October 27, 2014
anchor could choose not advertise the temporary prefix to mobile
node, and this will let the application session to select a new
prefix to reduce routing redundancy.
2.2.5 IP Address Release
To reduce the number of IP addresses that mobile node must maintains,
and contexts that network maintains for mobile node, there should be
an effective IP address release mechanism for mobile node.
Triggers that could cause IP address to be released:
(1) Prefix valid Lifetime expiration.
(2) No traffic is transported using the IP address. For example, when
mobile node hands over to a new anchor, if there is no traffic
transported on previous anchors' prefixes, the prefixes will be seen
as invalid in current anchor's network. But there should be a special
treatment for MN's public address which can be retrieved by others
through DNS (e.g. when MN is a mobile server) , public address is a
kind of stable address though current anchor could set it as a
deprecated address, but it should not be released even when there is
not traffic using it.
(3) Mobile node explicitly signals out that it wants to release
certain IP address.
3 Source Address selection
Which IP address could be selected as source address depends on what
IP addresses are provided by network. Based on the address management
model discussed in this document, there are some simple source
address selection criteria:
(1) New communication (e.g., the opening of a new TCP connection)
should use a preferred address when possible.
(2) If an existing app session could cope with IP address changes, it
could choose to use temporary address from temporary prefix. In a
visit network, when MN's previous temporary address becomes invalid,
a new temporary address from current anchor's temporary prefix will
be selected.
(3) A deprecated stable address should be used only by applications
that have been using it and would have difficulty switching to
another address without a service disruption.
(4) For the session which is initialized by CN, the address in the
X. Wei Expires April 30, 2015 [Page 6]
INTERNET DRAFT IP Address Management in DMM October 27, 2014
destination address field of packet from CN will be used as source
address of outgoing packets. (This is mainly for the case of using
MN's public address)
4 Security Considerations
TBD.
5 IANA Considerations
No.
6 References
6.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7333] H. Chan et al., Requirements for Distributed Mobility
Management, RFC 7333, August 2014.
6.2 Informative References
Authors' Addresses
Xinpeng Wei
Xin-Xi Rd. No. 3, Haidian District,
Beijing, 100095, P. R. China
E-mail: weixinpeng@huawei.com
X. Wei Expires April 30, 2015 [Page 7]
