Anima Bootstrapping
for Network ManagementHuawei TechnologiesN8, Huawei CampusNo. 101 Ruanjian RoadYu-Hua-Tai District, Nanjing210000P.R. Chinaduanfanghong@huawei.comHuawei TechnologiesQ14, Huawei CampusNo.156 Beiqing RoadHai-Dian District, Beijing100095P.R. Chinaleo.liubing@huawei.comHuawei TechnologiesN8, Huawei CampusNo. 101 Ruanjian RoadYu-Hua-Tai District, Nanjing210000P.R. Chinazhangyongkang@huawei.comThis 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.)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 , 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, 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 ), which provids meaningful names easy for human
operation and maintanance; autonomc NMS/Controller discovery by the
Autonomic Nodes ; and topology discovery and
collection 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.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 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 key words.This document use the key words defined in
.The following additional terms are used throughout this document:
AN: Autonomic Nodes.NMS: Networking Management System.EMS: Element Management System.NE: Networking Element.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 . 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:The autonomic nodes' physic location and functional roles in
networking MUST be initially setted before running and can be
dynamicly discoveried by the centralized management tools.The IP address of the centralized management tools MUST be
published as service in the ANIMA networking, so that the autonomic
nodes can trap the device information to the NMS host.By receiving the traps of the autonomic nodes, the centralized
management tools must create the corresponding EMS in autonomic
ways, not in manul ways by networking managers.- Representing each deviceInside a domain, each autonomic device needs a domain specific
identifier.- UniquenessThe names MUST NOT collide within one autonomic domain.It is acceptable that the names in different domains collide,
since they could be distinguished by domains.- Semantic EncodingIt is RECOMMENDED that the names encode some semantics rather
than meaningless strings. This is for ease of management
consideration that network administrators could easily recognize
the device directly through the names.- ConsistencyThe devices' naming SHOULD follow the same pattern within a
domain.- Naming ElementsThe whole name string could be combined with several
individual Naming Elements, each of which representing a
specific semantic. For example:
Location-DeviceType-FunctionalRole-
DistinguisherNumber@NameofDomain.The structure should be flexible that some elements are
optional. When these optional fields are added, the name could
still be recognized as the previous one.- Element AttributesEach Naming Element could have zero or more attributes
describing detailed information of the element. The attributes
do not need to be presented in the naming string, but be stored
as metadata in the devices and be reported to the management
system.- Mandatory and Optional Naming ElementsIn above example, the "DistinguisherNumber" and
"NameofDomain" are mandatory whereas others are optional. At
initial stage, the devices might be only capable of
self-generating the mandatory fields and the "DeviceType"
because of the lack of knowledge. Later, they might have learned
the "Location" and "FunctionalRole" and added the fields into
current name. However, the other devices could still recognize
it according to the same "DistinguisherNumber".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 :Device TypeOwnershipLocation. The physical location of the devices MUST be
abbreviated and abstracted, and usually be setted into the
device name feilds of the naming information. How to abbreviate
and abstract the location information, is a policy of the ISP
and out-of-scope of this document.Role and Function. The roles and the functions to be deployed
in the devices MUST be specified in high level words, and
usually be setted into the device function description feilds of
the naming information. It MUST NOT include any detailed
configuration parameters of the roles and functions. How to
define the high level words of each function and role is
out-of-scope of this document.TBD.There are mainly two kinds of naming information, as the
following.- Received Naming ElementsThe 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:Hardware interface. The operator uses some out-of-bind tools
to specify the naming information as a initiail configure file,
and write it to some storage material, such as USB devices, SD
cards and etc. The physical interfaces MUST be supported by the
devices to pluge in the storage materials. In the system
starting up procedure of the devices, it reads the naming
information from the initial setted configure file, and reports
the relation of the ULA addresses and device name to the
centralized tools as described in the following sections of this
document.Software interface. During the first startup of the device
system, the operator uses some in-bind software interfaces (such
as Command Line Interface (CLI), Web Brower and etc) to specify
the naming information as a configure file, and to write it to
its internal storage material, such as FLASH cards. If there is
no naming information configure file, the starting procedure
pauses and wait for the configuration of the naming information.
After the configuration or if there is already an exsting naming
information file, the device continues the starting procedure,
reads out the naming information and reports the relation of the
ULA addresses and device name to the management tools as
described in the following sections of this document.- Self-generated Naming ElementsThe 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.TBD.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.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
() it MUST
respond to 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.The discovery messages send from the AN devices to the centralized
management tool ( or Mangement Proxy) as follows:The value of centralized-tool-address field is zero. Other
fields are followed the specification of GRASP.The response from the Centralized Management Tool (or Mangement
Proxy) will be a M_RESPONSE with the following parameters: The value of centralized-tool-address field in
Centralized-tool-objective is zero. Other fields are followed the
specification of GRASP.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.This method is optional in ANIMA networking.Performs DNS-based Service Discovery over
Multicast DNS searching for the service
"_centralize_management_address.udp.local". To prevent unacceptable
levels of nework traffic the congestion avoidance mechanisms specified
in section 7 MUST be followed. The AN devices
SHOULD listen for an unsolicited broadcast response as described in
. 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 resFor 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.GRASP is used to carry topology information to the NMS/Controller.
(Detailes TBD.)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.TBD.TBD.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 .