--- 1/draft-ietf-dmm-requirements-16.txt 2014-06-05 21:14:25.586080447 -0700 +++ 2/draft-ietf-dmm-requirements-17.txt 2014-06-05 21:14:25.630081525 -0700 @@ -1,25 +1,25 @@ Network Working Group H. Chan (Ed.) Internet-Draft Huawei Technologies Intended status: Informational D. Liu -Expires: October 20, 2014 China Mobile +Expires: December 7, 2014 China Mobile P. Seite Orange H. Yokota KDDI Lab J. Korhonen Broadcom Communications - April 18, 2014 + June 5, 2014 Requirements for Distributed Mobility Management - draft-ietf-dmm-requirements-16 + draft-ietf-dmm-requirements-17 Abstract This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal @@ -39,21 +39,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 October 20, 2014. + This Internet-Draft will expire on December 7, 2014. Copyright 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 @@ -66,27 +66,27 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Centralized versus distributed mobility management . . . . . . 7 3.1. Centralized mobility management . . . . . . . . . . . . . 7 3.2. Distributed mobility management . . . . . . . . . . . . . 8 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction In the past decade a fair number of network-layer mobility protocols have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. Although these protocols differ in terms of functions and associated message formats, they all employ a mobility anchor to allow a mobile node to remain reachable after it has moved to a different network. The anchor point, among other tasks, ensures connectivity by forwarding packets destined to, or sent from, the @@ -511,38 +511,165 @@ This requirement attempts to avoid the need of new protocols development and therefore their potential problems of being time-consuming and error-prone. REQ5: Coexistence with deployed networks/hosts and operability across different networks A DMM solution may require loose, tight or no integration into existing mobility protocols and host IP stack. Regardless of - the integration level, such a DMM solution MUST be able to + the integration level, DMM implementations MUST be able to coexist with existing network deployments, end hosts and routers that may or may not implement existing mobility protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when the needed mobility management signaling, forwarding, and network access are allowed by the trust relationship between them. Motivation: (a) to preserve backwards compatibility so that existing networks and hosts are not affected and continue to function as usual, and (b) enable inter-domain operation if desired. This requirement addresses the problem PS7 described in Section 4. - REQ6: Security considerations + REQ6: Operation and Management considerations. + + A DMM solution needs to consider configuring a device, + monitoring the current operational state of a device, + responding to events that impact the device, possibly by + modifying the configuration and storing the data in a format + that can be analyzed later. Different management protocols + are available. For example: + + (a) SNMP [RFC1157] with definition of standardized management + information base MIB objects for DMM, that allows + monitoring traffic steering in a consistent manner across + different devices, + + (b) NETCONF [RFC6241] with definition of standardized YANG + [RFC6020] modules for DMM to achieve a standardized + configuration, + + (c) syslog [RFC3164] which is a one-way protocol allowing a + device to report significant events to a log analyzer in + a network management system. + + (d) IP Flow Information Export (IPFIX) Protocol, which serves + as a means for transmitting traffic flow information over + the network [RFC7011], with a formal description of IPFIX + Information Elements [RFC7012]. + + It is not the goal of the requirements document to impose + which management protocol(s) should be used. An inventory of + the management protocols and data models is covered in RFC + 6632. + + The following lists the operation and management + considerations required for a DMM solution; the list may not + be exhaustive and may be expanded according to the needs of + the solutions: + + A DMM solution MUST describe in what environment and how it + can be scalably deployed and managed. + + A DMM solution MUST support mechanisms to test if the DMM + solution is working properly. For example, when a DMM + solution employs traffic indirection to support a mobility + session, implementations MUST support mechanisms to test that + the appropriate traffic indirection operations are in place, + including the setup of traffic indirection and the subsequent + teardown of the indirection to release the associated network + resources when the mobility session has closed. + + A DMM solution SHOULD expose the operational state of DMM to + the administrators of the DMM entities. For example, when a + DMM solution employs separation between session identifier and + forwarding address, it should expose the association between + them. + + When flow mobility is supported by a DMM solution, the + solution SHOULD support means to correlate the flow routing + policies and the observed forwarding actions. + + A DMM solution SHOULD support mechanisms to check the liveness + of forwarding path. If the DMM solution sends periodic update + refresh messages to configure the forwarding path, the refresh + period SHOULD be configurable and a reasonable default + configuration value proposed. Information collected can be + logged or made available with protocols such as SNMP + [RFC1157], NETCONF [RFC6241], IPFIX [RFC7011], or syslog + [RFC3164]. + + A DMM solution MUST provide fault management and monitoring + mechanisms to manage situations where update of the mobility + session or the data path fails. The system must also be able + to handle situations where a mobility anchor with ongoing + mobility sessions fails. + + A DMM solution SHOULD be able to monitor usage of DMM + protocol. When a DMM solution uses an existing protocol, the + techniques already defined for that protocol SHOULD be used to + monitor the DMM operation. When these techniques are + inadequate, new techniques MUST be developed. + + In particular, the DMM solution SHOULD + + (a) be able to monitor the number of mobility sessions per + user as well as their average duration. + + (b) provide indication on DMM performance such as + + 1 the handover delay which includes the time necessary + to re-establish the forwarding path when the point of + attachment changes, + + 2 the protocol reactivity which is the time between + handover events such as the attachment to a new access + point and the completion of the mobility session + update. + + (c) provide means to measure the signaling cost of the DMM + protocol. + + (d) if tunneling is used for traffic redirection, monitor + + 1 the number of tunnels, + + 2 their transmission and reception information, + + 3 the used encapsulation method and overhead + + 4 the security used at a node level. + + DMM solutions SHOULD support standardized configuration with + NETCONF [RFC6241], using YANG [RFC6020] modules, which SHOULD + be created for DMM when needed for such configuration. + However, if a DMM solution creates extensions to MIPv6 or + PMIPv6, the allowed addition of the definition of management + information base (MIB) objects to MIPv6 MIB [RFC4295] or + PMIPv6 MIB [RFC6475] needed for the control and monitoring of + the protocol extensions SHOULD be limited to read-only + objects. + + Motivation: A DMM solution that is designed from the beginning + for operability and manageability can avoid difficulty or + incompatibility to implement efficient operations and + management solutions. + + These requirements avoid DMM designs that make operations and + management difficult or costly. + + REQ7: Security considerations A DMM solution MUST support any security protocols and mechanisms needed to secure the network and to make continuous security improvements. In addition, with security taken into consideration early in the design, a DMM solution MUST NOT introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security protocols and mechanisms. Motivation: Various attacks such as impersonation, denial of @@ -564,54 +691,41 @@ security protection, that candidate DMM solution is causing uncontrollable security problems. 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. - REQ7: Multicast considerations + REQ8: Multicast considerations DMM SHOULD enable multicast solutions to be developed to avoid network inefficiency in multicast traffic delivery. Motivation: Existing multicast deployment have been introduced after completing the design of the reference mobility protocol, often leading to network inefficiency and non- optimal forwarding for the multicast traffic. Instead DMM should consider multicast early so that the multicast solutions can better consider efficiency nature in the multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should then avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. This requirement addresses the problems PS1 and PS8 described in Section 4. - REQ8: OAM considerations - - DMM SHOULD support operations, administration and management - (OAM) solutions to reduce OAM complexity and operational - expenditure. - - Motivation: A DMM solution that takes OAM into considerations - from the beginning of its design can avoid difficulty or - incompatibility to implement efficient OAM solutions. - - This requirement avoids DMM designs that make OAM difficult or - costly. - 6. Security Considerations Please refer to the discussion under Security requirement in Section 5. 7. IANA Considerations None 8. Contributors @@ -730,55 +844,94 @@ Email: macsbug@research.att.com Hassan Ali-Ahmad Orange Email: hassan.aliahmad@orange.com Alper Yegin Samsung Email: alper.yegin@partner.samsung.com + David Harrington + Effective Software + Email: ietfdbh@comcast.net + 9. References 9.1. Normative References + [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, + "Simple Network Management Protocol (SNMP)", STD 15, + RFC 1157, May 1990. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, + August 2001. + [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. + [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, + "Mobile IPv6 Management Information Base", RFC 4295, + April 2006. + [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)", RFC 6020, + October 2010. + + [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. + Bierman, "Network Configuration Protocol (NETCONF)", + RFC 6241, June 2011. + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. + [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, + "Proxy Mobile IPv6 Management Information Base", RFC 6475, + May 2012. + + [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network + Management Standards", RFC 6632, June 2012. + + [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of + the IP Flow Information Export (IPFIX) Protocol for the + Exchange of Flow Information", STD 77, RFC 7011, + September 2013. + + [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow + Information Export (IPFIX)", RFC 7012, September 2013. + 9.2. Informative References [I-D.bhandari-dhc-class-based-prefix] Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class based prefix", draft-bhandari-dhc-class-based-prefix-05 (work in progress), July 2013. [I-D.korhonen-6man-prefix-properties] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix-properties-02 (work in progress), July 2013. [I-D.wakikawa-netext-pmip-cp-up-separation] - Wakikawa, R., Pazhyannur, R., and S. Gundavelli, - "Separation of Control and User Plane for Proxy Mobile - IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 - (work in progress), February 2014. + Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. + Perkins, "Separation of Control and User Plane for Proxy + Mobile IPv6", + draft-wakikawa-netext-pmip-cp-up-separation-03 (work in + progress), April 2014. [I-D.yokota-dmm-scenario] Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case scenarios for Distributed Mobility Management", draft-yokota-dmm-scenario-00 (work in progress), October 2010. [Paper-Distributed.Centralized.Mobility] Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed or Centralized Mobility", Proceedings of Global