draft-ietf-dmm-requirements-09.txt   draft-ietf-dmm-requirements-10.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: April 1, 2014 D. Liu Expires: May 11, 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
Renesas Mobile Renesas Mobile
September 28, 2013 November 7, 2013
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-09 draft-ietf-dmm-requirements-10
Abstract Abstract
This document defines the requirements for Distributed Mobility This document defines the requirements for Distributed Mobility
Management (DMM). The hierarchical structure in traditional wireless Management (DMM). The hierarchical structure in traditional wireless
networks has led primarily to centralized deployment models. As some networks has led primarily to centralized deployment models. As some
wireless networks are evolving away from the hierarchical structure, wireless networks are evolving away from the hierarchical structure,
such as in moving the content delivery servers closer to the users, a such as in moving the content delivery servers closer to the users, a
distributed model for mobility management can be useful to them. distributed model for mobility management can be useful to them.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 April 1, 2014. This Internet-Draft will expire on May 11, 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 23 skipping to change at page 3, line 23
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . 15 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 29 skipping to change at page 11, line 29
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
so that traffic does not need to traverse centrally deployed so that traffic can avoid traversing single mobility anchor
mobility anchors and thereby avoid non-optimal routes. far from the optimal route.
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.
skipping to change at page 13, line 50 skipping to change at page 13, line 50
in a DMM deployment. For instance, an illegitimate node may in a DMM deployment. For instance, an illegitimate node may
attempt to access a network providing DMM. Another example is attempt to access a network providing DMM. Another example is
that a malicious node can forge a number of signaling messages that a malicious node can forge a number of signaling messages
thus redirecting traffic from its legitimate path. thus redirecting traffic from its legitimate path.
Consequently, the specific node is under a denial of service Consequently, the specific node is under a denial of service
attack, whereas other nodes do not receive their traffic. attack, whereas other nodes do not receive their traffic.
Accordingly, security mechanisms/protocols providing access Accordingly, security mechanisms/protocols providing access
control, integrity, authentication, authorization, control, integrity, authentication, authorization,
confidentiality, etc. can be used to protect the DMM entities confidentiality, etc. can be used to protect the DMM entities
as they are already used to protect against existing networks as they are already used to protect against existing networks
and existing mobility protocols defined in IETF. In addition, and existing mobility protocols defined in IETF.
end-to-end security measures between communicating nodes may
already be used when deploying existing mobility protocols
where the signaling messages travel over the Internet. For
instance, EAP-based authentication can be used for network
access security, while IPsec can be used for end-to-end
security. When the existing security mechanisms/protocols are
applied to protect the DMM entities, the security risks that
may be introduced by DMM MUST be considered to be eliminated.
Else the security protection would be degraded in the DMM
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: Multicast considerations REQ7: Multicast considerations
skipping to change at page 19, line 5 skipping to change at page 18, line 37
Elena Demaria Elena Demaria
Telecom Italia Telecom Italia
via G. Reiss Romoli, 274, TORINO, 10148, Italy via G. Reiss Romoli, 274, TORINO, 10148, Italy
Email: elena.demaria@telecomitalia.it Email: elena.demaria@telecomitalia.it
- -
Jong-Hyouk Lee Jong-Hyouk Lee
Sangmyung University Sangmyung University
Email: hurryon@gmail.com Email: hurryon@gmail.com
- -
Kostas Pentikousis Kostas Pentikousis
Huawei Technologies EICT GmbH
Carnotstr. 4 10587 Berlin, Germany Email: k.pentikousis@eict.de
Email: k.pentikousis@huawei.com
- -
Tricci So Tricci So
ZTE ZTE
Email: tso@zteusa.com Email: tso@zteusa.com
- -
Carlos J. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30, Leganes, Madrid 28911, Spain Av. Universidad, 30, Leganes, Madrid 28911, Spain
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
- -
skipping to change at line 873 skipping to change at page 20, line 30
amuhanna@awardsolutions.com amuhanna@awardsolutions.com
- -
Byoung-Jo Kim Byoung-Jo Kim
ATT Labs ATT Labs
macsbug@research.att.com macsbug@research.att.com
- -
Hassan Ali-Ahmad Hassan Ali-Ahmad
Orange Orange
hassan.aliahmad@orange.com hassan.aliahmad@orange.com
- -
Alper Yegin
Samsung
alper.yegin@partner.samsung.com
-
 End of changes. 9 change blocks. 
22 lines changed or deleted 11 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/