[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/