draft-ietf-dmm-requirements-06.txt   draft-ietf-dmm-requirements-07.txt 
Network Working Group H. Chan (Ed.) Network Working Group H. Chan (Ed.)
Internet-Draft Huawei Technologies (more Internet-Draft Huawei Technologies (more
Intended status: Informational co-authors on P. 17) Intended status: Informational co-authors on P. 17)
Expires: January 31, 2014 D. Liu Expires: February 3, 2014 D. Liu
China Mobile China Mobile
P. Seite P. Seite
Orange Orange
H. Yokota H. Yokota
KDDI Lab KDDI Lab
J. Korhonen J. Korhonen
Nokia Siemens Networks Nokia Siemens Networks
July 30, 2013 August 2, 2013
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-06 draft-ietf-dmm-requirements-07
Abstract Abstract
This document defines the requirements for Distributed Mobility This document defines the requirements for Distributed Mobility
Management (DMM) in IPv6 deployments. The hierarchical structure in Management (DMM) in IPv6 deployments. The hierarchical structure in
traditional wireless networks has led to deployment models which are traditional wireless networks has led to deployment models which are
in practice centralized. Mobility management with logically in practice centralized. Mobility management with logically
centralized mobility anchoring in current mobile networks is prone to centralized mobility anchoring in current mobile networks is prone to
suboptimal routing and raises scalability issues. Such centralized suboptimal routing and raises scalability issues. Such centralized
functions can lead to single points of failure and inevitably functions can lead to single points of failure and inevitably
skipping to change at page 2, line 13 skipping to change at page 2, line 13
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2014. This Internet-Draft will expire on February 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11
5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11
5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12
5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12
5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Security considerations . . . . . . . . . . . . . . . . . 13 5.6. Security considerations . . . . . . . . . . . . . . . . . 13
5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the past decade a fair number of mobility protocols have been In the past decade a fair number of mobility protocols have been
standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
Although the protocols differ in terms of functions and associated Although the protocols differ in terms of functions and associated
skipping to change at page 11, line 20 skipping to change at page 11, line 20
After comparing distributed mobility management against centralized After comparing distributed mobility management against centralized
deployment in Section 3, this section identifies the following deployment in Section 3, this section identifies the following
requirements: requirements:
5.1. Distributed processing 5.1. Distributed processing
REQ1: Distributed processing REQ1: Distributed processing
IP mobility, network access and routing solutions provided by IP mobility, network access and routing solutions provided by
DMM MUST enable distributed processing for mobility management DMM MUST enable distributed processing for mobility management
of some flows so that traffic does not need to traverse so that traffic does not need to traverse centrally deployed
centrally deployed mobility anchors and thereby avoid non- mobility anchors and thereby avoid non-optimal routes.
optimal routes.
Motivation: This requirement is motivated by current trends in Motivation: This requirement is motivated by current trends in
network evolution: (a) it is cost- and resource-effective to network evolution: (a) it is cost- and resource-effective to
cache and distribute content by combining distributed mobility cache and distribute content by combining distributed mobility
anchors with caching systems (e.g., CDN); (b) the anchors with caching systems (e.g., CDN); (b) the
significantly larger number of mobile nodes and flows call for significantly larger number of mobile nodes and flows call for
improved scalability; (c) single points of failure are avoided improved scalability; (c) single points of failure are avoided
in a distributed system; (d) threats against centrally in a distributed system; (d) threats against centrally
deployed anchors, e.g., home agent and local mobility anchor, deployed anchors, e.g., home agent and local mobility anchor,
are mitigated in a distributed system. are mitigated in a distributed system.
This requirement addresses problems PS1, PS2, PS3, and PS4 in Section This requirement addresses the problems PS1, PS2, PS3, and PS4
4. (Existing route optimization is only a host-based solution. On described in Section 4. (Existing route optimization is only a host-
the other hand, localized routing with PMIPv6 addresses only a part based solution. On the other hand, localized routing with PMIPv6
of the problem where both the MN and the CN are located in the PMIP addresses only a part of the problem where both the MN and the CN are
domain and attached to a MAG, and is not applicable when the CN is located in the PMIP domain and attached to a MAG, and is not
outside the PMIP domain.) applicable when the CN is outside the PMIP domain.)
5.2. Transparency to Upper Layers when needed 5.2. Transparency to Upper Layers when needed
REQ2: Transparency to Upper Layers when needed REQ2: Transparency to Upper Layers when needed
DMM solutions MUST provide transparent mobility support above DMM solutions MUST provide transparent mobility support above
the IP layer when needed. Such transparency is needed, for the IP layer when needed. Such transparency is needed, for
example, when, upon change of point of attachment to the example, when, upon change of point of attachment to the
network, an application flow cannot cope with a change in the network, an application flow cannot cope with a change in the
IP address. However, it is not always necessary to maintain a IP address. However, it is not always necessary to maintain a
stable home IP address or prefix for every application or at stable home IP address or prefix for every application or at
all times for a mobile node. all times for a mobile node.
Motivation: The motivation of this requirement is to enable Motivation: The motivation of this requirement is to enable
more efficient use of network resources and more efficient more efficient use of network resources and more efficient
routing by not maintaining context at the mobility anchor when routing by not maintaining context at the mobility anchor when
there is no such need. there is no such need.
This requirement addresses the problem PS5 as well as the related This requirement addresses the problem PS5 as well as the related
problem PS6 in Section 4. problem PS6 stated in Section 4.
5.3. IPv6 deployment 5.3. IPv6 deployment
REQ3: IPv6 deployment REQ3: IPv6 deployment
DMM solutions SHOULD target IPv6 as the primary deployment DMM solutions SHOULD target IPv6 as the primary deployment
environment and SHOULD NOT be tailored specifically to support environment and SHOULD NOT be tailored specifically to support
IPv4, in particular in situations where private IPv4 addresses IPv4, in particular in situations where private IPv4 addresses
and/or NATs are used. and/or NATs are used.
skipping to change at page 13, line 23 skipping to change at page 13, line 17
support neither DMM nor another mobility protocol. support neither DMM nor another mobility protocol.
Furthermore, a DMM solution SHOULD work across different Furthermore, a DMM solution SHOULD work across different
networks, possibly operated as separate administrative networks, possibly operated as separate administrative
domains, when allowed by the trust relationship between them. domains, when allowed by the trust relationship between them.
Motivation: (a) to preserve backwards compatibility so that Motivation: (a) to preserve backwards compatibility so that
existing networks and hosts are not affected and continue to existing networks and hosts are not affected and continue to
function as usual, and (b) enable inter-domain operation if function as usual, and (b) enable inter-domain operation if
desired. desired.
This requirement addresses the following related problem PS7 in This requirement addresses the related problem PS7 described in
Section 4. Section 4.
5.6. Security considerations 5.6. Security considerations
REQ6: Security considerations REQ6: Security considerations
A DMM solution MUST not introduce new security risks or A DMM solution MUST not introduce new security risks or
amplify existing security risks against which the existing amplify existing security risks against which the existing
security mechanisms/protocols cannot offer sufficient security mechanisms/protocols cannot offer sufficient
protection. protection.
skipping to change at page 14, line 19 skipping to change at page 14, line 13
solution versus in existing mobility protocols. solution versus in existing mobility protocols.
This requirement prevents a DMM solution from introducing This requirement prevents a DMM solution from introducing
uncontrollable problems of potentially insecure mobility management uncontrollable problems of potentially insecure mobility management
protocols which make deployment infeasible because platforms protocols which make deployment infeasible because platforms
conforming to the protocols are at risk for data loss and numerous conforming to the protocols are at risk for data loss and numerous
other dangers, including financial harm to the users. other dangers, including financial harm to the users.
5.7. Multicast 5.7. Multicast
REQ7: DMM SHOULD consider multicast early so that solutions can be REQ7: Multicast considerations
developed not only to provide IP mobility to keep IP multicast
sessions when it is needed, but also to avoid network DMM SHOULD consider multicast early so that solutions can be
inefficiency issues in multicast traffic delivery (such as developed not only to provide IP mobility support when it is
duplicate multicast subscriptions towards the downstream needed, but also to avoid network inefficiency issues in
tunnel entities). The multicast solutions should therefore multicast traffic delivery (such as duplicate multicast
avoid restricting the management of all IP multicast traffic subscriptions towards the downstream tunnel entities). The
to a single host through a dedicated (tunnel) interface on multicast solutions should therefore avoid restricting the
multicast-capable access routers. management of all IP multicast traffic to a single host
through a dedicated (tunnel) interface on multicast-capable
access routers.
Motivation: Existing multicast deployment have been introduced Motivation: Existing multicast deployment have been introduced
after completing the design of the reference mobility after completing the design of the reference mobility
protocol, then optimization and extensions have been followed protocol, then optimization and extensions have been followed
by "patching-up" procedure, thus leading to network by "patching-up" procedure, thus leading to network
inefficiency and non-optimal routing. The multicast solutions inefficiency and non-optimal routing. The multicast solutions
should therefore be required to consider efficiency nature in should therefore be required to consider efficiency nature in
multicast traffic delivery. multicast traffic delivery.
This requirement addresses the problems PS1 and PS8 in Section 4. This requirement addresses the problems PS1 and PS8 described in
Section 4.
6. Security Considerations 6. Security Considerations
Please refer to the discussion under Security requirement in Session Please refer to the discussion under Security requirement in Section
5.6. 5.6.
7. IANA Considerations 7. IANA Considerations
None None
8. Co-authors and Contributors 8. Co-authors and Contributors
This problem statement document is a joint effort among the numerous This problem statement document is a joint effort among the numerous
participants. Each individual has made significant contributions to participants. Each individual has made significant contributions to
 End of changes. 12 change blocks. 
27 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/