[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                                  S. Jiang
Expires: July 10, 2017                      Huawei Technologies Co., Ltd
                                                         January 6, 2017


                Guidelines for Autonomic Service Agents
                draft-carpenter-anima-asa-guidelines-01

Abstract

   This document proposes guidelines for the design of Autonomic Service
   Agents for autonomic networks.  It is based on the Autonomic Network
   Infrastructure outlined in the ANIMA reference model, making use of
   the Autonomic Control Plane and the Generic Autonomic Signaling
   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 July 10, 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




Carpenter & Jiang         Expires July 10, 2017                 [Page 1]


Internet-Draft               ASA Guidelines                 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.  Logical Structure of an Autonomic Service Agent . . . . . . .   3
   3.  Interaction with the Autonomic Networking Infrastructure  . .   4
     3.1.  Interaction with the security mechanisms  . . . . . . . .   4
     3.2.  Interaction with the Autonomic Control Plane  . . . . . .   5
     3.3.  Interaction with GRASP and its API  . . . . . . . . . . .   5
     3.4.  Interaction with Intent mechanism . . . . . . . . . . . .   6
   4.  Design of GRASP Objectives  . . . . . . . . . . . . . . . . .   6
   5.  Life Cycle  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Coordination  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change log [RFC Editor: Please remove] . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document proposes guidelines for the design of Autonomic Service
   Agents (ASAs) in the context of an Autonomic Network (AN) based on
   the Autonomic Network Infrastructure (ANI) outlined in the ANIMA
   reference model [I-D.ietf-anima-reference-model].  This
   infrastructure makes use of the Autonomic Control Plane (ACP)
   [I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic
   Signaling Protocol (GRASP) [I-D.ietf-anima-grasp].

   There is a considerable literature about autonomic agents with a
   variety of proposals about how they should be characterized.  Some
   examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13].
   However, for the present document, the basic definitions and goals
   for autonomic networking given in [RFC7575] apply . According to RFC
   7575, an Autonomic Service Agent is "An agent implemented on an
   autonomic node that implements an autonomic function, either in part
   (in the case of a distributed function) or whole."

   The reference model [I-D.ietf-anima-reference-model] expands this by
   adding that an ASA is "a process that makes use of the features
   provided by the ANI to achieve its own goals, usually including
   interaction with other ASAs via the GRASP protocol
   [I-D.ietf-anima-grasp] or otherwise.  Of course it also interacts



Carpenter & Jiang         Expires July 10, 2017                 [Page 2]


Internet-Draft               ASA Guidelines                 January 2017


   with the specific targets of its function, using any suitable
   mechanism.  Unless its function is very simple, the ASA will need to
   be multi-threaded so that it can handle overlapping asynchronous
   operations.  It may therefore be a quite complex piece of software in
   its own right, forming part of the application layer above the ANI."

   A basic property of an ASA is that it is a relatively complex
   software component that will in many cases control and monitor
   simpler entities in the same host or elsewhere.  For example, a
   device controller that manages tens or hundreds of simple devices
   might contain a single ASA.

   The remainder of this document offers guidance on the design of ASAs.

2.  Logical Structure of an Autonomic Service Agent

   As mentioned above, all but the simplest ASAs will be multi-threaded
   programs.

   A typical ASA will have a main thread that performs various initial
   housekeeping actions such as:

   o  Obtain authorization credentials.

   o  Register the ASA with GRASP.

   o  Acquire relevant policy Intent.

   o  Define data structures for relevant GRASP objectives.

   o  Register with GRASP those objectives that it will actively manage.

   o  Launch a self-monitoring thread.

   o  Enter its main loop.

   The logic of the main loop will depend on the details of the
   autonomic function concerned.  Whenever asynchronous operations are
   required, extra threads will be launched.  Examples of such threads
   include:

   o  A background thread to repeatedly flood an objective to the AN, so
      that any ASA can receive the objective's latest value.

   o  A thread to accept incoming synchronization requests for an
      objective managed by this ASA.





Carpenter & Jiang         Expires July 10, 2017                 [Page 3]


Internet-Draft               ASA Guidelines                 January 2017


   o  A thread to accept incoming negotiation requests for an objective
      managed by this ASA, and then to conduct the resulting negotiation
      with the counterpart ASA.

   o  A thread to manage subsidiary non-autonomic devices directly.

   These threads should all either exit after their job is done, or
   enter a wait state for new work, to avoid blocking other threads
   unnecessarily.

   Note: Possibly an 'event loop' style of implementation could be
   adopted in place of true multi-threading, in which case each of these
   threads would be implemented as an event handler.

   According to the degree of parallelism needed by the application,
   some of these threads might be launched in multiple instances.  In
   particular, if negotiation sessions with other ASAs are expected to
   be long or to involve wait states, the ASA designer might allow for
   multiple simultaneous negotiating threads, with appropriate use of
   queues and locks to maintain consistency.

   The main loop itself could act as the initiator of synchronization
   requests or negotiation requests, when the ASA needs data or
   resources from other ASAs.  In particular, the main loop should watch
   for changes in policy Intent that affect its operation.  It should
   also do whatever is required to avoid unnecessary resource
   consumption, such as including an arbitrary wait time in each cycle
   of the main loop.

   The self-monitoring thread is of considerable importance.  Autonomic
   service agents must never fail.  To a large extent this depends on
   careful coding and testing, with no unhandled error returns or
   exceptions, but if there is nevertheless some sort of failure, the
   self-monitoring thread should detect it, fix it if possible, and in
   the worst case restart the entire ASA.

3.  Interaction with the Autonomic Networking Infrastructure

3.1.  Interaction with the security mechanisms

   An ASA by definition runs in an autonomic node.  Before any normal
   ASAs are started, such nodes must be bootstrapped into the autonomic
   network's secure key infrastructure in accordance with
   [I-D.ietf-anima-bootstrapping-keyinfra].  This key infrastructure
   will be used to secure the ACP (next section) and may be used by ASAs
   to set up additional secure interactions with their peers, if needed.





Carpenter & Jiang         Expires July 10, 2017                 [Page 4]


Internet-Draft               ASA Guidelines                 January 2017


   Note that the secure bootstrap process itself may include special-
   purpose ASAs that run in a constrained insecure mode.

3.2.  Interaction with the Autonomic Control Plane

   In a normal autonomic network, ASAs will run as clients of the ACP.
   It will provide a fully secured network environment for all
   communication with other ASAs, in most cases mediated by GRASP (next
   section).

   Note that the ACP formation process itself may include special-
   purpose ASAs that run in a constrained insecure mode.

3.3.  Interaction with GRASP and its API

   GRASP [I-D.ietf-anima-grasp] is expected to run as a separate process
   with its API [I-D.liu-anima-grasp-api] available in user space.  Thus
   ASAs may operate without special privilege, unless they need it for
   other reasons.  The ASA's view of GRASP is built around GRASP
   objectives (Section 4), defined as data structures containing
   administrative information such as the objective's unique name, and
   its current value.  The format and size of the value is not
   restricted by the protocol, except that it must be possible to
   serialise it for transmission in CBOR [RFC7049], which is no
   restriction at all in practice.

   The GRASP API offers the following features:

   o  Registration functions, so that an ASA can register itself and the
      objectives that it manages.

   o  A discovery function, by which an ASA can discover other ASAs
      supporting a given objective.

   o  A negotiation request function, by which an ASA can start
      negotiation of an objective with a counterpart ASA.  With this,
      there is a corresponding listening function for an ASA that wishes
      to respond to negotiation requests, and a set of functions to
      support negotiating steps.

   o  A synchronization function, by which an ASA can request the
      current value of an objective from a counterpart ASA.  With this,
      there is a corresponding listening function for an ASA that wishes
      to respond to synchronization requests.

   o  A flood function, by which an ASA can cause the current value of
      an objective to be flooded throughout the AN so that any ASA can
      receive it.



Carpenter & Jiang         Expires July 10, 2017                 [Page 5]


Internet-Draft               ASA Guidelines                 January 2017


   For further details and some additional housekeeping functions, see
   [I-D.liu-anima-grasp-api].

   This API is intended to support the various interactions expected
   between most ASAs, such as the interactions outlined in Section 2.
   However, if ASAs require additional communication between themselves,
   they can do so using any desired protocol.  One option is to use
   GRASP discovery and synchronization as a rendez-vous mechanism
   between two ASAs, passing communication parameters such as a TCP port
   number as the value of a GRASP objective.  As noted above, either the
   ACP or in special cases the autonomic key infrastructure will be used
   to secure such communications.

3.4.  Interaction with Intent mechanism

   At the time of writing, the Intent mechanism for the ANI is
   undefined.  It is expected to operate by an information distribution
   mechanism that can reach all autonomic nodes, and therefore every
   ASA.  However, each ASA must be capable of operating "out of the box"
   in the absence of locally defined Intent, so every ASA implementation
   must include carefully chosen default values and settings for all
   parameters and choices that might depend on Intent.

4.  Design of GRASP Objectives

   The general rules for the format of GRASP Objective options, their
   names, and IANA registration are given in [I-D.ietf-anima-grasp].
   Additionally that document discusses various general considerations
   for the design of objectives, which are not repeated here.  However,
   we emphasize that the GRASP protocol does not provide transactional
   integrity.  In other words, if an ASA is capable of overlapping
   several negotiations for a given objective, then the ASA itself must
   use suitable locking techniques to avoid interference between these
   negotiations.  For example, if an ASA is allocating part of a shared
   resource to other ASAs, it needs to ensure that the same part of the
   resource is not allocated twice.  This might impact the design of the
   objective as well as the logic flow of the ASA.

   The actual value field of an objective is limited by the GRASP
   protocol definition to any data structure that can be expressed in
   Concise Binary Object Representation (CBOR) [RFC7049].  For some
   objectives, a single data item will suffice; for example an integer,
   a floating point number or a UTF-8 string.  For more complex cases, a
   simple tuple structure such as [item1, item2, item3] could be used.
   Nothing prevents using other formats such as JSON, but this requires
   the ASA to be capable of parsing and generating JSON.  The formats
   acceptable by the GRASP API will limit the options in practice.  A
   fallback solution is for the API to accept and deliver the value



Carpenter & Jiang         Expires July 10, 2017                 [Page 6]


Internet-Draft               ASA Guidelines                 January 2017


   field in raw CBOR, with the ASA itself encoding and decoding it via a
   CBOR library.

5.  Life Cycle

   Autonomic functions could be permanent, in the sense that ASAs are
   shipped as part of a product and persist throughout the product's
   life.  However, a more likely situation is that ASAs need to be
   installed or updated dynamically, because of new requirements or
   bugs.  Because continuity of service is fundamental to autonomic
   networking, the process of seamlessly replacing a running instance of
   an ASA with a new version needs to be part of the ASA's design.  This
   topic is discussed in detail in "A Day in the Life of an Autonomic
   Function" [I-D.peloso-anima-autonomic-function].

6.  Coordination

   Some autonomic functions will be completely independent of each
   other.  However, others are at risk of interfering with each other -
   for example, two different optimization functions might both attempt
   to modify the same underlying parameter in different ways.  In a
   complete system, a method is needed of identifying ASAs that might
   interfere with each other and coordinating their actions when
   necessary.  This issue is considered in "Autonomic Functions
   Coordination" [I-D.ciavaglia-anima-coordination].

7.  Security Considerations

   ASAs are intended to run in an environment that is protected by the
   Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane],
   admission to which depends on an initial secure bootstrap process
   [I-D.ietf-anima-bootstrapping-keyinfra].  However, this does not
   relieve ASAs of responsibility for security.  In particular, when
   ASAs configure or manage network elements outside the ACP, they must
   use secure techniques and carefully validate any incoming
   information.  As appropriate to their specific functions, ASAs should
   take account of relevant privacy considerations [RFC6973].

   Authorization of ASAs is a subject for future study.

8.  IANA Considerations

   This document makes no request of the IANA.








Carpenter & Jiang         Expires July 10, 2017                 [Page 7]


Internet-Draft               ASA Guidelines                 January 2017


9.  Acknowledgements

   TBD.

10.  References

10.1.  Normative References

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

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-04 (work in progress), October 2016.

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

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>.

10.2.  Informative References

   [DeMola06]
              De Mola, F. and R. Quitadamo, "An Agent Model for Future
              Autonomic Communications", Proceedings of the 7th WOA 2006
              Workshop From Objects to Agents 51-59, September 2006.

   [GANA13]   ETSI GS AFI 002, , "Autonomic network engineering for the
              self-managing Future Internet (AFI): GANA Architectural
              Reference Model for Autonomic Networking, Cognitive
              Networking and Self-Management.", April 2013,
              <http://www.etsi.org/deliver/etsi_gs/
              AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.

   [Huebscher08]
              Huebscher, M. and J. McCann, "A survey of autonomic
              computing--degrees, models, and applications", ACM
              Computing Surveys (CSUR) Volume 40 Issue 3 DOI:
              10.1145/1380584.1380585, August 2008.




Carpenter & Jiang         Expires July 10, 2017                 [Page 8]


Internet-Draft               ASA Guidelines                 January 2017


   [I-D.ciavaglia-anima-coordination]
              Ciavaglia, L. and P. Peloso, "Autonomic Functions
              Coordination", draft-ciavaglia-anima-coordination-01 (work
              in progress), March 2016.

   [I-D.ietf-anima-reference-model]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
              Reference Model for Autonomic Networking", draft-ietf-
              anima-reference-model-02 (work in progress), July 2016.

   [I-D.liu-anima-grasp-api]
              Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic
              Autonomic Signaling Protocol Application Program Interface
              (GRASP API)", draft-liu-anima-grasp-api-02 (work in
              progress), September 2016.

   [I-D.peloso-anima-autonomic-function]
              Pierre, P. and L. Ciavaglia, "A Day in the Life of an
              Autonomic Function", draft-peloso-anima-autonomic-
              function-01 (work in progress), March 2016.

   [Movahedi12]
              Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A
              Survey of Autonomic Network Architectures and Evaluation
              Criteria", IEEE Communications Surveys & Tutorials Volume:
              14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078,
              Page(s): 464 - 490, 2012.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <http://www.rfc-editor.org/info/rfc6973>.

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

Appendix A.  Change log [RFC Editor: Please remove]

   draft-carpenter-anima-asa-guidelines-01, 2017-01-06:

   More sections filled in

   draft-carpenter-anima-asa-guidelines-00, 2016-09-30:



Carpenter & Jiang         Expires July 10, 2017                 [Page 9]


Internet-Draft               ASA Guidelines                 January 2017


   Initial version

Authors' Addresses

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com


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

   Email: jiangsheng@huawei.com






























Carpenter & Jiang         Expires July 10, 2017                [Page 10]


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