Network Working Group C. Li Internet-Draft C. Xie Intended status: Informational China Telecom Expires: September 7, 2017 J. Bi Tsinghua University W. Xu Huawei Technologies March 6, 2017 Interface to the Address Pool Management draft-li-casm-address-pool-management-arch-00 Abstract This document describes an mechanism for a standard, programmatic interface for address pool management. With the remaining IPv4 address becoming more and more scattered, it is complicated to manually configure the address pools on lots of Broadband Network Gateways(BNGs) for operators. By introducing SDN/NFV in BNG, the address pools can be allocated in a centralized way. It will not only simplify the address management for operators, but also improve the utilization efficiency of the address pool. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 September 7, 2017. Copyright Notice Copyright (c) 2017 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 Li, et al. Expires September 7, 2017 [Page 1] Internet-Draft Address Pool Management March 2017 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 4. Initial Address Pool Configuration . . . . . . . . . . . . . 5 5. Address Pool Status Report . . . . . . . . . . . . . . . . . 7 6. Address Pool Status Query . . . . . . . . . . . . . . . . . . 8 7. Address Exhaustion . . . . . . . . . . . . . . . . . . . . . 8 8. Address Pool Release . . . . . . . . . . . . . . . . . . . . 8 9. Compatibility of different forms of devices . . . . . . . . . 10 10. Control Protocol consideration . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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 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. Another use case which needs to configure the address pools is IPv6 migration. For IPv6 transition mechanisms, e.g. DS-Lite, lw4over6, etc., they all need to be configured with address pools as translated routeable addresses. When high availability features, e.g. active- active/active-standby failover mechanism, etc., are enabled for these IPv6 transition mechanisms, different address pools need to be Li, et al. Expires September 7, 2017 [Page 2] Internet-Draft Address Pool Management March 2017 configured on each transition instance. This will further increase the number of address pools need to be configured. Besides, the occupation of the address pools may vary during different transition periods, (e.g. at the early stage of IPv6 transition, IPv4 traffic will normally occupy a great portion of the total traffic, while in the later stage of IPv6 transition, IPv4 traffic will decrease and the amount of IPv4 address pools will decrease accordingly. There are other devices which may need to configure address pools as well. For example, the Firewall need to configure the address pool for acl/NAT process. The VPN also needs to configure the address pools for end-users. When SDN/NFV is introduced in the network, these devices (e.g. BNG, CGN, firewall, VPN, etc.) will run as VNFs in virtualized environment. A common centralized address management server can interact with different VNFs and allocate address pools automatically. In this document, we propose a mechanism to manage the address pools centrally. In this way, operators do not need to configure the address pools one by one manually and it also helps to use the address pools more efficiently. 2. Terminology The following terms are used in this document: APMS A management system which has a centralized databse manage the overall address pools and allocate address pools to the device in the devices. DA A device agent in device, which contact with APM server to manipulate address pool. 3. Architectural Overview In this architecture, the Address Pool Management (APM) server is a centralized address pool management server for operators to configure the overall address pools. It maintains the address pool database including the overall address pools (OAP) and the address pool status(APS). Operators can configure its remaining address pools in the OAP. They can also reserve some address pool for special-purpose usage. The address pools status is to reflects the current usage of the address pools for different devices. APM also has the interface to configure the address pools to different devices dynamically. Li, et al. Expires September 7, 2017 [Page 3] Internet-Draft Address Pool Management March 2017 In each device, there is an device agent (DA) to contact with APM server. It initiates the address pools allocation requests, passes the address pools to local instances, report the status of local address pool usage and update the address pools requests, etc. For some devices, e.g. v6transition, VPN, etc., additional routing modules needs to update the routing table accordingly. +*********************+ | APM server | | +------------+ | | | Address DB | | | +------------+ | +***^*****^******^*^**+ | | | | | | +------------+ | +------------+ | | | | | | +------v------+ +------v------+ +------v------+ | +--------+ | | +--------+ | | +--------+ | | | agent | | | | agent | | | | agent | | | +----+---+ | | +----+---+ | | +----+---+ | | | | | | | | | | | v | | v | | v | | +--------+ | | +---------+ | | +---------+ | | | Local | | | | v6tra | | | | VPN | | | | Conf | | | | instance| | | |instance | | | +--------+ | | +----+----+ | | +---------+ | +-------------+ | | | | | | | v | | v | | v | | +---------+ | | +---------+ | | +---------+ | | | routing | | | | routing | | | | routing | | | +---------+ | | +---------+ | | +---------+ | +-------------+ +-------------+ +-------------+ BNG/vBNG v6tra/fw VPN Figure 1: Interface to Address Pool Management (APM) The overall procedure is as follows: o Operators will configure remaining address pools centrally in the Address Pool Management System (APMS). There are multiple address pools which can be configured centrally. The APMS server will then divide the address pools into addressing unit (AU) which will be allocated to the agent in devices by default. Li, et al. Expires September 7, 2017 [Page 4] Internet-Draft Address Pool Management March 2017 o The agent will initiate Address Pool request to the APMS. It can carry its desired size of address pool the request, or just use a default value. The address pool size in the request is only used as a hint. The actual size of the address pool is totally determined by APMS. It will also carry the DA's identification and the type of address pool. o APMS looks up the remaining address pool in its local database. It will then allocate a set of address pools to the DA. Each address pool has a related lifetime. o DA receives the AddressPool reply and use them for their purpose. o If the lifetime of the address pool is going to expire, the DA should issue an AddressPoolRenew request to extend the lifetime,including the IPv4, IPv6, Ports, etc. o The AddressPoolReport module keeps monitoring and reports the current usage of all current address pools for each transition mechanism. if it is running out of address pools, it can renew the AddressPoolRequest for a newly allocated one. It can also release and recycle an existing address pool if the that address pool has not been used for a specific and configurable time. o When the connection of APMS is lost or the APMS needs the status information of certain applications, the APMS may pre-actively query the DA for the status information. 4. Initial Address Pool Configuration Li, et al. Expires September 7, 2017 [Page 5] Internet-Draft Address Pool Management March 2017 +--------------+ +-----------------+ | Device | |AddrPoolMangement| | Agent | | Server | +------+-------+ +--------+--------+ | | +--------+-------+ | |1.DA start-up | | +---------+------+ | | 2.Address Pool Request | |------------------------------------------>| | | | +--------+-------+ | | 3. Check | | | address pool | | +--------+-------+ | 4.Address Pool Reply | |<------------------------------------------| | | | | Figure 2: Initial Address Pool Configuration Figure 2 illustrates the initial address pool configuration procedure: 1. The DA checks whether there is already address pool configured in the local site when it starts up. if no, it means the initial start-up or the address pool has been released. if yes, the address pool could be used directly. 2. The DA will initiate Address Pool request to the APMS. It can carry its desired size of address pool in the request, or just use a default value. The address pool size in the DA's request is only used as a hint. The actual size of the address pool is totally determined by APMS. It will also carry the DA's identification, the type of transition mechanism and the indication of port allocation support. 3. The APMS determines the address pool allocated for the DA based on the parameters received. 4. The APMS sends the Address Pool Reply to the DA. It will also distribute the routing entry of the address pool automatically. In particular, if the newly received address pool can be aggregated to an existing one, the routing should be aggregated accordingly. Li, et al. Expires September 7, 2017 [Page 6] Internet-Draft Address Pool Management March 2017 5. Address Pool Status Report +--------------+ +-----------------+ | Device | |AddrPoolMangement| | Agent | | Server | +------+-------+ +--------+--------+ | | +--------+-------+ | |1.Monitor and | | |count the status| | +--------+-------+ | | 2.Address Pool Status Report | |--------------------------------------------->| | +--------+-------+ | | 3. Record | | | address pool | | +--------+-------+ | 4.Address Pool Report Confirm | |<---------------------------------------------| | | | | Figure 3: Address Pool Status Report Figure 3 illustrates the active address pool status report procedure: 1. The DA will monitor and count the usage status of the local address pool. The DA counts the address usage status in one month, one week and one day, which includes the local address, address usage ratio (peak and average values), and the port usage ratio (peak and average values). 2. The DA reports the address pool usage status to the APMS. for example, it will report the address usage status in one day, which contains the IP address, NAT44, address list: 30.14.44.0/28, peak address value 14, average address usage ratio 90%, TCP port usage ratio 20%, UDP port usage ratio 30% and etc. 3. The APMS records the status and compares with the existing address information to determine whether additional address pool is needed. 4. The APMS will confirm the address pool status report request to the DA. It will keep sending the address pool status report request to the APMS if no confirm message is received. Li, et al. Expires September 7, 2017 [Page 7] Internet-Draft Address Pool Management March 2017 6. Address Pool Status Query When the status of APMS is lost or the AMS needs the status information of the DAs, the APMS may actively query the TD for the status information, as shown in step 1 of Figure 4. The following steps 2,3,4,5 are the same as the Address Pool Status Report procedure. +--------------+ +-----------------+ | Device | |AddrPoolMangement| | Agent | | Server | +------+-------+ +--------+--------+ | | | | | 1.Address Pool Status Query | |<---------------------------------------------| | | +--------+-------+ | |2.Monitor and | | |count the status| | +--------+-------+ | | 3.Address Pool Status Report | |--------------------------------------------->| | +--------+-------+ | | 4. Record | | | address pool | | +--------+-------+ | 5.Address Pool Report Confirm | |<---------------------------------------------| | | | | Figure 4: Address Pool Status Query 7. Address Exhaustion When the DA uses up the addresses allocated, it will renew the address pool request to the APMS for an additional address pool. The procedure is the same as the initial address pool request. 8. Address Pool Release Li, et al. Expires September 7, 2017 [Page 8] Internet-Draft Address Pool Management March 2017 +--------------+ +-----------------+ | Device | |AddrPoolMangement| | Agent | | Server | +------+-------+ +--------+--------+ | | +--------+-------+ | |1.Address pools | | | not used for a| | | long time | | +--------+-------+ | | 2.Address Pool Release Request | |--------------------------------------------->| | +--------+-------+ | |3. Update | | | address pool | | | database | | +--------+-------+ | 4.Address Pool Release Notification | |<---------------------------------------------| +--------+-------+ | |5. Reduce | | | address pool | | +--------+-------+ | | 6.Address Pool Release Confirm | |--------------------------------------------->| | | | | Figure 5: Address Pool Release Figure 5 illustrates the address pool release procedure: 1. The counting module in the DA checks that there are addresses not used for a long time; 2. The DA sends the address pool release request to the APMS to ask the release of those addresses; 3. The APMS updates the local address pool information to add the new addressed released. 4. The APMS notifies the TD that the addresses have been release successfully; 5. The DA will update the local address pool. if no Address Pool Release Notification is received, the DA will repeat step 2; Li, et al. Expires September 7, 2017 [Page 9] Internet-Draft Address Pool Management March 2017 6. The DA confirms with the APMS that the addres pool has been released successfully. 9. Compatibility of different forms of devices As described in section 3, each device has its address pools, the Address Pool Management (APM) server act as a centralized address pool management server for operators to configure the overall address pools of each devices. In this form of device, the user plane and the control plane are integrated in the box. There are another form of device, the control plane is separated from the box and one or more devices share centralized control plane. In this device form, the control plane will manage multiple user plane devices. A number of devices that are subordinate to a control plane will jointly share the address pools. The control plane device, together with the dependent multiple user plane devices, forms a "big" device. This bigger device contacts with the APM server to manipulate IP address pool. For example, the device acts as a server side when running the NETCONF protocol between the device and the APM. It determines whether the usage status of the IP address pool resource in device is satisfies the condition. For example, the address pool resource of device is not enough or excessive. It sends address pools resource request to the APM server, and receives response with address pools resource for this device allocated from APM server. Then it passes the address pools resource to local instances. In addition, it report the status of local address pool resource usage and update the address pools requests, etc. 10. Control Protocol consideration The I2APM architecture consists of two major distinct entities: APM Server and network equipment with an APM Agent. In order to provide address pool manipulations between these two entities, the I2APM architecture calls for well-defined protocols for interfacing between them. For compatibility with legacy network equipment, the architecture reuse legacy protocol such as radius. While the IETF may also choose to define one or more specific approaches to manipulate address pool, such as NETCONF or RESTCONF with address pool YANG data model.In modern network management system, the NETCONF or RESTCONF is used widely, the device implements as the NETCONF or RESTCONF server, and the network management system implements as the NETCONF or RESTCONF client, that achieving more automated network management. Li, et al. Expires September 7, 2017 [Page 10] Internet-Draft Address Pool Management March 2017 11. Security Considerations 12. Acknowledgements N/A. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 13.2. Informative References [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, DOI 10.17487/RFC6674, July 2012, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . Authors' Addresses Chen Li China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: lichen.bri@chinatelecom.cn Chongfeng Xie China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: xiechf.bri@chinatelecom.cn Li, et al. Expires September 7, 2017 [Page 11] Internet-Draft Address Pool Management March 2017 Jun Bi Tsinghua University 3-212, FIT Building, Tsinghua University, Haidian District Beijing 100084 P.R. China Email: junbi@tsinghua.edu.cn Weiping Xu Huawei Technologies Bantian, Longgang District shenzhen 518129 P.R. China Email: xuweiping@huawei.com Li, et al. Expires September 7, 2017 [Page 12]