Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8194

A YANG Data Model for LMAP Measurement Agents

Pages: 59
Proposed Standard
Part 1 of 3 – Pages 1 to 10
None   None   Next

Top   ToC   RFC8194 - 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   ToC   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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   RFC8194 - 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