draft-ietf-lmap-information-model-03.txt | draft-ietf-lmap-information-model-04.txt | |||
---|---|---|---|---|
Network Working Group T. Burbridge | Network Working Group T. Burbridge | |||
Internet-Draft P. Eardley | Internet-Draft P. Eardley | |||
Intended status: Standards Track BT | Intended status: Standards Track BT | |||
Expires: July 9, 2015 M. Bagnulo | Expires: September 6, 2015 M. Bagnulo | |||
Universidad Carlos III de Madrid | Universidad Carlos III de Madrid | |||
J. Schoenwaelder | J. Schoenwaelder | |||
Jacobs University Bremen | Jacobs University Bremen | |||
January 05, 2015 | March 5, 2015 | |||
Information Model for Large-Scale Measurement Platforms (LMAP) | Information Model for Large-Scale Measurement Platforms (LMAP) | |||
draft-ietf-lmap-information-model-03 | draft-ietf-lmap-information-model-04 | |||
Abstract | Abstract | |||
This Information Model applies to the Measurement Agent within a | This Information Model applies to the Measurement Agent within a | |||
Large-Scale Measurement Platform. As such it outlines the | Large-Scale Measurement Platform. As such it outlines the | |||
information that is (pre-)configured on the MA or exists in | information that is (pre-)configured on the MA or exists in | |||
communications with a Controller or Collector within an LMAP | communications with a Controller or Collector within an LMAP | |||
framework. The purpose of such an Information Model is to provide a | framework. The purpose of such an Information Model is to provide a | |||
protocol and device independent view of the MA that can be | protocol and device independent view of the MA that can be | |||
implemented via one or more Control and Report protocols. | implemented via one or more Control and Report protocols. | |||
skipping to change at page 1, line 46 | skipping to change at page 1, line 46 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 9, 2015. | This Internet-Draft will expire on September 6, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 31 | skipping to change at page 2, line 31 | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 | 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Pre-Configuration Information . . . . . . . . . . . . . . 7 | 3.1. Pre-Configuration Information . . . . . . . . . . . . . . 7 | |||
3.2. Configuration Information . . . . . . . . . . . . . . . . 9 | 3.2. Configuration Information . . . . . . . . . . . . . . . . 9 | |||
3.3. Instruction Information . . . . . . . . . . . . . . . . . 10 | 3.3. Instruction Information . . . . . . . . . . . . . . . . . 10 | |||
3.4. Logging Information . . . . . . . . . . . . . . . . . . . 13 | 3.4. Logging Information . . . . . . . . . . . . . . . . . . . 13 | |||
3.5. Capability and Status Information . . . . . . . . . . . . 15 | 3.5. Capability and Status Information . . . . . . . . . . . . 15 | |||
3.6. Reporting Information . . . . . . . . . . . . . . . . . . 16 | 3.6. Reporting Information . . . . . . . . . . . . . . . . . . 16 | |||
3.7. Common Objects . . . . . . . . . . . . . . . . . . . . . 18 | 3.7. Common Objects . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.7.1. Schedules . . . . . . . . . . . . . . . . . . . . . . 18 | 3.7.1. Schedules . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.7.2. Channels . . . . . . . . . . . . . . . . . . . . . . 21 | 3.7.2. Channels . . . . . . . . . . . . . . . . . . . . . . 21 | |||
3.7.3. Task Configurations . . . . . . . . . . . . . . . . . 22 | 3.7.3. Task Configurations . . . . . . . . . . . . . . . . . 22 | |||
3.7.4. Timing Information . . . . . . . . . . . . . . . . . 24 | 3.7.4. Timing Information . . . . . . . . . . . . . . . . . 25 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 28 | 7.2. Informative References . . . . . . . . . . . . . . . . . 29 | |||
Appendix A. JSON Data Model Example . . . . . . . . . . . . . . 29 | Appendix A. JSON Data Model Example . . . . . . . . . . . . . . 30 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
1. Introduction | 1. Introduction | |||
A large-scale measurement platform is a collection of components that | A large-scale measurement platform is a collection of components that | |||
work in a coordinated fashion to perform measurements from a large | work in a coordinated fashion to perform measurements from a large | |||
number of vantage points. The main components of a large-scale | number of vantage points. The main components of a large-scale | |||
measurement platform are the Measurement Agents (hereafter MAs), the | measurement platform are the Measurement Agents (hereafter MAs), the | |||
Controller(s) and the Collector(s). | Controller(s) and the Collector(s). | |||
The MAs are the elements actually performing the measurements. The | The MAs are the elements actually performing the measurements. The | |||
skipping to change at page 5, line 46 | skipping to change at page 5, line 46 | |||
within those protocols. | within those protocols. | |||
The granularity of data transmitted in each operation of the Control | The granularity of data transmitted in each operation of the Control | |||
and Report Protocols is not dictated by the Information Model. For | and Report Protocols is not dictated by the Information Model. For | |||
example, the Instruction object may be delivered in a single | example, the Instruction object may be delivered in a single | |||
operation. Alternatively, Schedules and Task Configurations may be | operation. Alternatively, Schedules and Task Configurations may be | |||
separated or even each Schedule/Task Configuration may be delivered | separated or even each Schedule/Task Configuration may be delivered | |||
individually. Similarly the Information Model does not dictate | individually. Similarly the Information Model does not dictate | |||
whether data is read, write, or read/write. For example, some | whether data is read, write, or read/write. For example, some | |||
Control Protocols may have the ability to read back Configuration and | Control Protocols may have the ability to read back Configuration and | |||
Instruction information which have been previosuly set on the MA. | Instruction information which have been previously set on the MA. | |||
Lastly, while some protocols may simply overwrite information (for | Lastly, while some protocols may simply overwrite information (for | |||
example refreshing the entire Instruction Information), other | example refreshing the entire Instruction Information), other | |||
protocols may have the ability to update or delete selected items of | protocols may have the ability to update or delete selected items of | |||
information. | information. | |||
The information in these six sections is captured by a number of | The information in these six sections is captured by a number of | |||
common information objects. These objects are also described later | common information objects. These objects are also described later | |||
in this document and comprise of: | in this document and comprise of: | |||
1. Schedules. A set of Schedules tell the MA to do something. | 1. Schedules. A set of Schedules tell the MA to do something. | |||
skipping to change at page 6, line 38 | skipping to change at page 6, line 38 | |||
specify what Tasks the MA should execute. | specify what Tasks the MA should execute. | |||
4. Timings. A set of Timing objects that can be referenced from the | 4. Timings. A set of Timing objects that can be referenced from the | |||
Schedules. Each Schedule always references exactly one Timing | Schedules. Each Schedule always references exactly one Timing | |||
object. A Timing object specfies either a singleton or series of | object. A Timing object specfies either a singleton or series of | |||
time events. They are used to indicate when Tasks should be | time events. They are used to indicate when Tasks should be | |||
executed. | executed. | |||
The following diagram illustrates the structure in which these common | The following diagram illustrates the structure in which these common | |||
information objects are referenced. The references are achieved by | information objects are referenced. The references are achieved by | |||
each object (Channel, Task Configuration, Timing) being given a short | each object (Task Configuration, Timing) being given a short text | |||
text name that is used by other objects. The objects shown in | name that is used by other objects. The objects shown in parenthesis | |||
parenthesis are part of the internal object structure of a Schedule. | are part of the internal object structure of a Schedule. Channels | |||
are not shown in the diagram since they are only used as an option by | ||||
selected Task Configurations but are similarly referenced using a | ||||
short text name. | ||||
Schedule | Schedule | |||
|----------> Timing | |----------> Timing | |||
|----------> (Scheduled Tasks) | |----------> (Scheduled Tasks) | |||
|----------> Task Configuration | |----------> Task Configuration | |||
|----------> Destination Tasks | |----------> Destination Tasks | |||
It should be clear that the top-level bahaviour of an MA is simply to | It should be clear that the top-level bahaviour of an MA is simply to | |||
execute Schedules. Every action referenced by a Schedule is defined | execute Schedules. Every action referenced by a Schedule is defined | |||
as a Task. As such, these actions are configured through Task | as a Task. As such, these actions are configured through Task | |||
Configurations and executed according to the Timing referenced by the | Configurations and executed according to the Timing referenced by the | |||
Schedule in which they appear. Tasks can implement a variety of | Schedule in which they appear. Tasks can implement a variety of | |||
different types of actions. While in terms of the Information Model, | different types of actions. While in terms of the Information Model, | |||
all Tasks have the same structure, it can help conceptually to think | all Tasks have the same structure, it can help conceptually to think | |||
of different Task categories: | of different Task categories: | |||
1. Measurement Tasks measure some aspect of network performance or | 1. Measurement Tasks measure some aspect of network performance or | |||
traffic. They may also capture contextual information from the | traffic. They may also capture contextual information from the | |||
MA device or network interfaces such the the device type or | MA device or network interfaces such as the device type or | |||
available interface speed. | interface speed. | |||
2. Data Transfer Tasks | 2. Data Transfer Tasks | |||
A. Reporting Tasks report the results of Measurement Tasks to | A. Reporting Tasks report the results of Measurement Tasks to | |||
Collectors | Collectors | |||
B. Control Task(s) implement the Control Protocol and | B. Control Task(s) implement the Control Protocol and | |||
communicate with the Controller. Depending on the Control | communicate with the Controller. Depending on the Control | |||
Protocol there may be a number of specialist tasks such as: | Protocol there may be a number of specialist tasks such as: | |||
Configuration Task; Instruction Task; Suppression Task; | Configuration Task; Instruction Task; Suppression Task; | |||
skipping to change at page 7, line 36 | skipping to change at page 7, line 39 | |||
4. Data Management Tasks may exist to clean-up, filter or compress | 4. Data Management Tasks may exist to clean-up, filter or compress | |||
data on the MA such as Measurement Task results | data on the MA such as Measurement Task results | |||
3.1. Pre-Configuration Information | 3.1. Pre-Configuration Information | |||
This information is the minimal information that needs to be pre- | This information is the minimal information that needs to be pre- | |||
configured to the MA in order for it to successfully communicate with | configured to the MA in order for it to successfully communicate with | |||
a Controller during the registration process. Some of the Pre- | a Controller during the registration process. Some of the Pre- | |||
Configuration Information elements are repeated in the Configuration | Configuration Information elements are repeated in the Configuration | |||
Information in order to allow an LMAP Contoller to update these | Information in order to allow an LMAP Controller to update these | |||
items. The pre-configuration information also contains some elements | items. The pre-configuration information also contains some elements | |||
that are not under the control of the LMAP framework (such as the the | that are not under the control of the LMAP framework (such as the | |||
device identifier and device security credentials). | device identifier and device security credentials). | |||
This Pre-Configuration Information needs to include a URL of the | This Pre-Configuration Information needs to include a URL of the | |||
initial Controller from where configuration information can be | initial Controller from where configuration information can be | |||
communicated along with the security information required for the | communicated along with the security information required for the | |||
communication including the certificate of the Controller (or the | communication including the certificate of the Controller (or the | |||
certificate of the Certification Authority which was used to issue | certificate of the Certification Authority which was used to issue | |||
the certificate for the Controller). All this is expressed as a | the certificate for the Controller). All this is expressed as a | |||
Channel. While multiple Channels may be provided in the Pre- | Channel. While multiple Channels may be provided in the Pre- | |||
Configuration Information they must all be associated with a single | Configuration Information they must all be associated with a single | |||
Controller (e.g. over different interfaces or network protocols). | Controller (e.g. over different interfaces or network protocols). | |||
Where the MA pulls information from the Controller, the Pre- | Where the MA pulls information from the Controller, the Pre- | |||
Configuration Information also needs to contain the timing of the | Configuration Information also needs to contain the timing of the | |||
communication with the Controller as well as the nature of the | communication with the Controller as well as the nature of the | |||
communication itself (such as the protocol and data to be | communication itself (such as the protocol and data to be | |||
transfered). The timing is given as a Schedule that executes the | transferred). The timing is given as a Schedule that executes the | |||
Task(s) responsible for communication with the Controller. It is | Task(s) responsible for communication with the Controller. It is | |||
this Task (or Tasks) that implement the Control protocol between the | this Task (or Tasks) that implement the Control protocol between the | |||
MA and the Controller and utlises the Channel information. The | MA and the Controller and utilises the Channel information. The | |||
Task(s) may take additional parameters in which case a Task | Task(s) may take additional parameters in which case a Task | |||
Configuration can also be included. | Configuration can also be included. | |||
Even where information is pushed to the MA from the Controller | Even where information is pushed to the MA from the Controller | |||
(rather than pulled by the MA), a Schedule still needs to be | (rather than pulled by the MA), a Schedule still needs to be | |||
supplied. In this case the Schedule will simply execute a Controller | supplied. In this case the Schedule will simply execute a Controller | |||
listener task when the MA is started. A Channel is still required | listener task when the MA is started. A Channel is still required | |||
for the MA to establish secure communication with the Controller. | for the MA to establish secure communication with the Controller. | |||
It can be seen that these Channels, Schedules and Task Configurations | It can be seen that these Channels, Schedules and Task Configurations | |||
skipping to change at page 9, line 13 | skipping to change at page 9, line 13 | |||
since they are common to several parts of the information model. | since they are common to several parts of the information model. | |||
3.2. Configuration Information | 3.2. Configuration Information | |||
During registration or at any later point at which the MA contacts | During registration or at any later point at which the MA contacts | |||
the Controller (or vice-versa), the choice of Controller, details for | the Controller (or vice-versa), the choice of Controller, details for | |||
the timing of communication with the Controller or parameters for the | the timing of communication with the Controller or parameters for the | |||
communication Task(s) can be changed (as captured by the Channels, | communication Task(s) can be changed (as captured by the Channels, | |||
Schedules and Task Configurations objects). For example the pre- | Schedules and Task Configurations objects). For example the pre- | |||
configured Controller (specified as a Channel or Channels) may be | configured Controller (specified as a Channel or Channels) may be | |||
over-riden with a specific Controller that is more appropriate to the | over-ridden with a specific Controller that is more appropriate to | |||
MA device type, location or characteristics of the network (e.g. | the MA device type, location or characteristics of the network (e.g. | |||
access technology type or broadband product). The initial | access technology type or broadband product). The initial | |||
communication Schedule may be over-ridden with one more relevant to | communication Schedule may be over-ridden with one more relevant to | |||
routine communications between the MA and the Controller. | routine communications between the MA and the Controller. | |||
While some Control protocols may only use a single Schedule, other | While some Control protocols may only use a single Schedule, other | |||
protocolsmay use several Schedules (and related data transfer Tasks) | protocols may use several Schedules (and related data transfer Tasks) | |||
to update the Configuration Information, transfer the Instruction | to update the Configuration Information, transfer the Instruction | |||
Information, transfer Capability and Status Information and send | Information, transfer Capability and Status Information and send | |||
other information to the Controller such as log or error | other information to the Controller such as log or error | |||
notifications. Multiple Channels may be used to communicate with the | notifications. Multiple Channels may be used to communicate with the | |||
same Controller over multiple interfaces (e.g. to send logging | same Controller over multiple interfaces (e.g. to send logging | |||
information over a different network). | information over a different network). | |||
In addition the MA will be given further items of information that | In addition the MA will be given further items of information that | |||
relate specifically to the MA rather than the measurements it is to | relate specifically to the MA rather than the measurements it is to | |||
conduct or how to report results. The assignment of an ID to the MA | conduct or how to report results. The assignment of an ID to the MA | |||
skipping to change at page 10, line 13 | skipping to change at page 10, line 13 | |||
Schedule with the Controller and the duration for which the system is | Schedule with the Controller and the duration for which the system is | |||
willing to tolerate continued operation with potentially stale | willing to tolerate continued operation with potentially stale | |||
Instruction Information. | Instruction Information. | |||
While Pre-Configuration Information is persistent upon device reset | While Pre-Configuration Information is persistent upon device reset | |||
or power cycle, the persistency of the Configuration Information may | or power cycle, the persistency of the Configuration Information may | |||
be device dependent. Some devices may revert back to their pre- | be device dependent. Some devices may revert back to their pre- | |||
configuration state upon reboot or factory reset, while other devices | configuration state upon reboot or factory reset, while other devices | |||
may store all Configuration and Instruction information in persistent | may store all Configuration and Instruction information in persistent | |||
storage. A Controller can check whether an MA has the latest | storage. A Controller can check whether an MA has the latest | |||
Configuration and Instruction information by examing the Capability | Configuration and Instruction information by examining the Capability | |||
and Status information for the MA. | and Status information for the MA. | |||
It should be noted that control shedules and tasks cannot be | It should be noted that control shcedules and tasks cannot be | |||
suppressed as evidenced by the lack of suppression information in the | suppressed as evidenced by the lack of suppression information in the | |||
Configuration. The control schedule must only reference tasks listed | Configuration. The control schedule must only reference tasks listed | |||
as control tasks (i.e. within the Configuration information). Any | as control tasks (i.e. within the Configuration information). Any | |||
suppress-by-default flag against control tasks will be ignored. | suppress-by-default flag against control tasks will be ignored. | |||
Detail of the additional and updated information model elements: | Detail of the additional and updated information model elements: | |||
// MA Configuration | // MA Configuration | |||
object { | object { | |||
skipping to change at page 11, line 6 | skipping to change at page 11, line 6 | |||
2. Report Channels | 2. Report Channels | |||
3. Instruction Schedules | 3. Instruction Schedules | |||
4. Suppression | 4. Suppression | |||
The Instruction supports the execution of all Tasks on the MA except | The Instruction supports the execution of all Tasks on the MA except | |||
those that deal with communication with the Controller (specified in | those that deal with communication with the Controller (specified in | |||
(pre-)configuration information). The Tasks are configured in | (pre-)configuration information). The Tasks are configured in | |||
Instruction Task Configurations and included by reference in | Instruction Task Configurations and included by reference in | |||
Instruction Schdules that specify when to execute them. The results | Instruction Schedules that specify when to execute them. The results | |||
can be communicated to other Tasks or a Task may implement a | can be communicated to other Tasks or a Task may implement a | |||
Reporting Protocol and communicate results over Report Channels. | Reporting Protocol and communicate results over Report Channels. | |||
Suppression is used to temporarily stop the excution of new Tasks as | Suppression is used to temporarily stop the execution of new Tasks as | |||
specified by the Instruction Schedules (and optionally to stop | specified by the Instruction Schedules (and optionally to stop | |||
ongoing Tasks). | ongoing Tasks). | |||
A Task Configuration is used to configure the mandatory and optional | A Task Configuration is used to configure the mandatory and optional | |||
parameters of a Task. It also serves to instruct the MA about the | parameters of a Task. It also serves to instruct the MA about the | |||
Task including the ability to resolve the Task to an executable and | Task including the ability to resolve the Task to an executable and | |||
specifying the schema for the Task parameters. | specifying the schema for the Task parameters. | |||
A Report Channel defines how to communicate with a single remote | A Report Channel defines how to communicate with a single remote | |||
system specified by a URL. A Report Channel is used to send results | system specified by a URL. A Report Channel is used to send results | |||
skipping to change at page 12, line 13 | skipping to change at page 12, line 13 | |||
at a later time. | at a later time. | |||
The explicit Suppression instruction message is able to simply | The explicit Suppression instruction message is able to simply | |||
enable/disable all Instruction Tasks (that are enabled for default | enable/disable all Instruction Tasks (that are enabled for default | |||
suppression) as well as having fine control on which Tasks are | suppression) as well as having fine control on which Tasks are | |||
suppressed. Suppression of both specified Task Configurations and | suppressed. Suppression of both specified Task Configurations and | |||
Measurement Schedules is supported. Support for disabling specific | Measurement Schedules is supported. Support for disabling specific | |||
Task Configurations allows malfunctioning or mis-configured Tasks or | Task Configurations allows malfunctioning or mis-configured Tasks or | |||
Task Configurations that have an impact on a particular part of the | Task Configurations that have an impact on a particular part of the | |||
network infrastructure (e.g., a particular Measurement Peer) to be | network infrastructure (e.g., a particular Measurement Peer) to be | |||
targetted. Support for disabling specific Schedules allows for | targeted. Support for disabling specific Schedules allows for | |||
particularly heavy cycles or sets of less essential Measurement Tasks | particularly heavy cycles or sets of less essential Measurement Tasks | |||
to be suppressed quickly and effectively. Note that Suppression has | to be suppressed quickly and effectively. Note that Suppression has | |||
no effect on either Controller Tasks or Controller Schedules. | no effect on either Controller Tasks or Controller Schedules. | |||
When no tasks or schedules are explicitly listed, all Instruction | When no tasks or schedules are explicitly listed, all Instruction | |||
tasks will be suppressed (or not) as indicated by the suppress-by- | tasks will be suppressed (or not) as indicated by the suppress-by- | |||
default flag in the Task Configuration. If tasks or schedules are | default flag in the Task Configuration. If tasks or schedules are | |||
listed explicitly then only these listed tasks or schedules will be | listed explicitly then only these listed tasks or schedules will be | |||
suppressed regardless of the suppress-by-default flag. If both | suppressed regardless of the suppress-by-default flag. If both | |||
individual tasks and individual schedules are listed then only the | individual tasks and individual schedules are listed then only the | |||
listed schedules, plus the listed tasks where present in other | listed schedules, plus the listed tasks where present in other | |||
schedules, will be suppressed regardless of the suppress-by-default | schedules, will be suppressed regardless of the suppress-by-default | |||
flag. | flag. | |||
Suppression stops new Tasks from executing. In addtion, the | Suppression stops new Tasks from executing. In addition, the | |||
Suppression information also supports an additional Boolean that is | Suppression information also supports an additional Boolean that is | |||
used to select whether on-going tasks are also to be terminated. | used to select whether on-going tasks are also to be terminated. | |||
Unsuppression is achieved through either overwriting the Measurement | Unsuppression is achieved through either overwriting the Measurement | |||
Suppression information (e.g. changing 'enabled' to False) or through | Suppression information (e.g. changing 'enabled' to False) or through | |||
the use of an End time such that the Measurement Suppression will no | the use of an End time such that the Measurement Suppression will no | |||
longer be in effect beyond this time. The datetime format used for | longer be in effect beyond this time. The datetime format used for | |||
all elements in the information model (e.g. the suppression start and | all elements in the information model (e.g. the suppression start and | |||
end dates) MUST conform to RFC 3339 [RFC3339]. | end dates) MUST conform to RFC 3339 [RFC3339]. | |||
skipping to change at page 15, line 35 | skipping to change at page 15, line 35 | |||
Tasks/Roles (specified by a registry entry) that are actually | Tasks/Roles (specified by a registry entry) that are actually | |||
installed or available on the MA. Status information includes the | installed or available on the MA. Status information includes the | |||
times that operations were last performed such as contacting the | times that operations were last performed such as contacting the | |||
Controller or producing Reports. | Controller or producing Reports. | |||
MA Status information model elements: | MA Status information model elements: | |||
// Main MA Status information object | // Main MA Status information object | |||
object { | object { | |||
uuid ma-agent-id; | uuid ma-agent-id; | |||
urn ma-device-id; | urn ma-device-id; | |||
string ma-hardware; | string ma-hardware; | |||
string ma-firmware; | string ma-firmware; | |||
string ma-version; | string ma-version; | |||
ma-interface-obj ma-interfaces<0..*>; | ma-interface-obj ma-interfaces<0..*>; | |||
ma-task-capability-obj ma-supported-tasks<0..*>; | ||||
datetime ma-last-task; | datetime ma-last-started; | |||
datetime ma-last-report; | [ma-condition-obj ma-conditions<0..*>;] | |||
datetime ma-last-instruction; | [ma-task-status-obj ma-task-status<0..*>;] | |||
datetime ma-last-configuration; | } ma-status-obj; | |||
// Per-Task status information and conditions | ||||
[ma-condition-obj ma-conditions<0..*>;] | object { | |||
string ma-task-name; | ||||
string ma-task-role; | ||||
uri ma-task-registry; | ||||
datetime ma-task-last-invocation; | ||||
datetime ma-task-last-successful; | ||||
string ma-task-last-successful-message; | ||||
datetime ma-task-last-failed; | ||||
string ma-task-last-failed-message; | ||||
[ma-condition-obj ma-task-conditions<0..*>]; | ||||
} ma-task-status-obj | ||||
ma-task-capability-obj ma-supported-tasks<0..*>; | ||||
} ma-status-obj; | ||||
// Additional status conditions | // Additional status conditions | |||
object { | object { | |||
string ma-condition-code; | int ma-condition-code; | |||
string ma-condition-text; | string ma-condition-text; | |||
} ma-condition-obj | } ma-condition-obj | |||
// Interface information | // Interface information | |||
object { | object { | |||
string ma-interface-name; | string ma-interface-name; | |||
string ma-interface-type; | string ma-interface-type; | |||
[int ma-interface-speed;] // bps | [int ma-interface-speed;] // bps | |||
[string ma-link-layer-address;] | [string ma-link-layer-address;] | |||
[ip-address ma-interface-ip-addresses<0..*>]; | [ip-address ma-interface-ip-addresses<0..*>]; | |||
[ip-address ma-interface-gateways<0..*>;] | [ip-address ma-interface-gateways<0..*>;] | |||
[ip-address ma-interface-dns-servers<0..*>;] | [ip-address ma-interface-dns-servers<0..*>;] | |||
} ma-interface-obj; | } ma-interface-obj; | |||
// Supported tasks/roles | // Supported tasks/roles | |||
object { | object { | |||
string ma-task-name; | string ma-task-name; | |||
string ma-task-role; | ||||
uri ma-task-registry; | uri ma-task-registry; | |||
} ma-task-capability-obj; | } ma-task-capability-obj; | |||
3.6. Reporting Information | 3.6. Reporting Information | |||
At a point in time specified by a Schedule, the MA will execute a | 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 | task or tasks that communicate a set of measurement results to the | |||
Collector. Some of these Tasks (notably Reporting Tasks) will | Collector. These Reporting Tasks will be configured to transmit task | |||
understand how to transmit task results over a specified Report | results over a specified Report Channel to a Collector. | |||
Channel to a Collector. Where to send the data is defined within the | ||||
Task Configuration for the Reporting Task. | ||||
It should be noted that the output from Tasks does not need to be | It should be noted that the output from Tasks does not need to be | |||
sent to communication Channels. It can alternatively, or | sent to communication Channels. It can alternatively, or | |||
additionally, be sent to other Tasks on the MA. This facilitates | additionally, be sent to other Tasks on the MA. This facilitates | |||
using a first Measurement Task to control the operation of a later | using a first Measurement Task to control the operation of a later | |||
Measurement Task (such as first probing available line speed and then | Measurement Task (such as first probing available line speed and then | |||
adjusting the operation of a video testing measurement) and also to | adjusting the operation of a video testing measurement) and also to | |||
allow local processing of data to output alarms (e.g. when | allow local processing of data to output alarms (e.g. when | |||
performance drops from earlier levels). Of course, subsequent Tasks | performance drops from earlier levels). Of course, subsequent Tasks | |||
also include Tasks that implement the reporting protocol(s) and | also include Tasks that implement the reporting protocol(s) and | |||
transfer data to one or more Collector(s). | transfer data to one or more Collector(s). | |||
The report is structured hierarchically to avoid repetition of report | The Report generated by a Reporting Task is structured hierarchically | |||
header and Measurement Task Configuration information. The report | to avoid repetition of report header and Measurement Task | |||
starts with the timestamp of the report generation on the MA and | Configuration information. The report starts with the timestamp of | |||
details about the MA including the optional Measurement Agent ID and | the report generation on the MA and details about the MA including | |||
Group ID (controlled by the Configuration Information). | the optional Measurement Agent ID and Group ID (controlled by the | |||
Configuration Information). | ||||
Much of the report Information is optional and will depend on the | Much of the report Information is optional and will depend on the | |||
implementation of the Reporting Task and any parameters defined in | implementation of the Reporting Task and any parameters defined in | |||
the Task Configuration for the Reporting Task. For example some | the Task Configuration for the Reporting Task. For example some | |||
Reporting Tasks may choose not to include the Measurement Task | Reporting Tasks may choose not to include the Measurement Task | |||
Configuration or Sscheduled task parameters, while others may do so | Configuration or scheduled task parameters, while others may do so | |||
dependent on the Controller setting a configurable parameter in the | dependent on the Controller setting a configurable parameter in the | |||
Task Configuration. | Task Configuration. | |||
It is possible for a Reporting Task to send just the Report header | It is possible for a Reporting Task to send just the Report header | |||
(datetime and optional agent ID and/or Group ID) if no measurement | (datetime and optional agent ID and/or Group ID) if no measurement | |||
data is available. Whether to send such empty reports again is | data is available. Whether to send such empty reports again is | |||
dependent on the implementation of the Reporting Task and potential | dependent on the implementation of the Reporting Task and potential | |||
Task Configuration parameter. | Task Configuration parameter. | |||
The handling of measurement data on the MA before generating a Report | The handling of measurement data on the MA before generating a Report | |||
skipping to change at page 17, line 44 | skipping to change at page 18, line 11 | |||
reported by individual tasks at the time they execute. Either a | reported by individual tasks at the time they execute. Either a | |||
Measurement Task can report contextual parameters that are relevant | Measurement Task can report contextual parameters that are relevant | |||
to that particular measurement, or specific tasks can be used to | to that particular measurement, or specific tasks can be used to | |||
gather a set of contextual and environmental data. at certain times | gather a set of contextual and environmental data. at certain times | |||
independent of the reporting schedule. | independent of the reporting schedule. | |||
After the report header information the results are reported grouped | After the report header information the results are reported grouped | |||
according to different Measurement Task Configurations. Each Task | according to different Measurement Task Configurations. Each Task | |||
section optionally starts with replicating the Measurement Task | section optionally starts with replicating the Measurement Task | |||
Configuration information before the result headers (titles for data | Configuration information before the result headers (titles for data | |||
columns) and the result data rows. | columns) and the result data rows. The Options reported are those | |||
used for the scheduled execution of the Measurement Task and | ||||
therefore include the Options specified in the Task Configuration as | ||||
well as additional Options specified in the Scheduled Task. The | ||||
Scheduled Task Options are appended to the Task Configuration Options | ||||
in exactly the same order as they were provided to the Task during | ||||
execution. | ||||
The result row data includes a time for the start of the measurement | The result row data includes a time for the start of the measurement | |||
and optionally an end time where the duration also needs to be | and optionally an end time where the duration also needs to be | |||
considered in the data analysis. | considered in the data analysis. | |||
Some Measurement Tasks may optionally include an indication of the | Some Measurement Tasks may optionally include an indication of the | |||
cross-traffic although the meaning a definition of cross-traffic is | cross-traffic although the meaning a definition of cross-traffic is | |||
left up to each individual Measurement Task. Some Measurement Tasks | left up to each individual Measurement Task. Some Measurement Tasks | |||
may also output other environmental measures in addtion to cross- | may also output other environmental measures in addition to cross- | |||
traffic such as CPU utlisation or interface speed. | traffic such as CPU utlilisation or interface speed. | |||
Where the Configuration and Instruction information represent | Where the Configuration and Instruction information represent | |||
information transmitted via the Control Protocol, the Report | information transmitted via the Control Protocol, the Report | |||
represents the information that is transmitted via the Report | represents the information that is transmitted via the Report | |||
Protocol. It is constructed at the time of sending a report and | Protocol. It is constructed at the time of sending a report and | |||
represents the inherent structure of the information that is sent to | represents the inherent structure of the information that is sent to | |||
the Collector. | the Collector. | |||
Information model elements: | Information model elements: | |||
skipping to change at page 19, line 12 | skipping to change at page 19, line 39 | |||
Tasks. Each Schedule contains basically two elements: a list of | Tasks. Each Schedule contains basically two elements: a list of | |||
Tasks to be executed and a timing object for the Schedule. The | Tasks to be executed and a timing object for the Schedule. The | |||
Schedule states what Tasks to run (with what configuration) and when | Schedule states what Tasks to run (with what configuration) and when | |||
to run the Tasks. | to run the Tasks. | |||
Multiple Tasks in the list of a single Measurement Schedule will be | Multiple Tasks in the list of a single Measurement Schedule will be | |||
executed in order with minimal gaps. Tasks in different Schedules | executed in order with minimal gaps. Tasks in different Schedules | |||
execute in parallel with such conflicts being reported in the | execute in parallel with such conflicts being reported in the | |||
Reporting Information. If two or more Schedules have the same start | Reporting Information. If two or more Schedules have the same start | |||
time, then the two will execute in parallel. There is no mechanism | time, then the two will execute in parallel. There is no mechanism | |||
to prioritise one schedule over another or to mutex schduled tasks. | to prioritise one schedule over another or to mutex scheduled tasks. | |||
As well as specifying which Tasks to execute, the Schedule also | As well as specifying which Tasks to execute, the Schedule also | |||
specifies how to link the data outputs from each scheduled task to | specifies how to link the data outputs from each scheduled task to | |||
other scheduled tasks. Specifying this within the Schedule allows | other scheduled tasks. Specifying this within the Schedule allows | |||
the highest level of flexibility since it is even possible to send | the highest level of flexibility since it is even possible to send | |||
the output from different executions of the same Task Configuration | the output from different executions of the same Task Configuration | |||
to different destinations. Since a single Task may have multiple | to different destinations. Since a single Task may have multiple | |||
outputs, the Schedule can independently specify which outputs go to | outputs, the Schedule can independently specify which outputs go to | |||
which destinations. For example, a Measurement Task might report | which destinations. For example, a Measurement Task might report | |||
routine results to a data Reporting Task that communicates hourly via | routine results to a data Reporting Task that communicates hourly via | |||
the Broadband PPP interface, but also outputs emergency conditions | the Broadband PPP interface, but also outputs emergency conditions | |||
via an alarm Reporting Task communicating immediately over a GPRS | via an alarm Reporting Task communicating immediately over a GPRS | |||
channel. Note that task-to-task data transfer is always specified in | channel. Note that task-to-task data transfer is always specified in | |||
association with the scheduled execution of the sending task - there | association with the scheduled execution of the sending task - there | |||
is no need for a corresponding input specification for the receiving | is no need for a corresponding input specification for the receiving | |||
task. While it is likely that an MA implementation will use a queue | task. While it is likely that an MA implementation will use a queue | |||
mechanism between the scheduled tasks, this Information Model does | mechanism between the scheduled tasks, this Information Model does | |||
not mandate or define a queue, or any potential associated parameters | not mandate or define a queue, or any potential associated parameters | |||
such as storage size and retention policies. | such as storage size and retention policies. | |||
When specifying the task to execute withi the Schedule, it is | When specifying the task to execute within the Schedule, it is | |||
possible to add to the task configuration option parameters. This | possible to add to the task configuration option parameters. This | |||
allows the Task Configuration to deterimine the common | allows the Task Configuration to determine the common characteristics | |||
characteristics of a Task, while selected parameters (e.g. the test | of a Task, while selected parameters (e.g. the test target URL) are | |||
target URL) are defined within the schedule. A single Tasks | defined within the schedule. A single Tasks Configuration can even | |||
Configuration can even be used multiple times in the same schedule | be used multiple times in the same schedule with different additional | |||
with different additional parameters. This allows for effciency in | parameters. This allows for efficiency in creating and transferring | |||
creating and transferring the Instruction. Note that the semantics | the Instruction. Note that the semantics of what happens if an | |||
of what happens if an option is defined multiple times (either in the | option is defined multiple times (either in the Task Configuration, | |||
Task Configuration, Schedule or in both) is not standardised and will | Schedule or in both) is not standardised and will depend upon the | |||
depend upon the Task. For example some tasks may legitimately take | Task. For example, some tasks may legitimately take multiple values | |||
multiple values for a single parameter. | for a single parameter. | |||
Where Options are specified in both the Schedule and the Task | ||||
Configuration, the Schedule Options are appended to those specified | ||||
in the Task Configuration. | ||||
Example: A Schedule references a single Measurement Task | Example: A Schedule references a single Measurement Task | |||
Configuration for the UDP latency. It specifies that results are | Configuration for the UDP latency. It specifies that results are | |||
to be sent to a scheduled Reporting Task. This Reporting Task is | to be sent to a scheduled Reporting Task. This Reporting Task is | |||
executed by a separate Schedule that specifies that it should run | executed by a separate Schedule that specifies that it should run | |||
hourly at 5 minutes past the hour. When run this Reporting Task | 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 | 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 | other data to be included in the hourly report and transfers it to | |||
the Collector over the Report Channel specified within its own | the Collector over the Report Channel specified within its own | |||
Schedule. | Schedule. | |||
skipping to change at page 20, line 26 | skipping to change at page 21, line 15 | |||
// Scheduled Task object with reference (by name string) to Task | // Scheduled Task object with reference (by name string) to Task | |||
// Configuration and mappings of data outputs to destination tasks | // Configuration and mappings of data outputs to destination tasks | |||
object { | object { | |||
string ma-schedule-task-name; | string ma-schedule-task-name; | |||
[name-value-pair ma-schedule-task-options<0..*>]; | [name-value-pair ma-schedule-task-options<0..*>]; | |||
[ma-sched-downstream-tasks-obj ma-schedule-destination-tasks<0..*>;] | [ma-sched-downstream-tasks-obj ma-schedule-destination-tasks<0..*>;] | |||
} ma-sched-task-obj; | } ma-sched-task-obj; | |||
// Specification of destination scheduled tasks using reference | // Specification of destination scheduled tasks using reference | |||
// to schedule and task configuration configuration names. Mapping | // to schedule and task configuration names. Mapping of | |||
// of integer denoted data outputs to destination schduled task | // integer denoted data outputs to destination scheduled task | |||
object { | object { | |||
[string ma-schedule-task-destination-schedule-name]; | [string ma-schedule-task-destination-schedule-name]; | |||
[string ma-schedule-task-destination-task-configuration-name]; | [string ma-schedule-task-destination-task-configuration-name]; | |||
[int ma-schedule-task-output-selection<0..*>;] // default: all | [int ma-schedule-task-output-selection<0..*>;] // default: all | |||
} ma-sched-destination-tasks-obj; | } ma-sched-destination-tasks-obj; | |||
Example: A measurement task has two defined inter-task outputs, one | Example: A measurement task has two defined inter-task outputs, one | |||
for routine measurement results and one for errors during the task | for routine measurement results and one for errors during the task | |||
execution. These are defined as available outputs by the task and | execution. These are defined as available outputs by the task and | |||
are denoted by the integers 1 & 2. In this example, both outputs | are denoted by the integers 1 & 2. In this example, both outputs | |||
are sent to the same reporting task called "Hourly reporting Task" | are sent to the same reporting task called "Hourly reporting Task" | |||
that is excuted from the "Hourly Schedule" schedule. This is done | that is executed from the "Hourly Schedule" schedule. This is | |||
by creating a ma-sched-destination-tasks-obj with the output | done by creating a ma-sched-destination-tasks-obj with the output | |||
selection as [1,2] and the destination task configuration name as | selection as [1,2] and the destination task configuration name as | |||
["Hourly Reporting Task"] and the destination schedule name as | ["Hourly Reporting Task"] and the destination schedule name as | |||
"Hourly Schedule". | "Hourly Schedule". | |||
Measurement Task | Measurement Task | |||
Output 1 -----+----> "Hourly Schedule":"Hourly Reporting Task" | Output 1 -----+----> "Hourly Schedule":"Hourly Reporting Task" | |||
Output 2 ----/ | Output 2 ----/ | |||
3.7.2. Channels | 3.7.2. Channels | |||
A Channel defines a bi-directional communication channel between the | A Channel defines a bi-directional communication channel between the | |||
MA and a Controller or Collector. Multiple Channels can be defined | MA and a Controller or Collector. Multiple Channels can be defined | |||
to enable results to be split or duplicated across different | to enable results to be split or duplicated across different | |||
Collectors. | Collectors. | |||
Each Channel contains the details of the remote endpoint (including | Each Channel contains the details of the remote endpoint (including | |||
location and security credential information such as the | location and security credential information such as the | |||
certificate). The timing of when to communicate over a Channel is | certificate). The timing of when to communicate over a Channel is | |||
specified within the Schedule. The certificate can be the digital | specified by the Schedule which executes the corresponding Control or | |||
certificate associated to the FQDN in the URL or it can be the | Reporting Task. The certificate can be the digital certificate | |||
certificate of the Certification Authority that was used to issue the | associated to the FQDN in the URL or it can be the certificate of the | |||
certificate for the FQDN (Fully Qualified Domain Name) of the target | Certification Authority that was used to issue the certificate for | |||
URL (which will be retrieved later on using a communication protocol | the FQDN (Fully Qualified Domain Name) of the target URL (which will | |||
such as TLS). In order to establish a secure channel, the MA will | be retrieved later on using a communication protocol such as TLS). | |||
use it's own security credentials (in the Configuration Information) | In order to establish a secure channel, the MA will use it's own | |||
and the given credentials for the individual Channel end-point. | 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 text | As with the Task Configurations, each Channel is also given a text | |||
name by which it can be referenced from a Task Configuration. | name by which it can be referenced as a Task Option. | |||
Although the same in terms of information, Channels used for | Although the same in terms of information, Channels used for | |||
communication with the Controller are refered to as Control Channels | communication with the Controller are referred to as Control Channels | |||
whereas Channels to Collectors are refered to as Report Channels. | whereas Channels to Collectors are referred to as Report Channels. | |||
Hence Control Channels will be referenced from Control Tasks executed | Hence Control Channels will be referenced from Control Tasks executed | |||
by a Control Schedule, whereas Report Channels will be referenced | by a Control Schedule, whereas Report Channels will be referenced | |||
from within Reporting Tasks executed by an Instruction Schedule. | from within Reporting Tasks executed by an Instruction Schedule. | |||
Multiple interfaces are also supported. For example the Controller | Multiple interfaces are also supported. For example the Reporting | |||
could choose to receive some results over GPRS. This is especially | Task could be configured to send some results over GPRS. This is | |||
useful when such results indicate the loss of connectivity on a | especially useful when such results indicate the loss of connectivity | |||
different network interface. | on a different network interface. | |||
Example: A Channel using for reporting results may specify that | Example: A Channel using for reporting results may specify that | |||
results are to be sent to the URL (https://collector.foo.org/ | results are to be sent to the URL (https://collector.foo.org/ | |||
report/), using the appropriate digital certificate to establish a | report/), using the appropriate digital certificate to establish a | |||
secure channel.. | secure channel.. | |||
// Channel object with name string allowing reference from Schedule. | // Channel object with name string allowing reference. | |||
// Contains channel endpoint target URL and security credentials | // Contains channel endpoint target URL and security credentials | |||
// to establish secure channel. Optionally allows interface | // to establish secure channel. Optionally allows interface | |||
// specification (by interface name string reference) | // specification (by interface name string reference) | |||
// and connection when no data is pending for transfer | ||||
object { | object { | |||
string ma-channel-name; | string ma-channel-name; | |||
url ma-channel-target; | url ma-channel-target; | |||
credentials ma-channel-credentials; | credentials ma-channel-credentials; | |||
[string ma-channel-interface-name;] | [string ma-channel-interface-name;] | |||
} ma-channel-obj; | } ma-channel-obj; | |||
3.7.3. Task Configurations | 3.7.3. Task Configurations | |||
skipping to change at page 22, line 39 | skipping to change at page 23, line 16 | |||
A Measurement Task Configuration is the same in information terms to | A Measurement Task Configuration is the same in information terms to | |||
any other Task Configuration. Both measurement and non-measurement | any other Task Configuration. Both measurement and non-measurement | |||
Tasks have a registry entry to enable the MA to uniquely identify the | Tasks have a registry entry to enable the MA to uniquely identify the | |||
Task it should execute and retrieve the schema for any parameters | Task it should execute and retrieve the schema for any parameters | |||
that may be passed to the Task. This registry entry is specified as | that may be passed to the Task. This registry entry is specified as | |||
a URI and can therefore be used to identify the Task within a | a URI and can therefore be used to identify the Task within a | |||
namespace or point to a web or local file location for the Task | namespace or point to a web or local file location for the Task | |||
information. As mentioned previously this entry may be used to | information. As mentioned previously this entry may be used to | |||
identify the Measurement Task in a public namespace | identify the Measurement Task in a public namespace | |||
[I-D.bagnulo-ippm-new-registry] . | [I-D.ietf-ippm-metric-registry] . | |||
Example: A Measurement Task Configuration may configure a single | Example: A Measurement Task Configuration may configure a single | |||
Measurement Task for measuring UDP latency. The Measurement Task | Measurement Task for measuring UDP latency. The Measurement Task | |||
Configuration could define the destination port and address for | Configuration could define the destination port and address for | |||
the measurement as well as the duration, internal packet timing | the measurement as well as the duration, internal packet timing | |||
strategy and other parameters (for example a stream for one hour | strategy and other parameters (for example a stream for one hour | |||
and sending one packet every 500 ms). It may also define the | and sending one packet every 500 ms). It may also define the | |||
output type and possible parameters (for example the output type | output type and possible parameters (for example the output type | |||
can be the 95th percentile mean) where the measurement task | can be the 95th percentile mean) where the measurement task | |||
accepts such parameters. It does not define when the task starts | accepts such parameters. It does not define when the task starts | |||
(this is defined by the Schedule element), so it does not by | (this is defined by the Schedule element), so it does not by | |||
itself instruct the MA to actually perform this Measurement Task. | itself instruct the MA to actually perform this Measurement Task. | |||
The Task Configuration will include a local short name for reference | The Task Configuration will include a local short name for reference | |||
by a Schedule. Task Configurations will also contain a registry | by a Schedule. Task Configurations will also contain a registry | |||
entry as described above. In addition the Task can be configured | entry as described above. In addition the Task can be configured | |||
through a set of configuration Options. The nature and number of | through a set of configuration Options. The nature and number of | |||
these Options will depend upon the Task and will be resolved through | these Options will depend upon the Task. These options are expressed | |||
the registry parameter. These options are expressed as name-value | as name-value pairs although the 'value' may be a structured object | |||
pairs although the 'value' may be a structured object instead of a | instead of a simple string or numeric value. The implementation of | |||
simple string or numeric value. The implementation of these name- | these name-value pairs will vary between data models such as JSON, | |||
value pairs will vary between data models such as JSON, XML or TR- | XML or TR-069. | |||
069. | ||||
A parameter that must be present for Reporting Tasks is the Channel | A Option that must be present for Reporting Tasks is the Channel | |||
reference specifying how to communicate with a Collector. This is | reference specifying how to communicate with a Collector. This is | |||
included in the task options and will have a value that matches a | included in the task options and will have a value that matches a | |||
channel name that has been defined in the Instruction. Similarly | channel name that has been defined in the Instruction. Similarly | |||
Control Tasks will have a simialr option with the value set to a | Control Tasks will have a similar option with the value set to a | |||
specified Control Channel. | specified Control Channel. | |||
A reporting task might also have a flag parameter to indicate whether | A reporting task might also have a flag parameter to indicate whether | |||
to report if there is no measurement result data pending to be | to report if there is no measurement result data pending to be | |||
transferred to the Collector. In addition many tasks will also take | transferred to the Collector. In addition many tasks will also take | |||
as a parameter which interface to operate over. | as a parameter which interface to operate over. | |||
The Task Configuration also contains a suppress-by-default flag that | The Task Configuration also contains a suppress-by-default flag that | |||
specifies the behaviour of a default suppress instruction (that does | specifies the behaviour of a default suppress instruction (that does | |||
not list explicit tasks or schedules). If this flag is set to FALSE | not list explicit tasks or schedules). If this flag is set to FALSE | |||
skipping to change at page 24, line 13 | skipping to change at page 24, line 27 | |||
mean that two sets of results should not be directly compared. | mean that two sets of results should not be directly compared. | |||
// Task Configuration object with string name to allow reference | // Task Configuration object with string name to allow reference | |||
// from Schedule. Contains URI to link to registry or local | // from Schedule. Contains URI to link to registry or local | |||
// specification of the Task. Options allow the configuration | // specification of the Task. Options allow the configuration | |||
// of Task parameters (in the form of name-value pairs) | // of Task parameters (in the form of name-value pairs) | |||
object { | object { | |||
string ma-task-name; | string ma-task-name; | |||
uri ma-task-registry-entry; | uri ma-task-registry-entry; | |||
[name-value-pair ma-task-options<0..*>]; | [ma-task-option ma-task-options<0..*>]; | |||
[boolean ma-task-suppress-by-default;] // default: TRUE | [boolean ma-task-suppress-by-default;] // default: TRUE | |||
[string ma-task-cycle-id;] | [string ma-task-cycle-id;] | |||
} ma-task-obj; | } ma-task-obj; | |||
While many of the Task Configuration Options are left to individual | ||||
tasks to define, some common Options are used by multiple tasks and | ||||
benefit from standardisation. These Options are Channel and Role. | ||||
Channel is used to specify the details of an endpoint for Control or | ||||
Reporting Task communications and is detailed elsewhere in this | ||||
document. | ||||
Role is used to specify which Role the task should be performing (as | ||||
defined in the registry) if multiple roles are available. | ||||
// General Task Option | ||||
object { | ||||
string ma-option-name; | ||||
object ma-option-value; | ||||
} ma-task-option | ||||
// Channel Option | ||||
oobject { | ||||
string ma-option-name; // set to "channel" | ||||
string ma-option-value; // set to ma-channel-name reference | ||||
} ma-task-option | ||||
// Role Option | ||||
object { | ||||
string ma-option-name; // set to "role" | ||||
string ma-option-value; // set to registry role reference | ||||
} ma-task-option | ||||
3.7.4. Timing Information | 3.7.4. Timing Information | |||
The Timing information object used throughout the information models | The Timing information object used throughout the information models | |||
can take one of five different forms: | can take one of five different forms: | |||
1. Periodic. Specifies a start, end and interval time in | 1. Periodic. Specifies a start, end and interval time in | |||
milliseconds | milliseconds | |||
2. Calendar: Specifies a calendar based pattern - e.g. 22 minutes | 2. Calendar: Specifies a calendar based pattern - e.g. 22 minutes | |||
past each hour of the day on weekdays | past each hour of the day on weekdays | |||
skipping to change at page 24, line 48 | skipping to change at page 26, line 11 | |||
This randomness parameter defines a uniform interval in milliseconds | This randomness parameter defines a uniform interval in milliseconds | |||
over which the start of the task is delayed from the starting times | over which the start of the task is delayed from the starting times | |||
specified by the timing object. | specified by the timing object. | |||
Both the Periodic and Calendar timing objects allow for a series of | Both the Periodic and Calendar timing objects allow for a series of | |||
tasks to be executed. While both have an optional end time, it is | tasks to be executed. While both have an optional end time, it is | |||
best practice to always configure an end time and refresh the | best practice to always configure an end time and refresh the | |||
information periodically to ensure that lost MAs do not continue | information periodically to ensure that lost MAs do not continue | |||
their tasks forever. | their tasks forever. | |||
Starup timing is only excuted on device startup - not when a new | Starup timing is only executed on device startup - not when a new | |||
Instruction is transferred to the MA. If scheduled task execution is | Instruction is transferred to the MA. If scheduled task execution is | |||
desired both on the transfer of the Instruction and on device restart | desired both on the transfer of the Instruction and on device restart | |||
then both the Immediate and Starup timing needs to be used in | then both the Immediate and Startup timing needs to be used in | |||
conjunction. | conjunction. | |||
The datetime format used for all elements in the information model | The datetime format used for all elements in the information model | |||
MUST conform to RFC 3339 [RFC3339]. | MUST conform to RFC 3339 [RFC3339]. | |||
// Main Timing object with name string to allow reference by Schedule | // Main Timing object with name string to allow reference by Schedule | |||
// Must be specialised by one of the Timing options. | // Must be specialised by one of the Timing options. | |||
// Includes optional uniform random spread in ms from start time | // Includes optional uniform random spread in ms from start time | |||
// given by Timing specialisation | // given by Timing specialisation | |||
skipping to change at page 27, line 46 | skipping to change at page 29, line 7 | |||
This Information Model deals with information about the control and | This Information Model deals with information about the control and | |||
reporting of the Measurement Agent. There are broadly two security | reporting of the Measurement Agent. There are broadly two security | |||
considerations for such an Information Model. Firstly the | considerations for such an Information Model. Firstly the | |||
Information Model has to be sufficient to establish secure | Information Model has to be sufficient to establish secure | |||
communication channels to the Controller and Collector such that | communication channels to the Controller and Collector such that | |||
other information can be sent and received securely. Additionally, | other information can be sent and received securely. Additionally, | |||
any mechanisms that the Network Operator or other device | any mechanisms that the Network Operator or other device | |||
administrator employs to pre-configure the MA must also be secure to | administrator employs to pre-configure the MA must also be secure to | |||
protect unauthorized parties from modifying pre-configuration | protect unauthorized parties from modifying pre-configuration | |||
information. These mechanisms are important to ensure that the MA | information. These mechanisms are important to ensure that the MA | |||
cannot be hijacked, for example to particpate in a DDoS attack. | cannot be hijacked, for example to participate in a DDoS attack. | |||
The second consideration is that no mandated information items should | The second consideration is that no mandated information items should | |||
pose a risk to confidentiality or privacy given such secure | pose a risk to confidentiality or privacy given such secure | |||
communication channels. For this latter reason items such as the MA | communication channels. For this latter reason items such as the MA | |||
context and MA ID are left optional and can be excluded from some | context and MA ID are left optional and can be excluded from some | |||
deployments. This would, for example, allow the MA to remain | deployments. This would, for example, allow the MA to remain | |||
anonymous and for information about location or other context that | anonymous and for information about location or other context that | |||
might be used to identify or track the MA to be omitted or blurred. | might be used to identify or track the MA to be omitted or blurred. | |||
The Information Model should support wherever relevant, all the | The Information Model should support wherever relevant, all the | |||
skipping to change at page 28, line 28 | skipping to change at page 29, line 38 | |||
[FP7/2007-2013] under grant agreement number 317647. | [FP7/2007-2013] under grant agreement number 317647. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-lmap-framework] | [I-D.ietf-lmap-framework] | |||
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | |||
Aitken, P., and A. Akhter, "A framework for large-scale | Aitken, P., and A. Akhter, "A framework for large-scale | |||
measurement platforms (LMAP)", draft-ietf-lmap- | measurement platforms (LMAP)", draft-ietf-lmap- | |||
framework-03 (work in progress), January 2014. | framework-10 (work in progress), January 2015. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the | [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the | |||
Internet: Timestamps", RFC 3339, July 2002. | Internet: Timestamps", RFC 3339, July 2002. | |||
7.2. Informative References | 7.2. Informative References | |||
[I-D.bagnulo-ippm-new-registry] | [I-D.ietf-ippm-metric-registry] | |||
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and | Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. | |||
A. Morton, "A registry for commonly used metrics", draft- | Akhter, "Registry for Performance Metrics", draft-ietf- | |||
bagnulo-ippm-new-registry-01 (work in progress), July | ippm-metric-registry-01 (work in progress), September | |||
2013. | 2014. | |||
[I-D.schoenw-lmap-yang] | ||||
Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for | ||||
LMAP Measurement Agents", draft-schoenw-lmap-yang-02 (work | ||||
in progress), January 2015. | ||||
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between | [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between | |||
Information Models and Data Models", RFC 3444, January | Information Models and Data Models", RFC 3444, January | |||
2003. | 2003. | |||
Appendix A. JSON Data Model Example | Appendix A. JSON Data Model Example | |||
In order to give an example of data in the Information Model we need | In order to give an example of data in the Information Model we need | |||
to select a data model language. In this example we have expressed | to select a data model language. In the following example we have | |||
the Data Model using JSON as this will be of direct interest to some | expressed the Data Model using JSON as this will be of direct | |||
Control and Report Protocols. The example is broken down into a | interest to some Control and Report Protocols. A YANG data model | |||
number of different steps that might adhere to the steps within a | implementation of the Information Model is provided in a separate | |||
Control and Report Protocol: | draft [I-D.schoenw-lmap-yang]. | |||
The example is broken down into a number of different steps that | ||||
might adhere to the steps within a Control and Report Protocol: | ||||
1. Pre-configuration. | 1. Pre-configuration. | |||
2. Configuration | 2. Configuration | |||
3. Capabilities | 3. Capabilities | |||
4. Instruction | 4. Instruction | |||
5. Report | 5. Report | |||
skipping to change at page 36, line 39 | skipping to change at page 37, line 39 | |||
"ma-report-task-rows": | "ma-report-task-rows": | |||
["2014-06-09T02:30:10+00:00", "", "0", | ["2014-06-09T02:30:10+00:00", "", "0", | |||
"20.13", "18.3", "24.1"] | "20.13", "18.3", "24.1"] | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
The Controller decides that there is a problem with the UDP L:atency | The Controller decides that there is a problem with the UDP L:atency | |||
test and issues a Suppression Instruction. Since the task is marked | test and issues a Suppression Instruction. Since the task is marked | |||
as suppressable by default, simply turning on suppression will stop | as suppressible by default, simply turning on suppression will stop | |||
the task being executed in future. | the task being executed in future. | |||
// Suppression | // Suppression | |||
{ | { | |||
"ma-instruction": { | "ma-instruction": { | |||
"ma-suppression": { | "ma-suppression": { | |||
"ma-suppression-enabled": "TRUE" | "ma-suppression-enabled": "TRUE" | |||
} | } | |||
} | } | |||
End of changes. 55 change blocks. | ||||
121 lines changed or deleted | 182 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |