Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8194

Proposed STD
Pages: 59
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: LMAP

A YANG Data Model for LMAP Measurement Agents

Part 1 of 3, p. 1 to 10
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                  J. Schoenwaelder
Request for Comments: 8194                      Jacobs University Bremen
Category: Standards Track                                      V. Bajpai
ISSN: 2070-1721                           Technical University of Munich
                                                             August 2017


             A YANG Data Model for LMAP Measurement Agents

Abstract

   This document defines a data model for Large-Scale Measurement
   Platforms (LMAPs).  The data model is defined using the YANG data
   modeling language.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8194.

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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Data Model Overview . . . . . . . . . . . . . . . . . . . . .   3
   3.  Relationship to the Information Model . . . . . . . . . . . .   9
   4.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  LMAP Common YANG Module . . . . . . . . . . . . . . . . .  10
     4.2.  LMAP Control YANG Module  . . . . . . . . . . . . . . . .  18
     4.3.  LMAP Report YANG Module . . . . . . . . . . . . . . . . .  40
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  45
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  48
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  48
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  49
   Appendix A.  Example Parameter Extension Module . . . . . . . . .  51
   Appendix B.  Example Configuration  . . . . . . . . . . . . . . .  53
   Appendix C.  Example Report . . . . . . . . . . . . . . . . . . .  56
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  59
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  59

1.  Introduction

   This document defines a data model for Large-Scale Measurement
   Platforms (LMAPs) [RFC7594].  The data model is defined using the
   YANG [RFC7950] data modeling language.  It is based on the LMAP
   Information Model [RFC8193].

1.1.  Terminology

   This document uses the LMAP terminology defined in [RFC7594].

   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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Tree Diagrams

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in these diagrams is as
   follows:

   o  Brackets "[" and "]" enclose list keys.

Top      ToC       Page 3 
   o  Abbreviations before data node names: "rw" means configuration
      (read-write), "ro" means state data (read-only), and "w" means RPC
      input data (write-only).

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

2.  Data Model Overview

   The LMAP framework has three basic elements: Measurement Agents
   (MAs), Controllers, and Collectors.  Measurement Agents initiate the
   actual measurements, which are called Measurement Tasks in the LMAP
   terminology.  The Controller instructs one or more MAs and
   communicates the set of Measurement Tasks an MA should perform and
   when.  The Collector accepts Reports from the MAs with the Results
   from their Measurement Tasks.

   The YANG data model for LMAP has been split into three modules:

   1.  The module ietf-lmap-common.yang provides common definitions such
       as LMAP-specific data types.

   2.  The module ietf-lmap-control.yang defines the data structures
       exchanged between a Controller and Measurement Agents.

   3.  The module ietf-lmap-report.yang defines the data structures
       exchanged between Measurement Agents and Collectors.

   As shown in Figure 1, a Controller, implementing
   ietf-lmap-common.yang and ietf-lmap-control.yang as a client, will
   instruct Measurement Agents, which implement ietf-lmap-common.yang
   and ietf-lmap-control.yang as servers.  A Measurement Agent,
   implementing ietf-lmap-common.yang and ietf-lmap-report.yang, will
   send results to a Collector, which implements ietf-lmap-common.yang
   and ietf-lmap-report.yang as a server.

Top      ToC       Page 4 
                                         +------------------------+
                                         | LMAP Controller        |
                                         |                        |
                                         | Client:                |
                                         | ietf-lmap-common.yang  |
                                         | ietf-lmap-control.yang |
                                         +------------------------+
     +------------------------+                      |
     | LMAP Measurement Agent |                      |
     |                        |     <- request       |
     | Server:                |<---------------------'
     | ietf-lmap-common.yang  |     response ->
     | ietf-lmap-control.yang |
     |                        |
     |                        |     request ->
     | Client:                |----------------------.
     | ietf-lmap-common.yang  |     <- response      |
     | ietf-lmap-report.yang  |                      |
     +------------------------+                      v
                                         +------------------------+
                                         | LMAP Collector         |
                                         |                        |
                                         | Server:                |
                                         | ietf-lmap-common.yang  |
                                         | ietf-lmap-report.yang  |
                                         +------------------------+

    Figure 1: The LMAP Controller, Measurement Agent, and Collector and
            the YANG Modules They Implement as Client or Server

Top      ToC       Page 5 
   The tree diagram below shows the structure of the control data model.

module: ietf-lmap-control
    +--rw lmap
       +--ro capabilities
       |  +--ro version    string
       |  +--ro tag*       lmap:tag
       |  +--ro tasks
       |     +--ro task* [name]
       |        +--ro name        lmap:identifier
       |        +--ro function* [uri]
       |        |  +--ro uri     inet:uri
       |        |  +--ro role*   string
       |        +--ro version?    string
       |        +--ro program?    string
       +--rw agent
       |  +--rw agent-id?                   yang:uuid
       |  +--rw group-id?                   string
       |  +--rw measurement-point?          string
       |  +--rw report-agent-id?            boolean
       |  +--rw report-group-id?            boolean
       |  +--rw report-measurement-point?   boolean
       |  +--rw controller-timeout?         uint32
       |  +--ro last-started                yang:date-and-time
       +--rw tasks
       |  +--rw task* [name]
       |     +--rw name        lmap:identifier
       |     +--rw function* [uri]
       |     |  +--rw uri     inet:uri
       |     |  +--rw role*   string
       |     +--rw program?    string
       |     +--rw option* [id]
       |     |  +--rw id       lmap:identifier
       |     |  +--rw name?    string
       |     |  +--rw value?   string
       |     +--rw tag*        lmap:identifier

Top      ToC       Page 6 
       +--rw schedules
       |  +--rw schedule* [name]
       |     +--rw name               lmap:identifier
       |     +--rw start              event-ref
       |     +--rw (stop)?
       |     |  +--:(end)
       |     |  |  +--rw end?               event-ref
       |     |  +--:(duration)
       |     |     +--rw duration?          uint32
       |     +--rw execution-mode?    enumeration
       |     +--rw tag*               lmap:tag
       |     +--rw suppression-tag*   lmap:tag
       |     +--ro state              enumeration
       |     +--ro storage            yang:gauge64
       |     +--ro invocations        yang:counter32
       |     +--ro suppressions       yang:counter32
       |     +--ro overlaps           yang:counter32
       |     +--ro failures           yang:counter32
       |     +--ro last-invocation?   yang:date-and-time
       |     +--rw action* [name]
       |        +--rw name                      lmap:identifier
       |        +--rw task                      task-ref
       |        +--rw parameters
       |        |  +--rw (extension)?
       |        +--rw option* [id]
       |        |  +--rw id       lmap:identifier
       |        |  +--rw name?    string
       |        |  +--rw value?   string
       |        +--rw destination*              schedule-ref
       |        +--rw tag*                      lmap:tag
       |        +--rw suppression-tag*          lmap:tag
       |        +--ro state                     enumeration
       |        +--ro storage                   yang:gauge64
       |        +--ro invocations               yang:counter32
       |        +--ro suppressions              yang:counter32
       |        +--ro overlaps                  yang:counter32
       |        +--ro failures                  yang:counter32
       |        +--ro last-invocation           yang:date-and-time
       |        +--ro last-completion           yang:date-and-time
       |        +--ro last-status               lmap:status-code
       |        +--ro last-message              string
       |        +--ro last-failed-completion    yang:date-and-time
       |        +--ro last-failed-status        lmap:status-code
       |        +--ro last-failed-message       string

Top      ToC       Page 7 
       +--rw suppressions
       |  +--rw suppression* [name]
       |     +--rw name            lmap:identifier
       |     +--rw start?          event-ref
       |     +--rw end?            event-ref
       |     +--rw match*          lmap:glob-pattern
       |     +--rw stop-running?   boolean
       |     +--ro state           enumeration
       +--rw events
          +--rw event* [name]
             +--rw name                    lmap:identifier
             +--rw random-spread?          uint32
             +--rw cycle-interval?         uint32
             +--rw (event-type)?
                +--:(periodic)
                |  +--rw periodic
                |     +--rw interval    uint32
                |     +--rw start?      yang:date-and-time
                |     +--rw end?        yang:date-and-time
                +--:(calendar)
                |  +--rw calendar
                |     +--rw month*             lmap:month-or-all
                |     +--rw day-of-month*      lmap:day-of-months-or-all
                |     +--rw day-of-week*       lmap:weekday-or-all
                |     +--rw hour*              lmap:hour-or-all
                |     +--rw minute*            lmap:minute-or-all
                |     +--rw second*            lmap:second-or-all
                |     +--rw timezone-offset?   lmap:timezone-offset
                |     +--rw start?             yang:date-and-time
                |     +--rw end?               yang:date-and-time
                +--:(one-off)
                |  +--rw one-off
                |     +--rw time    yang:date-and-time
                +--:(immediate)
                |  +--rw immediate               empty
                +--:(startup)
                |  +--rw startup                 empty
                +--:(controller-lost)
                |  +--rw controller-lost         empty
                +--:(controller-connected)
                   +--rw controller-connected    empty

Top      ToC       Page 8 
   The tree diagram below shows the structure of the reporting data
   model.

   module: ietf-lmap-report

     rpcs:
       +---x report
          +---w input
             +---w date                 yang:date-and-time
             +---w agent-id?            yang:uuid
             +---w group-id?            string
             +---w measurement-point?   string
             +---w result*
                +---w schedule?       lmap:identifier
                +---w action?         lmap:identifier
                +---w task?           lmap:identifier
                +---w parameters
                |  +---w (extension)?
                +---w option* [id]
                |  +---w id       lmap:identifier
                |  +---w name?    string
                |  +---w value?   string
                +---w tag*            lmap:tag
                +---w event?          yang:date-and-time
                +---w start           yang:date-and-time
                +---w end?            yang:date-and-time
                +---w cycle-number?   lmap:cycle-number
                +---w status          lmap:status-code
                +---w conflict*
                |  +---w schedule-name?   lmap:identifier
                |  +---w action-name?     lmap:identifier
                |  +---w task-name?       lmap:identifier
                +---w table*
                   +---w function* [uri]
                   |  +---w uri     inet:uri
                   |  +---w role*   string
                   +---w column*     string
                   +---w row*
                      +---w value*   string

Top      ToC       Page 9 
3.  Relationship to the Information Model

   The LMAP Information Model [RFC8193] is divided into six aspects.
   They are mapped into the YANG data model as explained below:

   o  Preconfiguration Information: This is not modeled explicitly since
      bootstrapping information is outside the scope of this data model.
      Implementations may use some of the Configuration Information also
      for bootstrapping purposes.

   o  Configuration Information: This is modeled in the /lmap/agent
      subtree, the /lmap/schedules subtree, and the /lmap/tasks subtree
      described below.  Some items have been left out because they are
      expected to be dealt with by the underlying protocol.

   o  Instruction Information: This is modeled in the /lmap/suppressions
      subtree, the /lmap/schedules subtree, and the /lmap/tasks subtree
      described below.

   o  Logging Information: Some of the Logging Information, in
      particular 'success/failure/warning messages in response to
      information updates from the Controller', will be handled by the
      protocol used to manipulate the LMAP-specific configuration.  The
      LMAP data model defined in this document assumes that runtime
      Logging Information will be communicated using protocols that do
      not require a formal data model, e.g., the syslog protocol defined
      in [RFC5424].

   o  Capability and Status Information: Some of the Capability and
      Status Information is modeled in the /lmap/capability subtree.
      The list of supported Tasks is modeled in the /lmap/capabilities/
      task list.  Status Information about Schedules and Actions is
      included in the /lmap/schedules subtree.  Information about
      network interfaces can be obtained from the ietf-interfaces YANG
      data model [RFC7223].  Information about the hardware and the
      firmware can be obtained from the ietf-system YANG data model
      [RFC7317].  A device identifier can be obtained from the ietf-
      hardware YANG data model [YANG-HARDWARE].

   o  Reporting Information: This is modeled by the report data model to
      be implemented by the Collector.  Measurement Agents send results
      to the Collector by invoking an RPC on the Collector.

   These six Information Model aspects use a collection of common
   information objects.  These common information objects are
   represented in the YANG data model as follows:

   o  Schedules: Schedules are modeled in the /lmap/schedules subtree.

Top      ToC       Page 10 
   o  Channels: Channels are not modeled since the NETCONF server
      configuration data model [NETCONF-CLIENT-SERVER] already provides
      a mechanism to configure NETCONF server Channels.

   o  Task Configurations: Configured Tasks are modeled in the /lmap/
      tasks subtree.

   o  Event Information: Event definitions are modeled in the /lmap/
      events subtree.



(page 10 continued on part 2)

Next Section