Internet Working Group C.Xie Internet Draft Q.Sun Intended status: Informational China Telecom Expires: September 2016 W. Xu W. Liu Huawei I. Farrer Deutsche Telekom AG March 21, 2016 Problem statement for centralized address management draft-xie-ps-centralized-address-management-00 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 21, 2016. 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 21, 2016 [Page 1] Internet-Draft PS for Centralized Address Management March 2016 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 modern network devices and services bring new challenges for the management of network resources, such as IP addresses, bandwidth, VAS(Value Added Service) pool, etc. This draft contains a problem statement and defines the requirements for IP address management 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, VAS(Value Added Service) pool, etc. However, current approaches for address management result in low address allocation efficiency and complexity for the re-allocation of resources. A lack of integration between the IP address management functions of different OSS systems can make it difficult to share network resources. To reduce this complexity, and the associated OPEX and CAPEX, operators are looking for an intelligent, agile and flexible integration mechanism for the control and sharing of IP address resources, with a service-crossing and self-decision-making manner. Xie, et al Expires September 21, 2014 [Page 2] Internet-Draft PS for Centralized Address Management March 2016 Among all the resources aforementioned, address management gained traction by operators as it is fundamental for the provision of connectivity and services. This draft describes the problem and requirement 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 not as easily human- readable as IPv4 addresses. IPv6 networking, mobile computing, and multihoming require more dynamic 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, which is used to allocate specific IP addresses and options to CM. The second example is the address system integrated in Network Function Virtualization Infrastructure (NFVI), which is used to assign specified IP address to the VM. The third example is the address system in SDN network, the SDN controller could get the IP address of two inter-communication hosts, and then design an optimized forwarding path. 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. This is generally configured statically, via CLI or a configuration file. This approach poses the following problems for operators: o Low allocation efficiency o Manual configuration of address policy o Complexity in making real-time changes o Lack of an open, programmable interface between each system requiring IP addresses and the Management System Address pool management is a sub-issue of address management. Currently, operators are facing the following issues: Xie, et al Expires September 21, 2014 [Page 3] Internet-Draft PS for Centralized Address Management March 2016 1) The need to control and share addresses among devices a) With address shortage problem, the remaining IPv4 address pools are usually quite scattered. b) It is complicated to manually configure all the address pools statically in BNGs. c) Sometimes, the address pools are needed to be transited from one BNG to another. 2) The need to control and share addresses among functions a) For IPv6 transition technologies, e.g. DS-Lite, lw4over6, etc., they need to be configured with address pools as translated addresses. b) Different address pools are needed to be configured on each transition instance for HA support. c) The occupation of the 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 I2AM: Interface to address management I2APM: Interface to address pool management 4. Problems and Use Cases The Broadband Network Gateway (BNG), which manages a routable IP address on behalf of each subscriber, should be configured with the IP address pools allocated to subscribers. However, currently operators are facing with the address shortage problem, the remaining IPv4 address pools are usually quite scattered, no more than /24 per address pool in many cases. Therefore, it is complicated to manually configure the address pools on lots of Broadband Network Gateway (BNG) for operators. For large scale MAN, the number of BNGs can be up to Xie, et al Expires September 21, 2014 [Page 4] Internet-Draft PS for Centralized Address Management March 2016 over one hundred. Manual configuration on all the BNGs statically will not only greatly increase the workload, but also decrease the utilization efficiency of the address pools when the number of subscribers changes in the future. With NFV technology maturing, it can envisaged the edge of the IP network will be likely software- based, vBNG will be introduced into the network for broadband service provisioning. Since vBNG is launched and withdrawal dynamically based on the actual volume of users and traffic, the address pool configuration in vBNG will be even more dynamic than that of the classical hardware-based BNG +---------------+ | Address | | Management | | Server | +---------------+ | | | | | | | | | Configuration: | | | IPv6 address pools | | | IPv4 address pools | | | | | | | | +--------+ | | | BNG | _,.--.,, ,..-..,_ . | | +--------+` `. .'` '. - | | ,' `. ,' `. ,' | | / \ / \- | +--------+/ ,+-------+/ \ | | BNG || Metro || BR || Backbone | Internet | +--------+| Network || || Network | --------\ \ `+-------+\ /-, | \ / \ / `. +--------+`, ` `, ,' ' | BNG | ', ,-` '., ,' +--------+ ``'--'`` `''-''`` Figure 1 Configure address pools 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 21, 2014 [Page 5] Internet-Draft PS for Centralized Address Management March 2016 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 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 routeable 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 21, 2014 [Page 6] Internet-Draft PS for Centralized Address Management March 2016 Figure 2 illustrates address configuration on the IPv6 transition devices. For example, each DS-Lite AFTR or CGN devices should be configured with IPv4 address pool. 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 centralized excel spreadsheets to application specific databases/software (IPAM). Most IPAM software implement a RESTful API so that DevOps can use the IPAM for their needs, while having a centralized database. +---------------+ | Management | | System | |e.g., openstack| |,OSS,NMS. | +---------------+ | Configuraton: | IP address | Address allocation policy | e.g., static address | +---------------\--------------+ | | | IPAM | +------/----------------/------+ | | +------\------+ +-----\------+ | DHCP | | DNS | | SERVER | | Server | +-------------+ +------------+ Figure 3 Address configuration API of IPAM Figure 3 illustrates a general address configuration model in an IPAM tool. A management system, as Openstack, OSS, NMS, could configure address and address allocation policy through API. Typical policy examples is specific static IP address allocate to specific host. Xie, et al Expires September 21, 2014 [Page 7] Internet-Draft PS for Centralized Address Management March 2016 In CMTS scene, operations support system(OSS) or control system design the address allocation policy, deploy it to the CMTS device through an open, programmable interface. Then the CM could get customized IP address and DHCP options from address management system in CMTS. In Network Function Virtualization Infrastructure(NFVI) scene, the Management System(e.g., Openstack) design the address allocation policy, deploy it to the IPAM tool through an open, programmable interface. Then the VM could get customized IP address from IPAM tool. In SDN network scene, 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. 5. Requirements Based on the analysis above, some requirements for IP address management can be highlighted as following: 1) Centralized server placement, with a centralized address management server, IP addresses can be managed ,allocated and reclaimed in a more optimized and efficient way. 2) Dynamic, since address consumption in each device is time-changing and dynamic based on actual volume of the service, traffic or sessions, the IP address management process should be dynamic accordingly. 3) Multiple types of devices support, in production network, there are multiple types of IP equipment, i.e., BNG,vBNG, CGN, FW,etc, which need the IP address allocated from IP address management server, all these equipment should be supported. 4) Multiple types of IP address support, Not only IPv4 address, but also IPv6 address should be supported as well. Since some equipment, such as BRAS, allocates private IP address to end users from address pool, Private address should be supported as well as public address. In addition to the requirements above, as a telco network element, IP address management server, should meet other requirements,such as high availability, highly-secured,high-preformance, as well, since they are the basic requirements to telco equipment, they are not discussed in detail here. Xie, et al Expires September 21, 2014 [Page 8] Internet-Draft PS for Centralized Address Management March 2016 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. 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@ctbri.com.cn Xie, et al Expires September 21, 2014 [Page 9] Internet-Draft PS for Centralized Address Management March 2016 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 Xie, et al Expires September 21, 2014 [Page 10]