Problem statement for centralized address management
draft-xie-ps-centralized-address-management-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Chongfeng Xie , Qiong Sun , Weiping Xu , Will (Shucheng) LIU , Ian Farrer | ||
| Last updated | 2016-03-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xie-ps-centralized-address-management-00
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]