Internet Engineering Task Force R. Kumar
Internet-Draft A. Lohiya
Intended status: Informational Juniper Networks
Expires: August 3, 2017 M. Blanchet
Viagenie
January 30, 2017
Centralized Address Space Management(CASM) Requirements and Framework
draft-kumar-casm-requirements-and-framework-00
Abstract
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 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 August 3, 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
(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
Kumar, et al. Expires August 3, 2017 [Page 1]
Internet-Draft Centralized Address Space Management January 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements from CASM system . . . . . . . . . . . . . . . . 3
4.1. General operational requirements . . . . . . . . . . . . 3
4.2. Interafce modeling requirements . . . . . . . . . . . . . 3
4.3. Functional requirements . . . . . . . . . . . . . . . . . 4
4.3.1. Address pools . . . . . . . . . . . . . . . . . . . . 4
4.3.2. Pool management . . . . . . . . . . . . . . . . . . . 5
4.3.3. Integration with other address services . . . . . . . 5
5. Archiectural framework . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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].
Kumar, et al. Expires August 3, 2017 [Page 2]
Internet-Draft Centralized Address Space Management January 2017
3. Terminology
CASM: Centralized Address Space Management
IPAM: 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.
Multi-tenancy: All interfaces exposed by CASM system must be
multi-tenant capable. This is highly desirable for cloud based
network management solutions. It may also be applicable for a
service provider with different managed services use-case
scenario.
Autentication and Authorization: All interfaces exposed by CASM
system must support an authentication scheme. It also highly
desriable to support operational restrictions on certain resources
based on identity for security reasons.
Audit Logging: All CASM actvities must be logged for auditing or
debugging purposes. The system must provide an interface to
access these records.
Error notification: All interfaces exposed by CASM system must
support error handling and user-defined error notification
mechanism suh as alert or email. There may also be need to take
corrective action for autonomus operation.
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.
Kumar, et al. Expires August 3, 2017 [Page 3]
Internet-Draft Centralized Address Space Management January 2017
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.
Fucntional attributes such as switch, router, firewall, server,
end-point
Form-factoral attributes such as physical, virtual
Opertional attributes such as management plane, control plane,
data plane
Network segment identifier, such as VLAN, VxLAN or other user-
defined value
Network segment type such as point-to-point, multi-point, loopback
Addressing scope attributes such as private, public, vpn, unicast,
multicast
Extensible user-defined attributes
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.
Unicast address pool:
Private IPv4 addresses
Public IPv4 addresses
IPv6 addresses
MAC Addresses
Mulicast address pool:
Kumar, et al. Expires August 3, 2017 [Page 4]
Internet-Draft Centralized Address Space Management January 2017
IPv4 address
IPv6 address
4.3.2. Pool management
There should be a rich set of functionality as defined in this
section for operation of a given pool.
Address management:
Address allocation either as single or block
Address reservation
Allocation logic such as mapping schemes or algorithm per pool
General management:
Pool initializing, resizing, threshold markings for resource
monitoring
Pool attributes such as used to automatcally create DNS record
Pool priority for searching across different pools
Pool fragmenetation rules, such as how pool can be sub-divided
Pool lease rules for alloation requests
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.
DHCP server:
Interface to initialize address pools on DHCP server
Notification interface whenever an address lease is modified
Interface to access address lease records from DHCP server
Ability to store lease records and play back to DHCP server on
reboot
Kumar, et al. Expires August 3, 2017 [Page 5]
Internet-Draft Centralized Address Space Management January 2017
DNS server:
Interface to create DNS records on DNS server based on DHCP
server events
NAT device:
Interface to initialize NAT pools
Interface to access NAT records from NAT device
Ability to store NAT records and play back to NAT device on
reboot
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:
Pool management interface: Interface to external user or
applications such as SDN controller to manage addresses
Log interface: Interface to access log and records such as DHCP,
DNS, NAT
Integration interface: Interface to address services such as DHCP,
DNS, NAT
The propsed CASM framework is shown in Figure 1.
Kumar, et al. Expires August 3, 2017 [Page 6]
Internet-Draft Centralized Address Space Management January 2017
+----------------+ +------+ +----+ +-----+ +-----------------------+
|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| | | |
| +-----------+ +----------+ +--------+ |
| |
+-------------------------+-----------------------------+
|
+-----------v------------+
|Address Helper Plug|ins |
+----+--+------+-----+---+
| | | |--------------------+
| +----+ | |
| | ------------+ |
v +----| | |
+--------+ +-----+ +----------+ +--------+
| DNS | |NAT | | Address | | DHCP |
| Servers| | | | Mapping | | Servers|
| | | | | Systems | | |
+--------+ +-----+ +----------+ +--------+
Figure 1: CASM Architecture
6. Acknowledgements
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
TBD
Kumar, et al. Expires August 3, 2017 [Page 7]
Internet-Draft Centralized Address Space Management January 2017
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,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Rakesh Kumar
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
US
Email: rkkumar@juniper.net
Anil Lohiya
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
US
Email: alohiya@juniper.net
Marc Blanchet
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Email: marc.blanchet@viagenie.ca
URI: http://viagenie.ca
Kumar, et al. Expires August 3, 2017 [Page 8]