[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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
                draft-nmdt-anima-management-bootstrap-00

Abstract

   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 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 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
   (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




Duan, et al.             Expires January 4, 2018                [Page 1]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problems and Requirments  . . . . . . . . . . . . . . . . . .   3
   4.  Autonomic Structured Naming . . . . . . . . . . . . . . . . .   4
     4.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Name Format and Content . . . . . . . . . . . . . . . . .   5
       4.2.1.  Structured Naming Format  . . . . . . . . . . . . . .   5
       4.2.2.  Naming Content  . . . . . . . . . . . . . . . . . . .   5
     4.3.  Autonomic Naming Approaches . . . . . . . . . . . . . . .   6
       4.3.1.  Received and Self-generated Naming Elements . . . . .   6
       4.3.2.  Naming Metadata Storage . . . . . . . . . . . . . . .   7
   5.  Network Management Server/Controller Discovery  . . . . . . .   7
     5.1.  GRASP Method  . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  mDNS Method . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Topology Discovery and Collection . . . . . . . . . . . . . .   8
     6.1.  Local Topoloty Discovery  . . . . . . . . . . . . . . . .   8
     6.2.  Topology Collection by NMS/Controller . . . . . . . . . .   9
   7.  Device Names and Topoloty Mapping in the NMS/Controller . . .   9
   8.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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.





Duan, et al.             Expires January 4, 2018                [Page 2]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   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:

   o  AN: Autonomic Nodes.

   o  NMS: Networking Management System.

   o  EMS: Element Management System.

   o  NE: Networking Element.

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



Duan, et al.             Expires January 4, 2018                [Page 3]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   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:

   o  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.

   o  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.

   o  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.

4.  Autonomic Structured Naming

4.1.  Requirements

   - Representing each device

   o  Inside a domain, each autonomic device needs a domain specific
      identifier.

   - Uniqueness

   o  The names MUST NOT collide within one autonomic domain.

   o  It is acceptable that the names in different domains collide,
      since they could be distinguished by domains.

   - Semantic Encoding

   o  It 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.

   - Consistency




Duan, et al.             Expires January 4, 2018                [Page 4]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   o  The devices' naming SHOULD follow the same pattern within a
      domain.

4.2.  Name Format and Content

4.2.1.  Structured Naming Format

   - Naming Elements

      The 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 Attributes

      Each 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 Elements

      In 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".

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 :

   o  Device Type

   o  Ownership





Duan, et al.             Expires January 4, 2018                [Page 5]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   o  Location.  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.

   o  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.

   o  TBD.

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:

   o  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.

   o  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,



Duan, et al.             Expires January 4, 2018                [Page 6]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


      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 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

   TBD.

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.

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

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





Duan, et al.             Expires January 4, 2018                [Page 7]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   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:

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

              Figure 6: Centralized Management Tool Response

   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.

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.







Duan, et al.             Expires January 4, 2018                [Page 8]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


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

   TBD.

9.  IANA Considerations

   TBD.

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.






Duan, et al.             Expires January 4, 2018                [Page 9]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


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", draft-behringer-anima-
              reference-model-04 (work in progress), October 2015.

   [I-D.ietf-anima-autonomic-control-plane]
              Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
              Control Plane", draft-ietf-anima-autonomic-control-
              plane-06 (work in progress), March 2017.

   [I-D.ietf-anima-grasp]
              Bormann, C., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-14 (work in progress), July 2017.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

   [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,
              <http://www.rfc-editor.org/info/rfc7575>.

   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
              Analysis for Autonomic Networking", RFC 7576,
              DOI 10.17487/RFC7576, June 2015,
              <http://www.rfc-editor.org/info/rfc7576>.

Authors' Addresses

   Fanghong Duan
   Huawei Technologies
   N8, Huawei Campus
   No. 101 Ruanjian Road
   Yu-Hua-Tai District, Nanjing  210000
   P.R. China

   Email: duanfanghong@huawei.com




Duan, et al.             Expires January 4, 2018               [Page 10]


Internet-Draft    draft-nmdt-anima-management-bootstrap        July 2017


   Bing Liu (editor)
   Huawei Technologies
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China

   Email: leo.liubing@huawei.com


   Yongkang Zhang
   Huawei Technologies
   N8, Huawei Campus
   No. 101 Ruanjian Road
   Yu-Hua-Tai District, Nanjing  210000
   P.R. China

   Email: zhangyongkang@huawei.com

































Duan, et al.             Expires January 4, 2018               [Page 11]


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