--- 1/draft-ietf-dmm-requirements-09.txt 2013-11-07 15:15:00.478444701 -0800 +++ 2/draft-ietf-dmm-requirements-10.txt 2013-11-07 15:15:00.518445670 -0800 @@ -1,26 +1,26 @@ Network Working Group H. Chan (Ed.) Internet-Draft Huawei Technologies (more Intended status: Informational co-authors on P. 17) -Expires: April 1, 2014 D. Liu +Expires: May 11, 2014 D. Liu China Mobile P. Seite Orange H. Yokota KDDI Lab J. Korhonen Renesas Mobile - September 28, 2013 + November 7, 2013 Requirements for Distributed Mobility Management - draft-ietf-dmm-requirements-09 + draft-ietf-dmm-requirements-10 Abstract This document defines the requirements for Distributed Mobility Management (DMM). The hierarchical structure in traditional wireless networks has led primarily to centralized deployment models. As some wireless networks are evolving away from the hierarchical structure, such as in moving the content delivery servers closer to the users, a distributed model for mobility management can be useful to them. @@ -38,21 +38,21 @@ 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 April 1, 2014. + This Internet-Draft will expire on May 11, 2014. Copyright Notice Copyright (c) 2013 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 @@ -73,22 +73,22 @@ 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Security considerations . . . . . . . . . . . . . . . . . 13 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction In the past decade a fair number of mobility protocols have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. Although the protocols differ in terms of functions and associated @@ -432,22 +432,22 @@ After comparing distributed mobility management against centralized deployment in Section 3, this section identifies the following requirements: 5.1. Distributed processing REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management - so that traffic does not need to traverse centrally deployed - mobility anchors and thereby avoid non-optimal routes. + so that traffic can avoid traversing single mobility anchor + far from the optimal route. Motivation: This requirement is motivated by current trends in network evolution: (a) it is cost- and resource-effective to cache and distribute content by combining distributed mobility anchors with caching systems (e.g., CDN); (b) the significantly larger number of mobile nodes and flows call for improved scalability; (c) single points of failure are avoided in a distributed system; (d) threats against centrally deployed anchors, e.g., home agent and local mobility anchor, are mitigated in a distributed system. @@ -546,31 +546,21 @@ in a DMM deployment. For instance, an illegitimate node may attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks - and existing mobility protocols defined in IETF. In addition, - 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. + and existing mobility protocols defined in IETF. This requirement prevents a DMM solution from introducing uncontrollable problems of potentially insecure mobility management protocols which make deployment infeasible because platforms conforming to the protocols are at risk for data loss and numerous other dangers, including financial harm to the users. 5.7. Multicast REQ7: Multicast considerations @@ -775,23 +764,22 @@ Elena Demaria Telecom Italia via G. Reiss Romoli, 274, TORINO, 10148, Italy Email: elena.demaria@telecomitalia.it - Jong-Hyouk Lee Sangmyung University Email: hurryon@gmail.com - Kostas Pentikousis - Huawei Technologies - Carnotstr. 4 10587 Berlin, Germany - Email: k.pentikousis@huawei.com + EICT GmbH + Email: k.pentikousis@eict.de - Tricci So ZTE Email: tso@zteusa.com - Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30, Leganes, Madrid 28911, Spain Email: cjbc@it.uc3m.es - @@ -863,10 +851,14 @@ amuhanna@awardsolutions.com - Byoung-Jo Kim ATT Labs macsbug@research.att.com - Hassan Ali-Ahmad Orange hassan.aliahmad@orange.com - + Alper Yegin + Samsung + alper.yegin@partner.samsung.com + -