Network Working Group F. Duan
Internet-Draft B. Liu, Ed.
Intended status: Standards Track Y. Zhang
Expires: January 4, 2018 Huawei Technologies
July 03, 2017

Anima Bootstrapping for Network Management


This document points out the gaps of utilizing current Anima technologies into a traditional centralized management network. It raises some problems and requirments, based on which, as set of solutions are proposed. (These solutions are called Anima Bootstrapping for Network Management.)

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 January 4, 2018.

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

One typical usage of ANIMA technologyies is that they serve as a stable management channel of the management systems, such as controllers or network management system (NMS) hosts. And These cases is also described in section 6 of [I-D.ietf-anima-autonomic-control-plane], with the purpose of management and controllability of ACP for the controllers or NMS hosts. However, In ANIMA networking, the autonomic nodes in ACP are self configurable by default, most configuration of which is learning from neighboring nodes in decentralized ways. While in traditional networking, the configuration is got by the top-down ways from the centralized devices (such as controller, NMS hosts etc) . These are the gaps and differences between the traditional networking and ANIMA networking.

Following this Introduction, Section 3 describes the problems of the integration of ACP and traditional centralized netwoking nodes, and then layout the solution requirments of it.

Based on the problems and solution requirments, this document disscusses the Autonomic Structured Naming mechanism (in section Section 4), which provids meaningful names easy for human operation and maintanance; autonomc NMS/Controller discovery by the Autonomic Nodes Section 5 ; and topology discovery and collection Section 6 allowing the NMS/Controller to learn the topology of the managed network. Finally, dicusses the capability of NMS/Controller correlating the naming and topology information to layout the whole picture of the managed entities in the Anima domain.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119]key words.

This document use the key words defined in [RFC7575] .

The following additional terms are used throughout this document:

3. Problems and Requirments

In ANIMA networking, every autonomic node has a global unique management address, this is the same with traditional networking. However, in traditional networking, the management addresses are globally planned by administrator. While in ANIMA networking, they are locally defined by the autonomic node itself using the information extracted from the domain certificate, called ULA addresses, as described in the section 5.8.2 of [I-D.ietf-anima-autonomic-control-plane]. In the view of centralized management tools, such as Networking Management System (NMS) hosts, there are usually two function modules included, the Element Management System (EMS) and the NMS core. The EMS is created by networking manager manually one by one for each networking element, using globally planned management addresses to establish SNMP sessions between EMS and networking elements. In ANIMA networking, because of the local definition of ULA addresses, it is difficult for networking managers to select which address to establish SNMP session or to do a correct functional deployment for each device.

To resolve the problems raised above, the requirments listed following must be satisfied:

4. Autonomic Structured Naming

4.1. Requirements

- Representing each device

- Uniqueness

- Semantic Encoding

- Consistency

4.2. Name Format and Content

4.2.1. Structured Naming Format

- Naming Elements

- Element Attributes

- Mandatory and Optional Naming Elements

4.2.2. Naming Content

The naming information SHOULD be suitable for the centralized tools to determine the location of the device and the functions to be deployed. The composing parts of the naming information are listed as following :

4.3. Autonomic Naming Approaches

4.3.1. Received and Self-generated Naming Elements

There are mainly two kinds of naming information, as the following.

- Received Naming Elements

The elements are advertised or injected by some external source. Operators are responsible for provisioning this kind of information. At least one of the interface types listed as following SHOULD be supported by the Autonomic Network:

- Self-generated Naming Elements

The mandatory fields SHOULD be self-generated so that one device could name itself sufficiently without any advertised knowledges.

There should various methods for a device to extract/generate a proper word for each mandatory semantic fields (e.g. "DeviceType", "DistinguisherNum") from its self-knowledge.

4.3.2. Naming Metadata Storage


5. Network Management Server/Controller Discovery

In order to connect to the centralized management tool, the AN devices MUST get acknowledgement of the address of it. In ANIMA netwoking, this MUST be done in autonomic ways. This section describes two methods for dynamic learning of the address of centralized management tools.

5.1. GRASP Method

This method is mandatory in ANIMA networking.

A centralized management tool is typically configured manually. When the centralized management tool joins an Autonomic Control Plane ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP ([I-D.ietf-anima-grasp]) M_NEG_SYN message. If the centralized management tool dose not take part in the ACP, the IPV6 address MUST be configured in one device (called Mangement Proxy) of ANIMA networking and that AN device MUST be responsible for responding to GRASP M_NEG_SYN message.

discovery-message = [M_NEG_SYN, session-id, initiator, Centralized-tool-objective]
Centralized-tool-objective         = ["AN_centralized_tool", F_SYNCH, loop-count, centralized-tool-address]
centralized-tool-address = ipv6-address

Figure 5: Centralized Management Tool Discovery

The discovery messages send from the AN devices to the centralized management tool ( or Mangement Proxy) as follows:

response-message = [M_RESPONSE, session-id, initiator, ttl,
    (+locator-option // divert-option), Centralized-tool-objective)]

Figure 6: Centralized Management Tool Response

The response from the Centralized Management Tool (or Mangement Proxy) will be a M_RESPONSE with the following parameters:

After the discovery precedure, the AN devices use M_REQ_SYN messages and the Centralized Management Tool (or Mangement Proxy) responds with M_SYNCH message as described in GRASP. In M_SYNCH message, the Centralized Management Tool (or Mangement Proxy) filles the centralized-tool-address field in Centralized-tool-objective of M_SYNCH message with the valid IPV6 address of Centralized Tool.

5.2. mDNS Method

This method is optional in ANIMA networking.

Performs DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] searching for the service "_centralize_management_address.udp.local". To prevent unacceptable levels of nework traffic the congestion avoidance mechanisms specified in [RFC6762] section 7 MUST be followed. The AN devices SHOULD listen for an unsolicited broadcast response as described in [RFC6762]. This allows AN devices to avoid announcing their presence via mDNS broadcasts and instead silently join the centralized management tools by watching for periodic unsolicited broadcast res

6. Topology Discovery and Collection

6.1. Local Topoloty Discovery

For the traditional centralized tools such as NMS hosts, the Link Layer Dicovery Protocol (LLDP) is used to dicovery the neigboring nodes and the links between two nodes, this was specified in IEEE 802.1ab.

6.2. Topology Collection by NMS/Controller

GRASP is used to carry topology information to the NMS/Controller. (Detailes TBD.)

7. Device Names and Topoloty Mapping in the NMS/Controller

There are two information types for the AN devices that must be exchanged in ANIMA networking, So that the centralized management tools can get the acknowgledgment of the topology of it. The fixed information, which is the name of the AN devices, and were initially setted by the operators in the setting up procedures as described in the previous sections. The dynamic information, which is autonomously created or learned by the AN devices themselves, including the ULA addresses of the ACP, domain name of the neworking and etc.

8. Security


9. IANA Considerations


10. Acknowledgements

The main idea of this document was initiated by Gang Yan.

Valuable comments were received from Sheng Jiang etc.

This document was produced using the xml2rfc tool [RFC2629].

11. References

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999.

11.2. Informative References

[I-D.behringer-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Liu, B., Jeff, J. and J. Strassner, "A Reference Model for Autonomic Networking", Internet-Draft draft-behringer-anima-reference-model-04, October 2015.
[I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T. and S. Bjarnason, "An Autonomic Control Plane", Internet-Draft draft-ietf-anima-autonomic-control-plane-06, March 2017.
[I-D.ietf-anima-grasp] Bormann, C., Carpenter, B. and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", Internet-Draft draft-ietf-anima-grasp-14, July 2017.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S. and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015.
[RFC7576] Jiang, S., Carpenter, B. and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015.

Authors' Addresses

Fanghong Duan Huawei Technologies N8, Huawei Campus No. 101 Ruanjian Road Yu-Hua-Tai District, Nanjing, 210000 P.R. China EMail:
Bing Liu (editor) Huawei Technologies Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China EMail:
Yongkang Zhang Huawei Technologies N8, Huawei Campus No. 101 Ruanjian Road Yu-Hua-Tai District, Nanjing, 210000 P.R. China EMail: