xie-ps-centralized-address-management-02.txt

Internet DRAFT - draft-xie-ps-centralized-address-management

draft-xie-ps-centralized-address-management

Last Version:	draft-xie-ps-centralized-address-management-02.txt	Tracker Entry
Date:	`13-Mar-2017`
Disposition:	expired
Previous Versions:	draft-xie-ps-centralized-address-management-00.txt (diff) - 22-Mar-2016

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.

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.

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.

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]