Examples of LMAP Objects using IPPM Metrics and Protocols
draft-morton-lmap-examples-01

Abstract

In order to examine the completeness and coverage of the LMAP info and data models, we present examples expressing information from IP Performance Metric working group metrics and protocols, and the Performance Metrics Registry. The main update in the version provides a more realistic and useful example of the Cycle_ID in measurement instruction and reporting.

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 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 September 22, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Scope and Purpose
• 3. UDP Round Trip Latency
• 3.1. Measurement Task Capabilities
• 3.2. Instruction Object
• 3.3. Measurement Task
• 3.4. Report
• 3.5. Report Task
• 3.6. Schedule
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

The Large-scale Measurement of Broadband Performance (LMAP) working group has completed a Framework [RFC7594] and Use cases, and now proceeds with development of an information model [I-D.ietf-lmap-information-model] and data model.

The IETF IP Performance Metrics (IPPM) working group first created a framework for metric development in [RFC2330]. This framework has largely stood the test of time and enabled development of many fundamental metrics. It has been updated once in the area of metric composition [RFC5835], and again in several areas related to active stream measurement of modern networks with reactive propoerties [RFC7312]. The Working Group has developed an extensive set of Standards Track Metrics and Measurment Protocols. Among the work especially relevant to LMAP is the development of a Performance Metrics Registry [I-D.ietf-ippm-metric-registry], and a proposal for the initial regsitry contents [I-D.morton-ippm-initial-registry].

This memo is orgainzed into sections that present an example of LMAP Control and Reporting by populating the various information model objects for measurement Tasks and Reporting Tasks (and eventually Schedule, Event, Action, etc).

The first example is a UDP Round Trip Latency Metric.

2. Scope and Purpose

The purpose of this memo is to examine the features and capabilities of the LMAP information model [I-D.ietf-lmap-information-model] by populating the models with example data intended to enable measurement of IPPM metrics.

The scope is to create the examples for Active Metrics and their Methods of Measurement, as defined in the IPPM literature of Standards Track Metrics. Specifically, Metrics in the proposed initial contents for the Performance Metrics Registry [I-D.ietf-ippm-metric-registry] contined in [I-D.ietf-ippm-metric-registry] are the primary focus, along with existing standards track measurement protocols developed in IPPM [RFC4656] [RFC5357].

3. UDP Round Trip Latency

This draft presents information in a conceptual form. Safeguarding correct syntax is a collosal non-goal in the early drafts.

3.1. Measurement Task Capabilities

Example:
Measurement Capability [
   Measurement Protocol [
       Protocol Roles [ ]
   ]
   Registry URI  [
       Method Roles [ ]
   ]
]
so, an example would be

Measurement Capability [
    TWAMP [
       Control-Client; Session-Sender; Server; Session-Reflector;
       ]
    Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [
       Src; Dst;
    ... more URIs and Roles ...
       ]
]
for a fully-capable MA.

3.2. Instruction Object

3.3.1.  Definition of ma-instruction-obj
     object {
         ma-task-obj         ma-instruction-tasks<0..*>;
            name:UDP_RT_Metrics_001;
         ma-channel-obj      ma-report-channels<0..*>;
         ma-schedule-obj     ma-instruction-schedules<0..*>;
         ma-suppression-obj  ma-suppression;
     } ma-instruction-obj;

3.3. Measurement Task

3.9.1.  Definition of ma-task-obj
     object {
         string              ma-task-name;
           task-name: UDP_RT_Metrics_001;
         uri                 ma-task-registry-entries<1..*>;
           Prefix: Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson;
           Prefix: Act_IP_UDP_Round-trip_Delay_Mean_Poisson;
        [ma-option-obj       ma-task-options<0..*>];
           option-role: Src;  option-meas_point: mp100;
           option-measurement_protocol: TWAMP;
           option-meas_protocol_roles: Control-Client; Session-Sender;
           option-Src_IP: xxx.xxx.xxx;
           option-Dst_IP: xxx.xxx.xxx;
           option-T0:  0;  option-lambda: 1 second;
           option-Tf:  15 min; option-truncate: 30 seconds;
        [boolean             ma-task-suppress-by-default;]
           suppress: true;
        [string              ma-task-cycle-id;]
           cycle-id: Access_2016-03-21-0930;
     } ma-task-obj;

Prefix = urn:ietf:params:performance:metric

3.4. Report

3.6.1.  Definition of ma-report-obj

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

3.5. Report Task

3.6.2.  Definition of ma-report-task-obj
     object {
         string              ma-report-task-name;
            task-name: UDP_RT_Metrics_REPORT_001;
        [uri                 ma-report-task-registry-entries<1..*>;]
           Prefix: Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson;
           Prefix: Act_IP_UDP_Round-trip_Delay_Mean_Poisson;
        [ma-option-obj       ma-report-task-options<0..*>];
           option-role: Src;  option-meas_point: mp100;
           option-measurement_protocol: TWAMP;
           option-meas_protocol_roles: Control-Client; Session-Sender;
           option-Src_IP: xxx.xxx.xxx;
           option-Dst_IP: xxx.xxx.xxx;
           option-T0:  0;
           option-Tf:  15 minutes;
        [ma-option-obj       ma-report-task-action-options<0..*>];
        [string              ma-report-task-cycle-id;]
           cycle-id: Access_2016-03-21-0930;
        [string              ma-report-task-column-labels<0..*>;]
           label: Mean; label: 95%-tile; 
        [ma-report-row-obj   ma-report-task-rows<0..*>;]
           row(0): 0.25; 0.34;
     } ma-report-task-obj; 

3.6. Schedule

TBD

4. Security Considerations

The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357].

When considering privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques which are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [RFC7594], which covers active and passive techniques.

5. IANA Considerations

This memo makes no requests of IANA.

6. Acknowledgements

The author thanks LMAP Participants for their comments.

7. References

7.1. Normative References

7.2. Informative References

Author's Address