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

     Information Model for Large-Scale Measurement Platforms (LMAP)
                  draft-ietf-lmap-information-model-00
                  draft-ietf-lmap-information-model-01

Abstract

   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, December 28, 2014.

Copyright Notice

   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
   (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  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  LMAP Information Model  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Information Structure . . . . . . . . . . . . . . . . . .   4
     3.2.  Pre-Configuration Information . . . . . . . . . . . . . .  5   8
     3.3.  Configuration Information . . . . . . . . . . . . . . . .  6   9
     3.4.  Instruction Information . . . . . . . . . . . . . . . . .  7  10
     3.5.  MA to Controller  Logging Information . . . . . . . . . . . . . . . 11 . . . .  13
     3.6.  Capability and Status Information . . . . . . . . . . . . 13  15
     3.7.  Reporting Information . . . . . . . . . . . . . . . . . . 14  16
     3.8.  Schedules . . . . . . . . . . . . . . . . . . . . . . . .  18
     3.9.  Channels  . . . . . . . . . . . . . . . . . . . . . . . .  20
     3.10. Task Configurations . . 15
     3.9. . . . . . . . . . . . . . . . . .  21
     3.11. Timing Information  . . . . . . . . . . . . . . . . . . . . 16
       3.9.1.  22
       3.11.1.  Periodic Timing  . . . . . . . . . . . . . . . . . . . 17
       3.9.2.  23
       3.11.2.  Calendar Timing  . . . . . . . . . . . . . . . . . . . 17
       3.9.3.  23
       3.11.3.  One-Off Timing . . . . . . . . . . . . . . . . . . . . 18
       3.9.4.  24
       3.11.4.  Immediate Timing . . . . . . . . . . . . . . . . . . . 18
       3.9.5.  24
       3.11.5.  Startup Timing Randomness . . . . . . . . . . . . . . . . . . 18 .  25
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19  25
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . 19  25
   6.  Acknowledgements  Appendix: JSON Example  . . . . . . . . . . . . . . . . . . .  25
   7.  Acknowledgements  . . . . 19
   7.  References . . . . . . . . . . . . . . . . . .  34
   8.  References  . . . . . . . . 20
     7.1. . . . . . . . . . . . . . . . . .  34
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 20
     7.2.  34
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 20  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 20  34

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
   [I-D.ietf-lmap-framework].

   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 configured on 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). Model.  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

   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 form 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 object-oriented programming-like notation to
   define the fields parameters (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
   by protocols and using 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 a Controller and whether the device is enabled
       to participate as an MA.

   2.  Configuration Information.  Information delivered to  Update of the pre-configuration
       information during the MA on registration with a Controller of the MA or updated during a later
       communication, in particular detailing how to retrieve
       measurement and reporting instruction information from a
       Controller subsequent
       communication with the Controller, along with information specifically the configuration
       of further parameters about the MA. MA (rather than the Tasks it
       should perform) that were not mandatory for the initial
       communication between the MA and a Controller.

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

   4.  MA to Controller Information.  Information transmitted from the
       MA to task execution Schedules (other than
       the Controller detailing the results of any configuration
       operations along with error communication Schedule supplied as
       (pre)configuration information) and status related information from the
       operation of such as
       the MA.

   5.  Capability and Task Configuration, communication Channels to Collectors and
       schedule Timing information.  It also inlcudes Task Suppression
       information that is used to over-ride normal Task execution
       during emergency situations.

   4.  Logging 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
   extracted by a task and 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.

   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

   The granularity of the Controller (or the certificate data transmitted in each operation of the Certification Authority which was used to issue the certificate
   for the Controller) as well as the timing for that communication.
   All this Control
   and Report Protocols is expressed as not dictated by the Instruction Channel.  As part of Information Model.  For
   example, the Instruction Channel, the MA's security information is configured
   which can object may be either delivered in a certificate single
   operation.  Alternatively, Schedules and a private key or a password,
   depending on the security solution used.

   The MA Task Configurations may already be pre-configured with an MA ID,
   separated or even each Schdule/Task Configuration may use a
   Device ID in be delivered
   individually.  Similarly the initial Controller contact before it Information Model does not dictate
   whether data is assigned an
   MA ID.  The Device ID may be a MAC address read, write, or read/write.  For example, some other device
   identifier expressed as a URN.

   Detail of
   Control Protocols may have 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 ability to several parts of the information model.

3.3. read back Configuration Information

   During registration or at any later point at and
   Instruction information which have been previosuly set on the MA contacts
   the Controller, MA.
   Lastly, while some protocols may simply overwrite information (for
   example refreshing the choice of Controller and details for entire Instruction Information), other
   protocols may have the timing ability to update or delete selected items of communication with the Controller can be changed (as
   information.

   The information in these six sections is captured by
   the Instruction Channel a number of
   common information object).  For example objects.  These objects are also described later
   in this document and comprise of:

   1.  Schedules.  A set of Schedules tell the pre-
   configured Controller may be replaced with MA to do something.
       Without a specific Controller that
   is more appropriate Schedule no Task (from a measurement to the MA device type, location reporting or
   characteristics of
       communicating with the network (e.g. access technology type or
   broadband product).  The initial communication timing object may Controller) is ever executed.  Schedules
       are used within the Instruction to specify what tasks should be
   replaced with one more relevant
       performed, when, and how to routine communications between direct their results.  A Schedule is
       also used within the
   MA pre-Configuration and the Controller.

   In addition the MA will be given further items of Configuration
       information that
   relate specifically in order to execute the MA rather than the measurements it is to
   conduct Task or how to report results.  The assignment of an ID Tasks required to
       communicate with the MA
   is mandatory.  Optionally a Group ID may also be given which
   identifies a group Controller.

   2.  Channels.  A set of interest Channel objects are used to which that MA belongs.  For example
   the group could represent an ISP, broadband product, technology,
   market classification, geographic region, or communicate with
       a combination number of
   multiple such characteristics.  Where endpoints (i.e. the Measurement Group ID is set
   an additional flag (the Report MA ID flag) is Controller and Collectors).  Each
       Channel object contains the information required to control
   whether for the Measurement Agent ID is also to be reported.  The
   reporting of
       communication with a Group ID without the MA ID allows single endpoint such as the MA to remain
   anonymous, which may be particularly useful target location
       and security details.  Channels are referenced from within
       Schedules in order to prevent tracking say how Tasks should communicate.

   3.  Task Configurations.  A set of
   mobile MA devices.

   Optionally an MA can also be configured Task Configurations is used to stop Measurement
       configure the Tasks if that are run by the Controller is unreachable. MA.  This can be used as includes the
       registry entry for the Task and any configuration parameters.
       Task Configurations are referenced from a fail-safe Schedule in order to
   stop Measurement
       specify what Tasks being conducted when there is doubt the MA should execute.

   4.  Timings.  A set of Timing objects that can be referenced from the
   Instruction Information is still valid.  This is simply represented
   as
       Schedules.  Each Schedule always references exactly one Timing
       object.  A Timing object specfies either a number singleton or series of failed communication attempts before Measurement Tasks
       time events.  They are suspended. used to indicate when Tasks should be
       executed.

   The appropriate number of failed attempts will depend
   on the timing of the Instruction Channel and following diagram illustrates the duration for structure in which
   the system is willing to tolerate continued operation with
   potentially stale Instruction Information.

   Detail of the additional these common
   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 objects are referenced.  The Instruction information model has four sub-elements:

   1.  Measurement Task Configurations

   2.  Report Channels

   3.  Measurement Schedules

   4.  Measurement Suppression

   Conceptually references are achieved by
   each Measurement object (Channel, Task Configuration defines Configuration, Timing) being given a short
   text name that is used by other objects.  The objects shown in
   brackets are part of the
   parameters internal object structure of a Measurement Schedule.

          Schedule
              |----------> Timing
              |----------> (Scheduled Tasks)
                                   |----------> Task that the Measurement Agent (MA) may
   perform at some point in time. Configuration
                                   |----------> (Task datasets)
                                                      |----------> Channels
                                                      |----------> Ouput Tasks

   It does not by itself actually
   instruct should be clear that the general capability of an MA is simply to perform them at any particular time (this
   execute Schedules.  Every other action of an MA is done implemented as a
   Task.  As such, these actions are configured through Task
   Configurations and executed according to the Timing referenced by the
   Schedule in which they appear.  Tasks can implement a variety of
   different types of actions.  While in terms of the Information Model,
   all Tasks have the same information, it can help conceptually to
   think of different Task categories:

   1.  Measurement Schedule).

   Example:  A Tasks

       A.  Active Measurement Task Configuration may configure Tasks implement an active measurement
           protocol to a single
      Measurement Task for measuring UDP latency.  The remote network host

       B.  Passive Measurement Task
      Configuration could define Tasks analyse traffic passing through the destination port
           MA device or traffic that may be eavesdropped

       C.  Data Capture Tasks capture and address for analyse passive information
           stored on the measurement as well MA device such as the duration, internal packet timing
      strategy and other parameters (for example a stream for one hour counters and sending one packet every 500 ms).  It may also define device/network
           status information

   2.  Data Transfer Tasks

       A.  Reporting Tasks report the
      output type and possible parameters (for example results or Measurement Tasks to
           Collectors

       B.  Control Task(s) implement the output type
      can be Control Protocol and
           communicate with the 95th percentile mean) where Controller.  Depending on the measurement task
      accepts Control
           Protocol this may be a number of specialist tasks such parameters.  It does NOT define when the task starts
      (this is defined by the as:
           Configuration Task; Instruction Task; Suppression Task;
           Capabilities Task; Logging Task etc.

   3.  Data Analysis Tasks can exist to analyse data from other
       Measurement Schedule element), so it does
      not by itself instruct Tasks locally on the MA

   4.  Data Management Tasks may exist to actually perform this measurement
      task.

   The clean-up, filter or compress
       data on the MA such as Measurement Task Configuration will include a local short name
   for reference by results

3.2.  Pre-Configuration Information

   This information is the Measurement Schedule, along with a registry
   entry [I-D.bagnulo-ippm-new-registry] minimal information that defines needs to be pre-
   configured to the Measurement
   Task.  The MA itself will resolve the registry entry in order for it to successfully communicate with
   a local
   executable program.  In addition Controller during the Measurement Task registration process.  The pre-configuration
   information is specialised
   through a set subset of configuration Options.  The nature and number the Configuration Information along with
   some parameters that are not under the control of
   these Options will depend upon the Measurement Task and will be
   defined in LMAP framework
   (such as 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 device identifier and device security credentials).

   This pre-configuration information needs to easily identify include a
   set URL of measurement results that have been produced by Measurement
   Tasks the
   initial Controller where configuration information can be retrieved
   along with comparable Options.  This ID is manually incremented when
   an Option change is implemented which could mean that two sets the security information required for the communication
   including the certificate of
   results should not be directly compared.

   A Report Channel defines how to report results the Controller (or the certificate of
   the Certification Authority which was used to issue the certificate
   for the Controller).  All this is expressed as a single Collector.
   Several Report Channels can Channel.  Multiple
   channels may be defined to enable results given to be split
   or duplicated across the Controller (such as over different report intervals
   interfaces or destinations.
   E.g. a single Collector may have three Report Channels, one reporting
   hourly, another reporting daily network protocols).

   Where the MA pulls information from the Controller, the Pre-
   Configuration Information also needs to contain the timing of the
   communication with the Controller as well as the nature of the
   communication itself (such as the protocol and a third on which data to send
   immediate results for on-demand measurement tasks.  Alternatively
   multiple Report Channels can be used to send Measurement Task results
   to different Collectors.
   transfered).  The details of the Channel element timing is
   described later given as it a Schedule that executes the
   Task(s) responsible for communication with the Controller.  It is common
   this Task (or Tasks) that implement the Control protocol between the
   MA and the Controller.  The Task(s) may take additional parameters in
   which case a Task Configuration can also be included.

   Even where information is pushed to several objects.

   A Measurement Schedule contains the Instruction MA from the Controller
   to
   (rather than pulled by the MA to execute MA), a single or repeated series of Measurement
   Tasks.  Each Measurement Schedule contains basically two elements: a
   reference still needs to be
   supplied.  In this case the Schedule will simply execute a list of Measurement Task Configuration and a timing
   object for the schedule.  The schedule basically states what
   measurement Controller
   listener 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 MA is started.  A Channel is still required
   for the MA to report to
   several Collectors by specifying several Report Channels.

   Each Measurement Task Configuration named in establish secure communication with the Measurement Schedule Controller.

   It can be allocated to independent Report seen that these Channels, giving flexibility
   to report Schedules and Task Configurations
   for the initial MA-Controller communication are no different Measurement Tasks in terms
   of the Information Model to different Collectors any other Channel, Schedule 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
   Configuration that might execute a Measurement Task might or report routine results hourly via the Broadband PPP interface, but
   also output emergency conditions immediately via a GPRS channel.

   Example:  a Measurement Schedule references
   measurement results (as described later).

   The MA may be pre-configured with an MA ID, or may use a single Measurement Task
      Configuration for the UDP latency defined in the previous example.
      It references the Report Channel Device ID in
   the previous example to send
      results immediately 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 available to a URN.

   Detail of the specified Collector.  The
      timing is specified information model elements:

// MA pre-configuration minimal information to run the configured Measurement Task
      Configuration every hour at 23 minutes past communicate initially with Controller

object {
    [uuid                ma-agent-id;]
     ma-task-obj         ma-control-tasks<0..*>;
     ma-channel-obj      ma-control-channels<1..*>;
     ma-schedule-obj     ma-control-schedules<0..*>;
    [urn                 ma-device-id;]
     credentials         ma-credentials;
} ma-config-obj;

   The detail of the hour.

   Measurement Suppression information is used Channel and Schedule objects are described later
   since they are common to over-ride several parts of the
   Measurement Schedule and stop measurements from information model.

3.3.  Configuration Information

   During registration or at any later point at which the MA contacts
   the Controller (or vice-versa), the choice of Controller, details for a defined
   the timing of communication with the Controller or indefinite period.  While conceptually measurements parameters for the
   communication Task(s) can be stopped changed (as captured by simply removing them from the Measurement Schedule, splitting out
   separate information on Measurement Suppression allows this
   information to be updated on Channels,
   Schedules and Task Configurations objects).  For example the MA on pre-
   configured Controller (specified as a different timing cycle Channel or
   protocol implementation Channels) may be
   replaced with a specific Controller that is more appropriate to the Measurement Schedule.  It is also
   considered that it will
   MA device type, location or characteristics of the network (e.g.
   access technology type or broadband product).  The initial
   communication Schedule may be easier for a human operator replaced with one more relevant to implement
   routine communications between the MA and the Controller.

   While some Control protocols and uses may only use a
   temporary explicit suppression rather than having to move single Schedule,
   other protocols and uses may uses several Schedules (and related data
   transfer Tasks) to a
   reduced Schedule update the Configuration Information, transfer the
   Instruction Information, transfer Capability and then roll-back at a later time.  The explicit
   Suppression instruction message is able Status Information
   and send other information to simply enable/disable all
   Measurement Tasks as well the Controller such 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 log or Measurement
   Task Configurations that have an impact on a particular part of the
   network infrastructure (e.g., a particular Measurement Peer) to error
   notifications.  Multiple Channels may be
   targetted.  Support for disabling specific Measurement Schedules
   allows for particularly heavy cycles or sets of less essential
   Measurement Tasks used to be suppressed quickly and effectively.

   Unsuppression is achieved through either overwriting communicate with the Measurement
   Suppression information
   Controller over multiple interfaces (e.g. changing 'enabled' to False) or through send logging information
   over a different network).

   In addition the use MA will be given further items of an End time such information that
   relate specifically to the Measurement Suppression will no
   longer be in effect beyond this time.

   The goal when defining these four different elements MA rather than the measurements it is to allow each
   part
   conduct or how to report results.  The assignment of the information model an ID to change without affecting the other
   three elements.  For example it MA
   is envisaged mandatory.  Optionally a Group ID may also be given which
   identifies a group of interest to which that MA belongs.  For example
   the Report Channels
   and the set group could represent an ISP, broadband product, technology,
   market classification, geographic region, or a combination of
   multiple such characteristics.  Where the Measurement Tasks Configurations will be relatively
   static.  The Measurement Schedule on Group ID is set
   an additional flag (the Report MA ID flag) is required to control
   whether the other hand Measurement Agent ID is likely also to be
   more dynamic as reported.  The
   reporting of a Group ID without the measurement panel and test frequency are changed
   for various business goals.  Another example 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 stopexecuting any
   Instruction Schedule if the Controller is that measurements unreachable.  This can be suppressed with
   used as a fail-safe to stop Measurement Suppression command without removing
   the existing Measurement Schedules and other Tasks being
   conducted when there is doubt that would continue to apply after the Measurement Suppression expires or Instruction Information is removed.  In terms
   still valid.  This is simply represented as a time window in
   milliseconds since the last communication with the Controller after
   which Instruction Schedules are to be suspended.  The appropriate
   vaue of the
   Controller-MA time window will depend on the specified communication this can reduce
   Schedule with the data overhead.  It
   also encourages Controller and the re-use duration for which the system is
   willing to tolerate continued operation with potentially stale
   Instruction Information.

   While pre-configuration is persistent upon device reset or power
   cycle due to its very nature, the persistency of the same standard Measurement Task
   Configurations and Reporting Channels addtional
   configuration information may be control protocol dependent.  Some
   protocols may assume that reset devices will revert back to help ensure consistency their
   pre-configuration state, while other protocols may assume that all
   configuration and
   reduce errors.

   Definition instruction information is held in persistent
   storage.

   Detail of the additional and updated information model elements:

   // MA Configuration

   object {
       ma-task-obj         ma-tasks<0..*>;
       uuid                ma-agent-id;
      [ma-task-obj         ma-control-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..*>;      ma-control-channels<1..*>;
      [mas-schedule-obj    ma-control-schedules<0..*>];
      [urn                 ma-device-id;]
       credentials         ma-credentials;
      [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-group-id;]
      [boolean             ma-report-ma-id-flag;]
      [int                 ma-control-channel-failure-threshold;]
   } 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;
   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 ma-config-obj;

3.4.  Instruction 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 information model has four sub-elements:

   1.  Instruction Task Configurations

   2.  Report Channels

   3.  Instruction Schedules
   4.  Suppression

   The Instruction supports the operation exceution of all Tasks on the MA except
   those that deal with communication with the Controller (specified in
   (pre)configuration information).  The Tasks are configured in
   Instruction Task Configurations and
   updates inlcuded by reference in
   Instruction Schdules that specify when to capabilities may also be reported.  Reporting this
   information execute them.  The results
   are communicated to other Tasks or over Report Channels.  Suppression
   is achieved simply and flexibly in exactly used to temporarily stop the same
   manner excution of new Tasks 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 specified by
   the MA such as
   logging information.  One or more logging tasks can be programmed or
   configured Instruction Schedules (and optionaly to capture subsets stop ongoing Tasks).

   A Task Configuration is used to configure the optional parameters of
   a Task.  It also serves to instruct the MA to Controller Information.
   These logging tasks are then executed by Measurement Schedules (if
   not permanently running) and about the resultant data assigned Task including
   the ability to resolve the MA Task to
   Controller Channel.

   The type of MA an executable and specifying the
   schema for the Task parameters.

   A Report Channel defines how to Controller Information will fall into three communicate with a single remote
   system specified by a URL.  A Report Channel is used to send results
   to single Collector but is no different categories:

   1.  Success/failure/warning messages in response terms of the Information
   Model to the Control Channel used to transfer information
       updates from between the
   MA and the Controller.  Failure messages could  Several Report Channels can be produced
       due defined to some inability
   enable results to receive be split or parse duplicated across different
   destinations.  A single Channel can also be used by multiple
   Schedules to transfer data at different cycles to the Controller
       communication, or if same Collector.
   E.g. a single Collector may receive data at three different cycle
   rates, one Schedule reporting hourly, another reporting daily and a
   third specifying that results should be sent immediately for on-
   demand measurement tasks.  Alternatively multiple Report Channels can
   be used to send Measurement Task results to different Collectors.
   The details of the MA Channel element is not able to act described later as instructed.
       For example:

       *  "Measurement it is common
   to several objects.

   Instruction Schedules updated OK"

       *  "Unable specify which Tasks to parse JSON"

       *  "Missing mandatory element: Measurement Timing"

       *  "'Start' does not conform execute according to schema a
   simngle given Timing (that can execute a single or repeated series of
   Tasks).  The Schedule also specifies how to deal with Task inputs and
   outputs - expected datetime"

       *  "Date specified is in e.g. sending selected outputs to other Tasks or specifying
   the past"
       *  "'Hour' must Report Channels that should be in the range 1..24"

       *  "Schedule A refers used to non-existent Measurement Task
          Configuration"

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

       *  "Updated report results to
   Collectors.

   Measurement Task Configurations do not include M Suppression information is used
          by Measurement Schedule N"

   2.  Operational updates from the MA.  For example:

       *  "Out of memory: cannot record result"

       *  "Collector 'collector.example.com' not responding"

       *  "Unexpected restart"

       *  "Suppression timeout"

       *  "Failed to execute Measurement Task Configuration H"

   3.  Status updates from over-ride the MA.  For example:

       *  "Interface added: eth3 "

       *  "Supported
   Instruction Schedule and temporarily stop measurements updated"

       *  "New IP address or other Tasks
   from running on eth0: xxx.xxx.xxx.xxx"

   This Information Model document does not detail the precise format of
   logging information since it is to MA for a large extend protocol and
   measurement task specific.  However, some common information defined or indefinite period.  While
   conceptually measurements can be
   identified.

   MA Logging stopped by simply removing them from
   the Measurement Schedule, splitting out separate 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;

3.6.  Capability and Status Information

   The on
   Measurement Suppression allows this information to be updated on the
   MA will hold Capability Information on a different timing cycle or protocol implementation to the
   Measurement Schedule.  It is also considered that can it will be retrieved by easier
   for a
   Controller.  Capabilities include the interface details available human operator to
   Measurement Tasks implement a temporary explicit suppression
   rather than having to move to a reduced Schedule and Reports then roll-back
   at a later time.

   The explicit Suppression instruction message is able to simply
   enable/disable all Instruction Tasks (that are enabled for default
   suppression) as well as the set of Measurement Tasks
   that having fine control on which Tasks are actually installed
   suppressed.  Suppression of both specified Task Configurations and
   Measurement Schedules is supported.  Support for disabling specific
   Task Configurations allows malfunctioning or available mis-configured Tasks or
   Task Configurations that have an impact on a particular part of the MA.  Status
   information includes the times
   network infrastructure (e.g., a particular Measurement Peer) to be
   targetted.  Support for disabling specific Schedules allows for
   particularly heavy cycles or sets of less essential Measurement Tasks
   to be suppressed quickly and effectively.  Note that operations were last performed
   such as contacting the Suppression has
   no effect on either Controller Tasks 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;

3.7.  Reporting Information

   At a point in time specific Controller Schedules.

   When no tasks or schedules are explicitly listed, all Instruction
   tasks will be suppressed as indicated by the Report Channel, suppress-by-default flag
   in the MA Task Configuration.  If tasks or schedules are listed
   explicitly then these tasks will
   communicate a set be suppressed regardless of measurement results to the Collector.  These
   measurement results should be communicated within
   suppress-by-default flag.

   Suppression stops new Tasks from executing.  In addtion, the context in
   which they were collected.

   It should be noted
   Suppression information also supports an additional Boolean that Collectors can is
   used to select whether on-going tasks are also to be implemented by many types
   of devices and systems, including terminated.

   Unsuppression is achieved through either overwriting 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
   Suppression information (e.g. when
   performance drops from earlier levels).

   The report is structured hierarchically changing 'enabled' to avoid repetition of
   report, Measurement Agent and Measurement Task Configuration
   information.  The report starts with False) or through
   the timestamp use of an End time such that 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 Suppression will no
   longer be included at in effect beyond 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). time.  The datetime format used for
   all elements in the information model
   (i.e., Report Date and Measurement Time in (e.g. the Reporting Information) suppression start and
   end dates) 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;
   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, goal when defining these four different elements is not further detailed here.

3.8.  Channels

   A Channel defines a communication channel between the MA and other
   element to allow each
   part 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 model to be split or duplicated across different
   report intervals or destinations.  E.g. a single Collector may have change without affecting the other
   three elements.  For example it is envisaged that the Report Channels, one reporting hourly, another reporting daily Channels
   and a third on which to send immediate results for on-demand
   measurement tasks.

   Each Channel contains the details set of Task Configurations will be relatively static.  The
   Instruction Schedule, on the target (including location
   and security information such other hand, is likely to be more
   dynamic, as the certificate), measurement panel and the timing test frequency are changed for
   the communication i.e. when to establish the communication.  The
   certificate
   various business goals.  Another example is that measurements can be
   suppressed with a Suppression command without removing the digital certificate associated existing
   Instruction Schedules that would continue to apply after the FQDN in
   the URL
   Suppression expires or it can be the certificate is removed.  In terms of the Certification Authority
   that was used to issue Controller-MA
   communication this can reduce the certificate for data overhead.  It also encourages
   the FQDN (Fully Qualified
   Domain Name) re-use 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 standard Task Configurations 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
   elements.

   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.

   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 Reporting
   Channels to monitor the health help ensure consistency and reduce errors.

   Definition of the
   measurement system.

   Example:  A Channel using for reporting results may specify that
      results are to be sent information model elements:

// Instruction to the URL
      (https://collector.foo.org/report/), using the appropriate digital
      certificate MA to establish a secure channel.  The Channel specifies
      that the results are configure Tasks, Channels, Schedules and Suppression

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

// Suppression object to be sent immediately as available temporarily override new task execution in Instructions and not
      batched. optionally stop currently running tasks

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-suppression-enabled;
   [boolean             ma-channel-connect-always;]             ma-suppression-stop-ongoing-tasks;] // default: false
   [datetime            ma-suppression-start;] // (only connect when data 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 pending) empty
} ma-channel-obj;

3.9.  Timing ma-suppression-obj;

3.5.  Logging Information

   The Timing information object used throughout MA may report on the information models
   can take one success or failure of four different forms:

   1.  Periodic.  Specifies a start, end Configuration or
   Instruction communications from the Controller.  In addition further
   operational logs may be produced during the operation of the MA and interval time
   updates to capabilities may also be reported.  Reporting this
   information is achieved simply and flexibly in
       milliseconds

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

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

   4.  Immediate: Should occur same
   manner as soon any other Task.  We make no distinction between a
   Measurement Task conducting an active or passive network measurement
   and one which solely retrieves static or dynamic information from the
   MA such as possible

   Optionally each capabilities or logging information.  One or more logging
   tasks can be programmed or configured to capture subsets of the first three options may
   Logging Information.  These logging tasks are then executed by
   Schedules which also specify a
   randomness that should be evaluated and applied separately the resultant data is to each
   indicated event. be
   transferred over the Controller Channels.

   The datetime format used for all elements type of Logging Information will fall into three different
   categories:

   1.  Success/failure/warning messages in the response to information model
   (i.e., Report Date and Measurement Time in
       updates from the Reporting Information)
   MUST 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 RFC 3339 [RFC3339] and ISO8601.

   object schema - expected datetime"

       *  "Date specified is in the past"

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

       *  "Schedule A refers to non-existent Measurement Task
          Configuration"

       *  "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 'collector.example.com' 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: xxx.xxx.xxx.xxx"

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

   MA Logging information model elements:

   // Logging object

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

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 Channels 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:

   // Main MA Status information object

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

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

       ma-task-capability-obj   ma-supported-tasks<0..*>;
   } ma-status-obj;
   // Interface information

   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;

   // Supported tasks

   object {
       string              ma-task-name;
       uri                 ma-task-registry;
   } ma-task-capability-obj;

3.7.  Reporting Information

   At a point in time specified by a Schedule, the MA will execute a
   task or tasks that communicate a set of measurement results to the
   Collector.  Some of these Tasks (notably Reporting Tasks) will
   understand how to transmit task results over a specified Report
   Channel to a Collector.

   It should be noted that the output from Tasks does not need to be
   sent to communication Channels.  It can alternatively, or
   additionally, be sent to other Tasks on the MA.  This facilitates
   using a first Measurement Task to control the operation of a later
   Measurement Task (such as first probing available line speed and then
   adjusting the operation of a video testing measurement) and also to
   allow local processing of data to output alarms (e.g. when
   performance drops from earlier levels).  Of course, subsequent Tasks
   also include Tasks that implement the reporting protocol(s) and
   transfer data to one or more Collector(s).

   The report is structured hierarchically to avoid repetition of report
   header 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).

   No context information, such as line speed or broadband product are
   included within the report header information as this data is
   reported by individual tasks at the time they execute.  Either a
   Measurement Task can report contextual parameters that are relevant
   to that particular measurement, or specific tasks can be used to
   gather a set of contextual and environmental data. at certain times
   independent of the reporting schedule.

   After the report header information the results are reported grouped
   according to different Measurement Task Configurations.  Each Task
   section 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.  Cross traffic is defined as the
   total number of Bytes both upstream and downstream of non-measurement
   traffic passing through the interfaces used by a Measurement Task
   during the measurement period.

   Where the Configuration and Instruction information represent
   information transmitted via the Control Protocol, the Report
   represents the information that is transmitted via the Report
   Protocol.  It is constructed at the time of sending a report and
   represents the inherent structure of the information that is sent to
   the Collector.

   Information model elements:

   // Main Report object with report header information

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

   // Report task header information

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

// Report tasks result rows

object {
    datetime            ma-report-result-time;
    string              ma-report-conflicting-tasks<0..*>;
   [int                 ma-report-result-cross-traffic;] // Bytes of non-measurement traffic
                                                         // on measurement interface during measurement period
    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.  Schedules

   A Schedule specifies the execution of a single or repeated series of
   Tasks.  Each Schedule contains basically two elements: a list of
   Tasks to be executed and a timing object for the Schedule.  The
   Schedule basically states what Tasks to run (with what
   configuration), how to report the results, and when to run the Tasks.

   Multiple Tasks in the list of a single Measurement Schedule will be
   executed in order with minimal gaps.  Tasks in different Schedules
   can execute in parallel with such conflicts beings reported in the
   Reporting Information.

   As well as specifying which Tasks to execute, the Schedule also
   specifies where to send the data outputs from each Task.  Specifying
   this within the Schedule allows the highest level of flexibility
   since it is even possible to send the output from different
   executions of the same Task to different destinations.  Since a
   single Task may have multiple outputs, the Schedule can independently
   specify which outputs go to which destinations.  For example, a
   Measurement Task might report routine results to a data Reporting
   Task that communicates hourly via the Broadband PPP interface, but
   also outputs emergency conditions via an alarm Reporting Task
   communicating immediately over a GPRS channel.

   The destination options for a Task are either another Task or a
   Channel.  In this way the output of a Task can be sent to another
   Task.  For example a Measurement Task may send its output to a data
   transfer Task that reports the batched data to a Collector at a later
   time.  Alternatively the output from a Measurement Task may be fed to
   an alarm processing task that monitors the results of a series of
   Measurement Tasks.  Some Tasks will also understand how to send/
   receive data to/from Channels using the Reporting/Control protocol.
   Since Channels are bi-directional they can be considered inputs as
   well as outputs to the Control and Reporting Tasks that utlilise
   them.  Any Task that does not implement either the Reporting or
   Control protocol will ignore any specified Channels (e.g.  A
   Measurement Task will not know how to report results to a Collector
   using the Report Protocol.  Instead results can be passed to a
   Reporting Task that has the apropriate Collector specified as a
   Channel).

   The tasks outputs and channels are controlled using a series of
   filters.  Each filter is an array of integers specifying which Task
   datasets should be mapped to which output tasks and/or channels.

   Example:  A Schedule references a single Measurement Task
      Configuration for the UDP latency.  It specifies that results are
      to be sent to a Reporting Task.  This Reporting Task is executed
      by a separate Schedule that specifies that it should run hourly at
      5 minutes past the hour.  When run this Reporting Task takes the
      data generated by the UDP latency Task as well as any other data
      to be included in the hourly report and transfers it to the
      Collector over the Report Channel specified within its own
      Schedule.

   // main Schedule object with Timing and list of Scheduled Tasks

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

// Scheduled Task object with reference (by name string) to Task Configuration and input/output mapping
// of task datasets to output tasks and channels

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

// Selected Task interfaces (filtered by Integer list) can be output to other Task Configurations
// (referenced by name string) or connected to input/output Channels (referenced by name string)

object {
   [int                 ma-schedule-task-filters<0..*>;]  // default: all
   [string              ma-schedule-task-output-task-names<0..*>];
   [string              ma-schedule-task-channel-names<0..*>];
} ma-sched-dataset-obj;
3.9.  Channels

   A Channel defines a bi-directional communication channel between the
   MA and a Controller or Collector.  Multiple Channels can be defined
   to enable results to be split or duplicated across different
   Collectors.

   Each Channel contains the details of the endpoint (including location
   and security credential information such as the certificate).  The
   timing of when to communicate over a Channel is specified within the
   Schedule.  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 TLS).
   In order to establish a secure channel, the MA will use it's own
   security credentials (in the Configuration Information) and the given
   credentials for the individual Channel end-point.

   As with theTask Configurations, each Channel is also given a local
   short name by which it can be referenced from a Schedule.

   Although the same in terms of information, Channels used for
   communication with the Controller are refered to as Control Channels
   whereas Channels to Collectors are refered to as Report Channels.
   Hence Control Channels will be referenced from within the Control
   Schedule, whereas Report Channels will be referenced from within the
   Instruction Schedule.

   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.

   Example:  A Channel using for reporting results may specify that
      results are to be sent to the URL (https://collector.foo.org/
      report/), using the appropriate digital certificate to establish a
      secure channel..

// Channel object with name string allowing reference from Schedule. Contains channel endpoint target URL and security
// credentials to establish secure channel. Optionally allows interface specification (by interface name string reference)
// and connection when no data is pending for transfer

object {
    string              ma-channel-name;
    url                 ma-channel-target;
    credentials         ma-channel-credentials;
   [string              ma-channel-interface-name;]
} ma-channel-obj;

3.10.  Task Configurations

   Conceptually each Task Configuration defines the parameters of a 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 Schedule).  Tasks can be
   Measurement Tasks (i.e. those Tasks actually performing some type of
   passive or active measurement) or any other scheduled activity
   performed by the MA such as transferring information to or from the
   Controller and Collectors.  Other examples of Tasks may include data
   manipulation or processing Tasks conducted on the MA.

   A Measurement Task Configuration is the same in information terms to
   any other Task Configuration.  Both measurement and non-measurement
   Tasks have a registry entry to enable the MA to uniquely identify the
   Task it should execute and retrieve the schema for any parameters
   that may be passed to the Task.  This registry entry is specified as
   a URI and can therefore identify the Task within a namespace or point
   to a web or local file location for the Task information.  As
   mentioned previously this entry may refer to the Measurement Task in
   a public namespace [I-D.bagnulo-ippm-new-registry] that is used to
   define the Measurement Task.

   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 Schedule element), so it does not by
      itself instruct the MA to actually perform this Measurement Task.

   The Task Configuration will include a local short name for reference
   by a Schedule.  Task Configurations will also contain a registry
   entry as described above.  In addition the Task can be configured
   through a set of configuration Options.  The nature and number of
   these Options will depend upon the Task and will be resolved through
   the registry parameter.

   A parameter that may be present for Reporting Tasks is whether to
   report if there is no measurement result data pending to be
   transferred to the Collector.

   The Task Configuration also contains a suppress-by-default flag that
   specifies the behaviour of a default suppress instruction (that does
   not list explicit tasks or schedules).  If this flag is set to FALSE
   then the Task will not be suppressed.  It should be noted that
   Controller Tasks are not subject to the suppression instruction and
   therefore this flag will be ignored in such cases.

   In addition the 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 could be manually incremented
   or otherwise changed when an Option change is implemented which could
   mean that two sets of results should not be directly compared.

// Task Configuration object with string name to allow reference from Schedule. Contains URI to link to registry or local
// specification of Task. Options allow the configuration of Task parameters (in the form of name-value pairs)

object {
    string              ma-task-name;
    uri                 ma-task-registry;
    name-value-pair     ma-task-options<0..*>;
   [boolean             ma-task-suppress-by-default;] // default: TRUE
   [string              ma-task-cycle-id;]
} ma-task-obj;

3.11.  Timing Information

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

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

   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
   5.  Startup: Should occur whenever the MA is started (e.g. at device
       startup)

   Optionally each of the 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
   MUST conform to RFC 3339 [RFC3339] and ISO8601.

// Main Timing object with name string to allow reference by Schedule
// Must be specialised by one of the Timing options.
// Includes optional uniform random spread in ms from start time given by Timing specialisation

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-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-startup-obj   ma-timing-startup;
   }
   [int                 ma-timing-random-spread;]     // milliseconds
} ma-timing-obj;

3.11.1.  Periodic Timing

   Information model elements:

// Timing specialisation to run a series of Tasks repeated at set intervals

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

3.11.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:

// Timing specialisation to run repeated Tasks at specific times and/or days

object {
   [datetime            ma-calendar-start;] // default: immediate
   [datetime            ma-calendar-end;]   // default: indefinite
   [int                 ma-calendar-months<0..*>;]   // default: 1-12
   [days                ma-calendar-days-of-week<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-randomness-obj   ma-timing-randomness;] ma-calendar-obj;

3.11.3.  One-Off Timing

   Information model elements:

   // Timing specialisation to run once at a specified time/date

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

3.9.1.  Periodic ma-one-off-obj;

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

   // Timing

   Information model elements: specialisation to run immediately

   object {
      [datetime            ma-periodic start;]
                           // default: empty
   } ma-immediate-obj;

3.11.5.  Startup Timing

   The immediate
      [datetime            ma-periodic-end;] timing object has no further information elements.  The
   measurement or report is simply done at MA initiation.

   // default: indefinite
       int                 ma-periodic-interval; Timing specialisation to run at MA startup

   object {
                           // milliseconds empty
   } ma-periodic-obj;

3.9.2.  Calendar Timing

   Calendar Timing supports ma-startup-obj;

4.  IANA Considerations

   This document makes no request of IANA.

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

5.  Security Considerations

   This Information Model deals with information about the routine execution control and
   reporting of the Measurement Tasks
   at specific times and/or on specific dates.  It 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 support more
   flexible timing than Periodic Timing since be sent and received securely.  Additionally,
   any mechanisms that the Measurement Task
   execution does not have 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 should 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 uniformly spaced.  For omitted
   or blurred.

6.  Appendix: JSON Example

   In order to give an example of data in the Information Model we need
   to select a
   Calendar Timing could support data model language.  In this example we have expressed
   the execution Data Model using JSON as this will be of a Measurement Task
   every hour between 6pm direct interest to some
   Control and midnight on weekdays only.

   Calendar Timing Report Protocols.  The example is also required to perform measurements at
   meaningful instances in relation broken down into a
   number of different steps that might adhere to network usage (e.g., at peak
   times).  If the optional timezone offset steps within a
   Control and Report Protocol:

   1.  Pre-configuration.

   2.  Configuration

   3.  Capabilities

   4.  Instruction

   5.  Report

   6.  Suppression

   While the pre-configuration 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 delivered as through part of the mobile network).

   Information Control
   Protocol, the same JSON data model elements:

   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;] is used for consistency and to aid
   the reader.

// default: system timezone offset Pre-Configuration

{
  "ma-config": {
    "ma-agent-id": "550e8400-e29b-41d4-a716-446655440000",
    "ma-control-tasks": [
      {
        "ma-task-name": "Controller configuration",
        "uri": "urn:ietf:lmap:control:http_controller_configuration"
      } ma-calendar-obj;

3.9.3.  One-Off Timing

   Information model elements:

   object
    ]
    "ma-control-channels": [
      {
        "ma-channel-name": "Controller channel",
        "ma-channel-target": "http://www.example.com/lmap/controller",
        "ma-channel-credientials": {
       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 // structure of certificate ommitted for brevity
      }
    ]
    "ma-control-schedules": [
      {
        "ma-schedule-name": "pre-configured schedule",
        "ma-schedule-tasks": {
          {
            "ma-schedule-task-name": "Controller configuration",
            "ma-schedule-task-datasets": [
              {
                "ma-schedule-task-channel-names": "Controller channel"
              }
            ]
          }
        }
        "ma-schedule-timing": {
          "ma-timing-name": "startup plus up to be done as soon as possible.

   object one hour",
          "ma-timing-startup": {
          }
          "ma-timing-random-spread": "3600000"
        }
      }
    ]
    "ma-credentials": { } // empty structure of certificate ommitted for brevity
  } 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
}

   Given the pre-configuration information the MA is able to spread the load on contact the
   Controller, Collector
   Controller and network in receive 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. updated/expanded Configuration.  In this
   example additional
   optional upper Control Protocol tasks to post Status and lower bounds can be applied
   Capabilities to control extreme
   spread of timings.

   Information model elements:

   object the Controller and fetch the Instruction are added as
   well as moving the schedule timing for contacting the Controller to
   hourly.

// Configuration

{
       string              ma-randomness-distribution;
      [int                 ma-randomness-lower-cut;]
      [int                 ma-randomness-upper-cut;]
       int                 ma-randomness-spread;
  "ma-config": {
    "ma-agent-id": "550e8400-e29b-41d4-a716-446655440000",
    "ma-control-tasks": [
      {
        "ma-task-name": "Controller configuration",
        "uri": "urn:ietf:lmap:control:http_controller_configuration"
      },
      {
        "ma-task-name": "Controller status and capabilities",
        "uri": "urn:ietf:lmap:control:http_controller_status_and_capabilities"
      },
      {
        "ma-task-name": "Controller instruction",
        "uri": "urn:ietf:lmap:control:http_controller_instruction"
      } ma-randomness-obj;

4.  IANA Considerations

   This document makes no request
    ]
    "ma-control-channels": [
      {
        "ma-channel-name": "Controller instruction",
        "ma-channel-target": "http://www.example.com/lmap/controller",
        "ma-channel-credientials": { } // structure of IANA.

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

5.  Security Considerations

   This Information Model deals with information about the control certificate ommitted for brevity
      }
    ]
    "ma-control-schedules": [
      {
        "ma-schedule-name": "Controller schedule",
        "ma-schedule-tasks": {
          {
            "ma-schedule-task-name": "Controller configuration",
            "ma-schedule-task-datasets": [
              {
                "ma-schedule-task-channel-names": ["Controller channel"]
              }
            ]
          },
        {
            "ma-schedule-task-name": "Controller status and
   reporting capabilities",
            "ma-schedule-task-datasets": [
              {
                "ma-schedule-task-channel-names": ["Controller channel"]
              }

            ]
          },
        {
            "ma-schedule-task-name": "Controller instruction",
            "ma-schedule-task-datasets": [
              {
                "ma-schedule-task-channel-names": ["Controller channel"]
              }
            ]
          }
        }
        "ma-schedule-timing": {
          "ma-timing-name": "hourly randomly",
          "ma-timing-calendar": {
            "ma-calendar-minutes": ["00"],
            "ma-calendar-seconds": ["00"]
          }
          "ma-timing-random-spread": "3600000"
        }
      }
    ]
    "ma-credentials": { } // structure of the Measurement Agent.  There are broadly two security
   considerations certificate ommitted for such brevity
  }
}

   The above configuration now contacts the Controller randomnly within
   each hour.  The following is an Information Model.  Firstly example of the
   Information Model has to be sufficient to establish secure
   communication channels Status and
   Capabilities information that is transferred from the MA to the Controller
   Controller.

// Status and Collector such that
   other information can be sent Capabilities

{
  ma-status-and-capabilities {
    "ma-agent-id": "550e8400-e29b-41d4-a716-446655440000",
    "ma-device-id": "urn:dev:mac:0024befffe804ff1"
    "ma-hardware": "mfr-home-gateway-v10"
    "ma-firmware": "25637748-rev2a"
    "ma-version": "ispa-v1.01"
    "ma-interfaces: [
      {
        "ma-interface-name": "broadband",
        "ma-interface-type": "PPPoE"
      }
    ]
    "ma-last-measurement: "",
    "ma-last-report: "",
    "ma-last-instruction: "",
    "ma-last-configuration: "2014-06-08T22:47:31+00:00",
    "ma-supported-tasks: [
      {
        "ma-task-name": "Controller configuration",
        "ma-task-registry": "urn:ietf:lmap:control:http_controller_configuration"
      },
      {
        "ma-task-name": "Controller status and received securely.  Additionally,
   any mechanisms that capabilities",
        "ma-task-registry": "urn:ietf:lmap:control:http_controller_status_and_capabilities"
      },
      {
        "ma-task-name": "Controller instruction",
        "ma-task-registry": "urn:ietf:lmap:control:http_controller_instruction"
      },
      {
        "ma-task-name": "Report",
        "ma-task-registry": "urn:ietf:lmap:report:http_report"
      },
      {
        "ma-task-name": "UDP Latency",
        "ma-task-registry": "urn:ietf:ippm:measurement:UDPLatency-Poisson-XthPercentileMean"
      }
    ]
  }
}
   After fetching the Network Operator or other device
   administrator employs status and capabilties the Controller issues and
   Instruction 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 perform a risk single UDP latency measurement
   task 4 times a day and to confidentiality or privacy given
   such secure communication channels.  For this latter reason items
   such as report the MA context results immediately.

// Instruction

{
  "ma-instruction": {
    "ma-instruction-tasks": [
      {
        "ma-task-name": "UDP Latency",
        "uri": "urn:ietf:ippm:measurement:UDPLatency-Poisson-XthPercentileMean",
        "ma-task-options": [
          {"name": "X", "value": "99"},
          {"name":"rate", "value": "5"},
          {"name":"duration", "value": "30.000"},
          {"name":"interface", "value": "broadband"},
          {"name":"destination-ip", "value": {"version":"ipv4", "ip-address":"192.168.2.54"}},
          {"name":"destination-port", "value": "50000"},
          {"name":"source-port", "value": "50000"}
        ],
        "ma-task-suppress-by-default": "TRUE"
      },
      {
        "ma-task-name": "Report",
        "uri": "urn:ietf:lmap:report:http_report",
        "ma-task-options": [
          {"name": "report-with-no-data", "value": "FALSE"}
        ],
        "ma-task-suppress-by-default": "FALSE"
      }
    ]
    "ma-report-channels": [
      {
        "ma-channel-name": "Collector A",
        "ma-channel-target": "http://www.example2.com/lmap/collector",
        "ma-channel-credientials": { } // structure of certificate ommitted for brevity
      }
    ]
    "ma-instruction-schedules": [
      {
        "ma-schedule-name": "4 times daily test UDP latency and MA ID are left optional report",
        "ma-schedule-tasks": {
          {
            "ma-schedule-task-name": "UDP Latency",
            "ma-schedule-task-datasets": [
              {
                "ma-schedule-task-output-task-names": "Report"

              }
            ]
          },
          {
            "ma-schedule-task-name": "Report",
            "ma-schedule-task-datasets": [
              {
                "ma-schedule-task-channel-names": "Collector A"
              }
            ]
          }
        }
        "ma-schedule-timing": {
          "ma-timing-name": "once every 6 hours",
          "ma-timing-calendar": {
            "ma-calendar-hours": ["00", "06", "12", "18"],
            "ma-calendar-minutes": ["00"],
            "ma-calendar-seconds": ["00"]
          }
          "ma-timing-random-spread": "21600000"
        }
      }
    ]
  }
}

   The report task in the Instruction is executed immediately after the
   UDP test and can be
   excluded from some deployments.  This would, for example, allow transfers the
   MA following data to remain anonymous and for information about location or other
   context the Collector.

// Report

{
  ma-report: {
    "ma-report-date": "2014-06-09T02:30:45+00:00",
    "ma-report-agent-id": "550e8400-e29b-41d4-a716-446655440000",
    "ma-report-tasks": [
      "ma-report-task-config": {
        "ma-task-name": "UDP Latency",
        "uri": "urn:ietf:ippm:measurement:UDPLatency-Poisson-XthPercentileMean",
        "ma-task-options": [
          {"name": "X", "value": "99"},
          {"name":"rate", "value": "5"},
          {"name":"duration", "value": "30.000"},
          {"name":"interface", "value": "broadband"},
          {"name":"destination-ip", "value": {"version":"ipv4", "ip-address":"192.168.2.54"}},
          {"name":"destination-port", "value": "50000"},
          {"name":"source-port", "value": "50000"}
        ]
      },
      "ma-report-task-column-labels": ["time", "conflicting-tasks", "cross-traffic", "mean"],
      "ma-report-task-rows": [
        {"2014-06-09T02:30:10+00:00", "", "0", "20.13"}
      ]
    ]
  }
}

   The Controller decides that might be used to identify or track there is a problem with the MA to be omitted
   or blurred.

6. UDP L:atency
   test and issues a Suppression Instruction.  Since the task is marked
   as suppressable by default, simply turning on suppression will stop
   the task being executed in future.

   // Suppression

   {
     "ma-instruction": {
       "ma-suppression": {
          "ma-suppression-enabled": "TRUE"
       {
     }
   }

7.  Acknowledgements

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

   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.

8.  References
7.1.

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

8.2.  Informative References

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

   [I-D.ietf-lmap-framework]
              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 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
   BT
   Adastral Park, Martlesham Heath
   Ipswich,
   Ipswich  IP5 3RE
   United Kingdom

   Email: trevor.burbridge@bt.com
   Philip Eardley
   British Telecom
   BT
   Adastral Park, Martlesham Heath
   Ipswich,
   Ipswich  IP5 3RE
   United Kingdom

   Email: philip.eardley@bt.com

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

   Email: marcelo@it.uc3m.es

   Juergen Schoenwaelder
   Jacobs University Bremen
   Campus Ring 1
   Bremen,
   Bremen  28759
   Germany

   Email: j.schoenwaelder@jacobs-university.de