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

Versions: 00

Network Working Group                                             B. Liu
Internet-Draft                                                  S. Jiang
Intended status: Standards Track                     Huawei Technologies
Expires: December 14, 2015                                 June 12, 2015


              Intent Distribution for Autonomic Networking
                 draft-liu-anima-intent-distribution-00

Abstract

   This document describes the requirements of distributing intent
   information in an autonomic network.  Ideally, the intent may be
   generated/injected at an arbitrary autonomic node and be distributed
   among the whole autonomic domain.  Then this document resolves the
   distribution requirements into protocol design requirements.
   Specifically, this document introduces a solution which is some
   extension based on the Anima signalling protocol (GDNP, Generic
   Discovery and Negotiation Protocol).

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 December 14, 2015.

Copyright Notice

   Copyright (c) 2015 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



Liu & Jiang             Expires December 14, 2015               [Page 1]


Internet-Draft             Intent distribution                 June 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Intent Distribution Requirements  . . . . . . . . . . . . . .   2
     2.1.  Distributed to the Whole Domain . . . . . . . . . . . . .   3
       2.1.1.  Autonomic Domain Boundary . . . . . . . . . . . . . .   3
     2.2.  De-coupling of Intent Content and Bearing Protocol  . . .   3
     2.3.  Avoiding Signaling Storm  . . . . . . . . . . . . . . . .   3
     2.4.  Arbitary Intent Injecting Point (Optional)  . . . . . . .   3
     2.5.  Conflict Handling (Optional)  . . . . . . . . . . . . . .   3
   3.  Protocol Design . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Protocol Requirements . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Multicast and Unicast Communication . . . . . . . . .   4
       3.1.2.  Messages Interaction  . . . . . . . . . . . . . . . .   4
       3.1.3.  Fragmentation Considerations  . . . . . . . . . . . .   5
     3.2.  Intent Distribution over Anima Signaling Protocol . . . .   5
       3.2.1.  Intent Option . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Node Behavior . . . . . . . . . . . . . . . . . . . .   6
       3.2.3.  Flooding Control  . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document describes the requirements of distributing intent
   information in an autonomic network.  Ideally, the intent may be
   generated/injected at an arbitrary autonomic node and be distributed
   among the whole autonomic domain.  Then this document resolves the
   distribution requirements into protocol design requirements.
   Specifically, this document introduces a solution which is some
   extension based on the Anima signalling protocol (GDNP, Generic
   Discovery and Negotiation Protocol).

2.  Intent Distribution Requirements








Liu & Jiang             Expires December 14, 2015               [Page 2]


Internet-Draft             Intent distribution                 June 2015


2.1.  Distributed to the Whole Domain

   When the intent is injected at an arbitrary autonomic node, the node
   MUST be able to distribute it to the whole nodes in the domain.  This
   requirement does not necessarily mean the node need to send the
   intent to all nodes through unicast or multicast all by itself; there
   might be distribution function infrastructure that could be used/
   triggered by the node.

2.1.1.  Autonomic Domain Boundary

   The domain boundary devices are supposed to know themselves as
   boundary.When the messages come to the devices, they won't distribute
   them anymore so that the messages are only distributed with the
   domain.

   [Editor's Notes] It is a practical issue that how an autonomic node
   knows itself is the domain boundary.  It is not in the scope of this
   document.

2.2.  De-coupling of Intent Content and Bearing Protocol

   The content of intent SHOULD NOT be coupled with the bearing
   protocol.

2.3.  Avoiding Signaling Storm

   If flooding mechanism is used, then there should be a mechanism to
   prevent the packets which carrying the intent to travel around the
   domain again and again.

2.4.  Arbitary Intent Injecting Point (Optional)

   The intent SHOULD be injected at any autonomic node, rather than a
   pre-specified Node.

   Discuss: may be only within a group of autonomic nodes, it supports
   input at "any" node.

2.5.  Conflict Handling (Optional)

   So long as it supports arbitrary point where to inject an intent,
   there is possibility that two nodes advertise the same intent but
   with different contents.  Hence, there should be a mechanism to
   handle the conflicted intent.






Liu & Jiang             Expires December 14, 2015               [Page 3]


Internet-Draft             Intent distribution                 June 2015


3.  Protocol Design

3.1.  Protocol Requirements

3.1.1.  Multicast and Unicast Communication

   The following communication modes need to be supported to distribute
   intents.

   o  On Link Multicast

         This is a basic distribution behavior.  The message is
         multicasted to all the other nodes on the same link.

   o  Off Link Multicast

         Normally, an autonomic domain is not only limited within a
         link.  Thus, off link multicast is needed to reach the other
         nodes out of the initiator's link.

         When there is off-link multicast, there needs to be flooding
         control mechanisms as described in Section 3.2.3.

   o  Point to Point

         Besides multicast, the intent might be distributed only between
         two nodes.  Thus, point to point unicast communication is also
         needed.

3.1.2.  Messages Interaction

   The following message interaction modes need to be supported.

   o  Unsolicited advertisement

         This is the most typical use case of intent distribution.  The
         intent is advertised by one of the autonomic node and flooded
         to all the others in the same autonomic domain.  The process is
         stateless ,which means there is no need to pre-establish
         connections between autonomic nodes for intent exchange, hence
         the autonomic nodes are always monitoring the intent coming.

         [Editor's Note] This document doesn't achieve unsolicit
         advertisement for intent as a new explicit message type,
         instead, it is by the ASA interpreting the Intent Option
         (defined below) and resolving it into GDNP synchronization
         behavior at each hop.  However, Unsolicit Advertisement might
         be a generic function that reused by various ASA.  So, if the



Liu & Jiang             Expires December 14, 2015               [Page 4]


Internet-Draft             Intent distribution                 June 2015


         ANIMA signalling is going to provide such function at message
         level in the future, this document would update accordingly.

   o  Request-Response

         This is mostly for point-to-point intent exchange.  For
         example, when a new device gets online, it request intent from
         it's neighbor, then the neighbor will distribute the common
         intent that shared among all the nodes within the autonomic
         domain to the new device.

3.1.3.  Fragmentation Considerations

   Since the intent distribution runs over GDNP, it does not provide any
   explicit fragmentation/reassembly support.

   [Editor's Note] However, there might be concern that when an intent
   packet needs to be split, it might need to be split into fragments
   each of which could be interpreted individually, thus there is no
   need to wait for the assembling of all fragments.  However, this is
   only a hypothetical use case.

3.2.  Intent Distribution over Anima Signaling Protocol

   Since there is a signalling protocol under development in Anima
   working group, it is reasonable to leverage the current protocol to
   do intent distribution.

   This section makes some extension to the signalling protocol to
   fulfil the requirements described above.  Specifically, the extension
   is based on the 03 version of the GDNP protocol
   [I-D.carpenter-anima-gdn-protocol] .

3.2.1.  Intent Option

   The content of intent is encapsulated as a dedicated option, so that
   it could be carried by various type of messages if needed.














Liu & Jiang             Expires December 14, 2015               [Page 5]


Internet-Draft             Intent distribution                 June 2015


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         OPTION_INTENT         |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|  Flood TTL  |    Reserved   |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Domain ID of the Source Node of the Message           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TBD                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Intent Content                        |
   |          (variable length, Supporting arbitrary format)       |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OPTION_INTENT:  Identifies the Intent Option type.  16-bit.

   option-len:  Length of the whole intent.  16-bit.

   F bit:  Flooding flag bit.  When the flag is set, it means the intent
      needs to be flooded.

   Flood TTL:  Limits the hops that an Intent message could travel.
      8-bit.

   Reserved:  Set to zero, ignored on receipt.  8-bit.

   Sequence Number:  A sequence number to identify an intent option.
      16-bit.  Each time one node sends an Intent Option, the sequence
      number MUST be increased.

   Node ID:  Identifies the source of the Intent Option. 32-bit.  This
      documents assumes that each autonomic nodes has a Node ID
      available after the bootstrapping process described in
      [I-D.pritikin-anima-bootstrapping-keyinfra] . The Node ID may
      generated based on the domain certificate issued to the node
      during bootstrapping.

   Intent Content:  The intent content, such as the intent specified in
      [I-D.du-anima-an-intent].

3.2.2.  Node Behavior

   o  Initiating Node

      a) Assuming there is an ASA in charge of the intent distribution.




Liu & Jiang             Expires December 14, 2015               [Page 6]


Internet-Draft             Intent distribution                 June 2015


      b) The ASA generates the Intent Option and calls the GDNP module
         to send the Intent Option in a Request Message (as defined in
         Section 3.6.4 of [I-D.carpenter-anima-gdn-protocol] ).

      c) If this is a flooding intent, the ASA sets the F flag and calls
         the GDNP module to multicast the message to all it's neighbors
         in a Discovery Message (as defined in Section 3.6.2 of
         [I-D.carpenter-anima-gdn-protocol] ).

   o  Receiving Node

      a) Assuming there is an ASA in charge of the intent distribution.

      b) The GDNP module extracts the Intent Option and handle it up to
         the ASA.

      c) If the F flag is not set, the node calls the GDNP module to
         response a Negotiation-Ending message with a Accept Option; if
         set, then no need to response.  [Open Question] Does nodes need
         to response for the flooding intent?

      d) If it is a flooding intent, the node multicast the option again
         to all it's neighbors.

   [Editor's Note] The behavior as described above could also be
   achieved through Usolicit Synchronization message/function which was
   briefly discussed in the previous version of GDNP.  If the
   Unsolicited Synchronization is added back to the GDNP, this document
   should also consider the relevant solution accordingly.

3.2.3.  Flooding Control

   o  Loop Avoidance

         When messages are flooded off link, it is highly possible that
         the message would be flooded back to the initiator again, thus
         there would be a large amount of duplicated messages circling
         around the network.  So, there needs to be relevant mechanism
         to avoid/limit the packets loop.

         To achieve this goal, the nodes need to do the following
         actions:

         a) The node maintains a flooding state table which stores each
            interface's record that whether a specific intent option had
            been received or sent from it.  The option identification
            could be the combination of the Sequence Number and Node ID
            in the Intent Option.



Liu & Jiang             Expires December 14, 2015               [Page 7]


Internet-Draft             Intent distribution                 June 2015


         b) The node MUST NOT send a flooding Intent Option message to
            the interfaces that had received or sent the same Intent
            Option.

   o  Flooding TTL

         In case an Intent is occasionally looped around, the Flooding
         TTL is to guarantee the packet would not travel in a infinite
         loop in the network.

   [Open Question] Is Flooding TTL a redundant field?

4.  Security Considerations

   Intents could significantly influence the network nodes' behavior, so
   authentication is strongly required.

   However, the authentication could be done at multiple layers:

   o  Outer layer authentication: the ASAs' communication is within a
      protected channel such as ACP (Autonomic Control Plane,
      [I-D.behringer-anima-autonomic-control-plane] ).

   o  Inner layer authentication: the ASAs' communication might not be
      within a protected channel, then there should be embedded
      protection in intent distribution itself.

   [Open Question] As described in section 7.3 of
   [I-D.irtf-nmrg-autonomic-network-definitions], intent distribution is
   considered as a function of the ACP.  Do we consider to remove this
   limitation?  ACP is a good secure channel for distributing intent,
   but maybe not a mandatory channel.

5.  IANA Considerations

   TBD.

6.  Acknowledgements

   This document is inherited from [I-D.carpenter-anima-gdn-protocol]
   and [I-D.behringer-anima-reference-model].  So thanks all the
   contributors of the two work items.

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







Liu & Jiang             Expires December 14, 2015               [Page 8]


Internet-Draft             Intent distribution                 June 2015


7.  References

7.1.  Normative References

   [I-D.carpenter-anima-gdn-protocol]
              Carpenter, B. and B. Liu, "A Generic Discovery and
              Negotiation Protocol for Autonomic Networking", draft-
              carpenter-anima-gdn-protocol-03 (work in progress), April
              2015.

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

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

7.2.  Informative References

   [I-D.behringer-anima-autonomic-control-plane]
              Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
              Autonomic Control Plane", draft-behringer-anima-autonomic-
              control-plane-02 (work in progress), March 2015.

   [I-D.behringer-anima-reference-model]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              and B. Liu, "A Reference Model for Autonomic Networking",
              draft-behringer-anima-reference-model-01 (work in
              progress), April 2015.

   [I-D.irtf-nmrg-autonomic-network-definitions]
              Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking - Definitions and Design Goals", draft-irtf-
              nmrg-autonomic-network-definitions-07 (work in progress),
              March 2015.

   [I-D.pritikin-anima-bootstrapping-keyinfra]
              Pritikin, M., Behringer, M., and S. Bjarnason,
              "Bootstrapping Key Infrastructures", draft-pritikin-anima-
              bootstrapping-keyinfra-01 (work in progress), February
              2015.

Authors' Addresses








Liu & Jiang             Expires December 14, 2015               [Page 9]


Internet-Draft             Intent distribution                 June 2015


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

   Email: leo.liubing@huawei.com


   Sheng Jiang
   Huawei Technologies
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China

   Email: jiangsheng@huawei.com

































Liu & Jiang             Expires December 14, 2015              [Page 10]


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