RFC 8194
A YANG Data Model for LMAP Measurement Agents
Pages: 59
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 10
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 AgentsAbstract
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.
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 . . . . . . . . . . . . . . . . . . . . . . . 591. 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.
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.
+------------------------+ | 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
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
+--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
+--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
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
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.
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)