Network Working Group                                       T. Burbridge
Internet-Draft                                                P. Eardley
Intended status: Standards Track                         British Telecom
Expires: August 18, 2014                                      M. Bagnulo
                                        Universidad Carlos III de Madrid
                                                        J. Schoenwaelder
                                                Jacobs University Bremen
                                                       February 14, 2014

     Information Model for Large-Scale Measurement Platforms (LMAP)


   This Information Model applies to the Measurement Agent within a
   Large-Scale Measurement Platform.  As such it outlines the
   information that is (pre-)configured on the MA or exists in
   communications with a Controller or Collector within an LMAP
   framework.  The purpose of such an Information Model is to provide a
   protocol and device independent view of the MA that can be
   implemented via one or more Control and Report protocols.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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

   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 August 18, 2014.

Copyright Notice

Burbridge, et al.        Expires August 18, 2014                [Page 1]

Internet-Draft           LMAP Information Model            February 2014

   Copyright (c) 2014 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
   ( 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  LMAP Information Model . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Information Structure  . . . . . . . . . . . . . . . . . .  4
     3.2.  Pre-Configuration Information  . . . . . . . . . . . . . .  5
     3.3.  Configuration Information  . . . . . . . . . . . . . . . .  6
     3.4.  Instruction Information  . . . . . . . . . . . . . . . . .  7
     3.5.  MA to Controller Information . . . . . . . . . . . . . . . 11
     3.6.  Capability and Status Information  . . . . . . . . . . . . 13
     3.7.  Reporting Information  . . . . . . . . . . . . . . . . . . 14
     3.8.  Channels . . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.9.  Timing Information . . . . . . . . . . . . . . . . . . . . 16
       3.9.1.  Periodic Timing  . . . . . . . . . . . . . . . . . . . 17
       3.9.2.  Calendar Timing  . . . . . . . . . . . . . . . . . . . 17
       3.9.3.  One-Off Timing . . . . . . . . . . . . . . . . . . . . 18
       3.9.4.  Immediate Timing . . . . . . . . . . . . . . . . . . . 18
       3.9.5.  Timing Randomness  . . . . . . . . . . . . . . . . . . 18
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20

Burbridge, et al.        Expires August 18, 2014                [Page 2]

Internet-Draft           LMAP Information Model            February 2014

1.  Introduction

   A large-scale measurement platform is a collection of components that
   work in a coordinated fashion to perform measurements from a large
   number of vantage points.  The main components of a large-scale
   measurement platform are the Measurement Agents (hereafter MAs), the
   Controller(s) and the Collector(s).

   The MAs are the elements actually performing the measurements.  The
   MAs are controlled by exactly one Controller at a time and the
   Collectors gather the results generated by the MAs.  In a nutshell,
   the normal operation of a large-scale measurement platform starts
   with the Controller instructing a set of one or more MAs to perform a
   set of one or more Measurement Tasks at a certain point in time.  The
   MAs execute the instructions from a Controller, and once they have
   done so, they report the results of the measurements to one or more
   Collectors.  The overall framework for a Large Measurement platform
   as used in this document is described in detail in

   A large-scale measurement platform involves basically three
   protocols, namely, a Control protocol between a Controller and the
   MAs, a Report protocol between the MAs and the Collector(s) and
   several measurement protocols between the MAs and Measurement Peers
   (MPs), used to actually perform the measurements.  In addition some
   information is required to be provisioned in the MA prior to any
   communication with the initial Controller.

   This document defines the information model for both the Control and
   the Report protocol along with pre-configuration information that is
   required before communicating with the Controller, broadly named as
   the LMAP Information Model (or LMAP IM for short).  The measurement
   protocols are out of the scope of this document.

   As defined in [RFC3444], the LMAP IM defines the concepts involved in
   a large-scale measurement platform at a high level of abstraction,
   independent of any specific implementation or actual protocol used to
   exchange the information.  It is expected that the proposed
   information model can be used with different protocols in different
   measurement platform architectures and across different types of MA
   devices (e.g., home gateway, smartphone, PC, router).

   The definition of an Information Model serves a number of purposes:

   1.  To guide the standardisation of one or more Control and Report
       protocol and data model implementations

Burbridge, et al.        Expires August 18, 2014                [Page 3]

Internet-Draft           LMAP Information Model            February 2014

   2.  To enable high-level inter-operability between different Control
       and Report protocols by facilitating translation between their
       respective data models such that a Controller could instruct sub-
       populations of MAs using different protocols

   3.  To from agreement of what information needs to be held by an MA
       and passed over the Control and Report interfaces and support the
       functionality described in the LMAP framework

   4.  Enable existing protocols and data models to be assessed for
       their suitability as part of a large-scale measurement system

2.  Notation

   This document use an adaptation of the C-style struct notation to
   define the fields (names/values) of the objects of the information
   model.  An optional field is enclosed by [ ], and an array is
   indicated by two numbers in angle brackets, <m..n>>, where m
   indicates the minimal number of values, and n is the maximum.  The
   symbol * for n means no upper bound.

3.  LMAP Information Model

3.1.  Information Structure

   The information described herein relates to the information stored,
   received or transmitted by a Measurement Agent as described within
   the LMAP framework [I-D.ietf-lmap-framework].  As such, some subsets
   of this information model are applicable to the measurement
   Controller, Collector and systems that pre-configure the Measurement
   Agent.  The information described in these models will be transmitted
   across the protocols and interfaces between the Measurement Agent and
   such systems according to a Data Model.

   For clarity the information model is divided into six sections:

   1.  Pre-Configuration Information.  Information pre-configured on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture (i.e., the Controller,
       Collector and Measurement Peers), specifically detailing how to
       communicate with an initial Controller and whether the device is
       enabled to participate as an MA.

   2.  Configuration Information.  Information delivered to the MA on
       registration with a Controller or updated during a later
       communication, in particular detailing how to retrieve

Burbridge, et al.        Expires August 18, 2014                [Page 4]

Internet-Draft           LMAP Information Model            February 2014

       measurement and reporting instruction information from a
       Controller along with information specifically about the MA.

   3.  Instruction Information.  Information that is received by the MA
       from the Controller pertaining to the measurement and reporting
       configuration.  This includes measurement configuration, report
       channel configuration, measurement schedules and measurement
       suppression information.

   4.  MA to Controller Information.  Information transmitted from the
       MA to the Controller detailing the results of any configuration
       operations along with error and status information from the
       operation of the MA.

   5.  Capability and Status Information.  Information on the general
       status and capabilities of the MA.  For example, the set of
       measurements that are supported on the device.

   6.  Reporting Information.  Information transmitted from the MA to
       the Collector including measurement results and the context in
       which they were conducted.

   In addition the MA may hold further information not described herein,
   and which may be optionally transferred to or from other systems
   including the Controller and Collector.  One example of information
   in this category is subscriber or line information that may be
   reported by the MA as optional fields in the reporting communication
   to a Collector.

   It should also be noted that the MA may be in communication with
   other management systems which may be responsible for configuring and
   retrieving information from the MA device.  Such systems, where
   available, can perform an important role in transferring the pre-
   configuration information to the MA or enabling/disabling the
   measurement functionality of the MA.

   The Information Model is divided into sub-sections for a number of
   reasons.  Firstly the grouping of information facilitates reader
   understanding.  Secondly, the particular groupings chosen are
   expected to map to different protocols or different transmissions
   within those protocols.

3.2.  Pre-Configuration Information

   This information is the minimal information that needs to be pre-
   configured to the MA in order for it to successfully communicate with
   a Controller during the registration process.

Burbridge, et al.        Expires August 18, 2014                [Page 5]

Internet-Draft           LMAP Information Model            February 2014

   This pre-configuration information needs to include a URL of the
   initial Controller where configuration information can be retrieved
   along with the security information required for the communication
   including the certificate of the Controller (or the certificate of
   the Certification Authority which was used to issue the certificate
   for the Controller) as well as the timing for that communication.
   All this is expressed as the Instruction Channel.  As part of the
   Instruction Channel, the MA's security information is configured
   which can be either a certificate and a private key or a password,
   depending on the security solution used.

   The MA may already be pre-configured with an MA ID, or may use a
   Device ID in the initial Controller contact before it is assigned an
   MA ID.  The Device ID may be a MAC address or some other device
   identifier expressed as a URN.

   Detail of the information model elements:

   object {
       ma-channel-obj      ma-instruction-channel;
       ma-channel-obj      ma-ma-to-controller-channel;
       [urn                ma-device-id;]
       [uuid               ma-agent-id;]
   } ma-preconfig-obj;

   The detail of the Channel object is described later since it is
   common to several parts of the information model.

3.3.  Configuration Information

   During registration or at any later point at which the MA contacts
   the Controller, the choice of Controller and details for the timing
   of communication with the Controller can be changed (as captured by
   the Instruction Channel information object).  For example the pre-
   configured Controller may be replaced with a specific Controller that
   is more appropriate to the MA device type, location or
   characteristics of the network (e.g. access technology type or
   broadband product).  The initial communication timing object may be
   replaced with one more relevant to routine communications between the
   MA and the Controller.

   In addition the MA will be given further items of information that
   relate specifically to the MA rather than the measurements it is to
   conduct or how to report results.  The assignment of an ID to the MA
   is mandatory.  Optionally a Group ID may also be given which
   identifies a group of interest to which that MA belongs.  For example
   the group could represent an ISP, broadband product, technology,
   market classification, geographic region, or a combination of

Burbridge, et al.        Expires August 18, 2014                [Page 6]

Internet-Draft           LMAP Information Model            February 2014

   multiple such characteristics.  Where the Measurement Group ID is set
   an additional flag (the Report MA ID flag) is required to control
   whether the Measurement Agent ID is also to be reported.  The
   reporting of a Group ID without the MA ID allows the MA to remain
   anonymous, which may be particularly useful to prevent tracking of
   mobile MA devices.

   Optionally an MA can also be configured to stop Measurement Tasks if
   the Controller is unreachable.  This can be used as a fail-safe to
   stop Measurement Tasks being conducted when there is doubt that the
   Instruction Information is still valid.  This is simply represented
   as a number of failed communication attempts before Measurement Tasks
   are suspended.  The appropriate number of failed attempts will depend
   on the timing of the Instruction Channel and the duration for which
   the system is willing to tolerate continued operation with
   potentially stale Instruction Information.

   Detail of the additional information model elements:

   object {
       uuid                ma-agent-id;
       ma-channel-obj      ma-instruction-channel;
      [string              ma-group-id;]
      [boolean             ma-report-ma-id-flag;]
      [int                 ma-instruction-channel-failure-threshold;]
   } ma-config-obj;

3.4.  Instruction Information

   The Instruction information model has four sub-elements:

   1.  Measurement Task Configurations

   2.  Report Channels

   3.  Measurement Schedules

   4.  Measurement Suppression

   Conceptually each Measurement Task Configuration defines the
   parameters of a Measurement Task that the Measurement Agent (MA) may
   perform at some point in time.  It does not by itself actually
   instruct the MA to perform them at any particular time (this is done
   by a Measurement Schedule).

Burbridge, et al.        Expires August 18, 2014                [Page 7]

Internet-Draft           LMAP Information Model            February 2014

   Example:  A Measurement Task Configuration may configure a single
      Measurement Task for measuring UDP latency.  The Measurement Task
      Configuration could define the destination port and address for
      the measurement as well as the duration, internal packet timing
      strategy and other parameters (for example a stream for one hour
      and sending one packet every 500 ms).  It may also define the
      output type and possible parameters (for example the output type
      can be the 95th percentile mean) where the measurement task
      accepts such parameters.  It does NOT define when the task starts
      (this is defined by the Measurement Schedule element), so it does
      not by itself instruct the MA to actually perform this measurement

   The Measurement Task Configuration will include a local short name
   for reference by the Measurement Schedule, along with a registry
   entry [I-D.bagnulo-ippm-new-registry] that defines the Measurement
   Task.  The MA itself will resolve the registry entry to a local
   executable program.  In addition the Measurement Task is specialised
   through a set of configuration Options.  The nature and number of
   these Options will depend upon the Measurement Task and will be
   defined in the Measurement Task Registry.  In addition the
   Measurement Task Configuration may optionally also be given a
   Measurement Cycle ID.  The purpose of this ID is to easily identify a
   set of measurement results that have been produced by Measurement
   Tasks with comparable Options.  This ID is manually incremented when
   an Option change is implemented which could mean that two sets of
   results should not be directly compared.

   A Report Channel defines how to report results to a single Collector.
   Several Report Channels can be defined to enable results to be split
   or duplicated across different report intervals or destinations.
   E.g. a single Collector may have three Report Channels, one reporting
   hourly, another reporting daily and a third on which to send
   immediate results for on-demand measurement tasks.  Alternatively
   multiple Report Channels can be used to send Measurement Task results
   to different Collectors.  The details of the Channel element is
   described later as it is common to several objects.

   A Measurement Schedule contains the Instruction from the Controller
   to the MA to execute a single or repeated series of Measurement
   Tasks.  Each Measurement Schedule contains basically two elements: a
   reference to a list of Measurement Task Configuration and a timing
   object for the schedule.  The schedule basically states what
   measurement task to run, how to report the results per Measurement
   Task Configuration, and when to run the measurement task.  Multiple
   measurement tasks in the list will be executed in order with minimal
   gaps.  Note that the Controller can instruct the MA to report to
   several Collectors by specifying several Report Channels.

Burbridge, et al.        Expires August 18, 2014                [Page 8]

Internet-Draft           LMAP Information Model            February 2014

   Each Measurement Task Configuration named in the Measurement Schedule
   can be allocated to independent Report Channels, giving flexibility
   to report different Measurement Tasks to different Collectors or on
   different timings.  Furthermore, as each Measurement Task may have
   multiple data outputs, these outputs can each be assigned to
   different Report Channels.  For example a Measurement Task might
   report routine results hourly via the Broadband PPP interface, but
   also output emergency conditions immediately via a GPRS channel.

   Example:  a Measurement Schedule references a single Measurement Task
      Configuration for the UDP latency defined in the previous example.
      It references the Report Channel in the previous example to send
      results immediately as available to the specified Collector.  The
      timing is specified to run the configured Measurement Task
      Configuration every hour at 23 minutes past the hour.

   Measurement Suppression information is used to over-ride the
   Measurement Schedule and stop measurements from the MA for a defined
   or indefinite period.  While conceptually measurements can be stopped
   by simply removing them from the Measurement Schedule, splitting out
   separate information on Measurement Suppression allows this
   information to be updated on the MA on a different timing cycle or
   protocol implementation to the Measurement Schedule.  It is also
   considered that it will be easier for a human operator to implement a
   temporary explicit suppression rather than having to move to a
   reduced Schedule and then roll-back at a later time.  The explicit
   Suppression instruction message is able to simply enable/disable all
   Measurement Tasks as well as having fine control on which Tasks are
   suppressed.  Suppression of both specified Measurement Tasks
   Configurations and Measurement Schedules is supported.  Support for
   disabling specific Measurement Task Configurations allows
   malfunctioning or mis-configured Measurement Tasks or Measurement
   Task Configurations that have an impact on a particular part of the
   network infrastructure (e.g., a particular Measurement Peer) to be
   targetted.  Support for disabling specific Measurement Schedules
   allows for particularly heavy cycles or sets of less essential
   Measurement Tasks to be suppressed quickly and effectively.

   Unsuppression is achieved through either overwriting the Measurement
   Suppression information (e.g. changing 'enabled' to False) or through
   the use of an End time such that the Measurement Suppression will no
   longer be in effect beyond this time.

   The goal when defining these four different elements is to allow each
   part of the information model to change without affecting the other
   three elements.  For example it is envisaged that the Report Channels
   and the set of Measurement Tasks Configurations will be relatively
   static.  The Measurement Schedule on the other hand is likely to be

Burbridge, et al.        Expires August 18, 2014                [Page 9]

Internet-Draft           LMAP Information Model            February 2014

   more dynamic as the measurement panel and test frequency are changed
   for various business goals.  Another example is that measurements can
   be suppressed with a Measurement Suppression command without removing
   the existing Measurement Schedules that would continue to apply after
   the Measurement Suppression expires or is removed.  In terms of the
   Controller-MA communication this can reduce the data overhead.  It
   also encourages the re-use of the same standard Measurement Task
   Configurations and Reporting Channels to help ensure consistency and
   reduce errors.

   Definition of the information model elements:

   object {
       ma-task-obj         ma-tasks<0..*>;
       ma-channel-obj      ma-report-channels<0..*>;
       ma-schedule-obj     ma-schedules<0..*>;
       ma-suppression-obj  ma-suppression;
   } ma-instruction-obj;

   object {
       string              ma-task-name;
       urn                 ma-task-registry;
       string              ma-task-options<0..*>;
      [string              ma-task-cycle-id;]
   } ma-task-obj;

   object {
       string              ma-schedule-name;
       ma-sched-task-obj   ma-schedule-tasks<0..*>;
       ma-timing-obj       ma-schedule-timing;
   } ma-schedule-obj;

   object {
       string              ma-schedule-task-name;
       ma-sched-report-obj ma-schedule-task-reports<0..*>;
   } ma-sched-task-obj;

   object {
      [int                 ma-schedule-task-filter;]  // default: all
       string              ma-schedule-task-report-channel-name;
   } ma-sched-report-obj;

Burbridge, et al.        Expires August 18, 2014               [Page 10]

Internet-Draft           LMAP Information Model            February 2014

   object {
       boolean             ma-suppression-enabled;
      [datetime            ma-suppression-start;] // default: immediate
      [datetime            ma-suppression-end;]   // default: indefinite
      [string              ma-suppression-task-names<0..*>;]
                           // default: all tasks if
                           // ma-suppression-task-names is empty
      [string              ma-suppression-schedule-names<0..*>;]
                           // default: all schedules if
                           // ma-suppression-schedule-names is empty
   } ma-suppression-obj;

3.5.  MA to Controller Information

   The MA may report on the success or failure of Configuration or
   Instruction communications from the Controller.  In addition further
   operational logs may be produced during the operation of the MA and
   updates to capabilities may also be reported.  Reporting this
   information is achieved simply and flexibly in exactly the same
   manner as any Measurement Task.  We make no distinction between a
   Measurement Task conducting an active or passive network measurement
   and one which solely retrieves static information from the MA such as
   logging information.  One or more logging tasks can be programmed or
   configured to capture subsets of the MA to Controller Information.
   These logging tasks are then executed by Measurement Schedules (if
   not permanently running) and the resultant data assigned to the MA to
   Controller Channel.

   The type of MA to Controller Information will fall into three
   different categories:

   1.  Success/failure/warning messages in response to information
       updates from the Controller.  Failure messages could be produced
       due to some inability to receive or parse the Controller
       communication, or if the MA is not able to act as instructed.
       For example:

       *  "Measurement Schedules updated OK"

       *  "Unable to parse JSON"

       *  "Missing mandatory element: Measurement Timing"

       *  "'Start' does not conform to schema - expected datetime"

       *  "Date specified is in the past"

Burbridge, et al.        Expires August 18, 2014               [Page 11]

Internet-Draft           LMAP Information Model            February 2014

       *  "'Hour' must be in the range 1..24"

       *  "Schedule A refers to non-existent Measurement Task

       *  "Measurement Task Configuration X registry entry Y not found"

       *  "Updated Measurement Task Configurations do not include M used
          by Measurement Schedule N"

   2.  Operational updates from the MA.  For example:

       *  "Out of memory: cannot record result"

       *  "Collector '' not responding"

       *  "Unexpected restart"

       *  "Suppression timeout"

       *  "Failed to execute Measurement Task Configuration H"

   3.  Status updates from the MA.  For example:

       *  "Interface added: eth3 "

       *  "Supported measurements updated"

       *  "New IP address on eth0:"

   This Information Model document does not detail the precise format of
   logging information since it is to a large extend protocol and
   measurement task specific.  However, some common information can be

   MA Logging information model elements:

   object {
       uuid                ma-log-agent-id;
       datetime            ma-log-event-time;
       code                ma-log-code;
       string              ma-log-description;
   } ma-log-obj;

Burbridge, et al.        Expires August 18, 2014               [Page 12]

Internet-Draft           LMAP Information Model            February 2014

3.6.  Capability and Status Information

   The MA will hold Capability Information that can be retrieved by a
   Controller.  Capabilities include the interface details available to
   Measurement Tasks and Reports as well as the set of Measurement Tasks
   that are actually installed or available on the MA.  Status
   information includes the times that operations were last performed
   such as contacting the Controller or producing Reports.

   MA Status information model elements:

   object {
       uuid                ma-agent-id;
       urn                 ma-device-id;
       string              ma-hardware;
       string              ma-firmware;
       string              ma-software;
       ma-interface-obj    ma-interfaces<0..*>;

       datetime            ma-last-measurement;
       datetime            ma-last-report;
       datetime            ma-last-instruction;
       datetime            ma-last-configuration;

       ma-capability-obj   ma-supported-measurements<0..*>;
   } ma-status-obj;

   object {
       string              ma-interface-name;
       string              ma-interface-type;
       int                 ma-interface-speed;  // mbps
       string              ma-link-layer-address;
       ip-address          ma-interface-ip-addresses<0..*>;
      [ip-address          ma-interface-gateways<0..*>;]
      [ip-address          ma-interface-dns-servers<0..*>;]
   } ma-interface-obj;

   object {
       urn                 ma-measurement-id;
      [string              ma-measurement-version;]
   } ma-capability-obj;

Burbridge, et al.        Expires August 18, 2014               [Page 13]

Internet-Draft           LMAP Information Model            February 2014

3.7.  Reporting Information

   At a point in time specific by the Report Channel, the MA will
   communicate a set of measurement results to the Collector.  These
   measurement results should be communicated within the context in
   which they were collected.

   It should be noted that Collectors can be implemented by many types
   of devices and systems, including the MA itself.  In this manner data
   from Measurement Tasks can (also) be stored locally on the MA and
   used as input by other Measurement Tasks.  This facilitates using a
   first Measurement Task to control the operation of a later
   Measurement Task (such as probing available line speed) and also to
   allow local processing of data to output alarms (e.g. when
   performance drops from earlier levels).

   The report is structured hierarchically to avoid repetition of
   report, Measurement Agent and Measurement Task Configuration
   information.  The report starts with the timestamp of the report
   generation on the MA and details about the MA including the optional
   Measurement Agent ID and Group ID (controlled by the Configuration
   Information).  In addition optional further MA context information
   can be included at this point such as the line sync speed or ISP and
   product if known by the MA.

   After the MA information the results are reported grouped into the
   different Measurement Tasks.  Each Measurement Task starts with
   replicating the Measurement Task Configuration information before the
   result headers (titles for data columns) and the result data rows.
   The result data rows may optionally include an indication of the
   cross-traffic (e.g., the total number of octets of non-measurement
   traffic passing through the interfaces used by a Measurement Task
   during the measurement period).

   The datetime format used for all elements in the information model
   (i.e., Report Date and Measurement Time in the Reporting Information)
   MUST conform to RFC 3339 [RFC3339] and ISO8601.

   Information model elements:

   object {
       datetime            ma-report-date;
      [uuid                ma-report-agent-id;]
      [string              ma-report-group-id;]
       ma-context-obj      ma-report-context<0..*>;
       ma-report-task-obj  ma-report-tasks<0..*>;
   } ma-report-obj;

Burbridge, et al.        Expires August 18, 2014               [Page 14]

Internet-Draft           LMAP Information Model            February 2014

   object {
       ma-task-obj         ma-report-task-config;
       string              ma-report-task-column-headers<0..*>;
       ma-result-row-obj   ma-report-task-rows<0..*>;
   } ma-report-task-obj;

   object {
       datetime            ma-report-result-time;
      [int                 ma-report-result-cross-traffic;]
       data                ma-report-result-values<0..*>;
   } ma-result-row-obj;

   The ma-context-obj, which covers things like line speed or the device
   type, is not further detailed here.

3.8.  Channels

   A Channel defines a communication channel between the MA and other
   element of the measurement framework i.e. with the Collector to
   report results back, to Controller to retrieve Instructions or other
   information exchanged between the parties.  Several Channels can be
   defined to enable results to be split or duplicated across different
   report intervals or destinations.  E.g. a single Collector may have
   three Report Channels, one reporting hourly, another reporting daily
   and a third on which to send immediate results for on-demand
   measurement tasks.

   Each Channel contains the details of the target (including location
   and security information such as the certificate), and the timing for
   the communication i.e. when to establish the communication.  The
   certificate can be the digital certificate associated to the FQDN in
   the URL or it can be the certificate of the Certification Authority
   that was used to issue the certificate for the FQDN (Fully Qualified
   Domain Name) of the target URL (which will be retrieved later on
   using a communication protocol such as SSL).  The Channel can use the
   same timing information object as a Measurement Schedule and the
   Controller Communication Timing defined earlier.  There are several
   options, such as immediately after the results are obtained or at a
   given interval or calendar based cycle).  As with the Measurement
   task Configuration, each Channel is also given a local short name by
   which it can be referenced from a Measurement Schedule or other

   As for Measurement Tasks, multiple interfaces are also supported.
   For example the Controller could choose to receive some results over
   GPRS.  This is especially useful when such results indicate the loss
   of connectivity on a different network interface.

Burbridge, et al.        Expires August 18, 2014               [Page 15]

Internet-Draft           LMAP Information Model            February 2014

   Facility is also provided for the Controller to choose whether to
   receive empty reports where there is no Measurement Task information.
   In some cases this may be desirable to monitor the health of the
   measurement system.

   Example:  A Channel using for reporting results may specify that
      results are to be sent to the URL
      (, using the appropriate digital
      certificate to establish a secure channel.  The Channel specifies
      that the results are to be sent immediately as available and not

   object {
       string              ma-channel-name;
       url                 ma-channel-target;
       certificate         ma-channel-certificate;
       ma-timing-obj       ma-channel-timing;
      [string              ma-channel-interface-name;]
      [boolean             ma-channel-connect-always;]
                           // default: false
                           // (only connect when data is pending)
   } ma-channel-obj;

3.9.  Timing Information

   The Timing information object used throughout the information models
   can take one of four different forms:

   1.  Periodic.  Specifies a start, end and interval time in

   2.  Calendar: Specifies a calendar based pattern - e.g. 22 minutes
       past each hour of the day on weekdays

   3.  One Off: A single instance occurring at a specific time

   4.  Immediate: Should occur as soon as possible

   Optionally each of the first three options may also specify a
   randomness that should be evaluated and applied separately to each
   indicated event.

   The datetime format used for all elements in the information model
   (i.e., Report Date and Measurement Time in the Reporting Information)
   MUST conform to RFC 3339 [RFC3339] and ISO8601.

Burbridge, et al.        Expires August 18, 2014               [Page 16]

Internet-Draft           LMAP Information Model            February 2014

   object {
      [string              ma-timing-name;]
      union {
          ma-periodic-obj  ma-timing-periodic;
          ma-calendar-obj  ma-timing-calendar;
          ma-one-off-obj   ma-timing-one-off;
          ma-immediate-obj ma-timing-immediate;
      [ma-randomness-obj   ma-timing-randomness;]
   } ma-timing-obj;

3.9.1.  Periodic Timing

   Information model elements:

   object {
      [datetime            ma-periodic start;]   // default: immediate
      [datetime            ma-periodic-end;]     // default: indefinite
       int                 ma-periodic-interval; // milliseconds
   } ma-periodic-obj;

3.9.2.  Calendar Timing

   Calendar Timing supports the routine execution of Measurement Tasks
   at specific times and/or on specific dates.  It can support more
   flexible timing than Periodic Timing since the Measurement Task
   execution does not have to be uniformly spaced.  For example a
   Calendar Timing could support the execution of a Measurement Task
   every hour between 6pm and midnight on weekdays only.

   Calendar Timing is also required to perform measurements at
   meaningful instances in relation to network usage (e.g., at peak
   times).  If the optional timezone offset is not supplied then local
   system time is assumed.  This is essential in some use cases to
   ensure consistent peak-time measurements as well as supporting MA
   devices that may be in an unknown timezone or roam between different
   timezones (but know their own timezone information such as through
   the mobile network).

   Information model elements:

Burbridge, et al.        Expires August 18, 2014               [Page 17]

Internet-Draft           LMAP Information Model            February 2014

   object {
      [datetime            ma-calendar-start;] // default: immediate
      [datetime            ma-calendar-end;]   // default: indefinite
      [int                 ma-calendar-months<0..*>;]   // default: 1-12
      [days                ma-calendar-weekdays<0..*>;] // default: all
      [int                 ma-calendar-hours<0..*>;]    // default: 0-23
      [int                 ma-calendar-minutes<0..*>;]  // default: 0-59
      [int                 ma-calendar-seconds<0..*>;]  // default: 0-59
      [int                 ma-calendar-timezone-offset;]
                           // default: system timezone offset
   } ma-calendar-obj;

3.9.3.  One-Off Timing

   Information model elements:

   object {
       datetime            ma-one-off-time;
   } ma-one-off-obj;

3.9.4.  Immediate Timing

   The immediate timing object has no further information elements.  The
   measurement or report is simply to be done as soon as possible.

   object {
                           // empty
   } ma-immediate-obj;

3.9.5.  Timing Randomness

   The Timing randomness object specifies a random distribution that can
   be applied to any scheduled execution event such as a measurement or
   report.  The intention it to be able to spread the load on the
   Controller, Collector and network in an automated manner for a large
   number of Measurement Agents.  The randomness is expressed as a
   distribution (e.g.  Poison, Normal, Uniform etc.) along with the
   spread over which the distribution should be applied.  In additional
   optional upper and lower bounds can be applied to control extreme
   spread of timings.

   Information model elements:

   object {
       string              ma-randomness-distribution;
      [int                 ma-randomness-lower-cut;]
      [int                 ma-randomness-upper-cut;]
       int                 ma-randomness-spread;

Burbridge, et al.        Expires August 18, 2014               [Page 18]

Internet-Draft           LMAP Information Model            February 2014

   } ma-randomness-obj;

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

5.  Security Considerations

   This Information Model deals with information about the control and
   reporting of the Measurement Agent.  There are broadly two security
   considerations for such an Information Model.  Firstly the
   Information Model has to be sufficient to establish secure
   communication channels to the Controller and Collector such that
   other information can be sent and received securely.  Additionally,
   any mechanisms that the Network Operator or other device
   administrator employs to pre-configure the MA must also be secure to
   protect unauthorized parties from modifying pre-configuration
   information.  The second consideration is that no mandated
   information items pose a risk to confidentiality or privacy given
   such secure communication channels.  For this latter reason items
   such as the MA context and MA ID are left optional and can be
   excluded from some deployments.  This would, for example, allow the
   MA to remain anonymous and for information about location or other
   context that might be used to identify or track the MA to be omitted
   or blurred.

6.  Acknowledgements

   The notation was inspired by the notation used in the ALTO protocol

   Philip Eardley, Trevor Burbridge, Marcelo Bagnulo and Juergen
   Schoenwaelder work in part on the Leone research project, which
   receives funding from the European Union Seventh Framework Programme
   [FP7/2007-2013] under grant agreement number 317647.

7.  References

Burbridge, et al.        Expires August 18, 2014               [Page 19]

Internet-Draft           LMAP Information Model            February 2014

7.1.  Normative References

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

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

7.2.  Informative References

              Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
              A. Morton, "A registry for commonly used metrics",
              draft-bagnulo-ippm-new-registry-01 (work in progress),
              July 2013.

              Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and A. Akhter, "A framework for large-scale
              measurement platforms (LMAP)",
              draft-ietf-lmap-framework-03 (work in progress),
              January 2014.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              January 2003.

Authors' Addresses

   Trevor Burbridge
   British Telecom
   Adastral Park, Martlesham Heath
   Ipswich,   IP5 3RE
   United Kingdom

   Philip Eardley
   British Telecom
   Adastral Park, Martlesham Heath
   Ipswich,   IP5 3RE
   United Kingdom

Burbridge, et al.        Expires August 18, 2014               [Page 20]

Internet-Draft           LMAP Information Model            February 2014

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid,   28911

   Juergen Schoenwaelder
   Jacobs University Bremen
   Campus Ring 1
   Bremen,   28759

Burbridge, et al.        Expires August 18, 2014               [Page 21]