Internet Working Group C. Xie Internet Draft Q. Sun Intended status: Informational China Telecom Expires: September 2017 W. Xu W. Liu Huawei I. Farrer N. Kowalewski Deutsche Telekom AG Y. Cheng China Unicom March 12, 2017 Problem statement for centralized address management draft-xie-ps-centralized-address-management-02 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 11, 2017. Copyright Notice Copyright (c) 2016 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 include Simplified BSD License text as described in Section 4.e of Xie, et al Expires September 8, 2017 [Page 1] ? Internet-Draft PS for Centralized Address Management March 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The increase in number, diversity and complexity of devices and services in modern networks bring new challenges for the management of network resources, such as IP addresses, network prefixes, bandwidth, and services that utilize such resources. This draft contains a problem statement for IP address management and defines requirements with practical use cases provided by operators. Table of Contents 1. Introduction ............................................. 2 2. Conventions used in this document ......................... 4 3. Terminology .............................................. 4 4. Problems and Use Cases .................................... 4 5. Requirements ............................................. 8 6. Related IETF work ......................................... 9 7. Security Considerations ................................... 9 8. IANA Considerations ....................................... 9 9. References ............................................... 9 9.1. Normative References ................................... 9 9.2. Informative References ................................. 9 10. Acknowledgments .......................................... 9 1. Introduction The increase in number, diversity and complexity of modern network devices and services bring new challenges for the management of network resources, such as IP addresses, bandwidth, and services that utilize such resources. However, current approaches for address management often result in sub-optimal allocation efficiency and significant complexity for using, sharing and sharing such resources. Address resources are often managed across multiple, partly disconnected technical systems which have limited means of model based inter-operation. In the interest of reducing complexity, improve utilization of resources and reduce overall associated OPEX and CAPEX, operators are looking for an intelligent, agile and flexible integrated approach to control and manage IP address resources. Assignment of such resources should be possible across many services, and offer means of categorizing, selecting and decision making on the assignment and revocation of address resources. Xie, et al Expires September 8, 2017 [Page 2] ? Internet-Draft PS for Centralized Address Management March 2017 Among the resources aforementioned, the relevance of address management gained traction by operators as it is a fundamental precursor for the provision of Internet connectivity and services. This draft describes problems and requirements of address management with solid and practical use cases provided by operators. IPAM (IP address management), is a means of planning, tracking, and managing the Internet Protocol address space used in a network. This topic is increasingly important as aforementioned that networks are deployed with increasing in number, diversity and complexity of modern network devices and services, resulting in more and larger address pools, different subnetting techniques, and more complex 128- bit hexadecimal numbers for IPv6, which are significant less easily human-readable than IPv4 addresses. IPv6 networking, mobile computing, multi-homing and virtualization of compute and network functions require a much more dynamic approach to IP address management. [WIKI] In some scenarios, the address management system is integrated with the operator's network. For example, the address system integrated in CMTS (Cable Modem Termination Systems), which is used to allocate specific IP addresses and options to CMs (Cable Modems). The second example is the address system integrated in Network Function Virtualization Infrastructure (NFVI), which is used to assign specified IP address(es) to VMs (Virtual Machines). The third example is the address system in SDN networks, the SDN controller could learn IP address of two inter-communication hosts, and then compute and configure an optimized forwarding path between them. In the examples above, the address allocation policy, e.g., specific IP address assigned to a specific VM, usually originates from a management system, e.g, OSS, OpenStack, SDN controller, DHCP server instance. Many such systems are configured rather statically, via CLI or per configuration file. This approach poses the following problems for operators: o Low allocation efficiency due to pre-allocation o Manual configuration of address policy, with risk for consistency in applying policy o Complexity in making real-time changes to assignment o Lack of an open, programmable interface between systems which requires IP addresses and the Management Systems handling the respective IP address resources Address pool management is a sub-issue of address management. Currently, operators are facing the following issues: Xie, et al Expires September 8, 2017 [Page 3] ? Internet-Draft PS for Centralized Address Management March 2017 1) The need to control and share addresses among devices a) Supply of IPv4 addresses is short of has even ended; the remaining IPv4 address pools do usually no longer consist of large blocks of consecutive addresses, but of a randomly scattered sets of many small blocks or even of independent individual addresses b) It is complicated to configure all the address pools statically in Broadband Network Gateways (BNGs). c) Sometimes, the address pools need to transition from one BNG to another. 2) The need to control and share addresses among entities or functions a) For IPv6 transition technologies, e.g. DS-Lite, lw4over6, etc., the entities need to be configured with IPv4 and IPv6 address pools, as well as with mapping information between individual address resources. b) Different address pools may be needed to be configured on each transition instance for HA (High Availability) support. c) The level of utilization of address pools may vary during different transition periods. 2. Conventions used in this document 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 [RFC2119]. 3. Terminology IPAM: IP address management 4. Problems and Use Cases The BNG, which manages one of more routable IP addresses on behalf of each subscriber, should be configured with the IP address pools allocated to subscribers. However, operators are increasingly challenged by the IPv4 address shortage and IPv4 address pools are scattered into many blocks as small as an IPv4/24 per in many cases. In the worst case configuration of such address pools on a large number of Broadband Network Gateway (BNG) has to be done manually by for operators and is labor intensive. For large scale MAN, there can a three digit number of BNGs to configure. Xie, et al Expires September 8, 2017 [Page 4] ? Internet-Draft PS for Centralized Address Management March 2017 Usual approaches of manual configuration on BNGs with such data in a static way will not only create great workload, it also limits utilization efficiency of the address pools when the number of subscribers varies or shrinks at a given BNG instance. With NFV technology maturing, it can be envisioned that the edge of the IP network will become a software-based virtualized vBNG entity itself, so the network element itself is dynamically created and changed. Such virtualized network elements are going to become more common and may be launched and withdrawn dynamically, based on actual traffic and user load, and an efficient dynamic assignments and re-use of address resources will be much more necessary than with a classical hardware-based entities. +---------------+ | Address | | Management | | Server | +---------------+ | | | | | | | | | Configuration: | | | IPv6 address pools | | | IPv4 address pools | | | | | | | | +--------+ | | | BNG | _,.--.,, ,..-..,_ . | | +--------+` `. .'` '. - | | ,' `. ,' `. ,' | | / \ / \- | +--------+/ ,+-------+/ \ | | BNG || Metro || BR || Backbone | Internet | +--------+| Network || || Network | --------\ \ `+-------+\ /-, | \ / \ / `. +--------+`, ` `, ,' ' | BNG | ', ,-` '., ,' +--------+ ``'--'`` `''-''`` Figure 1 Address pools configuration on the BNGs Figure 1 illustrates address pool configuration for BNGs. Each BNG requires configuration with several IPv4 and IPv6 address pools used Xie, et al Expires September 8, 2017 [Page 5] ? Internet-Draft PS for Centralized Address Management March 2017 for allocation to subscribers. Those address pools are configured through an API from a centralized Address Management Server. Typical examples include IPv4 and IPv6 address pool configuration. The centralized management approach is very crucial for dynamically service creation that concerned Virtual BNGs The second use case for address pool configuration is for IPv6 migration. IPv6 transition mechanisms (e.g. DS-Lite, lw4over6, etc.), need to be configured with address pools to be used as translated routable addresses. When high availability features, e.g. active- active/active-standby failover mechanism, are used, different address pools may need to be configured on each transition instance. This will further increase the number of address pools that need to be configured. +---------------+ | Address | | Management | | Server | +---------------+ | | | | Configuration: | | IPv4 address pools | | Port-set quota | | | +--------+ | | CGN | _,.--.,, ,..-..,_ . | +--------+` `. .'` '. - | ,' `. ,' `. ,' | / \ / \- +--------+/ ,+-------+/ \ |DS-Lite || Metro || BR || Core | Internet +--------+| Network || || Network | \ `+-------+\ /-, \ / \ / `. `, ` `, ,' ' ', ,-` '., ,' ``'--'`` `''-''`` Figure 2 Configuring address pools on IPv6 transition devices Xie, et al Expires September 8, 2017 [Page 6] ? Internet-Draft PS for Centralized Address Management March 2017 Figure 2 illustrates address configuration on the IPv6 transition devices. For example, the DS-Lite AFTR and the CGN devices need both be configured with aligned information of the IPv4 address pool that is used. Those address pools are configured through an API from centralized Address Management Server. The third use case for address pool configuration is IPAM. Nowadays in provider environments, address management is implemented at various levels, from centrally aggregated spreadsheets to application specific databases/software (IPAM). Many IPAM software packages implement RESTful APIs so that organizations that employ modern operational methods like DevOps can use and expand IPAM for their needs, while at the same time establishing a centralized database to administer their IP address resources. Often such systems need to be integrated with provisioning systems for domain name resolution functions. +---------------+ | Management | | System | |e.g., openstack| |,OSS,NMS. | +---------------+ | Configuration: | IP address | Address allocation policy | e.g., static address | +---------------\--------------+ | | | IPAM | +------/----------------/------+ | | +------\------+ +-----\------+ | DHCP | | DNS | | SERVER | | Server | +-------------+ +------------+ Figure 3 Address configuration API of IPAM Figure 3 illustrates one possible approach of a general address configuration model where an network management system of OSS is triggering the IPAM tool to perform configuration actions on network elements. A management system, like an instance of OpenStack, of OSS, NMS, could configure address and address allocation policy through API. Typical policy example is specific static IP address allocate to specific host. Xie, et al Expires September 8, 2017 [Page 7] ? Internet-Draft PS for Centralized Address Management March 2017 in Figure 3, in the CMTS case, operations support system(OSS) or control system defines the address allocation policy, deploys resources to the CMTS device through an open, programmable interface. Then the CM would get its individually customized IP address and DHCP options from the designated address management sub-system in the CMTS. In the Network Function Virtualization Infrastructure(NFVI) case, the Management System (e.g., OpenStack) designs the address allocation policy, deploys it to the IPAM tool through an open, programmable interface. Then the VM could get customized IP address from IPAM tool. In SDN network scenario, two host communicate pass through a SDN network. The Management System(SDN controller) get the IP address of the two inter-communication hosts from address management system through an open, programmable interface, then the SDN controller could design an optimized forwarding path, and deploy it into forwarding plane. Another common model is that the MNS/OSS and IPAM perform address management on different levels of granularity. The overall authoritative ownership of all address resources lies with the IPAM, and the resources available in there are subject to a formally regulated assignment process (e.g. ARIN, RIPE, etc.). From IPAM, blocks of addresses can be requested according to inherently defined IP Address assignment policy. Requests are made by or on behalf of IP address consuming entities, typically by provisioning intermediaries like MNS, OSS. These systems may further break down the resource according to application specific substructures (e.g. DNS, DHCPv4, DHCPv6, OpenStack, ...) and sub-delegate them as needed. +---------------+ IP resource +----------------+ | | Request | | | IPAM + <-----------------+ Management | | - Resources | | System | | - Policies +-----------------> + e.g. OSS, NMS | | | Configuration: | | +---------------+ IP address object +-------/-------+ | Configuration: | IP address object | Entity address Model | e.g. DNS A record | DHCP IPv6 prefix | OpenStack public IPv4/24 | +------------------+-----------------+ | | | | | | | | | | | | +------\------+ +------\------+ +-----\------+ | OpenStack | | DHCP | | DNS | | Orchestrator| | SERVER | | Server | +-------------+ +-------------+ +------------+ Figure 4 Address configuration API of IPAM Figure 4 illustrates such a case where the address resources and management policy is represented in the IPAM tool, and the management system relies on an API to the IPAM system to offer the proper set of resources upon request based on an IPAM inherently defined and managed assignment policy. All consuming entities, such as the management system and the resource consuming target entities, like an instance of OpenStack, OSS, NMS, are configured with addresses as per an entity specific allocation model through API. An examples in the CMTS case could be the deployment of a new access router instance which requires new addresses for the expected new users be available for them to connect. Such addresses need to be deployed in the respective DHCPv4 and DHCPv6 entities. To achieve that, the MNS would request resources from IPAM and assigns the specific /48 address pool to a specific DHCPv6 instance, as well as adding a specific set of IPv4 /24 in a DHCPv4 instance. As example for a Network Function Virtualization Infrastructure (NFVI) case could be, that at the same time the NMS may need to query for a small set of internal IP resources for a newly to be launched set of additional machines to scale up the VOIP service for these new additional access users. NMS goes out to request these resources from IPAM, adds them to the resources that the OpenStack Orchestrator is aware of and triggers creation of the newly required VMs and virtual networks. The SDN case, the NMNS would instruct the OpenStack Orchestrator to setup the entities and provide the pool of require IP address endpoints respective 5. Requirements Based on the analysis above, some requirements for IP address management can be highlighted as following: 1) An integrated, centralized IP address management is desirable as it offers an aggregated view on all stages of the life cycle of IP address resources, from selection, allocation, assignment to reclaiming them into to free resources in an optimized and efficient way. 2) The approach needs to be much more dynamic and act on a much finer granularity than in the past, since address consumption in each device is changing over time, and resource usage can dynamically change over time based on actual user, service, traffic or session volume. A fast return of unused resources for reassignment is of high value. 3) IP address resource assignment policies have to be adaptable to a broad variety of usage scenarios and multiple types of network entities - physical and virtual. Examples are various types of network IP equipment, i.e., BNG, vBNG, CGN, FW, etc, which all need to be supported with resources - directly or indirectly - through the same IP address management server. 4) IP address management needs to be cable of handling IPv4 and IPv6 resources, including sub-netting, and prefixes in any valid configurable prefix length. All well defined and RFC covered address types should be administrable. 5) Overlapping pools of private addresses must be supported. It should be pointed out that the IP address management server SHALL meet additional requirements of high reliability, availability, security and performance, according to best practices for mission critical infrastructure, but these aspects are considers out of scope of this document. Xie, et al Expires September 8, 2017 [Page 8] ? Internet-Draft PS for Centralized Address Management March 2017 6. Related IETF work TBD 7. Security Considerations TBD. 8. IANA Considerations No IANA action is needed for this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [WIKI] https://en.wikipedia.org/wiki/IP_address_management 10. Acknowledgments The authors of this draft would like to thank the following persons for the provided valuable feedback and contributions: Benoit Claise, Marc Blancet, Yu Fu, John Strassner, Jun Bi, Diego Lopez, Zhiheng Liu, Laurent Ciavaglia, Fred Baker, Joel Jaeggli, Will Liu, Giuseppe Fioccola. Authors' Addresses Chongfeng Xie China Telecom Beijing Research Institute China Telecom Beijing Information Science&Technology Innovation Park Beiqijia Town Changping District Beijing 102209 China Email: xiechf.bri@chinatelecom.cn Xie, et al Expires September 8, 2017 [Page 9] ? Internet-Draft PS for Centralized Address Management March 2017 Qiong Sun China Telecom Beijing Research Institute China Telecom Beijing Information Science&Technology Innovation Park Beiqijia Town Changping District Beijing 102209 China Email: sunqiong@ctbri.com.cn Weiping Xu Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: xuweiping@huawei.com Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District, Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Ian Farrer Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany Email: ian.farrer@telekom.de Normen B. Kowalewski Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany Email: normen.kowalewski@telekom.de Ying Cheng China Unicom No.21 Financial Street, XiCheng District Beijing 100033 China Email: chengying10@chinaunicom.cn Xie, et al Expires September 8, 2017 [Page 10]