<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<rfc category="std" docName="draft-eardley-lmap-terminology-02"
     ipr="trust200902" obsoletes="" updates="">
  <front>
    <title abbrev="LMAP Terminology">Terminology for Large MeAsurement
    Platforms (LMAP)</title>

    <author fullname="Philip Eardley" initials="P." surname="Eardley">
      <organization abbrev="BT">British Telecom</organization>

      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>

          <city>Ipswich</city>

          <country>ENGLAND</country>
        </postal>

        <email>philip.eardley@bt.com</email>
      </address>
    </author>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization abbrev="AT&amp;T Labs">AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown, NJ</city>

          <country>USA</country>
        </postal>

        <email>acmorton@att.com</email>
      </address>
    </author>

    <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
      <organization abbrev="UC3M">Universidad Carlos III de
      Madrid</organization>

      <address>
        <postal>
          <street>Av. Universidad 30</street>

          <city>Leganes</city>

          <region>Madrid</region>

          <code>28911</code>

          <country>SPAIN</country>
        </postal>

        <phone>34 91 6249500</phone>

        <email>marcelo@it.uc3m.es</email>

        <uri>http://www.it.uc3m.es</uri>
      </address>
    </author>

    <author fullname="Trevor Burbridge" initials="T." surname="Burbridge">
      <organization abbrev="BT">British Telecom</organization>

      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>

          <city>Ipswich</city>

          <country>ENGLAND</country>
        </postal>

        <email>trevor.burbridge@bt.com</email>
      </address>
    </author>

    <date day="11" month="July" year="2013"/>

    <abstract>
      <t>This documents defines terminology for Large Scale Measurement
      Platforms.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document, in Section 3, defines terminology for LMAP. Since
      &lsquo;raw&rsquo; terminology is reader-unfriendly, Section 2 provides
      an initial idea of the terminology by explaining how LMAP works whilst
      using the terms. Section 4 provides some commentary on the terminology,
      including a comparison with that in <xref target="RFC2330"/>.</t>

      <t>Please note that defined terms are capitalized.</t>
    </section>

    <section title="Summary">
      <t>A Measurement Task is an act that yields a single Measurement Result.
      An Active Measurement Task involves (for example) a Measurement Agent
      injecting test packet(s) into the network destined for a Measurement
      Peer and measuring some performance or reliability parameter associated
      with the transfer. The generic version of the Measurement Task is the
      Measurement Method; in other words the Measurement Task is the
      instantiation of the Measurement Method at a specific time and
      place.</t>

      <t>For example, a Measurement Method might be the injection of a UDP
      packet by a Measurement Agent destined for a Measurement Peer, which
      immediately reflects the UDP packet back to the Measurement Agent, which
      measures the round trip latency. The associated Measurement Task might
      be: the injection of a UDP packet by the Measurement Agent at 192.0.2.0
      destined for the Measurement Peer at 198.51.100.0 at UTC 13:01 and 58.6
      seconds on 2013-06-15, with the Measurement Peer immediately reflecting
      the UDP packet back to the source, which measures the associated round
      trip latency (using a second timestamp associated with arrival).</t>

      <t>A Metric is a parameter of interest that is related to the
      performance and reliability of the Internet. For example, &ldquo;UDP
      latency&rdquo;. Typically the value of a Metric is assessed as simply
      the average of several Measurement Results. However a Derived Metric
      consists of some combination of various Measurement Results. For
      example, a path delay might be assessed by adding several component
      delays, or the bulk transport capacity might be assessed by combining
      several different parameters as suggested in <xref
      target="I-D.mathis-ippm-model-based-metrics"/>.</t>

      <t>How and when to perform the Measurement Task and report the
      Measurement Result is defined by the Instruction, which the Controller
      sends to the Measurement Agent. Whilst the Instruction may define a
      single Measurement Task, more typically it defines a series of
      Measurement Tasks, all based on the same Measurement Method and carried
      out at regular times according to a Measurement Schedule. The
      Measurement Result of the former is likely to be reported immediately,
      whilst Measurement Results of the latter will be sent at regular time
      intervals, as defined by the Report Schedule. The Instruction consists
      of the following items (which effectively define a series of Measurement
      Tasks):<list style="numbers">
          <t>The Measurement Method: typically this is defined by a reference
          in a well-known registry (for example, &lsquo;how to measure UDP
          latency&rsquo;)</t>

          <t>The configuration of parameters left open by the Measurement
          Method (for example, the addresses of the Measurement Agent and
          Measurement Peer)</t>

          <t>The Measurement Schedule (for example, start at 0400 UTC, repeat
          every 500 ms, end at 0403 UTC)</t>

          <t>Any environmental constraints (for example, do not perform the
          Measurement Task if there is cross-traffic)</t>

          <t>How and when to send a report:<list style="letters">
              <t>The definition of the Report. Typically the Report includes
              every single Measurement Result (since the last Report), but it
              may instead be a statistic (such as their average). Typically
              the Report also includes other relevant information, for example
              an &lsquo;echo&rsquo; of the Measurement Method, configuration
              parameters and schedule.</t>

              <t>The configuration of parameters associated with the Report
              (for example, the address of the Collector to which the Report
              is sent)</t>

              <t>The Report Schedule (for example, send once a day at 01:00
              hours)</t>
            </list></t>
        </list></t>

      <t>The Control Protocol and Report Protocol define the delivery of the
      Instruction and the Report (respectively); they consist of a Data Model
      (the semantics and structure of the information, in a particular data
      modeling language such as a JSON schema language or YANG) and a
      transport protocol (such as HTTP or NETCONF).</t>
    </section>

    <section title="LMAP Terminology">
      <t>Active Measurement Method (Task): A type of Measurement Method (Task)
      that involves a Measurement Agent and a Measurement Peer (or possibly
      Peers), where either the Measurement Agent or the Measurement Peer
      injects test packet(s) into the network destined for the other, and
      which involves one of them measuring some performance or reliability
      parameter associated with the transfer of the packet(s).</t>

      <t>Bootstrap Protocol: A protocol that initialises a Measurement Agent
      with the information necessary to talk to a Controller.</t>

      <t>Collector: A function that receives a Report from a Measurement
      Agent. Colloquially, a Collector is a physical device that performs this
      function.</t>

      <t>Controller: A function that provides a Measurement Agent with
      Instruction(s). Colloquially, a Controller is a physical device that
      performs this function.</t>

      <t>Control Protocol: The protocol delivering Instruction(s) from a
      Controller to a Measurement Agent.</t>

      <t>Data Model: The implementation of an Information Model in a
      particular data modelling language.</t>

      <t>Derived Metric: A Metric that is a combination of other Metrics,
      and/or a combination of the same Metric measured over different parts of
      the network, or at different times.</t>

      <t>Information Model: The protocol-neutral definition of the semantics
      of either the Instruction or the Report.</t>

      <t>Instruction: The description of Measurement Tasks to perform and the
      details of the Report to send. The Instruction is sent by a Controller
      to a Measurement Agent.</t>

      <t>Measurement Agent (MA): The function that receives Instructions from
      a Controller, performs Measurement Tasks (perhaps in concert with a
      Measurement Peer) and reports Measurement Results to a Collector.
      Colloquially, a Measurement Agent is a physical device that performs
      this function.</t>

      <t>Measurement Method: The process for assessing the value of a Metric;
      the process of measuring some performance or reliability parameter; the
      generalisation of a Measurement Task.</t>

      <t>Measurement Peer: The function that receives control messages and
      test packets from a Measurement Agent and may reply to the Measurement
      Agent as defined by the Measurement Method.</t>

      <t>Measurement Result: The output of a single Measurement Task (the
      value obtained for the parameter of interest, or Metric).</t>

      <t>Measurement Schedule: the schedule for performing a series of
      Measurement Tasks.</t>

      <t>Measurement Task: The act that yields a single Measurement Result;
      the act consisting of the (single) operation of the Measurement Method
      at a particular time and with all its parameters set to specific
      values.</t>

      <t>Metric: The quantity related to the performance and reliability of
      the Internet that we'd like to know the value of, and that is carefully
      specified.</t>

      <t>Passive Measurement Method (Task): A Measurement Method (Task) in
      which a Measurement Agent observes existing traffic at a specific
      measurement point, but does not inject test packet(s).</t>

      <t>Report: The Measurement Results and other associated information (as
      defined by the Instruction); a specific instance of the Data Model. The
      Report is sent by a Measurement Agent to a Collector.</t>

      <t>Report Protocol: The protocol delivering Report(s) from a Measurement
      Agent to a Collector.</t>

      <t>Report Schedule: the schedule for sending a series of Reports to a
      Collector.</t>

      <t/>

      <section title="Other potentially useful terminology">
        <t>The following terms have also been suggested and will be included
        above, assuming they prove useful during the early stages of the LMAP
        work.</t>

        <t>Cycle-ID: A tag that is sent by the Controller in an Instruction
        and echoed by the MA in its Report; Measurement Results with the same
        Cycle-ID are expected to be comparable.</t>

        <t>Environmental Constraint: A parameter that is measured as part of
        the Measurement Task, its value determining whether the rest of the
        Measurement Task proceeds.</t>

        <t>Group-ID: An identifier of a group of MAs.</t>

        <t>Measurement Parameter: A parameter whose value is left open by the
        Measurement Method.</t>

        <t>Measurement Suppression: a type of Instruction that stops
        (suppresses) Measurement Tasks.</t>

        <t>Report Channel: a specific Report Schedule and Collector</t>
      </section>
    </section>

    <section title="Commentary and notes">
      <t>To avoid confusion the word &lsquo;Measurement&rsquo; is only used as
      an adjective.</t>

      <t>It is worth explaining how the terms defined here compare with those
      in <xref target="RFC2330"/>, &ldquo;Framework for IP Performance
      Metrics&rdquo;. The definition of Metric is taken from RFC2330. The
      definition of Measurement Method is (we believe) equivalent in
      RFC2330&rsquo;s terms to a measurement methodology for a singleton
      metric. A set of Measurement Tasks defined by a Measurement Schedule
      relates to RFC2330&rsquo;s concept of a sample metric.</t>

      <t>If a Measurement Method is used multiple times under identical or
      similar conditions, it should result in a consistent value for the
      Metric.</t>

      <t>A Measurement Method may be a more specific version of another
      Measurement Method. For example, <xref
      target="I-D.bagnulo-ippm-new-registry-independent"/> defines UDP latency
      as a round trip delay <xref target="RFC2681"/> with the packet type set
      to UDP.</t>

      <t>A registry, as proposed in <xref
      target="I-D.bagnulo-ippm-new-registry-independent"/>, would be a
      registry of Measurement Methods and their associated Metrics. A Passive
      Measurement Method (Task) involves only a Measurement Agent; for
      example, it measures the mix of applications. An Active Measurement
      Method (Task) also involves a Measurement Peer. It is possible that some
      Active Measurement Methods (Tasks) involve additional Measurement
      Agent(s) or Measurement Peer(s); for example, one way to measure
      'latency under load' may be to send test traffic between a Measurement
      Agent and Measurement Peer whilst a second Measurement Peer generates
      the load (cross-traffic).</t>

      <t>The consensus is that the LMAP working group should assume that a
      Measurement Agent receives Instruction from only a single Controller at
      any point in time (however it may Report to more than one
      Collector).</t>

      <t>By definition a Measurement Peer does not interact with a Controller
      or Collector. A Measurement Peer will typically respond to the test
      packet(s) from the Measurement Agent. For example, it may echo a UDP
      packet, or measure the amount of loss of the test packets and then send
      the Measurement Results to the Measurement Agent.</t>

      <t>The Measurement Agent is implemented either in specialised hardware
      or as code on general purpose devices like a PC, tablet or smartphone.
      Note that a Measurement Peer may not have specific LMAP or IPPM
      functionality. For example, to assess DNS response time a Measurement
      Agent sends DNS requests to a standard DNS server.</t>

      <t>A Controller can send an Instruction for immediate action, containing
      a one-off Measurement Task. This is in addition to the more typical
      scenario of a series of Measurement Tasks carried out on a regular
      schedule, with the Measurement Results reported periodically.</t>

      <t>It may be sensible for an Instruction to be able to refer to more
      than one Measurement Method. This is for further study.</t>

      <t>[RFC3444] discusses the difference between an Information Model and
      Data Model. An Informational Model &ldquo;model[s] managed objects at a
      conceptual level, independent of any specific implementations or
      protocols used to transport the data ... it defines relationships
      between managed objects&rdquo;. A Data Model is &ldquo;defined at a
      lower level of abstraction and includes many details ... and include[s]
      protocol-specific constructs.&rdquo; Multiple Data Models can be derived
      from a single Information Model, since a conceptual/abstract model can
      be implemented in different ways. An Informational Model is for
      designers and operators, whilst a Data Model is for implementors.</t>

      <t>An Information Model can be divided into different parts and
      sub-parts, to allow the values in each part and sub-part to be updated
      independently. For example, one part could be contain the Instruction
      Information and another the Reporting Information. The Instruction could
      contain sub-parts for configuring Measurement Tasks and for setting
      Measurement Schedules (which may be updated at different times and
      frequencies). This is discussed in <xref
      target="information-model"/></t>

      <t>The Control Protocol defines the Data Model and so effectively
      defines the Instruction. The Instruction includes: the Measurement
      Method; values for the parameters that the Measurement Method leaves
      open (configuration); when to perform the Measurement Tasks (the
      Measurement Schedule); any environmental conditions (such as
      &ldquo;don't perform the Measurement Task if there is end user traffic
      present&rdquo;); the Report Protocol, which includes its Data Model;
      when to send a Report (the Report Schedule); where to send the Report
      (the address of the Collector) and values for any other parameters that
      the Report Protocol leaves open (configuration). This is for
      discussion.</t>

      <t>Typically the Report includes every single Measurement Result, but it
      may instead be a statistic (such as their average). The latter may be
      useful when the bandwidth between the Measurement Agent and Collector is
      severely constrained and/or the full set of Measurement Results provides
      little extra information.</t>

      <t>The Report includes: the Measurement Results (or statistic based on
      them); the details of the Measurement Tasks (essentially a copy of much
      of the Instruction, for example the Measurement Method, the
      configuration parameters and the time at which each Measurement Result
      was obtained); and other relevant information known by the Measurement
      Agent (such as the line&rsquo;s speed, the version of the Measurement
      Agent, and the amount of cross-traffic during the measurement). Again
      this is very much for discussion.</t>

      <t>A proposal for a Control Protocol based on HTTP is currently under
      development. There are already internet drafts describing a Control
      Protocol based on NETCONF and a Report Protocol based on IPFIX.</t>

      <t>The job of a Bootstrap Protocol is to provide an automated way to
      associate a Measurement Agent to its Controller, including
      authentication credentials. Similarly, there should be a way to pull the
      plug on rogue Measurement Agents. The current consensus on the LMAP
      mailing list is that the working group should define the bootstrap
      process but not a protocol. The reason is that it could be done in many
      different ways, depending on the device and the measurement system, for
      instance: loaded at manufacture, updated locally via USB port, or
      orchestrated via a protocol (which may be defined by organisations other
      than the IETF, for example, the Broadband Forum).</t>

      <t>The purpose of the Cycle-ID is to allow the data analysis tools to
      identify easily Measurement Results that are expected to be comparable,
      typically because the associated Measurement Tasks all operate the same
      Measurement Method with the same values for its parameters. This set of
      Measurement Tasks could be termed the Measurement Cycle.</t>

      <t>An example of an Environmental Constraint is "no end-user traffic".
      The Measurement Agent could measure the amount of end-user traffic over
      the previous 10 seconds; if there is none then it uploads a file to the
      Measurement Peer, whilst if the end-user is active then it defers the
      upload.</t>

      <t>The Report Channel contains the details of one collector (including
      location and security information such as the certificate), and the
      timing for the report (when to report the results). Each Report Channel
      is also given a local short name by which it can be referenced from a
      Measurement Schedule.</t>

      <t>The Group-ID identifies a group of interest to which a MA belongs.
      For example the group could represent an ISP, broadband product,
      technology, market classification, geographic region, or a combination
      of multiple such characteristics. A MA can remain anonymous by including
      its Group-ID (and not its own identifier) in the Reports it sends.</t>

      <t>Measurement Suppression is used to over-ride the Measurement
      Schedule. A Controller uses Measurement Suppresion to stop a MA making
      measurements for a defined or indefinite period. For discussion of
      Measurement Suppression, see <xref target="information-model"/></t>

      <t/>
    </section>

    <section title="Security considerations">
      <t>There are no security considerations in this memo.</t>
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA considerations in this memo.</t>
    </section>

    <section title="Acknowledgments">
      <t>We thank participants on the LMAP mailing list for their input,
      especially Juergen Schoenwaelder for his detailed review.</t>
    </section>

    <section title="History">
      <section title="from -00 to -01:">
        <t>'Complete Measurement Agent' replaced by 'Measurement Agent', and
        'Remote Measurement Agent' replaced by 'Measurement Peer'.</t>

        <t>Bootstrap protocol added</t>

        <t>Section 3.1 added, with terms Cycle-ID, Measurement Parameter and
        Environmental Constraints</t>

        <t>Adjustments to terms for: Active Measurement Method (Task), Control
        Protocol, Information Model, Instruction, Report Protocol.</t>
      </section>

      <section title="from -01 to -02">
        <t>Added to Section 3.1 the terms Group-ID, Measurement Suppression
        and Report Channel, as these are used in <xref
        target="information-model"/></t>

        <t>Other minor clarifications.</t>

        <t/>
      </section>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include='reference.I-D.bagnulo-ippm-new-registry-independent'?>

      <?rfc include='reference.RFC.2330'?>

      <?rfc include='reference.I-D.mathis-ippm-model-based-metrics'?>

      <?rfc include='reference.RFC.2681'?>

      <reference anchor="information-model"
                 target="http://tools.ietf.org/html/draft-burbridge-lmap-information-model">
        <front>
          <title>Information Model for Large-Scale Measurement Platforms
          (LMAP)</title>

          <author fullname="Trevor Burbridge" initials="T."
                  surname="Burbridge">
            <organization/>
          </author>

          <author fullname="Philip Eardley" initials="P." surname="Eardley">
            <organization/>
          </author>

          <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
            <organization/>
          </author>

          <author fullname="Juergen Schoenwaelder" initials="J."
                  surname="Schoenwaelder">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
