<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3432 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3432.xml"> nbsp    "&#160;">
  <!ENTITY RFC4086 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml"> zwsp   "&#8203;">
  <!ENTITY RFC4656 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4656.xml"> nbhy   "&#8209;">
  <!ENTITY RFC5357 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC6020 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6038 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6038.xml">
<!ENTITY RFC6241 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC7426 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY IPPMREG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ippm-metric-registry-02.xml">
<!ENTITY RESTCONF SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netconf-restconf-04.xml">
<!ENTITY UNIFY SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-unify-nfvrg-challenges-00.xml">
<!ENTITY SP-DEVOPS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-unify-nfvrg-devops-01.xml"> wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     docName="draft-ietf-ippm-twamp-yang-13" ipr="trust200902">
  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <?rfc compact="yes" ?>

  <?rfc subcompact="no" ?>

  <?rfc comments="yes"?>

  <?rfc inline="yes" ?> number="8913" ipr="trust200902"
     obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.44.0 -->
  <front>
    <title abbrev="TWAMP YANG Data Model">Two-Way Active Measurement Protocol
    (TWAMP) YANG Data Model</title>
    <seriesInfo name="RFC" value="8913"/>
    <author fullname="Ruth Civil" initials="R." surname="Civil">
      <organization>Ciena Corporation</organization>
      <address>
        <postal>
          <street>307 Legget Drive</street>
          <city>Kanata</city>
          <region>ON</region>
          <code>K2K 3C8</code>
          <country>Canada</country>
        </postal>

        <email>gcivil@ciena.com</email>
        <email>ruthcivil@gmail.com</email>
        <uri>www.ciena.com</uri>
      </address>
    </author>
    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>
      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>
        <email>acmorton@att.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Reshad Rahman" initials="R." surname="Rahman">
      <organization>Cisco Systems</organization>
      <organization></organization>
      <address>
        <postal>
          <street>2000 Innovation Drive</street>

          <city>Kanata</city>

          <region>ON</region>

          <code>K2K 3E8</code>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>Canada</country>
        </postal>

        <email>rrahman@cisco.com</email>
        <email>reshad@yahoo.com</email>
      </address>
    </author>
    <author fullname="Mahesh Jethanandani" initials="M." surname="Jethanandani">
      <organization>Xoriant Corporation</organization>
      <address>
        <postal>
          <street>1248 Reamswood Drive</street> Reamwood Avenue</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>mjethanandani@gmail.com</email>
      </address>
    </author>
    <author fullname="Kostas Pentikousis" initials="K." role="editor"
            surname="Pentikousis">
      <organization>Travelping</organization> surname="Pentikousis" role="editor">
      <organization>Detecon</organization>
      <address>
        <postal>
          <street>Siemensdamm 50</street>

          <code>13629</code>
          <street> Winterfeldtstrasse 21</street>
          <code>10781</code>
          <city>Berlin</city>
          <country>Germany</country>
        </postal>

        <email>k.pentikousis@travelping.com</email>
        <email>kostas.pentikousis@detecon.com</email>
      </address>
    </author>
    <date day="2" month="July" year="2018"/>

    <area>Transport</area>

    <workgroup>IPPM WG</workgroup> month="November" year="2021"/>

    <abstract>
      <t>This document specifies a data model for client and server
      implementations of the Two-Way Active Measurement Protocol (TWAMP). The This
      document defines the TWAMP data model through Unified Modeling Language
      (UML) class diagrams and formally specifies it using a NDMA-compliant the YANG model.</t> data
      modeling language (RFC 7950).  The data model is compliant with the Network Management Datastore Architecture
      (NMDA).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The <xref target="RFC5357">Two-Way target="RFC5357" format="default">Two-Way Active Measurement Protocol
      (TWAMP) </xref> is used to measure network performance parameters such
      as latency, bandwidth, and packet loss by sending probe packets and
      measuring their experience in the network. To date, TWAMP
      implementations do not come with a standard management framework, and,
      as such, implementers have no choice except to provide a proprietary
      mechanism. This document addresses this gap by defining the model using
      <xref target="UML">UML</xref>
      Unified Modeling Language (UML) class diagrams, diagrams <xref target="UML"
      format="default"></xref> and formally specifying a
      <xref target="RFC8342">NMDA-complaint</xref> TWAMP data model
      that is compliant with the Network Management Datastore Architecture
      (NMDA) <xref target="RFC8342" format="default"/>, using
      <xref target="RFC7950">YANG target="RFC7950" format="default">YANG 1.1 </xref>.</t>
      <section anchor="motivation" title="Motivation"> numbered="true" toc="default">
        <name>Motivation</name>
        <t>In current TWAMP deployments deployments, the lack of a standardized data model
        limits the flexibility to dynamically instantiate TWAMP-based
        measurements across equipment from different vendors. In large,
        virtualized, and dynamically instantiated infrastructures where
        network functions are placed according to orchestration algorithms,
        proprietary mechanisms for managing TWAMP measurements pose severe
        limitations with respect to programmability.</t>
        <t>Two major trends call for standardizing TWAMP management aspects.
        First, it is expected that in the coming years large-scale and
        multi-vendor TWAMP deployments will become the norm. From an
        operations perspective, using several vendor-specific TWAMP
        configuration mechanisms when one standard mechanism could provide an
        alternative is expensive and inefficient. Second, the increasingly
        software-defined and virtualized nature of network infrastructures,
        based on dynamic service chains <xref target="NSC"/> target="NSC" format="default"/> and programmable
        control and management planes <xref target="RFC7426">Software-Defined
        Networking (SDN): Layers and Architecture Terminology </xref> target="RFC7426" format="default"/>, requires
        a well-defined data model for TWAMP implementations. This document
        defines such a TWAMP data model and specifies it formally using the
        <xref target="RFC7950">YANG target="RFC7950" format="default">YANG 1.1 </xref> data modeling language.</t>

        <t>Note to RFC Editor:</t>

        <t>Please replace the date 2018-07-02 in Section 5.2 of the draft with
        the date of publication of this draft as a RFC. Also, replace
        reference to RFC XXXX, and draft-ietf-ippm-port-twamp-test with the
        RFC numbers assigned to the drafts.</t> language</xref>.</t>

      </section>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP&nbsp;14
        <xref target="RFC2119">BCP 14</xref> target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
      <section title="Document Organization"> numbered="true" toc="default">
        <name>Document Organization</name>
        <t>The rest of this document is organized as follows. <xref
        target="scope"/> target="scope" format="default"/> presents the scope and applicability of this
        document. <xref target="structure"/> target="structure" format="default"/> provides a high-level overview of
        the TWAMP data model. <xref target="parameters"/> target="parameters" format="default"/> details the
        configuration parameters of the data model model, and <xref target="module"/> target="module" format="default"/>
        specifies in YANG the TWAMP data model. <xref target="examples"/> target="examples" format="default"/>
        lists illustrative examples which that conform to the YANG data model
        specified in this document. <xref target="AuthExample"/> target="AuthExample" format="default"/> elaborates
        these examples further.</t>
      </section>
    </section>
    <section anchor="scope" title="Scope, numbered="true" toc="default">
      <name>Scope, Model, and Applicability"> Applicability</name>
      <t>The purpose of this document is the specification of a
      vendor-independent data model for TWAMP implementations.</t>
      <t><xref target="fig:scope"/> target="fig_scope" format="default"/> illustrates a redrawn version of the TWAMP
      logical model found in Section 1.2 of <xref target="RFC5357">TWAMP
      </xref>. target="RFC5357" sectionFormat="of"
      section="1.2">TWAMP</xref>. The figure is annotated with pointers to the
      <xref
      target="UML">UML</xref> diagrams target="UML" format="default">UML diagrams</xref> provided in this document and
      associated with the data model of the four logical entities in a TWAMP
      deployment, namely the TWAMP Control-Client, Server, Session-Sender Session-Sender, and
      Session-Reflector. A <xref target="UML">UML</xref> UML Notation Guide is available in Section 5 Section&nbsp;5
      of the said document.</t> UML <xref target="UML"/>.</t>
      <t>As per <xref target="RFC5357">TWAMP target="RFC5357" format="default">TWAMP </xref>, unlabeled links in <xref
      target="fig:scope"/> target="fig_scope" format="default"/> are left unspecified and may be proprietary
      protocols.</t>
      <figure anchor="fig:scope" title="Annotated anchor="fig_scope">
        <name>Annotated TWAMP logical model">
        <artwork><![CDATA[
    [Fig. 3]                                 [Fig. 4] Logical Model</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
         (Figure 3)                              (Figure 4)
     +----------------+                          +--------+
     | Control-Client |  <-- TWAMP-Control -->   | Server |
     +----------------+                          +--------+
             ^                                        ^
             |                                        |
             V                                        V
     +----------------+                     +-------------------+
     | Session-Sender |  <-- TWAMP-Test --> | Session-Reflector |
     +----------------+                     +-------------------+
    [Fig. 5]                                 [Fig. 6]
]]></artwork>
         (Figure 5)                               (Figure 6)]]></artwork>
      </figure>

      <t>As per <xref target="RFC5357">TWAMP target="RFC5357" format="default">TWAMP </xref>, a TWAMP implementation
      may follow a simplified logical model, in which the same node acts both as both
      Control-Client and Session-Sender, while another node acts at the
      same time as both TWAMP Server and Session-Reflector. <xref
      target="fig:scope2"/> target="fig_scope2" format="default"/> illustrates this simplified logical model and
      indicates the interaction between the TWAMP configuration client and
      server using, for instance, <xref target="RFC6241">NETCONF target="RFC6241" format="default">NETCONF </xref> or
      <xref target="RFC8040">RESTCONF target="RFC8040" format="default">RESTCONF </xref>.</t>
      <figure anchor="fig:scope2" title="Simplified anchor="fig_scope2">
        <name>Simplified TWAMP model Model and protocols">
        <artwork><![CDATA[ Protocols</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  o-------------------o                       o-------------------o
  |   Config client   |                       |   Config client   |
  o-------------------o                       o-------------------o
           ||                                          ||
   NETCONF || RESTCONF                         NETCONF || RESTCONF
           ||                                          ||
  o-------------------o                       o-------------------o
  |   Config server   |                       |   Config server   |
  |    [Fig. 3, 5] (Figures 3 and 5) |                       |    [Fig. 4, 6] (Figures 4 and 6) |
  +-------------------+                       +-------------------+
  |   Control-Client  | <-- TWAMP-Control --> |      Server       |
  |                   |                       |                   |
  |   Session-Sender  |  <-- TWAMP-Test -->   | Session-Reflector |
  +-------------------+                       +-------------------+
]]></artwork>                       +-------------------+]]></artwork>
      </figure>
      <t>The data model defined in this document is orthogonal to the specific
      protocol used between the Config client and Config server to communicate
      the TWAMP configuration parameters.</t>
      <t>Operational actions such as how TWAMP-Test sessions are started and
      stopped, how performance measurement results are retrieved, or how
      stored results are cleared, and so on, are not addressed by the
      configuration model defined in this document. As noted above, such
      operational actions are not part of the TWAMP specification <xref
      target="RFC5357">TWAMP </xref> target="RFC5357" format="default"></xref> and hence are out of scope of for this
      document. See also <xref target="OperationalCommands"/>. target="OperationalCommands"
      format="default"/>. In addition,
      for operational state, current work the information provided in <xref
      target="I-D.ietf-ippm-metric-registry">Registry for the Performance
      Metrics</xref>, Metrics Registry <xref target="RFC8911"/> and
      <xref target="PERF-METRICS"/> can be used to develop an independent model for the
      performance metrics
      Performance Metrics that need to be captured and retrieved.</t>
    </section>
    <section anchor="structure" title="Data numbered="true" toc="default">
      <name>Data Model Overview"> Overview</name>
      <t>The TWAMP data model includes four categories of configuration
      items.</t>
      <t>First, global configuration items relate to parameters that are set
      on a per device per-device level. For example, the administrative status of the
      device with respect to whether it allows TWAMP sessions and, if so, in
      what capacity (e.g. (e.g., Control-Client, Server Server, or both), both) is a typical
      instance of a global configuration item.</t>
      <t>A second category includes attributes that can be configured on a per
      TWAMP-Control connection
      per&nbhy;TWAMP-Control-connection basis, such as the Server IP address.</t>
      <t>A third category includes attributes related to per TWAMP-Test
      session attributes,
      per-TWAMP-Test-session attributes -- for instance instance, setting different values in the
      Differentiated Services Code Point (DSCP) field.</t>
      <t>Finally, the data model includes attributes that relate to the
      operational state of the TWAMP implementation.</t>
      <t>As the TWAMP data model is described in the remaining sections of
      this document, readers should keep in mind the functional entity
      grouping illustrated in <xref target="fig:scope"/>.</t> target="fig_scope" format="default"/>.</t>
      <section anchor="twamp-client" title="Control-Client"> numbered="true" toc="default">
        <name>Control-Client</name>
        <t>A TWAMP Control-Client has an administrative status field set at
        the device level that indicates whether the node is enabled to
        function as such.</t>
        <t>Each TWAMP Control-Client is associated with zero or more
        TWAMP-Control
        TWAMP&nbhy;Control connections. The main configuration parameters of each
        control connection are: <list style="symbols">
            <t>A </t>
        <ul spacing="normal">
          <li>A name which that can be used to uniquely identify at the
            Control-Client a particular control connection. This name is
            necessary for programmability reasons because at the time of
            creation of a TWAMP-Control connection not all IP and TCP port
            number information needed to uniquely identify the connection is
            available.</t>

            <t>The
            available.</li>
          <li>The IP address of the interface the Control-Client will use for
            connections.</t>

            <t>The
            connections.</li>
          <li>The IP address of the remote TWAMP Server.</t>

            <t>Authentication Server.</li>
          <li>Authentication and encryption attributes such as KeyID, Token Token,
            and the Client Control-Client Initialization Vector (Client-IV); see also
            Section
            3.1 in <xref target="RFC4656">OWAMP </xref> target="RFC4656" sectionFormat="bare"
            section="3.1"/> of <xref target="RFC4656" format="default">"A One-way
          Active Measurement Protocol (OWAMP)"</xref> and <xref
            target="RFC4086">Randomness target="RFC4086" format="default">"Randomness Requirements for Security </xref>.</t>
          </list></t> Security"</xref>.</li>
        </ul>
        <t>Each TWAMP-Control connection, in turn, is associated with zero or
        more TWAMP-Test sessions. For each test session, the following
        configuration items should be noted: <list style="symbols">
            <t>The </t>
        <ul spacing="normal">
          <li>The test session name name, which uniquely identifies a particular test
            session at the Control-Client and Session-Sender. Similar to the
            control connections mentioned above, this unique test session name is needed
            because at the time of creation of a TWAMP-Test session, for
            example, the source UDP port number is not known to uniquely
            identify the test session.</t>

            <t>The session.</li>
          <li>The IP address and UDP port number of the Session-Sender on the
            path under test by TWAMP.</t>

            <t>The TWAMP.</li>
          <li>The IP address and UDP port number of the Session-Reflector on
            said path.</t>

            <t>Information path.</li>
          <li>Information pertaining to the test packet stream, such as the
            test starting time, time; which performance metric Performance Metric is to be used, as
            defined in <xref target="I-D.ietf-ippm-metric-registry">Registry target="RFC8911" format="default">"Registry
            for Performance Metrics </xref>, Metrics"</xref>; or whether the test should be
            repeated.</t>
          </list></t>
            repeated.</li>
        </ul>
      </section>
      <section anchor="twamp-server" title="Server"> numbered="true" toc="default">
        <name>Server</name>
        <t>Each TWAMP Server has an administrative status field set at the
        device level to indicate whether the node is enabled to function as a
        TWAMP Server.</t>
        <t>Each Server is associated with zero or more TWAMP-Control
        connections. Each control connection is uniquely identified by the
        4-tuple {Control-Client IP address, Control-Client TCP port number,
        Server IP address, Server TCP port}. Control &nbsp;Control connection configuration
        items on a TWAMP Server are read-only.</t>
      </section>
      <section anchor="twampSender" title="Session-Sender"> numbered="true" toc="default">
        <name>Session-Sender</name>
        <t>A TWAMP Session-Sender has an administrative status field set at
        the device level that indicates whether the node is enabled to
        function as such.</t>
        <t>There is one Session-Sender instance for each TWAMP-Test session
        that is initiated from the sending device. Primary configuration
        fields include: <list style="symbols">
            <t>The </t>
        <ul spacing="normal">
          <li>The test session name MUST name, which <bcp14>MUST</bcp14> be identical to the corresponding
            test session name on the TWAMP Control-Client (<xref
            target="twamp-client"/>).</t>

            <t>The target="twamp-client" format="default"/>).</li>
          <li>The control connection name, which which, along with the test session
            name
            name, uniquely identify identifies the TWAMP Session-Sender instance.</t>

            <t>Information instance.</li>
          <li>Information pertaining to the test packet stream, such as, as the
            number of test packets and the packet distribution to be employed;
            see also <xref target="RFC3432">Network target="RFC3432" format="default">"Network performance measurement
            with periodic streams </xref>.</t>
          </list></t> streams"</xref>.</li>
        </ul>
      </section>
      <section anchor="twampReflector" title="Session-Reflector"> numbered="true" toc="default">
        <name>Session-Reflector</name>
        <t>Each TWAMP Session-Reflector has an administrative status field set
        at the device level to indicate whether the node is enabled to
        function as such.</t>
        <t>Each Session-Reflector is associated with zero or more TWAMP-Test
        sessions. For each test session, the REFWAIT timeout parameter, which
        determines whether to discontinue the session if no packets have been
        received (<xref target="RFC5357">TWAMP </xref>, Section 4.2), target="RFC5357" sectionFormat="comma" section="4.2">TWAMP</xref>), can be
        configured.</t>
        <t>Read-only access to other data model parameters, such as the Sender
        IP address, is foreseen. Each test session can be uniquely identified
        by the 4-tuple mentioned in <xref target="twamp-server"/>.</t> target="twamp-server" format="default"/>.</t>
      </section>
    </section>
    <section anchor="parameters" title="Data numbered="true" toc="default">
      <name>Data Model Parameters"> Parameters</name>
      <t>This section defines the TWAMP data model using UML <xref
      target="UML">UML</xref> target="UML"/> and introduces selected parameters associated
      with the four TWAMP logical entities. The complete TWAMP data model
      specification is provided in the YANG module presented in <xref
      target="yangmodule"/>.</t> target="yangmodule" format="default"/>.</t>
      <section anchor="clientConfig" title="Control-Client"> numbered="true" toc="default">
        <name>Control-Client</name>
        <t>The client container (see <xref target="fig:twamp-client"/>) target="fig_twamp-client" format="default"/>) holds
        items that are related to the configuration of the TWAMP
        Control-Client logical entity (recall <xref target="fig:scope"/>).</t> target="fig_scope" format="default"/>).</t>
        <t>The client container includes an administrative configuration
        parameter (client/admin-state) that indicates whether the device is
        allowed to initiate TWAMP-Control connections.</t>
        <figure anchor="fig:twamp-client"
                title="TWAMP anchor="fig_twamp-client">
          <name>TWAMP Control-Client UML class diagram">
          <artwork><![CDATA[ Class Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  +-------------+
  | client      |
  +-------------+                   1..* +-----------------------+
  | admin-state |<>----------------------| mode-preference-chain |
  |             |                        +-----------------------+
  |             |  1..* +------------+   | priority              |
  |             |<>-----| key-chain  |   | mode                  |
  +-------------+       +------------+   +-----------------------+
         ^              | key-id     |
         V              | secret-key |
         |              +------------+
         | 0..*
  +------------------------+
  | ctrl-connection        |
  +------------------------+
  | name                   |
  | client-ip              |
  | server-ip              |
  | server-tcp-port        |    0..* +----------------------+
  | control-packet-dscp    |<>-------| test-session-request |
  | key-id                 |         +----------------------+
  | max-count              |         | name                 |
  | client-tcp-port   {ro} |         | sender-ip            |
  | server-start-time {ro} |         | sender-udp-port      |
  | state             {ro} |         | reflector-ip         |
  | selected-mode     {ro} |         | reflector-udp-port   |
  | token             {ro} |         | timeout              |
  | client-iv         {ro} |         | padding-length       |
  +------------------------+         | test-packet-dscp     |
                                     | start-time           |
              +-------------+ 1      | repeat               |
              | pm-reg-list |------<>| repeat-interval      |
              +-------------+        | state           {ro} |
              | pm-index    |        | sid             {ro} |
              +-------------+        +----------------------+
]]></artwork>        +----------------------+]]></artwork>
        </figure>
        <t>The client container holds a list (mode-preference-chain) which that
        specifies the Mode mode values according to their preferred order of use by
        the operator of this Control-Client, including the authentication and
        encryption Modes. modes. Specifically, mode-preference-chain lists the mode
        and its corresponding priority, expressed as a 16-bit unsigned integer. Values
        for the priority start with zero, the highest priority, and decreasing
        priority value is indicated by every increase in value by one.</t>
        <t>Depending on the Modes modes available in the Server Greeting, the
        Control-Client MUST <bcp14>MUST</bcp14> choose the highest priority Mode highest-priority mode from the
        configured mode-preference-chain list.</t>
        <t>Note that the list of preferred Modes modes may set multiple bit
        positions independently, such as when referring to the extended TWAMP
        features in <xref target="RFC5618">Mixed target="RFC5618" format="default">"Mixed Security
        Mode for TWAMP
        </xref>, the Two-Way Active Measurement Protocol (TWAMP)"</xref>,
        <xref target="RFC5938">Individual target="RFC5938" format="default">"Individual Session Control
        Feature for
        TWAMP </xref>, the Two-Way Active Measurement Protocol (TWAMP)"</xref>, <xref target="RFC6038">TWAMP target="RFC6038" format="default">"Two-Way Active
Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features </xref>, Features"</xref>, and <xref
        target="RFC7717">IKEv2-Derived target="RFC7717"
        format="default">"IKEv2-Derived Shared Secret Key for OWAMP
        the One-Way Active Measurement Protocol (OWAMP) and TWAMP
        </xref>.
        Two-Way Active Measurement Protocol (TWAMP)"</xref>. If the Control-Client cannot determine an acceptable Mode, mode, or
        when the bit combinations do not make sense, e.g., both authenticated
        and unauthenticated bit bits are both set, it MUST <bcp14>MUST</bcp14> respond with zero Mode bits
        set in the Set-up Response Set-Up-Response message, indicating that it will not continue
        with the control connection.</t>
        <t>In addition, the client container holds a list named key-chain "key-chain",
        which relates key-id with the respective secret-key. Both the Server
        and the Control-Client use the same mappings from key-id to secret-key secret&nbhy;key
        (in <xref target="fig:twamp-client"/>); target="fig_twamp-client" format="default"/>); in order for this to work
        properly, key-id must be unique across all systems in the
        administrative domain. The Server, being prepared to conduct sessions
        with more than one Control-Client, uses key-id to choose the
        appropriate secret-key; a Control-Client would typically have
        different secret keys for different Servers. The secret-key is the
        shared secret, of type binary "binary", and the length SHOULD <bcp14>SHOULD</bcp14> contain at least
        128 bits of entropy. The key-id and secret-key encoding SHOULD <bcp14>SHOULD</bcp14> follow
        Section 9.8 of
        <xref target="RFC7950">YANG </xref>. target="RFC7950" sectionFormat="of" section="9.8">YANG</xref>. The derived key
        length (dkLen as defined in <xref target="RFC8018">PKCS target="RFC8018" format="default">"PKCS #5: Password-Based
        Cryptography Specification Version 2.1 </xref>) MUST 2.1"</xref>) <bcp14>MUST</bcp14> be 16 octets for
        the AES Session-key used for encryption and 32 octets 32&nbsp;octets for the
        HMAC-SHA1 Session-key used for authentication; see also Section 6.10
        of <xref target="RFC4656">OWAMP </xref>.</t> target="RFC4656" sectionFormat="of" section="6.10">OWAMP</xref>.</t>
        <t>Each client container also holds a list of control connections,
        where each item in the list describes a TWAMP control TWAMP-Control connection
        initiated by this Control-Client. There SHALL <bcp14>SHALL</bcp14> be one ctrl-connection
        per TWAMP-Control (TCP) connection that is to be initiated from this
        device.</t>
        <t>In turn, each ctrl-connection holds a test-session-request list.
        Each test-session-request holds information associated with the
        Control-Client for this test session. This includes information
        associated with the Request-TW-Session/Accept-Session message exchange
        (see Section 3.5 of <xref target="RFC5357">TWAMP </xref>).</t> target="RFC5357" sectionFormat="of" section="3.5">TWAMP</xref>).</t>
        <t>There SHALL <bcp14>SHALL</bcp14> be one instance of test-session-request for each
        TWAMP-Test
        TWAMP&nbhy;Test session that is to be negotiated by this TWAMP-Control
        connection via a Request-TW-Session/Accept-Session exchange.</t>
        <t>The Control-Client is also responsible for scheduling TWAMP-Test
        sessions, therefore
        sessions; therefore, test-session-request holds information related to
        these actions (e.g. (e.g., pm-index, repeat-interval).</t>
      </section>
      <section anchor="serverConfig" title="Server"> numbered="true" toc="default">
        <name>Server</name>
        <t>The server container (see <xref target="fig:twamp-server"/>) target="fig_twamp-server" format="default"/>) holds
        items that are related to the configuration of the TWAMP Server
        logical entity (recall <xref target="fig:scope"/>).</t> target="fig_scope" format="default"/>).</t>
        <t>The server container includes an administrative configuration
        parameter (server/admin-state) that indicates whether the device is
        allowed to receive TWAMP-Control connections.</t>
        <t>A device operating in the Server role Role cannot configure attributes
        on a per TWAMP-Control connection per-TWAMP-Control-connection basis, as it has no foreknowledge of
        the incoming TWAMP-Control connections to be received. Consequently,
        any parameter that the Server might want to apply to an incoming
        control connection must be configured at the overall Server level and
        applied to all incoming TWAMP-Control connections.</t>
        <figure anchor="fig:twamp-server"
                title="TWAMP anchor="fig_twamp-server">
          <name>TWAMP Server UML class diagram">
          <artwork><![CDATA[ Class Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    +---------------------+
    | server              |
    +---------------------+
    | admin-state         |   1..* +------------+
    | server-tcp-port     |<>------| key-chain  |
    | servwait            |        +------------+
    | control-packet-dscp |        | key-id     |
    | count               |        | secret-key |
    | max-count           |        +------------+
    | modes               |
    |                     |   0..* +--------------------------+
    |                     |<>------| ctrl-connection          |
    +---------------------+        +--------------------------+
                                   | client-ip           {ro} |
                                   | client-tcp-port     {ro} |
                                   | server-ip           {ro} |
                                   | server-tcp-port     {ro} |
                                   | state               {ro} |
                                   | control-packet-dscp {ro} |
                                   | selected-mode       {ro} |
                                   | key-id              {ro} |
                                   | count               {ro} |
                                   | max-count           {ro} |
                                   | salt                {ro} |
                                   | server-iv           {ro} |
                                   | challenge           {ro} |
                               +--------------------------+
]]></artwork>
                                   +--------------------------+]]></artwork>
        </figure>
        <t>Each server container holds a list named key-chain "key-chain", which relates
        key-id with the respective secret-key. As mentioned in <xref
        target="clientConfig"/>, target="clientConfig" format="default"/>, both the Server and the Control-Client use
        the same mapping from key-id key&nbhy;id to the shared secret-key; in order for this
        to work properly, key-id must be unique across all the systems in the
        administrative domain. The Server, being prepared to conduct sessions
        with more than one Control-Client, uses key-id to choose the
        appropriate secret-key; a Control-Client would typically have
        different secret keys for different Servers. The key-id &nbsp;key-id tells the
        Server which shared secret-key the Control-Client wishes to use for
        authentication or encryption.</t>
        <t>Each incoming control connection active on the Server is
        represented by a ctrl-connection. There SHALL <bcp14>SHALL</bcp14> be one ctrl-connection
        per incoming TWAMP-Control (TCP) connection that is received and
        active on the Server. Each ctrl-connection can be uniquely identified
        by the 4-tuple {client-ip, client-tcp-port, server-ip,
        server-tcp-port}. All &nbsp;All items in the ctrl-connection list are
        read-only.</t>
      </section>
      <section anchor="senderConfig" title="Session-Sender"> numbered="true" toc="default">
        <name>Session-Sender</name>
        <t>The session-sender container, illustrated in <xref
        target="fig:twampSenders"/>, target="fig_twampSenders" format="default"/>, holds items that are related to the
        configuration of the TWAMP Session-Sender logical entity.</t>
        <t>The session-sender container includes an administrative parameter
        (session-sender/admin-state) that controls whether the device is
        allowed to initiate TWAMP-Test sessions.</t>
        <figure anchor="fig:twampSenders"
                title="TWAMP anchor="fig_twampSenders">
          <name>TWAMP Session-Sender UML class diagram">
          <artwork><![CDATA[ Class Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      +----------------+
      | session-sender |
      +----------------+  0..* +---------------------------+
      | admin-state    |<>-----| test-session              |
      +----------------+       +---------------------------+
                               | name                      |
                               | ctrl-connection-name {ro} |
                               | fill-mode                 |
                               | number-of-packets         |
                               | state                {ro} |
                               | sent-packets         {ro} |
                               | rcv-packets          {ro} |
                               | last-sent-seq        {ro} |
                               | last-rcv-seq         {ro} |
                               +---------------------------+
                                            ^
                                            V
                                            | 1
                                +---------------------+
                                | packet-distribution |
                                +---------------------+
                                | periodic / poisson  |
                                +---------------------+
                                    |           |
                         +-------------------+  |
                         | periodic-interval |  |
                         +-------------------+  |
                                                |
                                        +--------------+
                                        | lambda       |
                                        | max-interval |
                                  +--------------+
]]></artwork>
                                        +--------------+]]></artwork>
        </figure>
        <t>Each TWAMP-Test session initiated by the Session-Sender will be
        represented by an instance of a test-session object. There SHALL <bcp14>SHALL</bcp14> be
        one instance of test-session for each TWAMP-Test session for which
        packets are being sent.</t>
      </section>
      <section anchor="reflectorConfig" title="Session-Reflector"> numbered="true" toc="default">
        <name>Session-Reflector</name>
        <t>The session-reflector container, illustrated in <xref
        target="fig:twampReflector"/>, target="fig_twampReflector" format="default"/>, holds items that are related to the
        configuration of the TWAMP Session-Reflector logical entity.</t>
        <t>The session-reflector container includes an administrative
        parameter (session-reflector/admin-state) that controls whether the
        device is allowed to respond to incoming TWAMP-Test sessions.</t>
        <t>A device operating in the Session-Reflector role Role cannot configure
        attributes on a per-session basis, as it has no foreknowledge of what
        incoming sessions it will receive. As such, any parameter that the
        Session-Reflector might want to apply to an incoming TWAMP-Test
        session must be configured at the overall Session-Reflector level and
        are
        applied to all incoming sessions.</t>
        <figure anchor="fig:twampReflector"
                title="TWAMP anchor="fig_twampReflector">
          <name>TWAMP Session-Reflector UML class diagram">
          <artwork><![CDATA[ Class Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
             +-------------------+
             | session-reflector |
             +-------------------+
             | admin-state       |
             | refwait           |
             +-------------------+
                      ^
                      V
                      |
                      | 0..*
             +----------------------------------------+
             | test-session                           |
             +----------------------------------------+
             | sid                               {ro} |
             | sender-ip                         {ro} |
             | sender-udp-port                   {ro} |
             | reflector-ip                      {ro} |
             | reflector-udp-port                {ro} |
             | parent-connection-client-ip       {ro} |
             | parent-connection-client-tcp-port {ro} |
             | parent-connection-server-ip       {ro} |
             | parent-connection-server-tcp-port {ro} |
             | test-packet-dscp                  {ro} |
             | sent-packets                      {ro} |
             | rcv-packets                       {ro} |
             | last-sent-seq                     {ro} |
             | last-rcv-seq                      {ro} |
+----------------------------------------+
]]></artwork>
             +----------------------------------------+]]></artwork>
        </figure>
        <t>Each incoming TWAMP-Test session that is active on the
        Session-Reflector SHALL <bcp14>SHALL</bcp14> be represented by an instance of a
        test-session object. All items in the test-session object are
        read-only.</t>
        <t>Instances of test-session are indexed by a session identifier
        (sid). Session Identifier
        (SID) (the sid parameter). This SID value is auto-allocated by the TWAMP Server as test
        session requests are received, received and is communicated back to the
        Control-Client in the SID field of the Accept-Session message; see
        Section 4.3 <xref target="RFC6038" sectionFormat="bare" section="4.3"/> of
        <xref target="RFC6038">TWAMP target="RFC6038">"Two-Way
        Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical
        Size Features </xref>.</t> Features"</xref>.</t>
        <t>When attempting to retrieve operational data for active test
        sessions from a Session-Reflector device, the user will not know what
        sessions are currently active on that device, device or what SIDs have been
        auto-allocated
        auto&nbhy;allocated for these test sessions. If the user has network access
        to the Control-Client device, then it is possible to read the data for
        this session under client/ctrl-connection/test-session-request/sid and
        obtain the SID (see <xref target="fig:twamp-client"/>). target="fig_twamp-client" format="default"/>). The user may
        then use this SID value as an index to retrieve an individual
        session-reflector/test-session instance on the Session-Reflector
        device.</t>
        <t>If the user has no network access to the Control-Client device,
        then the only option is to retrieve all test-session instances from
        the Session-Reflector device, device and then pick out specific test-session
        instances of interest to the user. This could be problematic if a
        large number of test sessions are currently active on that device.</t>
        <t>Each Session-Reflector TWAMP-Test session contains the following
        4-tuple: {parent-connection-client-ip,
        parent-connection-client-tcp-port, parent-connection-server-ip,
        parent-connection-server-tcp-port}. This &nbsp;This 4-tuple MUST <bcp14>MUST</bcp14> correspond to
        the equivalent 4-tuple {client-ip, client-tcp-port, server-ip,
        server-tcp-port} in server/ctrl-connection. server&wj;/ctrl-connection. This 4-tuple allows the
        user to trace back from the TWAMP-Test session to the (parent)
        TWAMP-Control connection that negotiated this test session.</t>
      </section>
    </section>
    <section anchor="module" title="Data Model"> numbered="true" toc="default">
      <name>Data Model</name>
      <t>This section formally specifies the TWAMP data model using YANG.</t>
      <section anchor="yangtree" title="YANG numbered="true" toc="default">
        <name>YANG Tree Diagram"> Diagram</name>
        <t>This section presents a simplified graphical representation of the
        TWAMP data model using a YANG tree diagram. Readers should keep in
        mind that the limit of 72 characters per line forces us to introduce
        artificial line breaks in some tree diagram nodes. Tree diagrams used
        in this document follow the notation defined in <xref
        target="RFC8340">YANG target="RFC8340"
        format="default">"YANG Tree Diagrams</xref>.</t> Diagrams"</xref>.</t>

        <t>Please note that the backslash ('\') character near the end of the
        diagram is used for formatting purposes only
        (i.e., "reflector&nbhy;udp&nbhy;port]" should be treated as part of
        the same line as "[sender&nbhy;ip&nbsp;sender&nbhy;udp&nbhy;port&nbsp;reflector&nbhy;ip").</t>

        <figure anchor="fig:yangtree" title="YANG anchor="fig_yangtree">
          <name>YANG Tree Diagram.">
          <artwork><![CDATA[ Diagram</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-twamp
  +--rw twamp
     +--rw client {control-client}?
     |  +--rw admin-state?             boolean
     |  +--rw mode-preference-chain* [priority]
     |  |  +--rw priority    uint16
     |  |  +--rw mode?       twamp-modes
     |  +--rw key-chain* [key-id]
     |  |  +--rw key-id        string
     |  |  +--rw secret-key?   binary
     |  +--rw ctrl-connection* [name]
     |     +--rw name                    string
     |     +--rw client-ip?              inet:ip-address
     |     +--rw server-ip               inet:ip-address
     |     +--rw server-tcp-port?        inet:port-number
     |     +--rw control-packet-dscp?    inet:dscp
     |     +--rw key-id?                 string
     |     +--rw max-count-exponent?     uint8
     |     +--ro client-tcp-port?        inet:port-number
     |     +--ro server-start-time?      uint64
     |     +--ro repeat-count?           uint64
     |     +--ro state?
     |     |       control-client-connection-state
     |     +--ro selected-mode?          twamp-modes
     |     +--ro token?                  binary
     |     +--ro client-iv?              binary
     |     +--rw test-session-request* [name]
     |        +--rw name                  string
     |        +--rw sender-ip?            inet:ip-address
     |        +--rw sender-udp-port?      union
     |        +--rw reflector-ip          inet:ip-address
     |        +--rw reflector-udp-port?   inet:port-number
     |        +--rw timeout?              uint64
     |        +--rw padding-length?       uint32
     |        +--rw test-packet-dscp?     inet:dscp
     |        +--rw start-time?           uint64
     |        +--rw repeat?               uint32
     |        +--rw repeat-interval?      uint32
     |        +--rw pm-reg-list* [pm-index]
     |        |  +--rw pm-index    uint16
     |        +--ro state?                test-session-state
     |        +--ro sid?                  string
     +--rw server {server}?
     |  +--rw admin-state?           boolean
     |  +--rw server-tcp-port?       inet:port-number
     |  +--rw servwait?              uint32
     |  +--rw control-packet-dscp?   inet:dscp
     |  +--rw count?                 uint8
     |  +--rw max-count-exponent?    uint8
     |  +--rw modes?                 twamp-modes
     |  +--rw key-chain* [key-id]
     |  |  +--rw key-id        string
     |  |  +--rw secret-key?   binary
     |  +--ro ctrl-connection*
     |          [client-ip client-tcp-port server-ip server-tcp-port]
     |     +--ro client-ip              inet:ip-address
     |     +--ro client-tcp-port        inet:port-number
     |     +--ro server-ip              inet:ip-address
     |     +--ro server-tcp-port        inet:port-number
     |     +--ro state?                 server-ctrl-connection-state
     |     +--ro control-packet-dscp?   inet:dscp
     |     +--ro selected-mode?         twamp-modes
     |     +--ro key-id?                string
     |     +--ro count?                 uint8
     |     +--ro max-count-exponent?    uint8
     |     +--ro salt?                  binary
     |     +--ro server-iv?             binary
     |     +--ro challenge?             binary
     +--rw session-sender {session-sender}?
     |  +--rw admin-state?    boolean
     |  +--rw test-session* [name]
     |     +--rw name                    string
     |     +--ro ctrl-connection-name?   string
     |     +--rw fill-mode?              padding-fill-mode
     |     +--rw number-of-packets       uint32
     |     +--rw (packet-distribution)?
     |     |  +--:(periodic)
     |     |  |  +--rw periodic-interval       decimal64
     |     |  +--:(poisson)
     |     |     +--rw lambda                  decimal64
     |     |     +--rw max-interval?           decimal64
     |     +--ro state?                  sender-session-state
     |     +--ro sent-packets?           uint32
     |     +--ro rcv-packets?            uint32
     |     +--ro last-sent-seq?          uint32
     |     +--ro last-rcv-seq?           uint32
     +--rw session-reflector {session-reflector}?
        +--rw admin-state?    boolean
        +--rw refwait?        uint32
        +--ro test-session*
                [sender-ip sender-udp-port reflector-ip reflector-udp
-port] \
                 reflector-udp-port]
           +--ro sid?                                string
           +--ro sender-ip                           inet:ip-address
           +--ro sender-udp-port
           |       dynamic-port-number
           +--ro reflector-ip                        inet:ip-address
           +--ro reflector-udp-port                   inet:port-numbe
r                  inet:port-number
           +--ro parent-connection-client-ip?        inet:ip-address
           +--ro parent-connection-client-tcp-port?   inet:port-numbe
r  inet:port-number
           +--ro parent-connection-server-ip?        inet:ip-address
           +--ro parent-connection-server-tcp-port?   inet:port-numbe
r  inet:port-number
           +--ro test-packet-dscp?                   inet:dscp
           +--ro sent-packets?                       uint32
           +--ro rcv-packets?                        uint32
           +--ro last-sent-seq?                      uint32
           +--ro last-rcv-seq?                        uint32
             ]]></artwork>                       uint32]]></sourcecode>
        </figure>

      </section>
      <section anchor="yangmodule" title="YANG Module"> numbered="true" toc="default">
        <name>YANG Module</name>
        <t>This section presents the YANG module for the TWAMP data model
        defined in this document. The module imports definitions from <xref
        target="RFC6991">Common
        target="RFC6991" format="default">"Common YANG Data Types</xref>, Types"</xref> and
        references <xref
        target="RFC5905">NTPv4 Specification</xref>, <xref
        target="RFC2330">Framework target="RFC2330" format="default">"Framework for IP Performance Metrics</xref>,
        Metrics"</xref>,
        <xref
        target="RFC4086">Randomness Requirements for Security</xref>, target="RFC3432">"Network performance measurement with periodic
        streams"</xref>, <xref
        target="RFC4656">OWAMP</xref>, target="RFC4656"
        format="default">"A One-way Active Measurement Protocol
        (OWAMP)"</xref>, <xref target="RFC5357">TWAMP</xref>, target="RFC5357" format="default">"A Two-Way
        Active Measurement Protocol (TWAMP)"</xref>,
        <xref target="RFC5618">More Features target="RFC5618" format="default">"Mixed Security Mode for TWAMP</xref>, the
        Two-Way Active Measurement Protocol (TWAMP)"</xref>,
        <xref
        target="RFC5938">Individual target="RFC5905" format="default">"Network Time
        Protocol Version 4: Protocol and Algorithms Specification"</xref>,
        <xref
        target="RFC5938" format="default">"Individual Session Control Feature</xref>, Feature
 for the Two-Way Active Measurement Protocol (TWAMP)"</xref>, <xref
        target="RFC6038">TWAMP target="RFC6038"
        format="default">"Two-Way Active Measurement Protocol (TWAMP) Reflect
        Octets and Symmetrical Size
        Features</xref>, Features"</xref>, <xref target="RFC7312">Advances target="RFC7312" format="default">"Advanced
        Stream and Sampling
        Framework</xref>, Framework for IP Performance Metrics
        (IPPM)"</xref>, <xref target="RFC7717">IKEv2-Derived target="RFC7717" format="default">"IKEv2-Derived
        Shared Secret Key for OWAMP the One-Way Active Measurement Protocol (OWAMP) and TWAMP</xref>, Two-Way Active Measurement Protocol (TWAMP)"</xref>, <xref target="RFC8545"
        format="default">"Well-Known Port Assignments for the One-Way Active
        Measurement Protocol (OWAMP) and the Two-Way Active Measurement
        Protocol (TWAMP)"</xref>, and <xref
        target="I-D.ietf-ippm-port-twamp-test">OWAMP target="RFC8911">"Registry for
        Performance Metrics"</xref>.</t>

<!-- The following text in this section is DNE.  During the
     verification step, made a couple updates where appropriate.
     AQed a mismatch; fixed the 'If an attacking system ...'
     text per author during AUTH48.

* As per Section 6 of RFC 4656,
  in 'authenticated mode, the timestamp is in the clear
  and TWAMP Well-Known Port
        Assignments</xref>.</t>

        <figure>
          <artwork><![CDATA[
<CODE BEGINS> file "ietf-twamp@2018-07-02.yang" is not protected cryptographically in any way,
  while the rest of the message has the same protection
  as in encrypted mode. This mode allows one to trade off
  cryptographic protection against accuracy of
  timestamps.'";

* 'makes it impossible to alter
  timestamps undetectably' [Section 6 of RFC 4656] *Fixed; it's Sec. 1

*  As per
   Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
   80 octets in length' and is used to select which 'shared
   shared secret the [Control-Client] wishes to use to
   authenticate or encrypt'.";

* if it 'receives a
  Server-Greeting message with Count greater that [sic] its
  maximum configured value', as per Section 6 of RFC 5357.

  Further, note that according to Section 6 of RFC 5357:

  'If an attacking system sets the maximum value in
  Count (2**32), then the system under attack would stall
  for a significant period of time while it attempts to
  generate keys.

  TWAMP-compliant systems SHOULD have a configuration
  control to limit the maximum count value. The default
  max-count-exponent value SHOULD be 15 which corresponds
  to a maximum value of 2**15 or 32768.'

Not quoted in original, but I found that the paragraph that follows
"As per RFC 4656:" was verbatim text, so added the single quotes.
**Note:**  The hyphen in "pseudo-random number source" has to be
kept, because it's DNE text.

Another DNE item that needed slight adjustment and single quotes
added (after verification):  "According to Section 3.1 of RFC 5357" -->

        <sourcecode name="ietf-twamp@2021-11-17.yang" type="yang" markers="true">
<![CDATA[
module ietf-twamp {
  yang-version 1.1;
  namespace urn:ietf:params:xml:ns:yang:ietf-twamp; "urn:ietf:params:xml:ns:yang:ietf-twamp";
  prefix ietf-twamp;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Types."; Data Types";
  }

  organization
    "IETF IPPM (IP Performance Metrics) Working Group";
  contact
    "WG Web: http://tools.ietf.org/wg/ippm/ <https://datatracker.ietf.org/wg/ippm/documents/>
     WG List: ippm@ietf.org <mailto:ippm@ietf.org>

     Editor: Ruth Civil
             gcivil@ciena.com
             <mailto:ruthcivil@gmail.com>

     Editor: Al Morton
             acmorton@att.com
             <mailto:acmorton@att.com>

     Editor: Reshad Rehman
             rrahman@cisco.com Rahman
             <mailto:reshad@yahoo.com>

     Editor: Mahesh Jethanandani
             mjethanandani@gmail.com
             <mailto:mjethanandani@gmail.com>

     Editor: Kostas Pentikousis
             k.pentikousis@travelping.com";
             <mailto:kostas.pentikousis@detecon.com>";
  description
    "This YANG module specifies a vendor-independent data
     model for the Two-Way Active Measurement Protocol (TWAMP).

     The data model covers defines four TWAMP logical entities, namely, namely
     Control-Client, Server, Session-Sender, and Session-Reflector,
     as illustrated in the annotated TWAMP logical model (Fig. (Figure 1
     of RFC XXXX). 8913).

     This YANG module uses features to indicate which of the four
     logical entities are supported by a TWAMP implementation.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2018 2021 IETF Trust and the persons identified as
     authors of the document authors. code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 8913; see the
     RFC itself for full legal notices.";

  revision 2018-07-02 2021-11-17 {
    description
      "Initial Revision.

      Covers revision.

       References RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717,
       and
      draft-ietf-ippm-metric-registry"; RFC 8911.";
    reference
      "RFC XXXX: TWAMP 8913: Two-Way Active Measurement Protocol (TWAMP) YANG
       Data Model."; Model";
  }

  /*
   * Typedefs
   */

  typedef twamp-modes {
    type bits {
      bit unauthenticated {
        position 0;
        description
          "Unauthenticated mode, in which no encryption or
           authentication is applied in TWAMP-Control and
           TWAMP-Test.  KeyID, Token, and Client-IV are not used in
           the Set-Up-Response message.  See Section 3.1 of
           RFC 4656.";
        reference
          "RFC 4656: A One-way Active Measurement Protocol
           (OWAMP)"; (OWAMP),
                     Section 3.1";
      }
      bit authenticated {
        position 1;
        description
          "Authenticated mode, in which the Control-Client and
           Server possess a shared secret secret, thus prohibiting
           'theft of service'.  As per Section 6 of RFC 4656,
           in 'authenticated mode, the timestamp is in the clear
           and is not protected cryptographically in any way,
           while the rest of the message has the same protection
           as in encrypted mode.  This mode allows one to trade off
           cryptographic protection against accuracy of
           timestamps.'";
        reference
          "RFC 4656: A One-way Active Measurement Protocol
           (OWAMP)"; (OWAMP),
                     Section 6";
      }
      bit encrypted {
        position 2;
        description
          "Encrypted mode 'makes it impossible to alter
           timestamps undetectably' [Section 6 (Section 1 of RFC 4656]. 4656).
           See also Section 4 of RFC 7717.";
        reference
          "RFC 4656: A One-way Active Measurement Protocol
           (OWAMP)"; (OWAMP),
                     Section 6
           RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way
           Active Measurement Protocol (OWAMP) and Two-Way Active
           Measurement Protocol (TWAMP), Section 4";
      }
      bit unauth-test-encrpyt-control unauth-test-encrypt-control {
        position 3;
        description
          "When using the Mixed Security Mode, mixed security mode, the TWAMP-Test
           protocol follows the Unauthenticated operates in unauthenticated mode and the
           TWAMP-Control protocol the Encrypted operates in encrypted mode.";
        reference
          "RFC 5618: Mixed Security Mode for the Two-Way Active
           Measurement Protocol (TWAMP)";
      }
      bit individual-session-control {
        position 4;
        description
          "This mode enables individual test sessions using
           Session Identifiers.";
        reference
          "RFC 5938: Individual Session Control Feature
           for the Two-Way Active Measurement Protocol (TWAMP)";
      }
      bit reflect-octets {
        position 5;
        description
          "This mode indicates the reflect octets capability.";
        reference
          "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
           Reflect Octets and Symmetrical Size Features";
      }
      bit symmetrical-size {
        position 6;
        description
          "This mode indicates support for the symmetrical size
           sender test packet format.";
        reference
          "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
           Reflect Octets and Symmetrical Size Features";
      }
      bit IKEv2Derived {
        position 7;
        description
          "In this mode the mode, the shared key is derived
           from an IKEv2 Internet Key Exchange Protocol Version 2 (IKEv2)
           security association (SA).";
        reference
          "RFC 7717: IKEv2-Derived Shared Secret Key for
           the One-Way Active Measurement Protocol (OWAMP)
           and Two-Way Active Measurement Protocol (TWAMP)";
      }
    }
    description
      "Specifies the configurable TWAMP-Modes supported during a
       TWAMP-Control Connection connection setup between a Control-Client
       and a Server.  Section 7 of RFC 7717 summarizes the
       TWAMP-Modes registry
       'TWAMP-Modes' Registry and points to their
       formal specification.";
  }

  typedef control-client-connection-state {
    type enumeration {
      enum active {
        description
          "Indicates an active TWAMP-Control connection to the
           Server.";
      }
      enum idle {
        description
          "Indicates an idle TWAMP-Control connection to the
           Server.";
      }
    }
    description
      "Indicates the Control-Client TWAMP-Control connection
       state.";
  }

  typedef test-session-state {
    type enumeration {
      enum accepted {
        value 0;
        description
          "Indicates an accepted TWAMP-Test session request.";
      }
      enum failed {
        value 1;
        description
          "Indicates a TWAMP-Test session failure due to
           some unspecified reason (catch-all).";
      }
      enum internal-error {
        value 2;
        description
          "Indicates a TWAMP-Test session failure due to
           an internal error.";
      }
      enum not-supported {
        value 3;
        description
          "Indicates a TWAMP-Test session failure because
           some aspect of the TWAMP-Test session request
           is not supported.";
      }
      enum permanent-resource-limit {
        value 4;
        description
          "Indicates a TWAMP-Test session failure due to
           permanent resource limitations.";
      }
      enum temp-resource-limit {
        value 5;
        description
          "Indicates a TWAMP-Test session failure due to
           temporary resource limitations.";
      }
    }
    description
      "Indicates the Control-Client TWAMP-Test session state.";
  }

  typedef server-ctrl-connection-state {
    type enumeration {
      enum active {
        description
          "Indicates an active TWAMP-Control connection
           to the Control-Client.";
      }
      enum servwait {
        description
          "Indicates that the TWAMP-Control connection to the
           Control-Client is in SERVWAIT as per the definition of in
           Section 3.1 of RFC 5357.";
        reference
          "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP),
                     Section 3.1";
      }
    }
    description
      "Indicates the Server TWAMP-Control connection state.";
  }

  typedef sender-session-state {
    type enumeration {
      enum active {
        description
          "Indicates that the TWAMP-Test session is active.";
      }
      enum failure {
        description
          "Indicates that the TWAMP-Test session has failed.";
      }
    }
    description
      "Indicates the Session-Sender TWAMP-Test session state.";
  }

  typedef padding-fill-mode {
    type enumeration {
      enum zero {
        description
          "TWAMP-Test packets are padded with all zeros.";
      }
      enum random {
        description
          "TWAMP-Test packets are padded with pseudo-random pseudorandom
           numbers.";
      }
    }
    description
      "Indicates what type of packet padding is used in the
       TWAMP-Test packets.";
  }

  typedef dynamic-port-number {
    type inet:port-number {
      range 49152..65535; "49152..65535";
    }
    description
      "Dynamic range for port numbers.";
  }

  /*
   * Features
   */

  feature control-client {
    description
      "Indicates that the device supports configuration of the
       TWAMP Control-Client logical entity.";
  }

  feature server {
    description
      "Indicates that the device supports configuration of the
       TWAMP Server logical entity.";
  }

  feature session-sender {
    description
      "Indicates that the device supports configuration of the
       TWAMP Session-Sender logical entity.";
  }

  feature session-reflector {
    description
      "Indicates that the device supports configuration of the
       TWAMP Session-Reflector logical entity.";
  }

  /*
   * Reusable node groups
   */

  grouping key-management {
    list key-chain {
      key key-id; "key-id";
      leaf key-id {
        type string {
          length 1..80; "1..80";
        }
        description
          "KeyID used for a TWAMP-Control connection.  As per
           Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
           80 octets in length' and is used to select which 'shared
           shared
           secret the [Control-Client] wishes client' (Control-Client) 'wishes to use to
           authenticate or encrypt'.";
      }
      leaf secret-key {
        type binary;
        description
          "The secret key corresponding to the KeyID for this
           TWAMP-Control connection.";
      }
      description
        "Relates KeyIDs with their respective secret keys
         in a TWAMP-Control connection.";
    }
    description
      "Used by the Control-Client and Server for TWAMP-Control
       key management.";
  }

  grouping maintenance-statistics {
    leaf sent-packets {
      type uint32;
      config false;
      description
        "Indicates the number of packets sent.";
    }
    leaf rcv-packets {
      type uint32;
      config false;
      description
        "Indicates the number of packets received.";
    }
    leaf last-sent-seq {
      type uint32;
      config false;
      description
        "Indicates the last sent sequence number.";
    }
    leaf last-rcv-seq {
      type uint32;
      config false;
      description
        "Indicates the last received sequence number.";
    }
    description
      "Used for TWAMP-Test maintenance statistics.";
  }

  grouping count {
    leaf count {
      type uint8 {
        range "10..31";
      }
      default 15; "15";
      description
        "Parameter communicated to the Control-Client as part of
         the Server Greeting message and used for deriving a key
         from a shared secret as per Section 3.1 of RFC 4656:
         MUST be a power of 2 and at least 1024.  It is configured
         by providing said power.  For example, configuring 20 here
         means count 2^20 = 1048576.  The default is 15,
         meaning 2^15 = 32768.";
    }
    description
      "Reusable data structure for count, which is used both in both the
       Server and the Control-Client.";
  }

  grouping max-count-exponent {
    leaf max-count-exponent {
      type uint8 {
        range 10..31; "10..31";
      }
      default 20; "20";
      description
        "This parameter limits the maximum Count value, which MUST
         be a power of 2 and at least 1024 as per RFC 5357.  It is
         configured by providing said power.  For example,
         configuring 10 here means max count 2^10 = 1024.
         The default is 20, meaning 2^20 = 1048576.

         A TWAMP Server uses this configured value in the
         Server-Greeting
         Server Greeting message sent to the Control-Client.

         A TWAMP Control-Client uses this configured value to
         prevent denial-of-service (DOS) (DoS) attacks by closing the
         control connection to the Server if it 'receives a
         Server-Greeting message with Count greater that [sic] its
         maximum configured value', as per Section 6 of RFC 5357.

         Further, note that according to Section 6 of RFC 5357:

         'If an attacking system sets set the maximum value in Count
         (2**32), then the system under attack would stall for a
         significant period of time while it attempts to generate
         keys.  Therefore, TWAMP-compliant systems SHOULD have a
         configuration control to limit the maximum count Count value.
         The default maximum Count value SHOULD be 32768.'

         In the case of this document, the default max-count-exponent
         value SHOULD be 15 15, which corresponds to a maximum value of
         2**15 or 32768.' 32768.

         RFC 5357 does not qualify 'significant period' in terms of
         time, but it is clear that this depends on the processing
         capacity available available, and operators need to pay attention to
         this security consideration.";
    }
    description
      "Reusable data structure for max-count which that is used in both at
       the Control-Client client (Control-Client) container and the Server containers."; server
       container.";
  }

  /*
   * Configuration data nodes
   */

  container twamp {
    description
      "TWAMP logical entity configuration grouping of four models
      which
       that correspond to the four TWAMP logical entities
       Control-Client, Server, Session-Sender, and Session-Reflector
       as illustrated in Fig. Figure 1 of RFC XXXX."; 8913.";
    container client {
      if-feature control-client; "control-client";
      description
        "Configuration of the TWAMP Control-Client logical entity.";
      leaf admin-state {
        type boolean;
        default true; "true";
        description
          "Indicates whether the device is allowed to operate as a
           TWAMP Control-Client.";
      }
      list mode-preference-chain {
        key priority; "priority";
        unique mode; "mode";
        leaf priority {
          type uint16;
          description
            "Indicates the Control-Client Mode mode preference priority priority,
             expressed as a 16-bit unsigned integer.  Values for the
             priority start with zero, the highest priority, and
             decreasing priority value is indicated by every increase
             in value by one.";
        }
        leaf mode {
          type twamp-modes;
          description
            "The supported TWAMP Mode TWAMP-Modes matching the corresponding
             priority.";
        }
        description
          "Indicates the Control-Client preferred order of use of
           the supported TWAMP Modes. TWAMP-Modes.

           Depending on the Modes modes available in the TWAMP Server
           Greeting message (see Fig. Figure 2 of RFC 7717), the
           Control-Client MUST choose the highest priority
           Mode highest-priority
           mode from the configured mode-preference-chain list.";
      }
      uses key-management;
      list ctrl-connection {
        key name; "name";
        description
          "List of TWAMP Control-Client control connections.
           Each item in the list describes a control connection
           that will be initiated by this Control-Client"; Control-Client.";
        leaf name {
          type string;
          description
            "A unique name used as a key to identify this
             individual TWAMP-Control connection on the
             Control-Client device.";
        }
        leaf client-ip {
          type inet:ip-address;
          description
            "The IP address of the local Control-Client device,
             to be placed in the source IP address field of the
             IP header in TWAMP-Control (TCP) packets belonging
             to this control connection.  If not configured, the
             device SHALL choose its own source IP address.";
        }
        leaf server-ip {
          type inet:ip-address;
          mandatory true;
          description
            "The IP address of the remote Server device, device to which
             the TWAMP-Control connection will be initiated to."; initiated.";
        }
        leaf server-tcp-port {
          type inet:port-number;
          default 862; "862";
          description
            "This parameter defines the TCP port number that is
             to be used by this outgoing TWAMP-Control connection.
             Typically, this is the well-known TWAMP-Control
             port number (862) as per RFC 5357 5357.  However, there are
             known realizations of TWAMP in the field that were
             implemented before this well-known port number was
             allocated.  These early implementations allowed the
             port number to be configured.  This parameter is
             therefore provided for backward compatibility backward-compatibility
             reasons.";
        }
        leaf control-packet-dscp {
          type inet:dscp;
          default 0; "0";
          description
            "The DSCP Differentiated Services Code Point (DSCP) value
             to be placed in the IP header of TWAMP-Control (TCP)
             packets generated by this Control-Client.";
        }
        leaf key-id {
          type string {
            length 1..80; "1..80";
          }
          description
            "Indicates the KeyID value selected for this
             TWAMP-Control connection.";
        }
        uses max-count-exponent;
        leaf client-tcp-port {
          type inet:port-number;
          config false;
          description
            "Indicates the source TCP port number used in the
             TWAMP-Control packets belonging to this control
             connection.";
        }
        leaf server-start-time {
          type uint64;
          config false;
          description
            "Indicates the Start-Time advertised by the Server in
             the Server-Start message (RFC 4656, Section 3.1),
             representing the time when the current
             instantiation of the Server started operating.
             The timestamp format follows RFC 5905 5905, according to
             Section 4.1.2 of RFC 4656.";
          reference
            "RFC 4656: OWAMP, Section A One-way Active Measurement Protocol (OWAMP),
             Sections 3.1 and 4.1.2, 4.1.2
             RFC 5905: NTPv4 Specification."; Network Time Protocol Version 4: Protocol and
             Algorithms Specification";
        }
        leaf repeat-count {
          type uint64;
          config false;
          description
            "Indicates how many times the test session has been
             repeated.  When a test is running, this value will be
             greater than 0.  If the repeat parameter is non-zero,
             this value is smaller than or equal to the repeat
             parameter.";
        }
        leaf state {
          type control-client-connection-state;
          config false;
          description
            "Indicates the current state of the TWAMP-Control connection state.";
        }
        leaf selected-mode {
          type twamp-modes;
          config false;
          description
            "The TWAMP Mode TWAMP-Modes that the Control-Client has chosen for
             this control connection as set in the Mode field of
             the Set-Up-Response message"; message.";
          reference
            "RFC 4656, 4656: A One-way Active Measurement Protocol (OWAMP),
                       Section 3.1."; 3.1";
        }
        leaf token {
          type binary {
            length 64; "64";
          }
          config false;
          description
            "This parameter holds the 64 octets containing the
             concatenation of a 16-octet Challenge, a 16-octet AES
             Session-key used for encryption, and a 32-octet
             HMAC-SHA1 Session-key used for authentication; see
             also the last paragraph of Section 6 in 6.10 of RFC 4656.

             If the Mode mode defined in RFC 7717 is selected
             (selected-mode), Token is limited to 16 octets.";
          reference
            "RFC 4086: Randomness Requirements for Security 4656: A One-way Active Measurement Protocol (OWAMP),
                       Section 6.10
             RFC 7717: IKEv2-Derived Shared Secret Key for the
             One-Way Active Measurement Protocol (OWAMP) and
             Two-Way Active Measurement Protocol (TWAMP)";
        }
        leaf client-iv {
          type binary {
            length 16; "16";
          }
          config false;
          description
            "Indicates the Control-Client Initialization Vector
             (Client-IV), that which is generated randomly by the
             Control-Client.  As per RFC 4656:

              Client-IV

             'Client-IV merely needs to be unique (i.e., it MUST
             never be repeated for different sessions using the
             same secret key; a simple way to achieve that without
             the use of cumbersome state is to generate the
             Client-IV values using a cryptographically secure
             pseudo-random number source. source.'

             If the Mode mode defined in RFC 7717 is selected
             (selected-mode), Client-IV is limited to 12 octets.";
          reference
            "RFC 4656: A One-way Active Measurement Protocol
             (OWAMP). (OWAMP)
             RFC 7717: IKEv2-Derived Shared Secret Key for the
             One-Way Active Measurement Protocol (OWAMP) and
             Two-Way Active Measurement Protocol (TWAMP)";
        }
        list test-session-request {
          key name; "name";
          description
            "Information associated with the Control-Client
             for this test session"; session.";
          leaf name {
            type string;
            description
              "A unique name to be used for identification of
               this TWAMP-Test session on the Control-Client.";
          }
          leaf sender-ip {
            type inet:ip-address;
            description
              "The IP address of the Session-Sender device,
               which is to be placed in the source IP address
               field of the IP header in TWAMP-Test (UDP) packets
               belonging to this test session.  This value will be
               used to populate the sender address Sender Address field of the
               Request-TW-Session message.

               If not configured, the device SHALL choose its own
               source IP address.";
          }
          leaf sender-udp-port {
            type union {
              type dynamic-port-number;
              type enumeration {
                enum autoallocate {
                  description
                    "Indicates that the Contol-Client Control-Client will
                     auto-allocate the TWAMP-Test (UDP) port number
                     from the dynamic port range.";
                }
              }
            }
            default autoallocate; "autoallocate";
            description
              "The UDP port number that is to be used by
               the Session-Sender for this TWAMP-Test session.
               The number is restricted to the dynamic port range.

               By default default, the Control-Client SHALL auto-allocate a
               UDP port number for this TWAMP-Test session.

               The configured (or auto-allocated) value is
               advertised in the Sender Port field of the
               Request-TW-session
               Request-TW-Session message (see Section 3.5 of
               RFC 5357).  Note that in the scenario where a device
               auto-allocates a UDP port number for a session, session and
               the repeat parameter for that session indicates that
               it should be repeated, the device is free to
               auto-allocate a different UDP port number when it
               negotiates the next (repeated) iteration of this
               session.";
          }
          leaf reflector-ip {
            type inet:ip-address;
            mandatory true;
            description
              "The IP address belonging to the remote
               Session-Reflector device to which the TWAMP-Test
               session will be initiated.  This value will be
               used to populate the receiver address Receiver Address field of
               the Request-TW-Session message.";
          }
          leaf reflector-udp-port {
            type inet:port-number {
              range "862 | 49152..65535";
            }
            description
              "This parameter defines the UDP port number that
               will be used by the Session-Reflector for
               this TWAMP-Test session.  The default number is
               within the dynamic port range and is to be placed
               in the Receiver Port field of the Request-TW-Session
               message.  The well-known port (862) MAY be used.";
            reference
              "draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP
              "RFC 8545: Well-Known Port Assignments."; Assignments for the One-Way
               Active Measurement Protocol (OWAMP) and the Two-Way
               Active Measurement Protocol (TWAMP)";
          }
          leaf timeout {
            type uint64;
            units seconds; "seconds";
            default 2; "2";
            description
              "The length of time (in seconds) that the
               Session-Reflector should continue to respond to
               packets belonging to this TWAMP-Test session after
               a Stop-Sessions TWAMP-Control message has been
               received.

               This value will be placed in the Timeout field of
               the Request-TW-Session message.";
            reference
              "RFC 5357: TWAMP, A Two-Way Active Measurement Protocol
               (TWAMP), Section 3.5."; 3.5";
          }
          leaf padding-length {
            type uint32 {
              range 64..4096; "64..4096";
            }
            description
              "The number of padding bytes to be added to the
               TWAMP-Test (UDP) packets generated by the
               Session-Sender.

               This value will be placed in the Padding Length
               field of the Request-TW-Session message.";
            reference
              "RFC 4656, 4656: A One-way Active Measurement Protocol
               (OWAMP), Section 3.5."; 3.5";
          }
          leaf test-packet-dscp {
            type inet:dscp;
            default 0; "0";
            description
              "The DSCP value to be placed in the IP header
               of TWAMP-Test packets generated by the
               Session-Sender,
               Session-Sender and in the UDP header of the
               TWAMP-Test response packets generated by the
               Session-Reflector for this test session.

               This value will be placed in the Type-P Descriptor
               field of the Request-TW-Session message"; message.";
            reference
              "RFC 5357."; 5357: A Two-Way Active Measurement Protocol
               (TWAMP)";
          }
          leaf start-time {
            type uint64;
            default 0; "0";
            description
              "Time when the session is to be started
               (but not before the TWAMP Start-Sessions command
               is issued; see Section 3.4 of RFC 5357).

               The start-time value is placed in the Start Time
               field of the Request-TW-Session message.

               The timestamp format follows RFC 5905 as per
               Section 3.5 of RFC 4656.

               The default value of 0 indicates that the session
               will be started as soon as the Start-Sessions
               message is received.";
          }
          leaf repeat {
            type uint32 {
              range 0..4294967295; "0..4294967295";
            }
            default 0; "0";
            description
              "This value determines if the TWAMP-Test session must
               be repeated.  When a test session has completed, the
               repeat parameter is checked.

               The default value of 0 indicates that the session
               MUST NOT be repeated.

               If the repeat value is 1 through 4,294,967,294 4,294,967,294,
               then the test session SHALL be repeated using the
               information in the repeat-interval parameter, and the
               parent TWAMP-Control connection for this test
               session is restarted to negotiate a new instance
               of this TWAMP-Test session.

               A value of 4,294,967,295 indicates that the test
               session SHALL be repeated *forever* using the
               information in the repeat-interval parameter, parameter and
               SHALL NOT decrement the value.";
          }
          leaf repeat-interval {
            when "../repeat!='0'" {
              description
                "This parameter determines the timing of repeated
                 TWAMP-Test sessions when repeat is more than 0.

                 When the value of repeat-interval is 0, the
                 negotiation of a new test session SHALL begin
                 immediately after the previous test session
                 completes.  Otherwise, the Control-Client will
                 wait for the number of seconds specified in the
                 repeat-interval parameter before negotiating the
                 new instance of this TWAMP-Test session.";
            }
            type uint32;
            units seconds; "seconds";
            default 0; "0";
            description
              "Repeat interval (in seconds).";
          }
          list pm-reg-list {
            key pm-index; "pm-index";
            leaf pm-index {
              type uint16;
              description
                "Numerical index value of a Registered Metric in
                 the Performance Metric Metrics Registry (see ietf-ippm-metric-registry). RFC 8911).
                 Output statistics are specified in the
                 corresponding Registry
                 entry."; Entry.";
            }
            description
              "A list of one or more Performance Metric Metrics Registry
               Index values, which communicate packet stream
               characteristics along with one or more metrics
               to be measured.

               All members of the pm-reg-list MUST have the same
               stream characteristics, such that they combine
               to specify all metrics that shall be measured on
               a single stream.";
            reference
              "ietf-ippm-metric-registry:
              "RFC 8911: Registry for Performance Metrics";
          }
          leaf state {
            type test-session-state;
            config false;
            description
              "Indicates the TWAMP-Test session state, state -- an accepted
               request or an indication of an error.";
            reference
              "Section 3.5 of RFC 5357.";
              "RFC 5357: A Two-Way Active Measurement Protocol
               (TWAMP), Section 3.5";
          }
          leaf sid {
            type string;
            config false;
            description
              "The SID Session Identifier (SID) allocated by the Server
               for this TWAMP-Test
               session, session and communicated back to
               the Control-Client in the SID field of the
               Accept-Session message"; message.";
            reference
              "Section 4.3 of RFC 6038.";
              "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
               Reflect Octets and Symmetrical Size
               Features, Section 4.3";
          }
        }
      }
    }
    container server {
      if-feature server; "server";
      description
        "Configuration of the TWAMP Server logical entity.";
      leaf admin-state {
        type boolean;
        default true; "true";
        description
          "Indicates whether the device is allowed to operate
           as a TWAMP Server.";
      }
      leaf server-tcp-port {
        type inet:port-number;
        default 862; "862";
        description
          "This parameter defines the well known well-known TCP port number
           that is used by TWAMP-Control.  The Server will listen
           on this port number for incoming TWAMP-Control
           connections.  Although this is defined as a fixed value
           (862) in RFC 5357, there are several realizations of
           TWAMP in the field that were implemented before this
           well-known port number was allocated.  These early
           implementations allowed the port number to be
           configured.  This parameter is therefore provided for
           backward compatibility
           backward-compatibility reasons.";
      }
      leaf servwait {
        type uint32 {
          range 1..604800; "1..604800";
        }
        units seconds; "seconds";
        default 900; "900";
        description
          "TWAMP-Control (TCP) session timeout, in seconds.
           According to Section 3.1 of RFC 5357, 5357:

           'The Server MAY discontinue any established control
           connection when no packet associated with that
           connection has been received within SERVWAIT seconds."; seconds.'";
      }
      leaf control-packet-dscp {
        type inet:dscp;
        description
          "The DSCP value to be placed in the IP header of
           TWAMP-Control (TCP) packets generated by the Server.

           Section 3.1 of RFC 5357 specifies that the server Server
           SHOULD use the DSCP value from the Control-Clients Control-Client's
           TCP SYN.  However, for practical purposes purposes, TWAMP will
           typically be implemented using a general purpose general-purpose TCP
           stack provided by the underlying operating system,
           and such a stack may not provide this information to the
           user.  Consequently, it is not always possible to
           implement the behavior described in RFC 5357 in an
           OS-portable version of TWAMP.

           The default behavior if this item is not set is to use
           the DSCP value from the Control-Clients Control-Client's TCP SYN.";
        reference
           "Section 3.1 of RFC 5357.";
          "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP),
           Section 3.1";
      }
      uses count;
      uses max-count-exponent;
      leaf modes {
        type twamp-modes;
        description
          "The bit mask of TWAMP Modes TWAMP-Modes this Server instance is
           willing to support; see the IANA TWAMP Modes 'TWAMP-Modes' Registry.";
      }
      uses key-management;
      list ctrl-connection {
        key "client-ip client-tcp-port server-ip server-tcp-port";
        config false;
        description
          "List of all incoming TWAMP-Control (TCP) connections.";
        leaf client-ip {
          type inet:ip-address;
          description
            "The IP address on the remote Control-Client device,
             which is the source IP address used in the
             TWAMP-Control (TCP) packets belonging to this control
             connection.";
        }
        leaf client-tcp-port {
          type inet:port-number;
          description
            "The source TCP port number used in the TWAMP-Control
             (TCP) packets belonging to this control connection.";
        }
        leaf server-ip {
          type inet:ip-address;
          description
            "The IP address of the local Server device, which is
             the destination IP address used in the
             TWAMP-Control (TCP) packets belonging to this control
             connection.";
        }
        leaf server-tcp-port {
          type inet:port-number;
          description
            "The destination TCP port number used in the
             TWAMP-Control (TCP) packets belonging to this
             control connection.  This will usually be the
             same value as the server-tcp-port configured
             under twamp/server.  However, in the event that
             the user re-configured reconfigured server/server-tcp-port
             after this control connection was initiated, this
             value will indicate the server-tcp-port that is
             actually in use for this control connection.";
        }
        leaf state {
          type server-ctrl-connection-state;
          description
            "Indicates the Server TWAMP-Control connection state.";
        }
        leaf control-packet-dscp {
          type inet:dscp;
          description
            "The DSCP value used in the IP header of the
             TWAMP-Control (TCP) packets sent by the Server
             for this control connection.  This will usually
             be the same value as is configured in the
             control-packet-dscp parameter under the twamp/server
             container.  However, in the event that the user
             re-configures
             reconfigures server/dscp after this control
             connection is already in progress, this read-only
             value will show the actual dscp DSCP value in use by this
             TWAMP-Control connection.";
        }
        leaf selected-mode {
          type twamp-modes;
          description
            "The Mode mode that was chosen for this TWAMP-Control
             connection as set in the Mode field of the
             Set-Up-Response message.";
        }
        leaf key-id {
          type string {
            length 1..80; "1..80";
          }
          description
            "The KeyID value that is in use by this TWAMP-Control
             connection as selected by the Control-Client.";
        }
        uses count {
          description
            "The count Count value that is in use by this TWAMP-Control
             connection.  This will usually be the same value
             as is configured under twamp/server.  However, in the
             event that the user re-configured reconfigures server/count
             after this control connection is already in progress,
             this read-only value will show the actual count that
             is in use for this TWAMP-Control connection.";
        }
        uses max-count-exponent {
          description
            "This read-only value indicates the actual max-count in
             use for this control connection. Usually  Usually, this would be
             the same value as is configured under twamp/server.";
        }
        leaf salt {
          type binary {
            length 16; "16";
          }
          description
            "A parameter used in deriving a key from a
             shared secret secret, as described in Section 3.1 of RFC 4656.
             It is communicated to the Control-Client as part of
             the Server Greeting message.";
        }
        leaf server-iv {
          type binary {
            length 16; "16";
          }
          description
            "The Server Initialization Vector
             (IV) (Server-IV)
             generated randomly by the Server.";
        }
        leaf challenge {
          type binary {
            length 16; "16";
          }
          description
            "A random sequence of octets generated by the Server.
             As described in client/token, a Challenge is used
             by the Control-Client to prove possession of a
             shared secret.";
        }
      }
    }
    container session-sender {
      if-feature session-sender; "session-sender";
      description
        "Configuration of the TWAMP Session-Sender logical entity"; entity.";
      leaf admin-state {
        type boolean;
        default true; "true";
        description
          "Indicates whether the device is allowed to operate
           as a TWAMP Session-Sender.";
      }
      list test-session{ test-session {
        key name; "name";
        description
          "List of TWAMP Session-Sender test sessions.";
        leaf name {
          type string;
          description
            "A unique name for this TWAMP-Test session to be used
             for identifying this test session by the
             Session-Sender logical entity.";
        }
        leaf ctrl-connection-name {
          type string;
          config false;
          description
            "The name of the parent TWAMP-Control connection that
             is responsible for negotiating this TWAMP-Test
             session.";
        }
        leaf fill-mode {
          type padding-fill-mode;
          default zero; "zero";
          description
            "Indicates whether the padding added to the
             TWAMP-Test (UDP) packets (1) will contain pseudo-random
             numbers, pseudorandom
             numbers or whether it (2) should consist of all zeroes, zeros, as per
             Section 4.2.1 of RFC 5357.";
        }
        leaf number-of-packets {
          type uint32;
          mandatory true;
          description
            "The overall number of TWAMP-Test (UDP) packets to be
             transmitted by the Session-Sender for this test
             session.";
        }
        choice packet-distribution {
          description
            "Indicates the distribution to be used for transmitting
             the TWAMP-Test (UDP) packets.";
          case periodic {
            leaf periodic-interval {
              type decimal64 {
                fraction-digits 5;
              }
              units seconds; "seconds";
              mandatory true;
              description
                "Indicates the time to wait (in seconds) between
                 the first bits of TWAMP-Test (UDP) packet
                 transmissions for this test session.";
              reference
                "RFC 3432: Network performance measurement with
                 periodic streams";
            }
          }
          case poisson {
            leaf lambda {
              type decimal64 {
                fraction-digits 5;
              }
              units seconds; "seconds";
              mandatory true;
              description
                "Indicates the average time interval (in seconds)
                 between packets in the Poisson distribution.
                 The packet is calculated using the reciprocal of
                 lambda and the TWAMP-Test packet size (which
                 depends on the selected Mode mode and the packet
                 padding).";
              reference
                "RFC 2330: Framework for IP Performance Metrics";
            }
            leaf max-interval {
              type decimal64 {
                fraction-digits 5;
              }
              units seconds; "seconds";
              description
                "Indicates the maximum time (in seconds)
                 between packet transmissions.";
              reference
                "RFC 7312: Advanced Stream and Sampling Framework
                 for IP Performance Metrics (IPPM)";
            }
          }
        }
        leaf state {
          type sender-session-state;
          config false;
          description
            "Indicates the Session-Sender test session state.";
        }
        uses maintenance-statistics;
      }
    }
    container session-reflector {
      if-feature session-reflector; "session-reflector";
      description
        "Configuration of the TWAMP Session-Reflector logical
         entity";
         entity.";
      leaf admin-state {
        type boolean;
        default true; "true";
        description
          "Indicates whether the device is allowed to operate
           as a TWAMP Session-Reflector.";
      }
      leaf refwait {
        type uint32 {
          range 1..604800; "1..604800";
        }
        units seconds; "seconds";
        default 900; "900";
        description
          "The Session-Reflector MAY discontinue any session that
           has been started when no packet associated with that
           session has been received for REFWAIT seconds.  As per
           Section 3.1 of RFC 5357, this timeout allows a
           Session-Reflector to free up resources in case of
           failure.";
      }
      list test-session {
        key "sender-ip sender-udp-port
             reflector-ip reflector-udp-port";
        config false;
        description
          "TWAMP Session-Reflectortest Session-Reflector test sessions.";
        leaf sid {
          type string;
          description
            "An auto-allocated identifier for this TWAMP-Test
             session that is unique within the context of this
             Server/Session-Reflector device only.  This value
             is communicated to the Control-Client that
             requested the test session in the SID field of the
             Accept-Session message.";
        }
        leaf sender-ip {
          type inet:ip-address;
          description
            "The IP address on the remote device, which is the
             source IP address used in the TWAMP-Test (UDP) packets
             belonging to this test session.";
        }
        leaf sender-udp-port {
          type dynamic-port-number;
          description
            "The source UDP port used in the TWAMP-Test packets
             belonging to this test session.";
        }
        leaf reflector-ip {
          type inet:ip-address;
          description
            "The IP address of the local Session-Reflector
             device, which is the destination IP address used
             in the TWAMP-Test (UDP) packets belonging to this test
             session.";
        }
        leaf reflector-udp-port {
          type inet:port-number {
            range "862 | 49152..65535";
          }
          description
            "The destination UDP port number used in the
             TWAMP-Test (UDP) test packets belonging to this
             test session.";
        }
        leaf parent-connection-client-ip {
          type inet:ip-address;
          description
            "The IP address on the Control-Client device, which
             is the source IP address used in the TWAMP-Control
             (TCP) packets belonging to the parent control
             connection that negotiated this test session.";
        }
        leaf parent-connection-client-tcp-port {
          type inet:port-number;
          description
            "The source TCP port number used in the TWAMP-Control
             (TCP) packets belonging to the parent control
             connection that negotiated this test session.";
        }
        leaf parent-connection-server-ip {
          type inet:ip-address;
          description
            "The IP address of the Server device, which is the
             destination IP address used in the TWAMP-Control
             (TCP) packets belonging to the parent control
             connection that negotiated this test session.";
        }
        leaf parent-connection-server-tcp-port {
          type inet:port-number;
          description
            "The destination TCP port number used in the
             TWAMP-Control (TCP) packets belonging to the parent
             control connection that negotiated this test
             session.";
        }
        leaf test-packet-dscp {
          type inet:dscp;
          description
            "The DSCP value present in the IP header of
             TWAMP-Test (UDP) packets belonging to this session.";
        }
        uses maintenance-statistics;
      }
    }
  }
}

<CODE ENDS>
]]></artwork>
        </figure>
}]]></sourcecode>

      </section>
    </section>
    <section anchor="examples" title="Data numbered="true" toc="default">
      <name>Data Model Examples"> Examples</name>
      <t>This section presents a simple but complete example examples of configuring
      all four entities in <xref target="fig:scope"/>, target="fig_scope" format="default"/>, based on the YANG
      module specified in <xref target="module"/>. target="module" format="default"/>. The example is
      examples are illustrative
      in nature, nature but aims aim to be self-contained, i.e. i.e., were it they to be executed in
      a real TWAMP implementation it implementation, they would lead to a correctly configured test
      session.
      sessions. For completeness, examples are provided for both IPv4 and
      IPv6.</t>

      <t>A more elaborated example,
      IPv6.  The examples are shown using XML
      <xref target="W3C.REC-xml-20081126"/>.</t>

      <t>More elaborate examples, which also includes include authentication
      parameters, is are provided in <xref target="AuthExample"/>.</t> target="AuthExample" format="default"/>.</t>
      <section anchor="ExampleCC" title="Control-Client"> numbered="true" toc="default">
        <name>Control-Client</name>
        <t><xref target="fig:ExampleCC"/> target="fig_ExampleCC" format="default"/> shows a configuration example for a
        Control-Client with client/admin-state enabled. In a real
        implementation following <xref target="fig:scope2"/> target="fig_scope2" format="default"/>, this would permit
        the initiation of TWAMP-Control connections and TWAMP-Test
        sessions.</t>
        <figure anchor="fig:ExampleCC"
                title="XML instance enabling Control-Client operation.">
          <artwork><![CDATA[ anchor="fig_ExampleCC">
          <name>XML Instance Enabling Control-Client Operation</name>
          <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <client>
      <admin-state>true</admin-state>
    </client>
  </twamp>
</config>

]]></artwork>
</config>]]></sourcecode>
        </figure>
        <t>The following example shows a Control-Client with two instances of
        client/ctrl-connection,
        client/ctrl-connection -- one called "RouterA" and another called
        "RouterB". Each TWAMP-Control connection is to a different Server. The
        control connection named "RouterA" has two test session requests. The
        TWAMP-Control connection named "RouterB" has no TWAMP-Test session
        requests.</t>

        <figure>
          <artwork><![CDATA[
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <client>
      <admin-state>true</admin-state>
      <ctrl-connection>
        <name>RouterA</name>
        <client-ip>203.0.113.1</client-ip>
        <server-ip>203.0.113.2</server-ip>
        <test-session-request>
          <name>Test1</name>
          <sender-ip>203.0.113.3</sender-ip>
          <sender-udp-port>54001</sender-udp-port>
          <reflector-ip>203.0.113.4</reflector-ip>
          <reflector-udp-port>50001</reflector-udp-port>
          <start-time>0</start-time>
        </test-session-request>
        <test-session-request>
          <name>Test2</name>
          <sender-ip>203.0.113.1</sender-ip>
          <sender-udp-port>54001</sender-udp-port>
          <reflector-ip>203.0.113.2</reflector-ip>
          <reflector-udp-port>50001</reflector-udp-port>
          <start-time>0</start-time>
        </test-session-request>
      </ctrl-connection>
      <ctrl-connection>
        <name>RouterB</name>
        <client-ip>203.0.113.1</client-ip>
        <server-ip>203.0.113.3</server-ip>
      </ctrl-connection>
    </client>
  </twamp>
</config>
</config>]]></sourcecode>

        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <client>
      <admin-state>true</admin-state>
      <ctrl-connection>
        <name>RouterA</name>
        <client-ip>2001:DB8:203:0:113::1</client-ip>
        <server-ip>2001:DB8:203:0:113::2</server-ip>
        <client-ip>2001:db8:203:0:113::1</client-ip>
        <server-ip>2001:db8:203:0:113::2</server-ip>
        <test-session-request>
          <name>Test1</name>
          <sender-ip>2001:DB8:203:1:113::3</sender-ip>
          <sender-ip>2001:db8:203:1:113::3</sender-ip>
          <sender-udp-port>54000</sender-udp-port>
          <reflector-ip>2001:DB8:203:1:113::4</reflector-ip>
          <reflector-ip>2001:db8:203:1:113::4</reflector-ip>
          <reflector-udp-port>55000</reflector-udp-port>
          <start-time>0</start-time>
        </test-session-request>
        <test-session-request>
          <name>Test2</name>
          <sender-ip>2001:DB8:203:0:113::1</sender-ip>
          <sender-ip>2001:db8:203:0:113::1</sender-ip>
          <sender-udp-port>54001</sender-udp-port>
          <reflector-ip>2001:DB8:203:0:113::2</reflector-ip>
          <reflector-ip>2001:db8:203:0:113::2</reflector-ip>
          <reflector-udp-port>55001</reflector-udp-port>
          <start-time>0</start-time>
        </test-session-request>
      </ctrl-connection>
      <ctrl-connection>
        <name>RouterB</name>
        <client-ip>2001:DB8:203:0:113::1</client-ip>
        <server-ip>2001:DB8:203:0:113::3</server-ip>
        <client-ip>2001:db8:203:0:113::1</client-ip>
        <server-ip>2001:db8:203:0:113::3</server-ip>
      </ctrl-connection>
    </client>
  </twamp>
</config>

]]></artwork>
        </figure>
</config>]]></sourcecode>
      </section>
      <section anchor="ExampleS" title="Server"> numbered="true" toc="default">
        <name>Server</name>
        <t><xref target="fig:ExampleS"/> target="fig_ExampleS" format="default"/> shows a configuration example for a
        Server with server/admin-state server&wj;/admin-state enabled, which permits a device
        following <xref target="fig:scope2"/> target="fig_scope2" format="default"/> to respond to TWAMP-Control
        connections and TWAMP-Test sessions.</t>
        <figure anchor="fig:ExampleS"
                title="XML instance enabling Server operation.">
          <artwork align="left"><![CDATA[ anchor="fig_ExampleS">
          <name>XML Instance Enabling Server Operation</name>
          <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <server>
      <admin-state>true</admin-state>
    </server>
  </twamp>
</config>

]]></artwork>
</config>]]></sourcecode>
        </figure>
        <t>The following example presents a Server with the TWAMP-Control
        connection corresponding to the control connection name
        (client/ctrl-connection/name)
        (client&wj;/ctrl&nbhy;connection/name) "RouterA" presented in <xref
        target="ExampleCC"/>.</t>

        <figure>
          <artwork><![CDATA[ target="ExampleCC" format="default"/>.</t>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <server>
      <admin-state>true</admin-state>
      <ctrl-connection>
        <client-ip>203.0.113.1</client-ip>
        <client-tcp-port>16341</client-tcp-port>
        <server-ip>203.0.113.2</server-ip>
        <server-tcp-port>862</server-tcp-port>
        <state>active</state>
      </ctrl-connection>
    </server>
  </twamp>
</data>
</data>]]></sourcecode>

        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <server>
      <admin-state>true</admin-state>
      <ctrl-connection>
        <client-ip>2001:DB8:203:0:113::1</client-ip>
        <client-ip>2001:db8:203:0:113::1</client-ip>
        <client-tcp-port>16341</client-tcp-port>
        <server-ip>2001:DB8:203:0:113::2</server-ip>
        <server-ip>2001:db8:203:0:113::2</server-ip>
        <server-tcp-port>862</server-tcp-port>
        <state>active</state>
      </ctrl-connection>
    </server>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
      <section anchor="ExampleSS" title="Session-Sender"> numbered="true" toc="default">
        <name>Session-Sender</name>
        <t><xref target="fig:ExampleSS"/> target="fig_ExampleSS" format="default"/> shows a configuration example for a
        Session-Sender with session-sender/admin-state enabled, which permits
        a device following <xref target="fig:scope2"/> target="fig_scope2" format="default"/> to initiate TWAMP-Test
        sessions.</t>
        <figure anchor="fig:ExampleSS"
                title="XML instance enabling anchor="fig_ExampleSS">
          <name>XML Instance Enabling Session-Sender operation.">
          <artwork align="left"><![CDATA[ Operation</name>
          <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-sender>
      <admin-state>true</admin-state>
    </session-sender>
  </twamp>
</config>

]]></artwork>
</config>]]></sourcecode>
        </figure>
        <t>The following configuration example shows a Session-Sender with the
        two TWAMP-Test sessions presented in <xref target="ExampleCC"/>.</t>

        <figure>
          <artwork><![CDATA[ target="ExampleCC" format="default"/>.</t>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-sender>
      <admin-state>true</admin-state>
      <test-session>
        <name>Test1</name>
        <ctrl-connection-name>RouterA</ctrl-connection-name>
        <number-of-packets>900</number-of-packets>
        <periodic-interval>1</periodic-interval>
      </test-session>
      <test-session>
        <name>Test2</name>
        <ctrl-connection-name>RouterA</ctrl-connection-name>
        <number-of-packets>900</number-of-packets>
        <lambda>1</lambda>
        <max-interval>2</max-interval>
      </test-session>
    </session-sender>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
      <section anchor="ExampleSR" title="Session-Reflector"> numbered="true" toc="default">
        <name>Session-Reflector</name>
        <t>This configuration example shows a Session-Reflector with
        session-reflector/admin-state
        session&nbhy;reflector/admin-state enabled, which permits a device
        following <xref target="fig:scope2"/> target="fig_scope2" format="default"/> to respond to TWAMP-Test
        sessions.</t>
        <figure anchor="fig:ExampleSR"
                title="XML instance enabling anchor="fig_ExampleSR">
          <name>XML Instance Enabling Session-Reflector operation.">
          <artwork align="left"><![CDATA[ Operation</name>
          <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-reflector>
      <admin-state>true</admin-state>
    </session-reflector>
  </twamp>
</config>

]]></artwork>
</config>]]></sourcecode>
        </figure>
        <t>The following example shows the two Session-Reflector TWAMP-Test
        sessions corresponding to the test sessions presented in <xref
        target="ExampleSS"/>.</t>

        <figure>
          <artwork><![CDATA[
[note:
        target="ExampleSS" format="default"/>.</t>

        <aside><t>Note: '\' line wrapping is for formatting only] only.</t></aside>

        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-reflector>
      <admin-state>true</admin-state>
      <test-session>
        <sender-ip>203.0.113.3</sender-ip>
        <sender-udp-port>54000</sender-udp-port>
        <reflector-ip>203.0.113.4</reflector-ip>
        <reflector-udp-port>50001</reflector-udp-port>
        <sid>1232</sid>
        <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <sent-packets>2</sent-packets>
        <rcv-packets>2</rcv-packets>
        <last-sent-seq>1</last-sent-seq>
        <last-rcv-seq>1</last-rcv-seq>
      </test-session>
      <test-session>
        <sender-ip>203.0.113.1</sender-ip>
        <sender-udp-port>54001</sender-udp-port>
        <reflector-ip>192.0.2.2</reflector-ip>
        <reflector-udp-port>50001</reflector-udp-port>
        <sid>178943</sid>
        <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <sent-packets>21</sent-packets>
        <rcv-packets>21</rcv-packets>
        <last-sent-seq>20</last-sent-seq>
        <last-rcv-seq>20</last-rcv-seq>
      </test-session>
    </session-reflector>
  </twamp>
</data>

[note:
</data>]]></sourcecode>

   <aside><t>Note: '\' line wrapping is for formatting only] only.</t></aside>

<sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-reflector>
      <admin-state>true</admin-state>
      <test-session>
        <sender-ip>203.0.113.3</sender-ip>
        <sender-udp-port>54000</sender-udp-port>
        <reflector-ip>203.0.113.4</reflector-ip>
        <reflector-udp-port>54001</reflector-udp-port>
        <sid>1232</sid>
        <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <sent-packets>2</sent-packets>
        <rcv-packets>2</rcv-packets>
        <last-sent-seq>1</last-sent-seq>
        <last-rcv-seq>1</last-rcv-seq>
      </test-session>
      <test-session>
        <sender-ip>203.0.113.1</sender-ip>
        <sender-udp-port>54001</sender-udp-port>
        <reflector-ip>192.0.2.2</reflector-ip>
        <reflector-udp-port>55001</reflector-udp-port>
        <sid>178943</sid>
        <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <sent-packets>21</sent-packets>
        <rcv-packets>21</rcv-packets>
        <last-sent-seq>20</last-sent-seq>
        <last-rcv-seq>20</last-rcv-seq>
      </test-session>
    </session-reflector>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Virtually all existing measurement systems using <xref
      target="RFC5357">TWAMP</xref> target="RFC5357" format="default">TWAMP</xref> are administered by the same network
      operator. Attacks For example, attacks on the measurement infrastructure could be launched by
      third-parties
      third parties to commandeer the packet generation capability, corrupt
      the measurements, or perform other examples of nefarious acts.</t>
<!-- Begin YANG security DNE text (Para.s 1, 2, and 3. -->
      <t>The YANG module specified in <xref target="module"/> of this document
      defines a schema for data that is designed to be accessed via network
      management protocols such as <xref target="RFC6241">NETCONF</xref> target="RFC6241" format="default">NETCONF</xref> or
      <xref target="RFC8040">RESTCONF</xref>. target="RFC8040" format="default">RESTCONF</xref>. The lowest <xref
      target="RFC6241">NETCONF</xref>
NETCONF layer is the secure transport layer, and
      the mandatory-to-implement secure transport is <xref
      target="RFC6242">Secure target="RFC6242" format="default">Secure Shell (SSH)</xref>. The lowest RESTCONF layer is
      HTTPS, and the mandatory-to-implement secure transport is <xref
      target="RFC5246">TLS</xref>.</t>
      target="RFC8446" format="default">TLS</xref>.</t>

      <t>The <xref target="RFC8341">NETCONF target="RFC8341" format="default">Network Configuration
      Access Control Module Model (NACM)</xref> provides the means to restrict access for particular
      NETCONF or RESTCONF users to a preconfigured subset of all available
      NETCONF or RESTCONF protocol operations and content.</t>

     <t>There are a number of data nodes defined in this YANG module which that are
      writeable.
     writable/creatable/deletable (i.e., config true, which is the default).
     These data nodes may be considered sensitive and or vulnerable
      to attacks in some network
     environments. Ability Write operations (e.g., edit-config) to write into these data nodes
     without proper protection can have a negative effect on network
     operations. These are the
      devices that support this feature.</t>

      <t>If subtrees and data nodes and their
     sensitivity/vulnerability:</t>
<!-- End YANG security DNE text (Para.s 1, 2, and 3. -->

     <ul spacing="normal">
     <li>If written, the 'admin-state' node can cause unintended test sessions
     to be created. If created.</li>
     <li>If the node 'number-of-packets' that 'number-of-packets', which dictates how many packets are
     sent in any particular test session session, is written with a large value, it
     can cause a test session to run longer than expected. Nodes expected.</li>
     <li>Nodes that are particularly vulnerable include several timeout values
     put in the protocol to protect against sessions that are not active but
     are consuming resources. These are the REFWAIT timeout parameter parameter, which
      determine
     determines whether to discontinue the session if no packets are received, received;
     and the nodes 'count' and 'max-count-exponent&rsquo; 'max-count-exponent', which can cause a long
     time to be spent on PBKDF2 iterations. In Password-Based Key Derivation Function 2 (PBKDF2)
     iterations.</li>
     <li>In addition, 'dscp&rsquo; a 'dscp' node marked with different DSCP markings, markings can
     cause the test traffic on the network to be skewed, skewed and the result manipulated. Finally,
     manipulated.</li>
     <li>Finally, nodes within
      'mode-preference-chain' 'mode-preference-chain', which specify specifies the
     'mode' and 'priority' values and indicate indicates the preferred order of use by
     an operator, can be manipulated to send unauthenticated or non-encrypted
     traffic, enabling a
      MITM attack. Limiting an on-path attack.</li>
     <li>Limiting access to these nodes will limit the ability to launch an
     attack in network environments.</t>

      <t>The &lsquo;token&rsquo; environments.</li>
     </ul>

<!-- Begin YANG security DNE text (Para. 4). -->
    <t>Some of the readable data nodes in this YANG module may be considered
    sensitive or vulnerable in some network environments. It is thus
    important to control read access (e.g., via get, get-config, or
    notification) to these data nodes. This is the subtree and data node
    and its sensitivity/vulnerability:</t>
<!-- End YANG security DNE text (Para. 4). -->

    <ul spacing="normal">
    <li>The 'token' node defined in the model, containing a concatenation of a
    Challenge, an AES Session-key used for encryption, and an HMAC-SHA1
    Session-key used for authentication, is sensitive from a privacy perspective,
    perspective and can be used to disrupt a test session. The ability to read
    the field should be limited to the administrator of the test network.</t> network.</li>
    </ul>

   <t>The TWAMP YANG data model does not define RPC operations, as detailed in
   <xref target="OperationalCommands"/>, and defers the definition of NETCONF
   RPC operations to each implementation. These RPC operations, when defined,
   may be considered sensitive or vulnerable in some network environments.
   It is thus important to control access to these operations.</t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>This document registers a numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has registered the following URI in the <xref target="RFC3688">IETF target="RFC3688" format="default">"IETF XML
      registry </xref>. Following the format in <xref target="RFC3688">IETF
      XML Registry </xref>, the following registration is requested to be
      made.</t>

      <t>URI: urn:ietf:params:xml:ns:yang:ietf-twamp</t>

      <t>Registrant Contact: The IESG.</t>

      <t>XML: N/A,
      Registry"</xref>.</t>
      <dl newline="false" spacing="compact">
       <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-twamp</dd>
       <dt>Registrant Contact:</dt><dd>The IESG.</dd>
       <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</t>

      <t>This document registers a YANG module in the YANG Module Names
      registry <xref target="RFC6020">YANG </xref>.</t>

      <t>name: ietf-twamp</t>

      <t>namespace: urn:ietf:params:xml:ns:yang:ietf-twamp</t>

      <t>prefix: twamp</t>

      <t>reference: RFC XXXX</t>
    </section>

    <section anchor="acks" title="Acknowledgements">
      <t>We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell,
      Robert Sherman, and Marius Georgescu for their thorough and constructive
      reviews, comments and text suggestions.</t>

      <t>Haoxing Shen contributed to the definition of namespace.</dd>
      </dl>
      <t>IANA has registered the following YANG module in
      <xref target="module"/>.</t>

      <t>Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG
      module and the examples in
      <xref target="AuthExample"/>.</t>

      <t>Kostas Pentikousis was partially supported by FP7 UNIFY
      (http://fp7-unify.eu), a research project partially funded by the
      European Community under the Seventh Framework Program (grant agreement
      no. 619609). The views expressed here are those of the authors only. The
      European Commission is not liable for any use that may be made of the
      information in this document.</t>
    </section>

    <section anchor="contributors" title="Contributors">
      <t>Lianshu Zheng.</t> target="RFC6020" format="default">"YANG Module Names" registry</xref>.</t>
      <dl newline="false" spacing="compact">
       <dt>Name:</dt><dd>ietf-twamp</dd>
       <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-twamp</dd>
       <dt>Prefix:</dt><dd>twamp</dd>
       <dt>Reference:</dt><dd>RFC 8913</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-ippm-port-twamp-test'?>

      <?rfc include='reference.I-D.ietf-ippm-metric-registry'?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6038.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7717.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>

<!-- draft-ietf-ippm-port-twamp-test (RFC 8545) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8545.xml"/>

<!-- draft-ietf-ippm-metric-registry (RFC 8911) -->
        <reference anchor="RFC8911" target="https://www.rfc-editor.org/info/rfc8911">
          <front>
            <title>Registry for Performance Metrics</title>
            <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
              <organization/>
            </author>
            <author fullname="Benoit Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <author fullname="Phil Eardley" initials="P." surname="Eardley">
              <organization/>
            </author>
            <author fullname="Al Morton" initials="A." surname="Morton">
              <organization/>
            </author>
            <author fullname="Aamer Akhter" initials="A." surname="Akhter">
              <organization/>
            </author>
            <date month="November" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8911"/>
          <seriesInfo name="DOI" value="10.17487/RFC8911"/>
      </reference>

        <reference anchor="UML">
          <front>
            <title>Information technology - Open Distributed Processing -
          Unified Modeling Language</title> Language (UML) Version 1.4.2</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date month="April" year="2005"/>
          </front>
          <seriesInfo name="ISO/IEC" value="19501:2005"/>
          <seriesInfo name="OMG-UML" value="VER 1.3"/>
        </reference>

     <reference anchor='W3C.REC-xml-20081126'
         target='https://www.w3.org/TR/2008/REC-xml-20081126'>
     <front>
     <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
     <author initials='T.' surname='Bray' fullname='Tim Bray'>
         <organization />
     </author>
     <author initials='J.' surname='Paoli' fullname='Jean Paoli'>
         <organization />
     </author>
     <author initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg-McQueen'>
         <organization />
     </author>
     <author initials='E.' surname='Maler' fullname='Eve Maler'>
         <organization />
     </author>
     <author initials='F.' surname='Yergeau' fullname='Francois Yergeau'>
         <organization />
     </author>
     <date month='November' year='2008' />
     </front>
     <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126"/>
     </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2330'?>

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.RFC.8342'?>
    <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5618.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5938.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7312.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8018.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>

        <reference anchor="NSC">
          <front>
            <title>Research directions in network service chaining</title>

          <author>
            <organization>John, W., Pentikousis, K., et al.</organization>
            <author fullname="Wolfgang John" initials="W." surname="John">
              <organization/>
            </author>
            <author fullname="Konstantinos Pentikousis" initials="K." surname="Pentikousis">
              <organization/>
            </author>
            <author fullname="George Agapiou" initials="G." surname="Agapiou">
              <organization/>
            </author>
            <author fullname="Eduardo Jacob" initials="E." surname="Jacob">
              <organization/>
            </author>
            <author fullname="Mario Kind" initials="M." surname="Kind">
              <organization/>
            </author>
            <author fullname="Antonio Manzalini" initials="A." surname="Manzalini">
              <organization/>
            </author>
            <author fullname="Fulvio Risso" initials="F." surname="Risso">
              <organization/>
            </author>
            <author fullname="Dimitri Staessens" initials="D." surname="Staessens">
              <organization/>
            </author>
            <author fullname="Rebecca Steinert" initials="R." surname="Steinert">
              <organization/>
            </author>
            <author fullname="Catalin Meirosu" initials="C." surname="Meirosu">
              <organization/>
            </author>
            <date month="November" year="2013"/>
          </front>
          <seriesInfo name="Proc. name="DOI" value="10.1109/SDN4FNS.2013.6702549"/>
          <refcontent>2013 IEEE SDN for Future Networks and Services
          (SDN4FNS), Trento, Italy"
                    value="IEEE"/> Italy</refcontent>
        </reference>
       <reference anchor="PERF-METRICS"
          target="https://www.iana.org/assignments/performance-metrics">
         <front>
         <title>Performance Metrics</title>
         <author><organization>IANA</organization></author>
         <date/>
         </front>
         </reference>
      </references>
    </references>
    <section anchor="AuthExample" title="Detailed numbered="true" toc="default">
      <name>Detailed Data Model Examples"> Examples</name>
      <t>This appendix extends the example examples presented in <xref
      target="examples"/> target="examples" format="default"/> by configuring more fields fields, such as authentication
      parameters, DSCP values values, and so on.</t>

      <section title="Control-Client">
        <figure>
          <artwork><![CDATA[ numbered="true" toc="default">
        <name>Control-Client</name>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <client>
      <admin-state>true</admin-state>
      <mode-preference-chain>
        <priority>0</priority>
        <mode>authenticated</mode>
      </mode-preference-chain>
      <mode-preference-chain>
        <priority>1</priority>
        <mode>unauthenticated</mode>
      </mode-preference-chain>
      <key-chain>
        <key-id>KeyClient1ToRouterA</key-id>
        <secret-key>c2VjcmV0MQ==</secret-key>
      </key-chain>
      <key-chain>
        <key-id>KeyForRouterB</key-id>
        <secret-key>c2VjcmV0Mg0K</secret-key>
      </key-chain>
      <ctrl-connection>
        <name>RouterA</name>
        <client-ip>203.0.113.1</client-ip>
        <server-ip>203.0.113.2</server-ip>
        <control-packet-dscp>32</control-packet-dscp>
        <key-id>KeyClient1ToRouterA</key-id>
        <test-session-request>
          <name>Test1</name>
          <sender-ip>203.0.113.3</sender-ip>
          <sender-udp-port>54000</sender-udp-port>
          <reflector-ip>203.0.113.4</reflector-ip>
          <reflector-udp-port>55000</reflector-udp-port>
          <padding-length>64</padding-length>
          <start-time>0</start-time>
        </test-session-request>
        <test-session-request>
          <name>Test2</name>
          <sender-ip>203.0.113.1</sender-ip>
          <sender-udp-port>54001</sender-udp-port>
          <reflector-ip>203.0.113.2</reflector-ip>
          <reflector-udp-port>55001</reflector-udp-port>
          <padding-length>128</padding-length>
          <start-time>0</start-time>
        </test-session-request>
      </ctrl-connection>
    </client>
  </twamp>
</data>
</data>]]></sourcecode>

        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <client>
      <admin-state>true</admin-state>
      <mode-preference-chain>
        <priority>0</priority>
        <mode>authenticated</mode>
      </mode-preference-chain>
      <mode-preference-chain>
        <priority>1</priority>
        <mode>unauthenticated</mode>
      </mode-preference-chain>
      <key-chain>
        <key-id>KeyClient1ToRouterA</key-id>
        <secret-key>c2VjcmV0MQ==</secret-key>
      </key-chain>
      <key-chain>
        <key-id>KeyForRouterB</key-id>
        <secret-key>c2VjcmV0Mg0K</secret-key>
      </key-chain>
      <ctrl-connection>
        <name>RouterA</name>
        <client-ip>2001:DB8:203:0:113::1</client-ip>
        <server-ip>2001:DB8:203:0:113::2</server-ip>
        <client-ip>2001:db8:203:0:113::1</client-ip>
        <server-ip>2001:db8:203:0:113::2</server-ip>
        <control-packet-dscp>32</control-packet-dscp>
        <key-id>KeyClient1ToRouterA</key-id>
        <test-session-request>
          <name>Test1</name>
          <sender-ip>2001:DB8:10:1:1::1</sender-ip>
          <sender-ip>2001:db8:10:1:1::1</sender-ip>
          <sender-udp-port>54000</sender-udp-port>
          <reflector-ip>2001:DB8:10:1:1::2</reflector-ip>
          <reflector-ip>2001:db8:10:1:1::2</reflector-ip>
          <reflector-udp-port>55000</reflector-udp-port>
          <padding-length>64</padding-length>
          <start-time>0</start-time>
        </test-session-request>
        <test-session-request>
          <name>Test2</name>
          <sender-ip>2001:DB8:203:0:113::1</sender-ip>
          <sender-ip>2001:db8:203:0:113::1</sender-ip>
          <sender-udp-port>54001</sender-udp-port>
          <reflector-ip>2001:DB8:203:0:113::2</reflector-ip>
          <reflector-ip>2001:db8:203:0:113::2</reflector-ip>
          <reflector-udp-port>55001</reflector-udp-port>
          <padding-length>128</padding-length>
          <start-time>0</start-time>
        </test-session-request>
      </ctrl-connection>
    </client>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
      <section title="Server">
        <figure>
          <artwork><![CDATA[ numbered="true" toc="default">
        <name>Server</name>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <server>
      <admin-state>true</admin-state>
      <servwait>1800</servwait>
      <control-packet-dscp>32</control-packet-dscp>
      <modes>authenticated unauthenticated</modes>
      <count>15</count>
      <key-chain>
        <key-id>KeyClient1ToRouterA</key-id>
        <secret-key>c2VjcmV0MQ==</secret-key>
      </key-chain>
      <key-chain>
        <key-id>KeyClient10ToRouterA</key-id>
        <secret-key>c2VjcmV0MTANCg==</secret-key>
      </key-chain>
      <ctrl-connection>
        <client-ip>203.0.113.1</client-ip>
        <client-tcp-port>16341</client-tcp-port>
        <server-ip>203.0.113.2</server-ip>
        <server-tcp-port>862</server-tcp-port>
        <control-packet-dscp>32</control-packet-dscp>
        <selected-mode>unauthenticated</selected-mode>
        <key-id>KeyClient1ToRouterA</key-id>
        <count>15</count>
      </ctrl-connection>
    </server>
  </twamp>
</data>
</data>]]></sourcecode>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <server>
      <admin-state>true</admin-state>
      <servwait>1800</servwait>
      <control-packet-dscp>32</control-packet-dscp>
      <modes>authenticated unauthenticated</modes>
      <count>15</count>
      <key-chain>
        <key-id>KeyClient1ToRouterA</key-id>
        <secret-key>c2VjcmV0MQ==</secret-key>
      </key-chain>
      <key-chain>
        <key-id>KeyClient10ToRouterA</key-id>
        <secret-key>c2VjcmV0MTANCg==</secret-key>
      </key-chain>
      <ctrl-connection>
        <client-ip>2001:DB8:203:0:113::1</client-ip>
        <client-ip>2001:db8:203:0:113::1</client-ip>
        <client-tcp-port>16341</client-tcp-port>
        <server-ip>2001:DB8:203:0:113::2</server-ip>
        <server-ip>2001:db8:203:0:113::2</server-ip>
        <server-tcp-port>862</server-tcp-port>
        <control-packet-dscp>32</control-packet-dscp>
        <selected-mode>unauthenticated</selected-mode>
        <key-id>KeyClient1ToRouterA</key-id>
        <count>15</count>
      </ctrl-connection>
    </server>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
      <section title="Session-Sender">
        <figure>
          <artwork><![CDATA[ numbered="true" toc="default">
        <name>Session-Sender</name>
        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-sender>
      <admin-state>true</admin-state>
      <test-session>
        <name>Test1</name>
        <ctrl-connection-name>RouterA</ctrl-connection-name>
        <fill-mode>zero</fill-mode>
        <number-of-packets>900</number-of-packets>
        <periodic-interval>1</periodic-interval>
        <sent-packets>2</sent-packets>
        <rcv-packets>2</rcv-packets>
        <last-sent-seq>1</last-sent-seq>
        <last-rcv-seq>1</last-rcv-seq>
      </test-session>
      <test-session>
        <name>Test2</name>
        <ctrl-connection-name>RouterA</ctrl-connection-name>
        <fill-mode>random</fill-mode>
        <number-of-packets>900</number-of-packets>
        <lambda>1</lambda>
        <max-interval>2</max-interval>
        <sent-packets>21</sent-packets>
        <rcv-packets>21</rcv-packets>
        <last-sent-seq>20</last-sent-seq>
        <last-rcv-seq>20</last-rcv-seq>
      </test-session>
    </session-sender>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
      <section title="Session-Reflector">
        <figure>
          <artwork><![CDATA[
[note: numbered="true" toc="default">
        <name>Session-Reflector</name>

        <aside><t>Note: '\' line wrapping is for formatting only] only.</t></aside>

        <sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-reflector>
      <admin-state>true</admin-state>
      <test-session>
        <sender-ip>203.0.113.3</sender-ip>
        <sender-udp-port>54000</sender-udp-port>
        <reflector-ip>203.0.113.4</reflector-ip>
        <reflector-udp-port>55000</reflector-udp-port>
        <sid>1232</sid>
        <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <test-packet-dscp>32</test-packet-dscp>
        <sent-packets>2</sent-packets>
        <rcv-packets>2</rcv-packets>
        <last-sent-seq>1</last-sent-seq>
        <last-rcv-seq>1</last-rcv-seq>
      </test-session>
      <test-session>
        <sender-ip>203.0.113.1</sender-ip>
        <sender-udp-port>54001</sender-udp-port>
        <reflector-ip>192.0.2.2</reflector-ip>
        <reflector-udp-port>55001</reflector-udp-port>
        <sid>178943</sid>
        <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <test-packet-dscp>32</test-packet-dscp>
        <sent-packets>21</sent-packets>
        <rcv-packets>21</rcv-packets>
        <last-sent-seq>20</last-sent-seq>
        <last-rcv-seq>20</last-rcv-seq>
      </test-session>
    </session-reflector>
  </twamp>
</data>

[note:
</data>]]></sourcecode>

<aside><t>Note: '\' line wrapping is for formatting only] only.</t></aside>

<sourcecode type="xml"><![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-reflector>
      <admin-state>true</admin-state>
      <test-session>
        <sender-ip>2001:DB8:10:1:1::1</sender-ip>
        <sender-ip>2001:db8:10:1:1::1</sender-ip>
        <sender-udp-port>54000</sender-udp-port>
        <reflector-ip>2001:DB8:10:1:1::2</reflector-ip>
        <reflector-ip>2001:db8:10:1:1::2</reflector-ip>
        <reflector-udp-port>55000</reflector-udp-port>
        <sid>1232</sid>
        <parent-connection-client-ip>2001:DB8:203:0:113::1</parent-c\
        <parent-connection-client-ip>2001:db8:203:0:113::1</parent-c\
onnection-client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>2001:DB8:203:0:113::2</parent-c\
        <parent-connection-server-ip>2001:db8:203:0:113::2</parent-c\
onnection-server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <test-packet-dscp>32</test-packet-dscp>
        <sent-packets>2</sent-packets>
        <rcv-packets>2</rcv-packets>
        <last-sent-seq>1</last-sent-seq>
        <last-rcv-seq>1</last-rcv-seq>
      </test-session>
      <test-session>
        <sender-ip>2001:DB8:203:0:113::1</sender-ip>
        <sender-ip>2001:db8:203:0:113::1</sender-ip>
        <sender-udp-port>54001</sender-udp-port>
        <reflector-ip>2001:DB8:192:68::2</reflector-ip>
        <reflector-ip>2001:db8:192:68::2</reflector-ip>
        <reflector-udp-port>55001</reflector-udp-port>
        <sid>178943</sid>
        <parent-connection-client-ip>2001:DB8:203:0:113::1</parent-c\
        <parent-connection-client-ip>2001:db8:203:0:113::1</parent-c\
onnection-client-ip>
        <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port>
        <parent-connection-server-ip>2001:DB8:203:0:113::2</parent-c\
        <parent-connection-server-ip>2001:db8:203:0:113::2</parent-c\
onnection-server-ip>
        <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port>
        <test-packet-dscp>32</test-packet-dscp>
        <sent-packets>21</sent-packets>
        <rcv-packets>21</rcv-packets>
        <last-sent-seq>20</last-sent-seq>
        <last-rcv-seq>20</last-rcv-seq>
      </test-session>
    </session-reflector>
  </twamp>
</data>

]]></artwork>
        </figure>
</data>]]></sourcecode>
      </section>
    </section>
    <section anchor="OperationalCommands" title="TWAMP numbered="true" toc="default">
      <name>TWAMP Operational Commands"> Commands</name>
      <t>TWAMP operational commands could be performed programmatically or
      manually, e.g. e.g., using a command-line interface (CLI).</t>
      <t>With respect to programmability, YANG can be used to define NETCONF
      Remote Procedure Calls (RPC), therefore (RPCs); therefore, it would be, in principle,
      possible to define TWAMP RPC operations for actions such as starting or
      stopping control connections or connections, test sessions sessions, or groups of sessions;
      retrieving results; clearing stored results, results; and so on.</t>
      <t>However, <xref target="RFC5357">TWAMP target="RFC5357" format="default">TWAMP </xref> does not attempt to
      describe such operational actions. Refer also to <xref target="scope"/> target="scope" format="default"/>
      and the unlabeled links in <xref target="fig:scope"/>. target="fig_scope" format="default"/>. In actual
      deployments
      deployments, different TWAMP implementations may support different sets
      of operational commands, with different restrictions. Therefore, this
      document considers it the responsibility of the individual
      implementation to define its corresponding data model for TWAMP operational commands
      data model.</t> commands.</t>
    </section>
    <section anchor="acks" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>We thank <contact fullname="Fred Baker"/>, <contact fullname="Kevin D'Souza"/>, <contact fullname="Gregory Mirsky"/>, <contact fullname="Brian Trammell"/>,
      <contact fullname="Robert Sherman"/>, and <contact fullname="Marius Georgescu"/> for their thorough and constructive
      reviews, comments, and text suggestions.</t>
      <t><contact fullname="Haoxing Shen"/> contributed to the definition of the YANG module in
      <xref target="module" format="default"/>.</t>
      <t><contact fullname="Jan Lindblad"/> and <contact fullname="Ladislav Lhotka"/> did thorough reviews of the YANG
      module and the examples in <xref target="AuthExample"
      format="default"/>.</t>
      <t><contact fullname="Kostas Pentikousis"/> was partially supported by FP7 UNIFY, a research project partially funded by the
      European Community under the Seventh Framework Program (grant agreement
      no. 619609). The views expressed here are those of the authors only. The
      European Commission is not liable for any use that may be made of the
      information in this document.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="default">
      <name>Contributors</name>
      <t><contact fullname="Lianshu Zheng"/></t>
    </section>
  </back>
</rfc>