Internet Engineering Task Force R. Kumar
Internet-Draft A. Lohiya
Intended status: Informational Juniper Networks
Expires: August 2, 2017 M. Blanchet
January 29, 2017

Centralized Address Space Management(CASM) Requirements and Framework


The organizations use IP Address Space Management (IPAM) tools to manage their IP address space, often with proprietary database and interfaces. This document describes evolution of IPAM into a standardized interfaces for centralized management of IP addresses.

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

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 August 2, 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 ( 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

The address space management is an intergral part of any network management solution. The network architectures are rapidally changing with the migration toward private and public clouds. At the same time, application architectures are also evolving with a shift toward micro-services and multi-tiered approach.

There is a pressing need to define a new address management system which can meet these diverse set of requirements. Such a system must be built with well defined interfaces so users can easily migrate from one vendor to another without rewriting their network management systems.

This document identifies a broad set of requirements and defins a architectural framework that should become the basis to develop a new address management system. We are calling this new system as Centralized Address Space Management (CSAM) system.

2. Requirements Language

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 RFC 2119 [RFC2119].

3. Terminology

Centralized Address Space Management
IP Address Management

4. Requirements from CASM system

In order to build CASM, there is a clear need to define a broad set of requirements that must be the basis for defining the architecture framework for CASM. The requirements should be able to meet the various use-cases identified in the draft.

This sections identifies the major set of requirements for defining CASM system.

4.1. General operational requirements

Some requirements are not specific to any particular functiolaity of CASM but applicable to all aspects of CASM system.

4.2. Interafce modeling requirements

The interface to external user must be meta-dat driven as much as possible to meet wider set of use-cases, e.g., instead of requesting an explicit IPv4 address, user should specify an adsress request based on its requirements.

The following requirements should be considered for pool management interface defintion. The attributes should be realted to the requestor which could a physical device, virtual machine, container or other entities present in a network.

4.3. Functional requirements

The CASM should support following functionality for it to be adopted for wide varierty of use cases.

4.3.1. Address pools

A CASM system should allow ability to manage different kind of address pools. The following pools should be considered for implementation; this is not mandatory or exhaustive by any means but given here as most commonly used in networks. The CASM system should allow user-defined pools with any address objects.

4.3.2. Pool management

There should be a rich set of functionality as defined in this section for operation of a given pool.

4.3.3. Integration with other address services

In order to build a complete address management system, it is important that CASM should be able to integrate with other address services. This will provide a complete solution to network operators without requiring any manual or proprietary workflows.

5. Archiectural framework

Based on the requirements specifed in this document, we propose the following high-level architecture for building CASM.

There are three broad categories for CASM interface defintion:

        +----------------+ +------+ +----+ +-----+ +-----------------------+
        |Interface for   | |SDN/  | |OSS/| |ADMIN| |Interface for logs,    |
        |managing address| |Legacy| |BSS | |     | |DHCP, DNS, NAT, Address|
        |space and pools | |      | |    | |     | |allocation records     |
        +--------+-------+ +--+---+ +-+--+ +--+--+ +----------+------------+
        |            |       |       |               ^
        |            |       |       |               |
        |            |       |       |               |
        |            |       |       |               |
        v            v       v       v               |
        |    Address Space Management (IPAM) System             |
        |      +-----------+ +----------+ +--------+            |
        |      | Pool      | |Address   | |Database|            |
        |      | Management| |Management| |        |            |
        |      +-----------+ +----------+ +--------+            |
        |                                                       |
        |Address Helper Plug|ins |
        +-------------|  |      |     |-------+
        |           +----+      |             |
        |           |           |             |
        +--v----+    +-v---+  +----v-----+   +---v----+
        +--------+|   +-----+| +----------+|  +--------+|
        | DNS    ||   |NAT  || |  Address ||  | DHCP   ||
        | Servers||   |     || |  Mapping ||  | Servers||
        |        |+   |     |+ |  Systems |+  |        |+
        +--------+    +-----+  +----------+   +--------+


Figure 1: CASM Architecture

The propsed CASM framework is shown in Figure 1.

6. Acknowledgements

This document started from a slide deck authored by Rakesh Kumar and Anil Lohiya.

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations


9. Informative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

Authors' Addresses

Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 US EMail:
Anil Lohiya Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 US EMail:
Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada EMail: URI: