rfc8913.original   rfc8913.txt 
IPPM WG R. Civil Internet Engineering Task Force (IETF) R. Civil
Internet-Draft Ciena Corporation Request for Comments: 8913 Ciena Corporation
Intended status: Standards Track A. Morton Category: Standards Track A. Morton
Expires: January 3, 2019 AT&T Labs ISSN: 2070-1721 AT&T Labs
R. Rahman R. Rahman
Cisco Systems
M. Jethanandani M. Jethanandani
Xoriant Corporation Xoriant Corporation
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Detecon
July 2, 2018 November 2021
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) YANG Data Model
draft-ietf-ippm-twamp-yang-13
Abstract Abstract
This document specifies a data model for client and server This document specifies a data model for client and server
implementations of the Two-Way Active Measurement Protocol (TWAMP). implementations of the Two-Way Active Measurement Protocol (TWAMP).
The document defines the TWAMP data model through Unified Modeling This document defines the TWAMP data model through Unified Modeling
Language (UML) class diagrams and formally specifies it using a NDMA- Language (UML) class diagrams and formally specifies it using the
compliant YANG model. YANG data modeling language (RFC 7950). The data model is compliant
with the Network Management Datastore Architecture (NMDA).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 3, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8913.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology
1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 1.3. Document Organization
2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4 2. Scope, Model, and Applicability
3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 3. Data Model Overview
3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6 3.1. Control-Client
3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Server
3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7 3.3. Session-Sender
3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 8 3.4. Session-Reflector
4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Parameters
4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8 4.1. Control-Client
4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Server
4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 13 4.3. Session-Sender
4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 14 4.4. Session-Reflector
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Data Model
5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 5.1. YANG Tree Diagram
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. YANG Module
6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48 6. Data Model Examples
6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48 6.1. Control-Client
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. Server
6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51 6.3. Session-Sender
6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52 6.4. Session-Reflector
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 8. IANA Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 9. References
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 9.1. Normative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.2. Informative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 57 Appendix A. Detailed Data Model Examples
11.2. Informative References . . . . . . . . . . . . . . . . . 59 A.1. Control-Client
Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60 A.2. Server
A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60 A.3. Session-Sender
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.4. Session-Reflector
A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64 Appendix B. TWAMP Operational Commands
A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 65 Acknowledgments
Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses
1. Introduction 1. Introduction
The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to
measure network performance parameters such as latency, bandwidth, measure network performance parameters such as latency, bandwidth,
and packet loss by sending probe packets and measuring their and packet loss by sending probe packets and measuring their
experience in the network. To date, TWAMP implementations do not experience in the network. To date, TWAMP implementations do not
come with a standard management framework, and, as such, implementers come with a standard management framework, and, as such, implementers
have no choice except to provide a proprietary mechanism. This have no choice except to provide a proprietary mechanism. This
document addresses this gap by defining the model using UML [UML] document addresses this gap by defining the model using Unified
class diagrams, and formally specifying a NMDA-complaint [RFC8342] Modeling Language (UML) class diagrams [UML] and formally specifying
TWAMP data model using YANG 1.1 [RFC7950]. a TWAMP data model that is compliant with the Network Management
Datastore Architecture (NMDA) [RFC8342], using YANG 1.1 [RFC7950].
1.1. Motivation 1.1. Motivation
In current TWAMP deployments the lack of a standardized data model In current TWAMP deployments, the lack of a standardized data model
limits the flexibility to dynamically instantiate TWAMP-based limits the flexibility to dynamically instantiate TWAMP-based
measurements across equipment from different vendors. In large, measurements across equipment from different vendors. In large,
virtualized, and dynamically instantiated infrastructures where virtualized, and dynamically instantiated infrastructures where
network functions are placed according to orchestration algorithms, network functions are placed according to orchestration algorithms,
proprietary mechanisms for managing TWAMP measurements pose severe proprietary mechanisms for managing TWAMP measurements pose severe
limitations with respect to programmability. limitations with respect to programmability.
Two major trends call for standardizing TWAMP management aspects. Two major trends call for standardizing TWAMP management aspects.
First, it is expected that in the coming years large-scale and multi- First, it is expected that in the coming years large-scale and multi-
vendor TWAMP deployments will become the norm. From an operations vendor TWAMP deployments will become the norm. From an operations
perspective, using several vendor-specific TWAMP configuration perspective, using several vendor-specific TWAMP configuration
mechanisms when one standard mechanism could provide an alternative mechanisms when one standard mechanism could provide an alternative
is expensive and inefficient. Second, the increasingly software- is expensive and inefficient. Second, the increasingly software-
defined and virtualized nature of network infrastructures, based on defined and virtualized nature of network infrastructures, based on
dynamic service chains [NSC] and programmable control and management dynamic service chains [NSC] and programmable control and management
planes Software-Defined Networking (SDN): Layers and Architecture planes [RFC7426], requires a well-defined data model for TWAMP
Terminology [RFC7426] requires a well-defined data model for TWAMP
implementations. This document defines such a TWAMP data model and implementations. This document defines such a TWAMP data model and
specifies it formally using the YANG 1.1 [RFC7950] data modeling specifies it formally using the YANG 1.1 data modeling language
language. [RFC7950].
Note to RFC Editor:
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.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Document Organization 1.3. Document Organization
The rest of this document is organized as follows. Section 2 The rest of this document is organized as follows. Section 2
presents the scope and applicability of this document. Section 3 presents the scope and applicability of this document. Section 3
provides a high-level overview of the TWAMP data model. Section 4 provides a high-level overview of the TWAMP data model. Section 4
details the configuration parameters of the data model and Section 5 details the configuration parameters of the data model, and Section 5
specifies in YANG the TWAMP data model. Section 6 lists illustrative specifies in YANG the TWAMP data model. Section 6 lists illustrative
examples which conform to the YANG data model specified in this examples that conform to the YANG data model specified in this
document. Appendix A elaborates these examples further. document. Appendix A elaborates these examples further.
2. Scope, Model, and Applicability 2. Scope, Model, and Applicability
The purpose of this document is the specification of a vendor- The purpose of this document is the specification of a vendor-
independent data model for TWAMP implementations. independent data model for TWAMP implementations.
Figure 1 illustrates a redrawn version of the TWAMP logical model Figure 1 illustrates a redrawn version of the TWAMP logical model
found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated
with pointers to the UML [UML] diagrams provided in this document and with pointers to the UML diagrams [UML] provided in this document and
associated with the data model of the four logical entities in a associated with the data model of the four logical entities in a
TWAMP deployment, namely the TWAMP Control-Client, Server, Session- TWAMP deployment, namely the TWAMP Control-Client, Server, Session-
Sender and Session-Reflector. A UML [UML] Notation Guide is Sender, and Session-Reflector. A UML Notation Guide is available in
available in Section 5 of the said document. Section 5 of UML [UML].
As per TWAMP [RFC5357], unlabeled links in Figure 1 are left As per TWAMP [RFC5357], unlabeled links in Figure 1 are left
unspecified and may be proprietary protocols. unspecified and may be proprietary protocols.
[Fig. 3] [Fig. 4] (Figure 3) (Figure 4)
+----------------+ +--------+ +----------------+ +--------+
| Control-Client | <-- TWAMP-Control --> | Server | | Control-Client | <-- TWAMP-Control --> | Server |
+----------------+ +--------+ +----------------+ +--------+
^ ^ ^ ^
| | | |
V V V V
+----------------+ +-------------------+ +----------------+ +-------------------+
| Session-Sender | <-- TWAMP-Test --> | Session-Reflector | | Session-Sender | <-- TWAMP-Test --> | Session-Reflector |
+----------------+ +-------------------+ +----------------+ +-------------------+
[Fig. 5] [Fig. 6] (Figure 5) (Figure 6)
Figure 1: Annotated TWAMP logical model Figure 1: Annotated TWAMP Logical Model
As per TWAMP [RFC5357], a TWAMP implementation may follow a As per TWAMP [RFC5357], a TWAMP implementation may follow a
simplified logical model, in which the same node acts both as simplified logical model, in which the same node acts as both
Control-Client and Session-Sender, while another node acts at the Control-Client and Session-Sender, while another node acts at the
same time as TWAMP Server and Session-Reflector. Figure 2 same time as both TWAMP Server and Session-Reflector. Figure 2
illustrates this simplified logical model and indicates the illustrates this simplified logical model and indicates the
interaction between the TWAMP configuration client and server using, interaction between the TWAMP configuration client and server using,
for instance, NETCONF [RFC6241] or RESTCONF [RFC8040]. for instance, NETCONF [RFC6241] or RESTCONF [RFC8040].
o-------------------o o-------------------o o-------------------o o-------------------o
| Config client | | Config client | | Config client | | Config client |
o-------------------o o-------------------o o-------------------o o-------------------o
|| || || ||
NETCONF || RESTCONF NETCONF || RESTCONF NETCONF || RESTCONF NETCONF || RESTCONF
|| || || ||
o-------------------o o-------------------o o-------------------o o-------------------o
| Config server | | Config server | | Config server | | Config server |
| [Fig. 3, 5] | | [Fig. 4, 6] | | (Figures 3 and 5) | | (Figures 4 and 6) |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| Control-Client | <-- TWAMP-Control --> | Server | | Control-Client | <-- TWAMP-Control --> | Server |
| | | | | | | |
| Session-Sender | <-- TWAMP-Test --> | Session-Reflector | | Session-Sender | <-- TWAMP-Test --> | Session-Reflector |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
Figure 2: Simplified TWAMP model and protocols Figure 2: Simplified TWAMP Model and Protocols
The data model defined in this document is orthogonal to the specific The data model defined in this document is orthogonal to the specific
protocol used between the Config client and Config server to protocol used between the Config client and Config server to
communicate the TWAMP configuration parameters. communicate the TWAMP configuration parameters.
Operational actions such as how TWAMP-Test sessions are started and Operational actions such as how TWAMP-Test sessions are started and
stopped, how performance measurement results are retrieved, or how stopped, how performance measurement results are retrieved, or how
stored results are cleared, and so on, are not addressed by the stored results are cleared, and so on, are not addressed by the
configuration model defined in this document. As noted above, such configuration model defined in this document. As noted above, such
operational actions are not part of the TWAMP specification TWAMP operational actions are not part of the TWAMP specification [RFC5357]
[RFC5357] and hence are out of scope of this document. See also and hence are out of scope for this document. See also Appendix B.
Appendix B. In addition, for operational state, current work in In addition, for operational state, the information provided in the
Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], can Performance Metrics Registry [RFC8911] and [PERF-METRICS] can be used
be used to develop an independent model for the performance metrics to develop an independent model for the Performance Metrics that need
that need to be captured and retrieved. to be captured and retrieved.
3. Data Model Overview 3. Data Model Overview
The TWAMP data model includes four categories of configuration items. The TWAMP data model includes four categories of configuration items.
First, global configuration items relate to parameters that are set First, global configuration items relate to parameters that are set
on a per device level. For example, the administrative status of the on a per-device level. For example, the administrative status of the
device with respect to whether it allows TWAMP sessions and, if so, device with respect to whether it allows TWAMP sessions and, if so,
in what capacity (e.g. Control-Client, Server or both), is a typical in what capacity (e.g., Control-Client, Server, or both) is a typical
instance of a global configuration item. instance of a global configuration item.
A second category includes attributes that can be configured on a per A second category includes attributes that can be configured on a
TWAMP-Control connection basis, such as the Server IP address. per-TWAMP-Control-connection basis, such as the Server IP address.
A third category includes attributes related to per TWAMP-Test A third category includes attributes related to per-TWAMP-Test-
session attributes, for instance setting different values in the session attributes -- for instance, setting different values in the
Differentiated Services Code Point (DSCP) field. Differentiated Services Code Point (DSCP) field.
Finally, the data model includes attributes that relate to the Finally, the data model includes attributes that relate to the
operational state of the TWAMP implementation. operational state of the TWAMP implementation.
As the TWAMP data model is described in the remaining sections of As the TWAMP data model is described in the remaining sections of
this document, readers should keep in mind the functional entity this document, readers should keep in mind the functional entity
grouping illustrated in Figure 1. grouping illustrated in Figure 1.
3.1. Control-Client 3.1. Control-Client
A TWAMP Control-Client has an administrative status field set at the A TWAMP Control-Client has an administrative status field set at the
device level that indicates whether the node is enabled to function device level that indicates whether the node is enabled to function
as such. as such.
Each TWAMP Control-Client is associated with zero or more TWAMP- Each TWAMP Control-Client is associated with zero or more
Control connections. The main configuration parameters of each TWAMP-Control connections. The main configuration parameters of each
control connection are: control connection are:
o A name which can be used to uniquely identify at the Control- * A name that can be used to uniquely identify at the Control-Client
Client a particular control connection. This name is necessary a particular control connection. This name is necessary for
for programmability reasons because at the time of creation of a programmability reasons because at the time of creation of a
TWAMP-Control connection not all IP and TCP port number TWAMP-Control connection not all IP and TCP port number
information needed to uniquely identify the connection is information needed to uniquely identify the connection is
available. available.
o The IP address of the interface the Control-Client will use for * The IP address of the interface the Control-Client will use for
connections. connections.
o The IP address of the remote TWAMP Server. * The IP address of the remote TWAMP Server.
o Authentication and encryption attributes such as KeyID, Token and * Authentication and encryption attributes such as KeyID, Token, and
the Client Initialization Vector (Client-IV); see also Section 3.1 the Control-Client Initialization Vector (Client-IV); see also
in OWAMP [RFC4656] and Randomness Requirements for Security Section 3.1 of "A One-way Active Measurement Protocol (OWAMP)"
[RFC4086]. [RFC4656] and "Randomness Requirements for Security" [RFC4086].
Each TWAMP-Control connection, in turn, is associated with zero or Each TWAMP-Control connection, in turn, is associated with zero or
more TWAMP-Test sessions. For each test session, the following more TWAMP-Test sessions. For each test session, the following
configuration items should be noted: configuration items should be noted:
o The test session name uniquely identifies a particular test * The test session name, which uniquely identifies a particular test
session at the Control-Client and Session-Sender. Similar to the session at the Control-Client and Session-Sender. Similar to the
control connections above, this unique test session name is needed control connections mentioned above, this unique test session name
because at the time of creation of a TWAMP-Test session, for is needed because at the time of creation of a TWAMP-Test session,
example, the source UDP port number is not known to uniquely for example, the source UDP port number is not known to uniquely
identify the test session. identify the test session.
o The IP address and UDP port number of the Session-Sender on the * The IP address and UDP port number of the Session-Sender on the
path under test by TWAMP. path under test by TWAMP.
o The IP address and UDP port number of the Session-Reflector on * The IP address and UDP port number of the Session-Reflector on
said path. said path.
o Information pertaining to the test packet stream, such as the test * Information pertaining to the test packet stream, such as the test
starting time, which performance metric is to be used, as defined starting time; which Performance Metric is to be used, as defined
in Registry for Performance Metrics in "Registry for Performance Metrics" [RFC8911]; or whether the
[I-D.ietf-ippm-metric-registry], or whether the test should be test should be repeated.
repeated.
3.2. Server 3.2. Server
Each TWAMP Server has an administrative status field set at the Each TWAMP Server has an administrative status field set at the
device level to indicate whether the node is enabled to function as a device level to indicate whether the node is enabled to function as a
TWAMP Server. TWAMP Server.
Each Server is associated with zero or more TWAMP-Control Each Server is associated with zero or more TWAMP-Control
connections. Each control connection is uniquely identified by the connections. Each control connection is uniquely identified by the
4-tuple {Control-Client IP address, Control-Client TCP port number, 4-tuple {Control-Client IP address, Control-Client TCP port number,
Server IP address, Server TCP port}. Control connection configuration Server IP address, Server TCP port}. Control connection
items on a TWAMP Server are read-only. configuration items on a TWAMP Server are read-only.
3.3. Session-Sender 3.3. Session-Sender
A TWAMP Session-Sender has an administrative status field set at the A TWAMP Session-Sender has an administrative status field set at the
device level that indicates whether the node is enabled to function device level that indicates whether the node is enabled to function
as such. as such.
There is one Session-Sender instance for each TWAMP-Test session that There is one Session-Sender instance for each TWAMP-Test session that
is initiated from the sending device. Primary configuration fields is initiated from the sending device. Primary configuration fields
include: include:
o The test session name MUST be identical to the corresponding test * The test session name, which MUST be identical to the
session name on the TWAMP Control-Client (Section 3.1). corresponding test session name on the TWAMP Control-Client
(Section 3.1).
o The control connection name, which along with the test session * The control connection name, which, along with the test session
name uniquely identify the TWAMP Session-Sender instance. name, uniquely identifies the TWAMP Session-Sender instance.
o Information pertaining to the test packet stream, such as, the * Information pertaining to the test packet stream, such as the
number of test packets and the packet distribution to be employed; number of test packets and the packet distribution to be employed;
see also Network performance measurement with periodic streams see also "Network performance measurement with periodic streams"
[RFC3432]. [RFC3432].
3.4. Session-Reflector 3.4. Session-Reflector
Each TWAMP Session-Reflector has an administrative status field set Each TWAMP Session-Reflector has an administrative status field set
at the device level to indicate whether the node is enabled to at the device level to indicate whether the node is enabled to
function as such. function as such.
Each Session-Reflector is associated with zero or more TWAMP-Test Each Session-Reflector is associated with zero or more TWAMP-Test
sessions. For each test session, the REFWAIT timeout parameter, sessions. For each test session, the REFWAIT timeout parameter,
skipping to change at page 9, line 5 skipping to change at line 357
4.1. Control-Client 4.1. Control-Client
The client container (see Figure 3) holds items that are related to The client container (see Figure 3) holds items that are related to
the configuration of the TWAMP Control-Client logical entity (recall the configuration of the TWAMP Control-Client logical entity (recall
Figure 1). Figure 1).
The client container includes an administrative configuration The client container includes an administrative configuration
parameter (client/admin-state) that indicates whether the device is parameter (client/admin-state) that indicates whether the device is
allowed to initiate TWAMP-Control connections. allowed to initiate TWAMP-Control connections.
+-------------+ +-------------+
| client | | client |
+-------------+ 1..* +-----------------------+ +-------------+ 1..* +-----------------------+
| admin-state |<>----------------------| mode-preference-chain | | admin-state |<>----------------------| mode-preference-chain |
| | +-----------------------+ | | +-----------------------+
| | 1..* +------------+ | priority | | | 1..* +------------+ | priority |
| |<>-----| key-chain | | mode | | |<>-----| key-chain | | mode |
+-------------+ +------------+ +-----------------------+ +-------------+ +------------+ +-----------------------+
^ | key-id | ^ | key-id |
V | secret-key | V | secret-key |
| +------------+ | +------------+
| 0..* | 0..*
+------------------------+ +------------------------+
| ctrl-connection | | ctrl-connection |
+------------------------+ +------------------------+
| name | | name |
| client-ip | | client-ip |
| server-ip | | server-ip |
| server-tcp-port | 0..* +----------------------+ | server-tcp-port | 0..* +----------------------+
| control-packet-dscp |<>-------| test-session-request | | control-packet-dscp |<>-------| test-session-request |
| key-id | +----------------------+ | key-id | +----------------------+
| max-count | | name | | max-count | | name |
| client-tcp-port {ro} | | sender-ip | | client-tcp-port {ro} | | sender-ip |
| server-start-time {ro} | | sender-udp-port | | server-start-time {ro} | | sender-udp-port |
| state {ro} | | reflector-ip | | state {ro} | | reflector-ip |
| selected-mode {ro} | | reflector-udp-port | | selected-mode {ro} | | reflector-udp-port |
| token {ro} | | timeout | | token {ro} | | timeout |
| client-iv {ro} | | padding-length | | client-iv {ro} | | padding-length |
+------------------------+ | test-packet-dscp | +------------------------+ | test-packet-dscp |
| start-time | | start-time |
+-------------+ 1 | repeat | +-------------+ 1 | repeat |
| pm-reg-list |------<>| repeat-interval | | pm-reg-list |------<>| repeat-interval |
+-------------+ | state {ro} | +-------------+ | state {ro} |
| pm-index | | sid {ro} | | pm-index | | sid {ro} |
+-------------+ +----------------------+ +-------------+ +----------------------+
Figure 3: TWAMP Control-Client UML class diagram Figure 3: TWAMP Control-Client UML Class Diagram
The client container holds a list (mode-preference-chain) which The client container holds a list (mode-preference-chain) that
specifies the Mode values according to their preferred order of use specifies the mode values according to their preferred order of use
by the operator of this Control-Client, including the authentication by the operator of this Control-Client, including the authentication
and encryption Modes. Specifically, mode-preference-chain lists the and encryption modes. Specifically, mode-preference-chain lists the
mode and its corresponding priority, as a 16-bit unsigned integer. mode and its corresponding priority, expressed as a 16-bit unsigned
Values for the priority start with zero, the highest priority, and integer. Values for the priority start with zero, the highest
decreasing priority value is indicated by every increase in value by priority, and decreasing priority value is indicated by every
one. increase in value by one.
Depending on the Modes available in the Server Greeting, the Control- Depending on the modes available in the Server Greeting, the Control-
Client MUST choose the highest priority Mode from the configured Client MUST choose the highest-priority mode from the configured
mode-preference-chain list. mode-preference-chain list.
Note that the list of preferred Modes may set multiple bit positions Note that the list of preferred modes may set multiple bit positions
independently, such as when referring to the extended TWAMP features independently, such as when referring to the extended TWAMP features
in Mixed Security Mode for TWAMP [RFC5618], Individual Session in "Mixed Security Mode for the Two-Way Active Measurement Protocol
Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and (TWAMP)" [RFC5618], "Individual Session Control Feature for the
Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret Two-Way Active Measurement Protocol (TWAMP)" [RFC5938], "Two-Way
Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical
determine an acceptable Mode, or when the bit combinations do not Size Features" [RFC6038], and "IKEv2-Derived Shared Secret Key for
make sense, e.g., both authenticated and unauthenticated bit are set, the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active
it MUST respond with zero Mode bits set in the Set-up Response Measurement Protocol (TWAMP)" [RFC7717]. If the Control-Client
message, indicating it will not continue with the control connection. cannot determine an acceptable mode, or when the bit combinations do
not make sense, e.g., authenticated and unauthenticated bits are both
set, it MUST respond with zero Mode bits set in the Set-Up-Response
message, indicating that it will not continue with the control
connection.
In addition, the client container holds a list named key-chain which In addition, the client container holds a list named "key-chain",
relates key-id with the respective secret-key. Both the Server and which relates key-id with the respective secret-key. Both the Server
the Control-Client use the same mappings from key-id to secret-key and the Control-Client use the same mappings from key-id to
(in Figure 3); in order for this to work properly, key-id must be secret-key (in Figure 3); in order for this to work properly, key-id
unique across all systems in the administrative domain. The Server, must be unique across all systems in the administrative domain. The
being prepared to conduct sessions with more than one Control-Client, Server, being prepared to conduct sessions with more than one
uses key-id to choose the appropriate secret-key; a Control-Client Control-Client, uses key-id to choose the appropriate secret-key; a
would typically have different secret keys for different Servers. Control-Client would typically have different secret keys for
The secret-key is the shared secret, of type binary and the length different Servers. The secret-key is the shared secret, of type
SHOULD contain at least 128 bits of entropy. The key-id and secret- "binary", and the length SHOULD contain at least 128 bits of entropy.
key encoding SHOULD follow Section 9.8 of YANG [RFC7950]. The The key-id and secret-key encoding SHOULD follow Section 9.8 of YANG
derived key length (dkLen in PKCS #5: Password-Based Cryptography [RFC7950]. The derived key length (dkLen as defined in "PKCS #5:
Specification Version 2.1 [RFC8018]) MUST be 16 octets for the AES Password-Based Cryptography Specification Version 2.1" [RFC8018])
Session-key used for encryption and 32 octets for the HMAC-SHA1 MUST be 16 octets for the AES Session-key used for encryption and
Session-key used for authentication; see also Section 6.10 of OWAMP 32 octets for the HMAC-SHA1 Session-key used for authentication; see
[RFC4656]. also Section 6.10 of OWAMP [RFC4656].
Each client container also holds a list of control connections, where Each client container also holds a list of control connections, where
each item in the list describes a TWAMP control connection initiated each item in the list describes a TWAMP-Control connection initiated
by this Control-Client. There SHALL be one ctrl-connection per by this Control-Client. There SHALL be one ctrl-connection per
TWAMP-Control (TCP) connection that is to be initiated from this TWAMP-Control (TCP) connection that is to be initiated from this
device. device.
In turn, each ctrl-connection holds a test-session-request list. In turn, each ctrl-connection holds a test-session-request list.
Each test-session-request holds information associated with the Each test-session-request holds information associated with the
Control-Client for this test session. This includes information Control-Client for this test session. This includes information
associated with the Request-TW-Session/Accept-Session message associated with the Request-TW-Session/Accept-Session message
exchange (see Section 3.5 of TWAMP [RFC5357]). exchange (see Section 3.5 of TWAMP [RFC5357]).
There SHALL be one instance of test-session-request for each TWAMP- There SHALL be one instance of test-session-request for each
Test session that is to be negotiated by this TWAMP-Control TWAMP-Test session that is to be negotiated by this TWAMP-Control
connection via a Request-TW-Session/Accept-Session exchange. connection via a Request-TW-Session/Accept-Session exchange.
The Control-Client is also responsible for scheduling TWAMP-Test The Control-Client is also responsible for scheduling TWAMP-Test
sessions, therefore test-session-request holds information related to sessions; therefore, test-session-request holds information related
these actions (e.g. pm-index, repeat-interval). to these actions (e.g., pm-index, repeat-interval).
4.2. Server 4.2. Server
The server container (see Figure 4) holds items that are related to The server container (see Figure 4) holds items that are related to
the configuration of the TWAMP Server logical entity (recall the configuration of the TWAMP Server logical entity (recall
Figure 1). Figure 1).
The server container includes an administrative configuration The server container includes an administrative configuration
parameter (server/admin-state) that indicates whether the device is parameter (server/admin-state) that indicates whether the device is
allowed to receive TWAMP-Control connections. allowed to receive TWAMP-Control connections.
A device operating in the Server role cannot configure attributes on A device operating in the Server Role cannot configure attributes on
a per TWAMP-Control connection basis, as it has no foreknowledge of a per-TWAMP-Control-connection basis, as it has no foreknowledge of
the incoming TWAMP-Control connections to be received. Consequently, the incoming TWAMP-Control connections to be received. Consequently,
any parameter that the Server might want to apply to an incoming any parameter that the Server might want to apply to an incoming
control connection must be configured at the overall Server level and control connection must be configured at the overall Server level and
applied to all incoming TWAMP-Control connections. applied to all incoming TWAMP-Control connections.
+---------------------+ +---------------------+
| server | | server |
+---------------------+ +---------------------+
| admin-state | 1..* +------------+ | admin-state | 1..* +------------+
| server-tcp-port |<>------| key-chain | | server-tcp-port |<>------| key-chain |
| servwait | +------------+ | servwait | +------------+
| control-packet-dscp | | key-id | | control-packet-dscp | | key-id |
| count | | secret-key | | count | | secret-key |
| max-count | +------------+ | max-count | +------------+
| modes | | modes |
| | 0..* +--------------------------+ | | 0..* +--------------------------+
| |<>------| ctrl-connection | | |<>------| ctrl-connection |
+---------------------+ +--------------------------+ +---------------------+ +--------------------------+
| client-ip {ro} | | client-ip {ro} |
| client-tcp-port {ro} | | client-tcp-port {ro} |
| server-ip {ro} | | server-ip {ro} |
| server-tcp-port {ro} | | server-tcp-port {ro} |
| state {ro} | | state {ro} |
| control-packet-dscp {ro} | | control-packet-dscp {ro} |
| selected-mode {ro} | | selected-mode {ro} |
| key-id {ro} | | key-id {ro} |
| count {ro} | | count {ro} |
| max-count {ro} | | max-count {ro} |
| salt {ro} | | salt {ro} |
| server-iv {ro} | | server-iv {ro} |
| challenge {ro} | | challenge {ro} |
+--------------------------+ +--------------------------+
Figure 4: TWAMP Server UML class diagram Figure 4: TWAMP Server UML Class Diagram
Each server container holds a list named key-chain which relates key- Each server container holds a list named "key-chain", which relates
id with the respective secret-key. As mentioned in Section 4.1, both key-id with the respective secret-key. As mentioned in Section 4.1,
the Server and the Control-Client use the same mapping from key-id to both the Server and the Control-Client use the same mapping from
shared secret-key; in order for this to work properly, key-id must be key-id to the shared secret-key; in order for this to work properly,
unique across all the systems in the administrative domain. The key-id must be unique across all the systems in the administrative
Server, being prepared to conduct sessions with more than one domain. The Server, being prepared to conduct sessions with more
Control-Client, uses key-id to choose the appropriate secret-key; a than one Control-Client, uses key-id to choose the appropriate
Control-Client would typically have different secret keys for secret-key; a Control-Client would typically have different secret
different Servers. The key-id tells the Server which shared secret- keys for different Servers. key-id tells the Server which shared
key the Control-Client wishes to use for authentication or secret-key the Control-Client wishes to use for authentication or
encryption. encryption.
Each incoming control connection active on the Server is represented Each incoming control connection active on the Server is represented
by a ctrl-connection. There SHALL be one ctrl-connection per by a ctrl-connection. There SHALL be one ctrl-connection per
incoming TWAMP-Control (TCP) connection that is received and active incoming TWAMP-Control (TCP) connection that is received and active
on the Server. Each ctrl-connection can be uniquely identified by on the Server. Each ctrl-connection can be uniquely identified by
the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}. the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-
All items in the ctrl-connection list are read-only. port}. All items in the ctrl-connection list are read-only.
4.3. Session-Sender 4.3. Session-Sender
The session-sender container, illustrated in Figure 5, holds items The session-sender container, illustrated in Figure 5, holds items
that are related to the configuration of the TWAMP Session-Sender that are related to the configuration of the TWAMP Session-Sender
logical entity. logical entity.
The session-sender container includes an administrative parameter The session-sender container includes an administrative parameter
(session-sender/admin-state) that controls whether the device is (session-sender/admin-state) that controls whether the device is
allowed to initiate TWAMP-Test sessions. allowed to initiate TWAMP-Test sessions.
+----------------+ +----------------+
| session-sender | | session-sender |
+----------------+ 0..* +---------------------------+ +----------------+ 0..* +---------------------------+
| admin-state |<>-----| test-session | | admin-state |<>-----| test-session |
+----------------+ +---------------------------+ +----------------+ +---------------------------+
| name | | name |
| ctrl-connection-name {ro} | | ctrl-connection-name {ro} |
| fill-mode | | fill-mode |
| number-of-packets | | number-of-packets |
| state {ro} | | state {ro} |
| sent-packets {ro} | | sent-packets {ro} |
| rcv-packets {ro} | | rcv-packets {ro} |
| last-sent-seq {ro} | | last-sent-seq {ro} |
| last-rcv-seq {ro} | | last-rcv-seq {ro} |
+---------------------------+ +---------------------------+
^ ^
V V
| 1 | 1
+---------------------+ +---------------------+
| packet-distribution | | packet-distribution |
+---------------------+ +---------------------+
| periodic / poisson | | periodic / poisson |
+---------------------+ +---------------------+
| | | |
+-------------------+ | +-------------------+ |
| periodic-interval | | | periodic-interval | |
+-------------------+ | +-------------------+ |
| |
+--------------+ +--------------+
| lambda | | lambda |
| max-interval | | max-interval |
+--------------+ +--------------+
Figure 5: TWAMP Session-Sender UML class diagram Figure 5: TWAMP Session-Sender UML Class Diagram
Each TWAMP-Test session initiated by the Session-Sender will be Each TWAMP-Test session initiated by the Session-Sender will be
represented by an instance of a test-session object. There SHALL be represented by an instance of a test-session object. There SHALL be
one instance of test-session for each TWAMP-Test session for which one instance of test-session for each TWAMP-Test session for which
packets are being sent. packets are being sent.
4.4. Session-Reflector 4.4. Session-Reflector
The session-reflector container, illustrated in Figure 6, holds items The session-reflector container, illustrated in Figure 6, holds items
that are related to the configuration of the TWAMP Session-Reflector that are related to the configuration of the TWAMP Session-Reflector
logical entity. logical entity.
The session-reflector container includes an administrative parameter The session-reflector container includes an administrative parameter
(session-reflector/admin-state) that controls whether the device is (session-reflector/admin-state) that controls whether the device is
allowed to respond to incoming TWAMP-Test sessions. allowed to respond to incoming TWAMP-Test sessions.
A device operating in the Session-Reflector role cannot configure A device operating in the Session-Reflector Role cannot configure
attributes on a per-session basis, as it has no foreknowledge of what attributes on a per-session basis, as it has no foreknowledge of what
incoming sessions it will receive. As such, any parameter that the incoming sessions it will receive. As such, any parameter that the
Session-Reflector might want to apply to an incoming TWAMP-Test Session-Reflector might want to apply to an incoming TWAMP-Test
session must be configured at the overall Session-Reflector level and session must be configured at the overall Session-Reflector level and
are applied to all incoming sessions. applied to all incoming sessions.
+-------------------+ +-------------------+
| session-reflector | | session-reflector |
+-------------------+ +-------------------+
| admin-state | | admin-state |
| refwait | | refwait |
+-------------------+ +-------------------+
^ ^
V V
| |
| 0..* | 0..*
+----------------------------------------+ +----------------------------------------+
| test-session | | test-session |
+----------------------------------------+ +----------------------------------------+
| sid {ro} | | sid {ro} |
| sender-ip {ro} | | sender-ip {ro} |
| sender-udp-port {ro} | | sender-udp-port {ro} |
| reflector-ip {ro} | | reflector-ip {ro} |
| reflector-udp-port {ro} | | reflector-udp-port {ro} |
| parent-connection-client-ip {ro} | | parent-connection-client-ip {ro} |
| parent-connection-client-tcp-port {ro} | | parent-connection-client-tcp-port {ro} |
| parent-connection-server-ip {ro} | | parent-connection-server-ip {ro} |
| parent-connection-server-tcp-port {ro} | | parent-connection-server-tcp-port {ro} |
| test-packet-dscp {ro} | | test-packet-dscp {ro} |
| sent-packets {ro} | | sent-packets {ro} |
| rcv-packets {ro} | | rcv-packets {ro} |
| last-sent-seq {ro} | | last-sent-seq {ro} |
| last-rcv-seq {ro} | | last-rcv-seq {ro} |
+----------------------------------------+ +----------------------------------------+
Figure 6: TWAMP Session-Reflector UML class diagram Figure 6: TWAMP Session-Reflector UML Class Diagram
Each incoming TWAMP-Test session that is active on the Session- Each incoming TWAMP-Test session that is active on the Session-
Reflector SHALL be represented by an instance of a test-session Reflector SHALL be represented by an instance of a test-session
object. All items in the test-session object are read-only. object. All items in the test-session object are read-only.
Instances of test-session are indexed by a session identifier (sid). Instances of test-session are indexed by a Session Identifier (SID)
This value is auto-allocated by the TWAMP Server as test session (the sid parameter). This SID value is auto-allocated by the TWAMP
requests are received, and communicated back to the Control-Client in Server as test session requests are received and is communicated back
the SID field of the Accept-Session message; see Section 4.3 of TWAMP to the Control-Client in the SID field of the Accept-Session message;
Reflect Octets and Symmetrical Size Features [RFC6038]. see Section 4.3 of "Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features" [RFC6038].
When attempting to retrieve operational data for active test sessions When attempting to retrieve operational data for active test sessions
from a Session-Reflector device, the user will not know what sessions from a Session-Reflector device, the user will not know what sessions
are currently active on that device, or what SIDs have been auto- are currently active on that device or what SIDs have been
allocated for these test sessions. If the user has network access to auto-allocated for these test sessions. If the user has network
the Control-Client device, then it is possible to read the data for access to the Control-Client device, then it is possible to read the
this session under client/ctrl-connection/test-session-request/sid data for this session under client/ctrl-connection/test-session-
and obtain the SID (see Figure 3). The user may then use this SID request/sid and obtain the SID (see Figure 3). The user may then use
value as an index to retrieve an individual session-reflector/test- this SID value as an index to retrieve an individual session-
session instance on the Session-Reflector device. reflector/test-session instance on the Session-Reflector device.
If the user has no network access to the Control-Client device, then 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 the only option is to retrieve all test-session instances from the
Session-Reflector device, and then pick out specific test-session Session-Reflector device and then pick out specific test-session
instances of interest to the user. This could be problematic if a instances of interest to the user. This could be problematic if a
large number of test sessions are currently active on that device. large number of test sessions are currently active on that device.
Each Session-Reflector TWAMP-Test session contains the following Each Session-Reflector TWAMP-Test session contains the following
4-tuple: {parent-connection-client-ip, parent-connection-client-tcp- 4-tuple: {parent-connection-client-ip, parent-connection-client-tcp-
port, parent-connection-server-ip, parent-connection-server-tcp- port, parent-connection-server-ip, parent-connection-server-tcp-
port}. This 4-tuple MUST correspond to the equivalent 4-tuple port}. This 4-tuple MUST correspond to the equivalent 4-tuple
{client-ip, client-tcp-port, server-ip, server-tcp-port} in server/ {client-ip, client-tcp-port, server-ip, server-tcp-port} in
ctrl-connection. This 4-tuple allows the user to trace back from the server/ctrl-connection. This 4-tuple allows the user to trace back
TWAMP-Test session to the (parent) TWAMP-Control connection that from the TWAMP-Test session to the (parent) TWAMP-Control connection
negotiated this test session. that negotiated this test session.
5. Data Model 5. Data Model
This section formally specifies the TWAMP data model using YANG. This section formally specifies the TWAMP data model using YANG.
5.1. YANG Tree Diagram 5.1. YANG Tree Diagram
This section presents a simplified graphical representation of the This section presents a simplified graphical representation of the
TWAMP data model using a YANG tree diagram. Readers should keep in 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 mind that the limit of 72 characters per line forces us to introduce
artificial line breaks in some tree diagram nodes. Tree diagrams artificial line breaks in some tree diagram nodes. Tree diagrams
used in this document follow the notation defined in YANG Tree used in this document follow the notation defined in "YANG Tree
Diagrams [RFC8340]. Diagrams" [RFC8340].
module: ietf-twamp Please note that the backslash ('\') character near the end of the
diagram is used for formatting purposes only (i.e.,
"reflector-udp-port]" should be treated as part of the same line as
"[sender-ip sender-udp-port reflector-ip").
module: ietf-twamp
+--rw twamp +--rw twamp
+--rw client {control-client}? +--rw client {control-client}?
| +--rw admin-state? boolean | +--rw admin-state? boolean
| +--rw mode-preference-chain* [priority] | +--rw mode-preference-chain* [priority]
| | +--rw priority uint16 | | +--rw priority uint16
| | +--rw mode? twamp-modes | | +--rw mode? twamp-modes
| +--rw key-chain* [key-id] | +--rw key-chain* [key-id]
| | +--rw key-id string | | +--rw key-id string
| | +--rw secret-key? binary | | +--rw secret-key? binary
| +--rw ctrl-connection* [name] | +--rw ctrl-connection* [name]
skipping to change at page 18, line 29 skipping to change at line 768
| | +--rw max-interval? decimal64 | | +--rw max-interval? decimal64
| +--ro state? sender-session-state | +--ro state? sender-session-state
| +--ro sent-packets? uint32 | +--ro sent-packets? uint32
| +--ro rcv-packets? uint32 | +--ro rcv-packets? uint32
| +--ro last-sent-seq? uint32 | +--ro last-sent-seq? uint32
| +--ro last-rcv-seq? uint32 | +--ro last-rcv-seq? uint32
+--rw session-reflector {session-reflector}? +--rw session-reflector {session-reflector}?
+--rw admin-state? boolean +--rw admin-state? boolean
+--rw refwait? uint32 +--rw refwait? uint32
+--ro test-session* +--ro test-session*
[sender-ip sender-udp-port reflector-ip reflector-udp [sender-ip sender-udp-port reflector-ip \
-port] reflector-udp-port]
+--ro sid? string +--ro sid? string
+--ro sender-ip inet:ip-address +--ro sender-ip inet:ip-address
+--ro sender-udp-port +--ro sender-udp-port
| dynamic-port-number | dynamic-port-number
+--ro reflector-ip inet:ip-address +--ro reflector-ip inet:ip-address
+--ro reflector-udp-port inet:port-numbe +--ro reflector-udp-port inet:port-number
r +--ro parent-connection-client-ip? inet:ip-address
+--ro parent-connection-client-ip? inet:ip-address +--ro parent-connection-client-tcp-port? inet:port-number
+--ro parent-connection-client-tcp-port? inet:port-numbe +--ro parent-connection-server-ip? inet:ip-address
r +--ro parent-connection-server-tcp-port? inet:port-number
+--ro parent-connection-server-ip? inet:ip-address +--ro test-packet-dscp? inet:dscp
+--ro parent-connection-server-tcp-port? inet:port-numbe +--ro sent-packets? uint32
r +--ro rcv-packets? uint32
+--ro test-packet-dscp? inet:dscp +--ro last-sent-seq? uint32
+--ro sent-packets? uint32 +--ro last-rcv-seq? uint32
+--ro rcv-packets? uint32
+--ro last-sent-seq? uint32
+--ro last-rcv-seq? uint32
Figure 7: YANG Tree Diagram. Figure 7: YANG Tree Diagram
5.2. YANG Module 5.2. YANG Module
This section presents the YANG module for the TWAMP data model This section presents the YANG module for the TWAMP data model
defined in this document. The module imports definitions from Common defined in this document. The module imports definitions from
YANG Data Types [RFC6991], and references NTPv4 Specification "Common YANG Data Types" [RFC6991] and references "Framework for IP
[RFC5905], Framework for IP Performance Metrics [RFC2330], Randomness Performance Metrics" [RFC2330], "Network performance measurement with
Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP periodic streams" [RFC3432], "A One-way Active Measurement Protocol
[RFC5357], More Features for TWAMP [RFC5618], Individual Session (OWAMP)" [RFC4656], "A Two-Way Active Measurement Protocol (TWAMP)"
Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size [RFC5357], "Mixed Security Mode for the Two-Way Active Measurement
Features [RFC6038], Advances Stream and Sampling Framework [RFC7312], Protocol (TWAMP)" [RFC5618], "Network Time Protocol Version 4:
IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717], and Protocol and Algorithms Specification" [RFC5905], "Individual Session
OWAMP and TWAMP Well-Known Port Assignments Control Feature for the Two-Way Active Measurement Protocol (TWAMP)"
[I-D.ietf-ippm-port-twamp-test]. [RFC5938], "Two-Way Active Measurement Protocol (TWAMP) Reflect
Octets and Symmetrical Size Features" [RFC6038], "Advanced Stream and
<CODE BEGINS> file "ietf-twamp@2018-07-02.yang" Sampling Framework for IP Performance Metrics (IPPM)" [RFC7312],
"IKEv2-Derived Shared Secret Key for the One-Way Active Measurement
Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"
[RFC7717], "Well-Known Port Assignments for the One-Way Active
Measurement Protocol (OWAMP) and the Two-Way Active Measurement
Protocol (TWAMP)" [RFC8545], and "Registry for Performance Metrics"
[RFC8911].
<CODE BEGINS> file "ietf-twamp@2021-11-17.yang"
module ietf-twamp { module ietf-twamp {
yang-version 1.1; yang-version 1.1;
namespace urn:ietf:params:xml:ns:yang:ietf-twamp; namespace "urn:ietf:params:xml:ns:yang:ietf-twamp";
prefix ietf-twamp; prefix ietf-twamp;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Types."; "RFC 6991: Common YANG Data Types";
} }
organization organization
"IETF IPPM (IP Performance Metrics) Working Group"; "IETF IPPM (IP Performance Metrics) Working Group";
contact contact
"WG Web: http://tools.ietf.org/wg/ippm/ "WG Web: <https://datatracker.ietf.org/wg/ippm/documents/>
WG List: ippm@ietf.org WG List: <mailto:ippm@ietf.org>
Editor: Ruth Civil Editor: Ruth Civil
gcivil@ciena.com <mailto:ruthcivil@gmail.com>
Editor: Al Morton Editor: Al Morton
acmorton@att.com <mailto:acmorton@att.com>
Editor: Reshad Rehman
rrahman@cisco.com Editor: Reshad Rahman
<mailto:reshad@yahoo.com>
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
Editor: Kostas Pentikousis
k.pentikousis@travelping.com";
Editor: Kostas Pentikousis
<mailto:kostas.pentikousis@detecon.com>";
description description
"This YANG module specifies a vendor-independent data "This YANG module specifies a vendor-independent data
model for the Two-Way Active Measurement Protocol (TWAMP). model for the Two-Way Active Measurement Protocol (TWAMP).
The data model covers four TWAMP logical entities, namely, The data model defines four TWAMP logical entities, namely
Control-Client, Server, Session-Sender, and Session-Reflector, Control-Client, Server, Session-Sender, and Session-Reflector,
as illustrated in the annotated TWAMP logical model (Fig. 1 as illustrated in the annotated TWAMP logical model (Figure 1
of RFC XXXX). of RFC 8913).
This YANG module uses features to indicate which of the four This YANG module uses features to indicate which of the four
logical entities are supported by a TWAMP implementation. logical entities are supported by a TWAMP implementation.
Copyright (c) 2018 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
the document authors. All rights reserved. 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) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD the license terms contained in, the Simplified BSD License set
License set forth in Section 4.c of the IETF Trust's Legal forth in Section 4.c of the IETF Trust's Legal Provisions
Provisions Relating to IETF Documents 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; see This version of this YANG module is part of RFC 8913; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2018-07-02 { revision 2021-11-17 {
description description
"Initial Revision. "Initial revision.
Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and
draft-ietf-ippm-metric-registry";
References RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717,
and RFC 8911.";
reference reference
"RFC XXXX: TWAMP YANG Data Model."; "RFC 8913: Two-Way Active Measurement Protocol (TWAMP) YANG
Data Model";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef twamp-modes { typedef twamp-modes {
type bits { type bits {
bit unauthenticated { bit unauthenticated {
position 0; position 0;
description description
"Unauthenticated mode, in which no encryption or "Unauthenticated mode, in which no encryption or
authentication is applied in TWAMP-Control and authentication is applied in TWAMP-Control and
TWAMP-Test. KeyID, Token, and Client-IV are not used in TWAMP-Test. KeyID, Token, and Client-IV are not used in
the Set-Up-Response message. See Section 3.1 of the Set-Up-Response message. See Section 3.1 of
RFC 4656."; RFC 4656.";
reference reference
"RFC 4656: A One-way Active Measurement Protocol "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
(OWAMP)"; Section 3.1";
} }
bit authenticated { bit authenticated {
position 1; position 1;
description description
"Authenticated mode, in which the Control-Client and "Authenticated mode, in which the Control-Client and
Server possess a shared secret thus prohibiting Server possess a shared secret, thus prohibiting
'theft of service'. As per Section 6 of RFC 4656, 'theft of service'. As per Section 6 of RFC 4656,
in 'authenticated mode, the timestamp is in the clear in 'authenticated mode, the timestamp is in the clear
and is not protected cryptographically in any way, and is not protected cryptographically in any way,
while the rest of the message has the same protection while the rest of the message has the same protection
as in encrypted mode. This mode allows one to trade off as in encrypted mode. This mode allows one to trade off
cryptographic protection against accuracy of cryptographic protection against accuracy of
timestamps.'"; timestamps.'";
reference reference
"RFC 4656: A One-way Active Measurement Protocol "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
(OWAMP)"; Section 6";
} }
bit encrypted { bit encrypted {
position 2; position 2;
description description
"Encrypted mode 'makes it impossible to alter "Encrypted mode 'makes it impossible to alter
timestamps undetectably' [Section 6 of RFC 4656]. timestamps undetectably' (Section 1 of RFC 4656).
See also Section 4 of RFC 7717."; See also Section 4 of RFC 7717.";
reference reference
"RFC 4656: A One-way Active Measurement Protocol "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 { bit unauth-test-encrypt-control {
position 3; position 3;
description description
"When using the Mixed Security Mode, the TWAMP-Test "When using the mixed security mode, the TWAMP-Test
protocol follows the Unauthenticated mode and the protocol operates in unauthenticated mode and the
TWAMP-Control protocol the Encrypted mode."; TWAMP-Control protocol operates in encrypted mode.";
reference reference
"RFC 5618: Mixed Security Mode for the Two-Way Active "RFC 5618: Mixed Security Mode for the Two-Way Active
Measurement Protocol (TWAMP)"; Measurement Protocol (TWAMP)";
} }
bit individual-session-control { bit individual-session-control {
position 4; position 4;
description description
"This mode enables individual test sessions using "This mode enables individual test sessions using
Session Identifiers."; Session Identifiers.";
reference reference
skipping to change at page 22, line 26 skipping to change at line 970
description description
"This mode indicates support for the symmetrical size "This mode indicates support for the symmetrical size
sender test packet format."; sender test packet format.";
reference reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP) "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features"; Reflect Octets and Symmetrical Size Features";
} }
bit IKEv2Derived { bit IKEv2Derived {
position 7; position 7;
description description
"In this mode the the shared key is derived "In this mode, the shared key is derived
from an IKEv2 security association (SA)."; from an Internet Key Exchange Protocol Version 2 (IKEv2)
security association (SA).";
reference reference
"RFC 7717: IKEv2-Derived Shared Secret Key for "RFC 7717: IKEv2-Derived Shared Secret Key for
the One-Way Active Measurement Protocol (OWAMP) the One-Way Active Measurement Protocol (OWAMP)
and Two-Way Active Measurement Protocol (TWAMP)"; and Two-Way Active Measurement Protocol (TWAMP)";
} }
} }
description description
"Specifies the configurable TWAMP-Modes supported during a "Specifies the configurable TWAMP-Modes supported during a
TWAMP-Control Connection setup between a Control-Client TWAMP-Control connection setup between a Control-Client
and a Server. Section 7 of RFC 7717 summarizes the and a Server. Section 7 of RFC 7717 summarizes the
TWAMP-Modes registry and points to their formal 'TWAMP-Modes' Registry and points to their
specification."; formal specification.";
} }
typedef control-client-connection-state { typedef control-client-connection-state {
type enumeration { type enumeration {
enum active { enum active {
description description
"Indicates an active TWAMP-Control connection to "Indicates an active TWAMP-Control connection to the
Server."; Server.";
} }
enum idle { enum idle {
description description
"Indicates an idle TWAMP-Control connection to Server."; "Indicates an idle TWAMP-Control connection to the
Server.";
} }
} }
description description
"Indicates the Control-Client TWAMP-Control connection "Indicates the Control-Client TWAMP-Control connection
state."; state.";
} }
typedef test-session-state { typedef test-session-state {
type enumeration { type enumeration {
enum accepted { enum accepted {
value 0; value 0;
skipping to change at page 24, line 4 skipping to change at line 1047
enum temp-resource-limit { enum temp-resource-limit {
value 5; value 5;
description description
"Indicates a TWAMP-Test session failure due to "Indicates a TWAMP-Test session failure due to
temporary resource limitations."; temporary resource limitations.";
} }
} }
description description
"Indicates the Control-Client TWAMP-Test session state."; "Indicates the Control-Client TWAMP-Test session state.";
} }
typedef server-ctrl-connection-state { typedef server-ctrl-connection-state {
type enumeration { type enumeration {
enum active { enum active {
description description
"Indicates an active TWAMP-Control connection "Indicates an active TWAMP-Control connection
to the Control-Client."; to the Control-Client.";
} }
enum servwait { enum servwait {
description description
"Indicates that the TWAMP-Control connection to the "Indicates that the TWAMP-Control connection to the
Control-Client is in SERVWAIT as per the definition of Control-Client is in SERVWAIT as per the definition in
Section 3.1 of RFC 5357."; Section 3.1 of RFC 5357.";
reference
"RFC 5357: A Two-Way Active Measurement Protocol (TWAMP),
Section 3.1";
} }
} }
description description
"Indicates the Server TWAMP-Control connection state."; "Indicates the Server TWAMP-Control connection state.";
} }
typedef sender-session-state { typedef sender-session-state {
type enumeration { type enumeration {
enum active { enum active {
description description
skipping to change at page 24, line 45 skipping to change at line 1092
} }
typedef padding-fill-mode { typedef padding-fill-mode {
type enumeration { type enumeration {
enum zero { enum zero {
description description
"TWAMP-Test packets are padded with all zeros."; "TWAMP-Test packets are padded with all zeros.";
} }
enum random { enum random {
description description
"TWAMP-Test packets are padded with pseudo-random "TWAMP-Test packets are padded with pseudorandom
numbers."; numbers.";
} }
} }
description description
"Indicates what type of packet padding is used in the "Indicates what type of packet padding is used in the
TWAMP-Test packets."; TWAMP-Test packets.";
} }
typedef dynamic-port-number { typedef dynamic-port-number {
type inet:port-number { type inet:port-number {
range 49152..65535; range "49152..65535";
} }
description "Dynamic range for port numbers."; description
"Dynamic range for port numbers.";
} }
/* /*
* Features * Features
*/ */
feature control-client { feature control-client {
description description
"Indicates that the device supports configuration of the "Indicates that the device supports configuration of the
TWAMP Control-Client logical entity."; TWAMP Control-Client logical entity.";
skipping to change at page 25, line 48 skipping to change at line 1143
"Indicates that the device supports configuration of the "Indicates that the device supports configuration of the
TWAMP Session-Reflector logical entity."; TWAMP Session-Reflector logical entity.";
} }
/* /*
* Reusable node groups * Reusable node groups
*/ */
grouping key-management { grouping key-management {
list key-chain { list key-chain {
key key-id; key "key-id";
leaf key-id { leaf key-id {
type string { type string {
length 1..80; length "1..80";
} }
description description
"KeyID used for a TWAMP-Control connection. As per "KeyID used for a TWAMP-Control connection. As per
Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to 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 80 octets in length' and is used to select which 'shared
shared secret the [Control-Client] wishes to use to secret the client' (Control-Client) 'wishes to use to
authenticate or encrypt'."; authenticate or encrypt'.";
} }
leaf secret-key { leaf secret-key {
type binary; type binary;
description
"The secret key corresponding to the KeyID for this
TWAMP-Control connection.";
}
description description
"Relates KeyIDs with their respective secret keys "The secret key corresponding to the KeyID for this
in a TWAMP-Control connection."; TWAMP-Control connection.";
}
description
"Relates KeyIDs with their respective secret keys
in a TWAMP-Control connection.";
} }
description description
"Used by the Control-Client and Server for TWAMP-Control "Used by the Control-Client and Server for TWAMP-Control
key management."; key management.";
} }
grouping maintenance-statistics { grouping maintenance-statistics {
leaf sent-packets { leaf sent-packets {
type uint32; type uint32;
config false; config false;
description description
"Indicates the number of packets sent."; "Indicates the number of packets sent.";
} }
leaf rcv-packets { leaf rcv-packets {
type uint32; type uint32;
config false; config false;
description description
"Indicates the number of packets received."; "Indicates the number of packets received.";
} }
leaf last-sent-seq { leaf last-sent-seq {
type uint32; type uint32;
config false; config false;
description description
"Indicates the last sent sequence number."; "Indicates the last sent sequence number.";
} }
leaf last-rcv-seq { leaf last-rcv-seq {
type uint32; type uint32;
config false; config false;
description description
"Indicates the last received sequence number."; "Indicates the last received sequence number.";
} }
description description
"Used for TWAMP-Test maintenance statistics."; "Used for TWAMP-Test maintenance statistics.";
} }
grouping count { grouping count {
leaf count { leaf count {
type uint8 { type uint8 {
range "10..31"; range "10..31";
} }
default 15; default "15";
description description
"Parameter communicated to the Control-Client as part of "Parameter communicated to the Control-Client as part of
the Server Greeting message and used for deriving a key the Server Greeting message and used for deriving a key
from a shared secret as per Section 3.1 of RFC 4656: 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 MUST be a power of 2 and at least 1024. It is configured
by providing said power. For example, configuring 20 here by providing said power. For example, configuring 20 here
means count 2^20 = 1048576. The default is 15, means count 2^20 = 1048576. The default is 15,
meaning 2^15 = 32768."; meaning 2^15 = 32768.";
} }
description description
"Reusable data structure for count, which is used both in the "Reusable data structure for count, which is used in both the
Server and the Control-Client."; Server and the Control-Client.";
} }
grouping max-count-exponent { grouping max-count-exponent {
leaf max-count-exponent { leaf max-count-exponent {
type uint8 { type uint8 {
range 10..31; range "10..31";
} }
default 20; default "20";
description description
"This parameter limits the maximum Count value, which MUST "This parameter limits the maximum Count value, which MUST
be a power of 2 and at least 1024 as per RFC 5357. It is be a power of 2 and at least 1024 as per RFC 5357. It is
configured by providing said power. For example, configured by providing said power. For example,
configuring 10 here means max count 2^10 = 1024. configuring 10 here means max count 2^10 = 1024.
The default is 20, meaning 2^20 = 1048576. The default is 20, meaning 2^20 = 1048576.
A TWAMP Server uses this configured value in the A TWAMP Server uses this configured value in the
Server-Greeting message sent to the Control-Client. Server Greeting message sent to the Control-Client.
A TWAMP Control-Client uses this configured value to A TWAMP Control-Client uses this configured value to
prevent denial-of-service (DOS) attacks by closing the prevent denial-of-service (DoS) attacks by closing the
control connection to the Server if it 'receives a control connection to the Server if it 'receives a
Server-Greeting message with Count greater that its Server-Greeting message with Count greater that [sic] its
maximum configured value', as per Section 6 of RFC 5357. maximum configured value', as per Section 6 of RFC 5357.
Further, note that according to Section 6 of RFC 5357: Further, note that according to Section 6 of RFC 5357:
'If an attacking system sets the maximum value in 'If an attacking system set the maximum value in Count
Count (2**32), then the system under attack would stall (2**32), then the system under attack would stall for a
for a significant period of time while it attempts to significant period of time while it attempts to generate
generate keys. keys. Therefore, TWAMP-compliant systems SHOULD have a
configuration control to limit the maximum Count value.
The default maximum Count value SHOULD be 32768.'
TWAMP-compliant systems SHOULD have a configuration In the case of this document, the default max-count-exponent
control to limit the maximum count value. The default value SHOULD be 15, which corresponds to a maximum value of
max-count-exponent value SHOULD be 15 which corresponds 2**15 or 32768.
to a maximum value of 2**15 or 32768.'
RFC 5357 does not qualify 'significant period' in terms of RFC 5357 does not qualify 'significant period' in terms of
time, but it is clear that this depends on the processing time, but it is clear that this depends on the processing
capacity available and operators need to pay attention to capacity available, and operators need to pay attention to
this security consideration."; this security consideration.";
} }
description description
"Reusable data structure for max-count which is used both at "Reusable data structure for max-count that is used in both
the Control-Client and the Server containers."; the client (Control-Client) container and the server
container.";
} }
/* /*
* Configuration data nodes * Configuration data nodes
*/ */
container twamp { container twamp {
description description
"TWAMP logical entity configuration grouping of four models "TWAMP logical entity configuration grouping of four models
which correspond to the four TWAMP logical entities that correspond to the four TWAMP logical entities
Control-Client, Server, Session-Sender, and Session-Reflector Control-Client, Server, Session-Sender, and Session-Reflector
as illustrated in Fig. 1 of RFC XXXX."; as illustrated in Figure 1 of RFC 8913.";
container client { container client {
if-feature control-client; if-feature "control-client";
description description
"Configuration of the TWAMP Control-Client logical "Configuration of the TWAMP Control-Client logical entity.";
entity.";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
default true; default "true";
description description
"Indicates whether the device is allowed to operate as a "Indicates whether the device is allowed to operate as a
TWAMP Control-Client."; TWAMP Control-Client.";
} }
list mode-preference-chain { list mode-preference-chain {
key priority; key "priority";
unique mode; unique "mode";
leaf priority { leaf priority {
type uint16; type uint16;
description description
"Indicates the Control-Client Mode preference priority "Indicates the Control-Client mode preference priority,
expressed as a 16-bit unsigned integer. Values for the expressed as a 16-bit unsigned integer. Values for the
priority start with zero, the highest priority, and priority start with zero, the highest priority, and
decreasing priority value is indicated by every increase decreasing priority value is indicated by every increase
in value by one."; in value by one.";
} }
leaf mode { leaf mode {
type twamp-modes; type twamp-modes;
description description
"The supported TWAMP Mode matching the corresponding "The supported TWAMP-Modes matching the corresponding
priority."; priority.";
} }
description description
"Indicates the Control-Client preferred order of use of "Indicates the Control-Client preferred order of use of
the supported TWAMP Modes. the supported TWAMP-Modes.
Depending on the Modes available in the TWAMP Server Depending on the modes available in the TWAMP Server
Greeting message (see Fig. 2 of RFC 7717), the Greeting message (see Figure 2 of RFC 7717), the
Control-Client MUST choose the highest priority Control-Client MUST choose the highest-priority
Mode from the configured mode-preference-chain list."; mode from the configured mode-preference-chain list.";
} }
uses key-management; uses key-management;
list ctrl-connection { list ctrl-connection {
key name; key "name";
description description
"List of TWAMP Control-Client control connections. "List of TWAMP Control-Client control connections.
Each item in the list describes a control connection Each item in the list describes a control connection
that will be initiated by this Control-Client"; that will be initiated by this Control-Client.";
leaf name { leaf name {
type string; type string;
description description
"A unique name used as a key to identify this "A unique name used as a key to identify this
individual TWAMP-Control connection on the individual TWAMP-Control connection on the
Control-Client device."; Control-Client device.";
} }
leaf client-ip { leaf client-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the local Control-Client device, "The IP address of the local Control-Client device,
to be placed in the source IP address field of the to be placed in the source IP address field of the
IP header in TWAMP-Control (TCP) packets belonging IP header in TWAMP-Control (TCP) packets belonging
to this control connection. If not configured, the to this control connection. If not configured, the
device SHALL choose its own source IP address."; device SHALL choose its own source IP address.";
} }
leaf server-ip { leaf server-ip {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"The IP address of the remote Server device, which the "The IP address of the remote Server device to which
TWAMP-Control connection will be initiated to."; the TWAMP-Control connection will be initiated.";
} }
leaf server-tcp-port { leaf server-tcp-port {
type inet:port-number; type inet:port-number;
default 862; default "862";
description description
"This parameter defines the TCP port number that is "This parameter defines the TCP port number that is
to be used by this outgoing TWAMP-Control connection. to be used by this outgoing TWAMP-Control connection.
Typically, this is the well-known TWAMP-Control Typically, this is the well-known TWAMP-Control
port number (862) as per RFC 5357 However, there are port number (862) as per RFC 5357. However, there are
known realizations of TWAMP in the field that were known realizations of TWAMP in the field that were
implemented before this well-known port number was implemented before this well-known port number was
allocated. These early implementations allowed the allocated. These early implementations allowed the
port number to be configured. This parameter is port number to be configured. This parameter is
therefore provided for backward compatibility therefore provided for backward-compatibility
reasons."; reasons.";
} }
leaf control-packet-dscp { leaf control-packet-dscp {
type inet:dscp; type inet:dscp;
default 0; default "0";
description description
"The DSCP value to be placed in the IP header of "The Differentiated Services Code Point (DSCP) value
TWAMP-Control (TCP) packets generated by this to be placed in the IP header of TWAMP-Control (TCP)
Control-Client."; packets generated by this Control-Client.";
} }
leaf key-id { leaf key-id {
type string { type string {
length 1..80; length "1..80";
} }
description description
"Indicates the KeyID value selected for this "Indicates the KeyID value selected for this
TWAMP-Control connection."; TWAMP-Control connection.";
} }
uses max-count-exponent; uses max-count-exponent;
leaf client-tcp-port { leaf client-tcp-port {
type inet:port-number; type inet:port-number;
config false; config false;
description description
"Indicates the source TCP port number used in the "Indicates the source TCP port number used in the
TWAMP-Control packets belonging to this control TWAMP-Control packets belonging to this control
connection."; connection.";
} }
leaf server-start-time { leaf server-start-time {
type uint64; type uint64;
config false; config false;
description description
"Indicates the Start-Time advertised by the Server in "Indicates the Start-Time advertised by the Server in
the Server-Start message (RFC 4656, Section 3.1), the Server-Start message (RFC 4656, Section 3.1),
representing the time when the current representing the time when the current
instantiation of the Server started operating. instantiation of the Server started operating.
The timestamp format follows RFC 5905 The timestamp format follows RFC 5905, according to
according to Section 4.1.2 of RFC 4656."; Section 4.1.2 of RFC 4656.";
reference reference
"RFC 4656: OWAMP, Section 3.1 and 4.1.2, "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
RFC 5905: NTPv4 Specification."; Sections 3.1 and 4.1.2
RFC 5905: Network Time Protocol Version 4: Protocol and
Algorithms Specification";
} }
leaf repeat-count { leaf repeat-count {
type uint64; type uint64;
config false; config false;
description description
"Indicates how many times the test session has been "Indicates how many times the test session has been
repeated. When a test is running, this value will be repeated. When a test is running, this value will be
greater than 0. If the repeat parameter is non-zero, greater than 0. If the repeat parameter is non-zero,
this value is smaller than or equal to the repeat this value is smaller than or equal to the repeat
parameter."; parameter.";
} }
leaf state { leaf state {
type control-client-connection-state; type control-client-connection-state;
config false; config false;
description description
"Indicates the current state of the TWAMP-Control "Indicates the current TWAMP-Control connection state.";
connection state.";
} }
leaf selected-mode { leaf selected-mode {
type twamp-modes; type twamp-modes;
config false; config false;
description description
"The TWAMP Mode that the Control-Client has chosen for "The TWAMP-Modes that the Control-Client has chosen for
this control connection as set in the Mode field of this control connection as set in the Mode field of
the Set-Up-Response message"; the Set-Up-Response message.";
reference reference
"RFC 4656, Section 3.1."; "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
Section 3.1";
} }
leaf token { leaf token {
type binary { type binary {
length 64; length "64";
} }
config false; config false;
description description
"This parameter holds the 64 octets containing the "This parameter holds the 64 octets containing the
concatenation of a 16-octet Challenge, a 16-octet AES concatenation of a 16-octet Challenge, a 16-octet AES
Session-key used for encryption, and a 32-octet Session-key used for encryption, and a 32-octet
HMAC-SHA1 Session-key used for authentication; see HMAC-SHA1 Session-key used for authentication; see
also the last paragraph of Section 6 in RFC 4656. also the last paragraph of Section 6.10 of RFC 4656.
If the Mode defined in RFC 7717 is selected If the mode defined in RFC 7717 is selected
(selected-mode), Token is limited to 16 octets."; (selected-mode), Token is limited to 16 octets.";
reference reference
"RFC 4086: Randomness Requirements for Security "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
Section 6.10
RFC 7717: IKEv2-Derived Shared Secret Key for the RFC 7717: IKEv2-Derived Shared Secret Key for the
One-Way Active Measurement Protocol (OWAMP) and One-Way Active Measurement Protocol (OWAMP) and
Two-Way Active Measurement Protocol (TWAMP)"; Two-Way Active Measurement Protocol (TWAMP)";
} }
leaf client-iv { leaf client-iv {
type binary { type binary {
length 16; length "16";
} }
config false; config false;
description description
"Indicates the Control-Client Initialization Vector "Indicates the Control-Client Initialization Vector
(Client-IV), that is generated randomly by the (Client-IV), which is generated randomly by the
Control-Client. As per RFC 4656: Control-Client. As per RFC 4656:
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.
If the Mode defined in RFC 7717 is selected 'Client-IV merely needs to be unique (i.e., it MUST
(selected-mode), Client-IV is limited to 12 octets."; 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.'
If the mode defined in RFC 7717 is selected
(selected-mode), Client-IV is limited to 12 octets.";
reference reference
"RFC 4656: A One-way Active Measurement Protocol "RFC 4656: A One-way Active Measurement Protocol (OWAMP)
(OWAMP).
RFC 7717: IKEv2-Derived Shared Secret Key for the RFC 7717: IKEv2-Derived Shared Secret Key for the
One-Way Active Measurement Protocol (OWAMP) and One-Way Active Measurement Protocol (OWAMP) and
Two-Way Active Measurement Protocol (TWAMP)"; Two-Way Active Measurement Protocol (TWAMP)";
} }
list test-session-request { list test-session-request {
key name; key "name";
description description
"Information associated with the Control-Client "Information associated with the Control-Client
for this test session"; for this test session.";
leaf name { leaf name {
type string; type string;
description description
"A unique name to be used for identification of "A unique name to be used for identification of
this TWAMP-Test session on the Control-Client."; this TWAMP-Test session on the Control-Client.";
} }
leaf sender-ip { leaf sender-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the Session-Sender device, "The IP address of the Session-Sender device,
which is to be placed in the source IP address which is to be placed in the source IP address
field of the IP header in TWAMP-Test (UDP) packets field of the IP header in TWAMP-Test (UDP) packets
belonging to this test session. This value will be belonging to this test session. This value will be
used to populate the sender address field of the used to populate the Sender Address field of the
Request-TW-Session message. Request-TW-Session message.
If not configured, the device SHALL choose its own If not configured, the device SHALL choose its own
source IP address."; source IP address.";
} }
leaf sender-udp-port { leaf sender-udp-port {
type union { type union {
type dynamic-port-number; type dynamic-port-number;
type enumeration { type enumeration {
enum autoallocate { enum autoallocate {
description description
"Indicates that the Contol-Client will "Indicates that the Control-Client will
auto-allocate the TWAMP-Test (UDP) port number auto-allocate the TWAMP-Test (UDP) port number
from the dynamic port range."; from the dynamic port range.";
} }
} }
} }
default autoallocate; default "autoallocate";
description description
"The UDP port number that is to be used by "The UDP port number that is to be used by
the Session-Sender for this TWAMP-Test session. the Session-Sender for this TWAMP-Test session.
The number is restricted to the dynamic port range. The number is restricted to the dynamic port range.
By default the Control-Client SHALL auto-allocate a By default, the Control-Client SHALL auto-allocate a
UDP port number for this TWAMP-Test session. UDP port number for this TWAMP-Test session.
The configured (or auto-allocated) value is The configured (or auto-allocated) value is
advertised in the Sender Port field of the advertised in the Sender Port field of the
Request-TW-session message (see Section 3.5 of Request-TW-Session message (see Section 3.5 of
RFC 5357). Note that in the scenario where a device RFC 5357). Note that in the scenario where a device
auto-allocates a UDP port number for a session, and auto-allocates a UDP port number for a session and
the repeat parameter for that session indicates that the repeat parameter for that session indicates that
it should be repeated, the device is free to it should be repeated, the device is free to
auto-allocate a different UDP port number when it auto-allocate a different UDP port number when it
negotiates the next (repeated) iteration of this negotiates the next (repeated) iteration of this
session."; session.";
} }
leaf reflector-ip { leaf reflector-ip {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"The IP address belonging to the remote "The IP address belonging to the remote
Session-Reflector device to which the TWAMP-Test Session-Reflector device to which the TWAMP-Test
session will be initiated. This value will be session will be initiated. This value will be
used to populate the receiver address field of used to populate the Receiver Address field of
the Request-TW-Session message."; the Request-TW-Session message.";
} }
leaf reflector-udp-port { leaf reflector-udp-port {
type inet:port-number { type inet:port-number {
range "862 | 49152..65535"; range "862 | 49152..65535";
} }
description description
"This parameter defines the UDP port number that "This parameter defines the UDP port number that
will be used by the Session-Reflector for will be used by the Session-Reflector for
this TWAMP-Test session. The default number is this TWAMP-Test session. The default number is
within the dynamic port range and is to be placed within the dynamic port range and is to be placed
in the Receiver Port field of the Request-TW-Session in the Receiver Port field of the Request-TW-Session
message. The well-known port (862) MAY be message. The well-known port (862) MAY be used.";
used.";
reference reference
"draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP "RFC 8545: Well-Known Port Assignments for the One-Way
Well-Known Port Assignments."; Active Measurement Protocol (OWAMP) and the Two-Way
Active Measurement Protocol (TWAMP)";
} }
leaf timeout { leaf timeout {
type uint64; type uint64;
units seconds; units "seconds";
default 2; default "2";
description description
"The length of time (in seconds) that the "The length of time (in seconds) that the
Session-Reflector should continue to respond to Session-Reflector should continue to respond to
packets belonging to this TWAMP-Test session after packets belonging to this TWAMP-Test session after
a Stop-Sessions TWAMP-Control message has been a Stop-Sessions TWAMP-Control message has been
received. received.
This value will be placed in the Timeout field of This value will be placed in the Timeout field of
the Request-TW-Session message."; the Request-TW-Session message.";
reference reference
"RFC 5357: TWAMP, Section 3.5."; "RFC 5357: A Two-Way Active Measurement Protocol
(TWAMP), Section 3.5";
} }
leaf padding-length { leaf padding-length {
type uint32 { type uint32 {
range 64..4096; range "64..4096";
} }
description description
"The number of padding bytes to be added to the "The number of padding bytes to be added to the
TWAMP-Test (UDP) packets generated by the TWAMP-Test (UDP) packets generated by the
Session-Sender. Session-Sender.
This value will be placed in the Padding Length This value will be placed in the Padding Length
field of the Request-TW-Session message."; field of the Request-TW-Session message.";
reference reference
"RFC 4656, Section 3.5."; "RFC 4656: A One-way Active Measurement Protocol
(OWAMP), Section 3.5";
} }
leaf test-packet-dscp { leaf test-packet-dscp {
type inet:dscp; type inet:dscp;
default 0; default "0";
description description
"The DSCP value to be placed in the IP header "The DSCP value to be placed in the IP header
of TWAMP-Test packets generated by the of TWAMP-Test packets generated by the
Session-Sender, and in the UDP header of the Session-Sender and in the UDP header of the
TWAMP-Test response packets generated by the TWAMP-Test response packets generated by the
Session-Reflector for this test session. Session-Reflector for this test session.
This value will be placed in the Type-P Descriptor This value will be placed in the Type-P Descriptor
field of the Request-TW-Session message"; field of the Request-TW-Session message.";
reference reference
"RFC 5357."; "RFC 5357: A Two-Way Active Measurement Protocol
(TWAMP)";
} }
leaf start-time { leaf start-time {
type uint64; type uint64;
default 0; default "0";
description description
"Time when the session is to be started "Time when the session is to be started
(but not before the TWAMP Start-Sessions command (but not before the TWAMP Start-Sessions command
is issued; see Section 3.4 of RFC 5357). is issued; see Section 3.4 of RFC 5357).
The start-time value is placed in the Start Time The start-time value is placed in the Start Time
field of the Request-TW-Session message. field of the Request-TW-Session message.
The timestamp format follows RFC 5905 as per The timestamp format follows RFC 5905 as per
Section 3.5 of RFC 4656. Section 3.5 of RFC 4656.
skipping to change at page 36, line 22 skipping to change at line 1620
The start-time value is placed in the Start Time The start-time value is placed in the Start Time
field of the Request-TW-Session message. field of the Request-TW-Session message.
The timestamp format follows RFC 5905 as per The timestamp format follows RFC 5905 as per
Section 3.5 of RFC 4656. Section 3.5 of RFC 4656.
The default value of 0 indicates that the session The default value of 0 indicates that the session
will be started as soon as the Start-Sessions will be started as soon as the Start-Sessions
message is received."; message is received.";
} }
leaf repeat { leaf repeat {
type uint32 { type uint32 {
range 0..4294967295; range "0..4294967295";
} }
default 0; default "0";
description description
"This value determines if the TWAMP-Test session must "This value determines if the TWAMP-Test session must
be repeated. When a test session has completed, the be repeated. When a test session has completed, the
repeat parameter is checked. repeat parameter is checked.
The default value of 0 indicates that the session The default value of 0 indicates that the session
MUST NOT be repeated. MUST NOT be repeated.
If the repeat value is 1 through 4,294,967,294 If the repeat value is 1 through 4,294,967,294,
then the test session SHALL be repeated using the then the test session SHALL be repeated using the
information in repeat-interval parameter, and the information in the repeat-interval parameter, and the
parent TWAMP-Control connection for this test parent TWAMP-Control connection for this test
session is restarted to negotiate a new instance session is restarted to negotiate a new instance
of this TWAMP-Test session. of this TWAMP-Test session.
A value of 4,294,967,295 indicates that the test A value of 4,294,967,295 indicates that the test
session SHALL be repeated *forever* using the session SHALL be repeated *forever* using the
information in repeat-interval parameter, and SHALL information in the repeat-interval parameter and
NOT decrement the value."; SHALL NOT decrement the value.";
} }
leaf repeat-interval {
leaf repeat-interval {
when "../repeat!='0'" { when "../repeat!='0'" {
description description
"This parameter determines the timing of repeated "This parameter determines the timing of repeated
TWAMP-Test sessions when repeat is more than 0. TWAMP-Test sessions when repeat is more than 0.
When the value of repeat-interval is 0, the When the value of repeat-interval is 0, the
negotiation of a new test session SHALL begin negotiation of a new test session SHALL begin
immediately after the previous test session immediately after the previous test session
completes. Otherwise, the Control-Client will completes. Otherwise, the Control-Client will
wait for the number of seconds specified in the wait for the number of seconds specified in the
repeat-interval parameter before negotiating the repeat-interval parameter before negotiating the
new instance of this TWAMP-Test session."; new instance of this TWAMP-Test session.";
} }
type uint32; type uint32;
units seconds; units "seconds";
default 0; default "0";
description description
"Repeat interval (in seconds)."; "Repeat interval (in seconds).";
} }
list pm-reg-list { list pm-reg-list {
key pm-index; key "pm-index";
leaf pm-index { leaf pm-index {
type uint16; type uint16;
description description
"Numerical index value of a Registered Metric "Numerical index value of a Registered Metric in
in the Performance Metric Registry the Performance Metrics Registry (see RFC 8911).
(see ietf-ippm-metric-registry). Output statistics Output statistics are specified in the
are specified in the corresponding Registry corresponding Registry Entry.";
entry.";
} }
description description
"A list of one or more Performance Metric Registry "A list of one or more Performance Metrics Registry
Index values, which communicate packet stream Index values, which communicate packet stream
characteristics along with one or more metrics characteristics along with one or more metrics
to be measured. to be measured.
All members of the pm-reg-list MUST have the same All members of the pm-reg-list MUST have the same
stream characteristics, such that they combine stream characteristics, such that they combine
to specify all metrics that shall be measured on to specify all metrics that shall be measured on
a single stream."; a single stream.";
reference reference
"ietf-ippm-metric-registry: Registry for "RFC 8911: Registry for Performance Metrics";
Performance Metrics";
} }
leaf state { leaf state {
type test-session-state; type test-session-state;
config false; config false;
description description
"Indicates the TWAMP-Test session state, accepted or "Indicates the TWAMP-Test session state -- an accepted
indication of an error."; request or an indication of an error.";
reference reference
"Section 3.5 of RFC 5357."; "RFC 5357: A Two-Way Active Measurement Protocol
(TWAMP), Section 3.5";
} }
leaf sid { leaf sid {
type string; type string;
config false; config false;
description description
"The SID allocated by the Server for this TWAMP-Test "The Session Identifier (SID) allocated by the Server
session, and communicated back to the Control-Client for this TWAMP-Test session and communicated back to
in the SID field of the Accept-Session message"; the Control-Client in the SID field of the
Accept-Session message.";
reference 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 { container server {
if-feature server; if-feature "server";
description description
"Configuration of the TWAMP Server logical entity."; "Configuration of the TWAMP Server logical entity.";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
default true; default "true";
description description
"Indicates whether the device is allowed to operate "Indicates whether the device is allowed to operate
as a TWAMP Server."; as a TWAMP Server.";
} }
leaf server-tcp-port { leaf server-tcp-port {
type inet:port-number; type inet:port-number;
default 862; default "862";
description description
"This parameter defines the well known TCP port number "This parameter defines the well-known TCP port number
that is used by TWAMP-Control. The Server will listen that is used by TWAMP-Control. The Server will listen
on this port number for incoming TWAMP-Control on this port number for incoming TWAMP-Control
connections. Although this is defined as a fixed value connections. Although this is defined as a fixed value
(862) in RFC 5357, there are several realizations of (862) in RFC 5357, there are several realizations of
TWAMP in the field that were implemented before this TWAMP in the field that were implemented before this
well-known port number was allocated. These early well-known port number was allocated. These early
implementations allowed the port number to be implementations allowed the port number to be
configured. This parameter is therefore provided for configured. This parameter is therefore provided for
backward compatibility reasons."; backward-compatibility reasons.";
} }
leaf servwait { leaf servwait {
type uint32 { type uint32 {
range 1..604800; range "1..604800";
} }
units seconds; units "seconds";
default 900; default "900";
description description
"TWAMP-Control (TCP) session timeout, in seconds. "TWAMP-Control (TCP) session timeout, in seconds.
According to Section 3.1 of RFC 5357, According to Section 3.1 of RFC 5357:
Server MAY discontinue any established control 'The Server MAY discontinue any established control
connection when no packet associated with that connection when no packet associated with that
connection has been received within SERVWAIT seconds."; connection has been received within SERVWAIT seconds.'";
} }
leaf control-packet-dscp { leaf control-packet-dscp {
type inet:dscp; type inet:dscp;
description description
"The DSCP value to be placed in the IP header of "The DSCP value to be placed in the IP header of
TWAMP-Control (TCP) packets generated by the Server. TWAMP-Control (TCP) packets generated by the Server.
Section 3.1 of RFC 5357 specifies that the server Section 3.1 of RFC 5357 specifies that the Server
SHOULD use the DSCP value from the Control-Clients SHOULD use the DSCP value from the Control-Client's
TCP SYN. However, for practical purposes TWAMP will TCP SYN. However, for practical purposes, TWAMP will
typically be implemented using a general purpose TCP typically be implemented using a general-purpose TCP
stack provided by the underlying operating system, stack provided by the underlying operating system,
and such a stack may not provide this information to the and such a stack may not provide this information to the
user. Consequently, it is not always possible to user. Consequently, it is not always possible to
implement the behavior described in RFC 5357 in an implement the behavior described in RFC 5357 in an
OS-portable version of TWAMP. OS-portable version of TWAMP.
The default behavior if this item is not set is to use The default behavior if this item is not set is to use
the DSCP value from the Control-Clients TCP SYN."; the DSCP value from the Control-Client's TCP SYN.";
reference reference
"Section 3.1 of RFC 5357."; "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP),
Section 3.1";
} }
uses count; uses count;
uses max-count-exponent; uses max-count-exponent;
leaf modes { leaf modes {
type twamp-modes; type twamp-modes;
description description
"The bit mask of TWAMP Modes this Server instance "The bit mask of TWAMP-Modes this Server instance is
is willing to support; see IANA TWAMP Modes Registry."; willing to support; see the IANA 'TWAMP-Modes' Registry.";
} }
uses key-management; uses key-management;
list ctrl-connection { list ctrl-connection {
key "client-ip client-tcp-port server-ip server-tcp-port"; key "client-ip client-tcp-port server-ip server-tcp-port";
config false; config false;
description description
"List of all incoming TWAMP-Control (TCP) connections."; "List of all incoming TWAMP-Control (TCP) connections.";
leaf client-ip { leaf client-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address on the remote Control-Client device, "The IP address on the remote Control-Client device,
which is the source IP address used in the which is the source IP address used in the
TWAMP-Control (TCP) packets belonging to this control TWAMP-Control (TCP) packets belonging to this control
connection."; connection.";
} }
leaf client-tcp-port { leaf client-tcp-port {
type inet:port-number; type inet:port-number;
description description
"The source TCP port number used in the TWAMP-Control "The source TCP port number used in the TWAMP-Control
(TCP) packets belonging to this control connection."; (TCP) packets belonging to this control connection.";
} }
leaf server-ip { leaf server-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the local Server device, which is "The IP address of the local Server device, which is
the destination IP address used in the the destination IP address used in the
TWAMP-Control (TCP) packets belonging to this control TWAMP-Control (TCP) packets belonging to this control
connection."; connection.";
} }
leaf server-tcp-port { leaf server-tcp-port {
type inet:port-number; type inet:port-number;
description description
"The destination TCP port number used in the "The destination TCP port number used in the
TWAMP-Control (TCP) packets belonging to this TWAMP-Control (TCP) packets belonging to this
control connection. This will usually be the control connection. This will usually be the
same value as the server-tcp-port configured same value as the server-tcp-port configured
under twamp/server. However, in the event that under twamp/server. However, in the event that
the user re-configured server/server-tcp-port the user reconfigured server/server-tcp-port
after this control connection was initiated, this after this control connection was initiated, this
value will indicate the server-tcp-port that is value will indicate the server-tcp-port that is
actually in use for this control connection."; actually in use for this control connection.";
} }
leaf state { leaf state {
type server-ctrl-connection-state; type server-ctrl-connection-state;
description description
"Indicates the Server TWAMP-Control connection state."; "Indicates the Server TWAMP-Control connection state.";
} }
leaf control-packet-dscp { leaf control-packet-dscp {
type inet:dscp; type inet:dscp;
description description
"The DSCP value used in the IP header of the "The DSCP value used in the IP header of the
TWAMP-Control (TCP) packets sent by the Server TWAMP-Control (TCP) packets sent by the Server
for this control connection. This will usually for this control connection. This will usually
be the same value as is configured in the be the same value as is configured in the
control-packet-dscp parameter under the twamp/server control-packet-dscp parameter under the twamp/server
container. However, in the event that the user container. However, in the event that the user
re-configures server/dscp after this control reconfigures server/dscp after this control
connection is already in progress, this read-only connection is already in progress, this read-only
value will show the actual dscp value in use by this value will show the actual DSCP value in use by this
TWAMP-Control connection."; TWAMP-Control connection.";
} }
leaf selected-mode { leaf selected-mode {
type twamp-modes; type twamp-modes;
description description
"The Mode that was chosen for this TWAMP-Control "The mode that was chosen for this TWAMP-Control
connection as set in the Mode field of the connection as set in the Mode field of the
Set-Up-Response message."; Set-Up-Response message.";
} }
leaf key-id { leaf key-id {
type string { type string {
length 1..80; length "1..80";
} }
description description
"The KeyID value that is in use by this TWAMP-Control "The KeyID value that is in use by this TWAMP-Control
connection as selected by Control-Client."; connection as selected by the Control-Client.";
} }
uses count { uses count {
description description
"The count value that is in use by this TWAMP-Control "The Count value that is in use by this TWAMP-Control
connection. This will usually be the same value connection. This will usually be the same value
as is configured under twamp/server. However, in the as is configured under twamp/server. However, in the
event that the user re-configured server/count event that the user reconfigures server/count
after this control connection is already in progress, after this control connection is already in progress,
this read-only value will show the actual count that this read-only value will show the actual count that
is in use for this TWAMP-Control connection."; is in use for this TWAMP-Control connection.";
} }
uses max-count-exponent { uses max-count-exponent {
description description
"This read-only value indicates the actual max-count in "This read-only value indicates the actual max-count in
use for this control connection. Usually this would be use for this control connection. Usually, this would be
the same value as configured under twamp/server."; the same value as is configured under twamp/server.";
} }
leaf salt { leaf salt {
type binary { type binary {
length 16; length "16";
} }
description description
"A parameter used in deriving a key from a "A parameter used in deriving a key from a
shared secret as described in Section 3.1 of RFC 4656. shared secret, as described in Section 3.1 of RFC 4656.
It is communicated to the Control-Client as part of It is communicated to the Control-Client as part of
the Server Greeting message."; the Server Greeting message.";
} }
leaf server-iv { leaf server-iv {
type binary { type binary {
length 16; length "16";
} }
description description
"The Server Initialization Vector "The Server Initialization Vector (Server-IV)
(IV) generated randomly by the Server."; generated randomly by the Server.";
} }
leaf challenge { leaf challenge {
type binary { type binary {
length 16; length "16";
} }
description description
"A random sequence of octets generated by the Server. "A random sequence of octets generated by the Server.
As described in client/token, Challenge is used As described in client/token, a Challenge is used
by the Control-Client to prove possession of a by the Control-Client to prove possession of a
shared secret."; shared secret.";
} }
} }
} }
container session-sender { container session-sender {
if-feature session-sender; if-feature "session-sender";
description description
"Configuration of the TWAMP Session-Sender logical entity"; "Configuration of the TWAMP Session-Sender logical entity.";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
default true; default "true";
description description
"Indicates whether the device is allowed to operate "Indicates whether the device is allowed to operate
as a TWAMP Session-Sender."; as a TWAMP Session-Sender.";
} }
list test-session {
list test-session{ key "name";
key name;
description description
"List of TWAMP Session-Sender test sessions."; "List of TWAMP Session-Sender test sessions.";
leaf name { leaf name {
type string; type string;
description description
"A unique name for this TWAMP-Test session to be used "A unique name for this TWAMP-Test session to be used
for identifying this test session by the for identifying this test session by the
Session-Sender logical entity."; Session-Sender logical entity.";
} }
leaf ctrl-connection-name { leaf ctrl-connection-name {
type string; type string;
config false; config false;
description description
"The name of the parent TWAMP-Control connection that "The name of the parent TWAMP-Control connection that
is responsible for negotiating this TWAMP-Test is responsible for negotiating this TWAMP-Test
session."; session.";
} }
leaf fill-mode { leaf fill-mode {
type padding-fill-mode; type padding-fill-mode;
default zero; default "zero";
description description
"Indicates whether the padding added to the "Indicates whether the padding added to the
TWAMP-Test (UDP) packets will contain pseudo-random TWAMP-Test (UDP) packets (1) will contain pseudorandom
numbers, or whether it should consist of all zeroes, numbers or (2) should consist of all zeros, as per
as per Section 4.2.1 of RFC 5357."; Section 4.2.1 of RFC 5357.";
} }
leaf number-of-packets { leaf number-of-packets {
type uint32; type uint32;
mandatory true; mandatory true;
description description
"The overall number of TWAMP-Test (UDP) packets to be "The overall number of TWAMP-Test (UDP) packets to be
transmitted by the Session-Sender for this test transmitted by the Session-Sender for this test
session."; session.";
} }
choice packet-distribution { choice packet-distribution {
description description
"Indicates the distribution to be used for transmitting "Indicates the distribution to be used for transmitting
the TWAMP-Test (UDP) packets."; the TWAMP-Test (UDP) packets.";
case periodic { case periodic {
leaf periodic-interval { leaf periodic-interval {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
} }
units seconds; units "seconds";
mandatory true; mandatory true;
description description
"Indicates the time to wait (in seconds) between "Indicates the time to wait (in seconds) between
the first bits of TWAMP-Test (UDP) packet the first bits of TWAMP-Test (UDP) packet
transmissions for this test session."; transmissions for this test session.";
reference reference
"RFC 3432: Network performance measurement "RFC 3432: Network performance measurement with
with periodic streams"; periodic streams";
} }
} }
case poisson { case poisson {
leaf lambda { leaf lambda {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
} }
units seconds; units "seconds";
mandatory true; mandatory true;
description description
"Indicates the average time interval (in seconds) "Indicates the average time interval (in seconds)
between packets in the Poisson distribution. between packets in the Poisson distribution.
The packet is calculated using the reciprocal of The packet is calculated using the reciprocal of
lambda and the TWAMP-Test packet size (which lambda and the TWAMP-Test packet size (which
depends on the selected Mode and the packet depends on the selected mode and the packet
padding)."; padding).";
reference reference
"RFC 2330: Framework for IP Performance Metrics"; "RFC 2330: Framework for IP Performance Metrics";
} }
leaf max-interval { leaf max-interval {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 5;
} }
units seconds; units "seconds";
description description
"Indicates the maximum time (in seconds) "Indicates the maximum time (in seconds)
between packet transmissions."; between packet transmissions.";
reference reference
"RFC 7312: Advanced Stream and Sampling Framework "RFC 7312: Advanced Stream and Sampling Framework
for IP Performance Metrics (IPPM)"; for IP Performance Metrics (IPPM)";
} }
} }
} }
leaf state { leaf state {
type sender-session-state; type sender-session-state;
config false; config false;
description description
"Indicates the Session-Sender test session state."; "Indicates the Session-Sender test session state.";
} }
uses maintenance-statistics; uses maintenance-statistics;
} }
} }
container session-reflector { container session-reflector {
if-feature session-reflector; if-feature "session-reflector";
description description
"Configuration of the TWAMP Session-Reflector logical "Configuration of the TWAMP Session-Reflector logical
entity"; entity.";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
default true; default "true";
description description
"Indicates whether the device is allowed to operate "Indicates whether the device is allowed to operate
as a TWAMP Session-Reflector."; as a TWAMP Session-Reflector.";
} }
leaf refwait { leaf refwait {
type uint32 { type uint32 {
range 1..604800; range "1..604800";
} }
units seconds; units "seconds";
default 900; default "900";
description description
"The Session-Reflector MAY discontinue any session that "The Session-Reflector MAY discontinue any session that
has been started when no packet associated with that has been started when no packet associated with that
session has been received for REFWAIT seconds. As per session has been received for REFWAIT seconds. As per
Section 3.1 of RFC 5357, this timeout allows a Section 3.1 of RFC 5357, this timeout allows a
Session-Reflector to free up resources in case of Session-Reflector to free up resources in case of
failure."; failure.";
} }
list test-session { list test-session {
key key "sender-ip sender-udp-port
"sender-ip sender-udp-port reflector-ip reflector-udp-port";
reflector-ip reflector-udp-port";
config false; config false;
description description
"TWAMP Session-Reflectortest sessions."; "TWAMP Session-Reflector test sessions.";
leaf sid { leaf sid {
type string; type string;
description description
"An auto-allocated identifier for this TWAMP-Test "An auto-allocated identifier for this TWAMP-Test
session that is unique within the context of this session that is unique within the context of this
Server/Session-Reflector device only. This value Server/Session-Reflector device only. This value
is communicated to the Control-Client that is communicated to the Control-Client that
requested the test session in the SID field of the requested the test session in the SID field of the
Accept-Session message."; Accept-Session message.";
} }
leaf sender-ip { leaf sender-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address on the remote device, which is the "The IP address on the remote device, which is the
source IP address used in the TWAMP-Test (UDP) packets source IP address used in the TWAMP-Test (UDP) packets
belonging to this test session."; belonging to this test session.";
} }
leaf sender-udp-port { leaf sender-udp-port {
type dynamic-port-number; type dynamic-port-number;
description description
"The source UDP port used in the TWAMP-Test packets "The source UDP port used in the TWAMP-Test packets
belonging to this test session."; belonging to this test session.";
} }
leaf reflector-ip { leaf reflector-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the local Session-Reflector "The IP address of the local Session-Reflector
device, which is the destination IP address used device, which is the destination IP address used
in the TWAMP-Test (UDP) packets belonging to this test in the TWAMP-Test (UDP) packets belonging to this test
session."; session.";
} }
leaf reflector-udp-port { leaf reflector-udp-port {
type inet:port-number { type inet:port-number {
range "862 | 49152..65535"; range "862 | 49152..65535";
} }
description description
"The destination UDP port number used in the "The destination UDP port number used in the
TWAMP-Test (UDP) test packets belonging to this TWAMP-Test (UDP) test packets belonging to this
test session."; test session.";
} }
leaf parent-connection-client-ip { leaf parent-connection-client-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address on the Control-Client device, which "The IP address on the Control-Client device, which
is the source IP address used in the TWAMP-Control is the source IP address used in the TWAMP-Control
(TCP) packets belonging to the parent control (TCP) packets belonging to the parent control
connection that negotiated this test session."; connection that negotiated this test session.";
} }
leaf parent-connection-client-tcp-port { leaf parent-connection-client-tcp-port {
type inet:port-number; type inet:port-number;
description description
"The source TCP port number used in the TWAMP-Control "The source TCP port number used in the TWAMP-Control
(TCP) packets belonging to the parent control (TCP) packets belonging to the parent control
connection that negotiated this test session."; connection that negotiated this test session.";
} }
leaf parent-connection-server-ip { leaf parent-connection-server-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the Server device, which is the "The IP address of the Server device, which is the
destination IP address used in the TWAMP-Control destination IP address used in the TWAMP-Control
(TCP) packets belonging to the parent control (TCP) packets belonging to the parent control
connection that negotiated this test session."; connection that negotiated this test session.";
} }
leaf parent-connection-server-tcp-port { leaf parent-connection-server-tcp-port {
type inet:port-number; type inet:port-number;
description description
"The destination TCP port number used in the "The destination TCP port number used in the
TWAMP-Control (TCP) packets belonging to the parent TWAMP-Control (TCP) packets belonging to the parent
control connection that negotiated this test control connection that negotiated this test
session."; session.";
} }
leaf test-packet-dscp { leaf test-packet-dscp {
type inet:dscp; type inet:dscp;
description description
"The DSCP value present in the IP header of "The DSCP value present in the IP header of
TWAMP-Test (UDP) packets belonging to this session."; TWAMP-Test (UDP) packets belonging to this session.";
} }
uses maintenance-statistics; uses maintenance-statistics;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. Data Model Examples 6. Data Model Examples
This section presents a simple but complete example of configuring This section presents simple but complete examples of configuring all
all four entities in Figure 1, based on the YANG module specified in four entities in Figure 1, based on the YANG module specified in
Section 5. The example is illustrative in nature, but aims to be Section 5. The examples are illustrative in nature but aim to be
self-contained, i.e. were it to be executed in a real TWAMP self-contained, i.e., were they to be executed in a real TWAMP
implementation it would lead to a correctly configured test session. implementation, they would lead to correctly configured test
For completeness, examples are provided for both IPv4 and IPv6. sessions. For completeness, examples are provided for both IPv4 and
IPv6. The examples are shown using XML [W3C.REC-xml-20081126].
A more elaborated example, which also includes authentication More elaborate examples, which also include authentication
parameters, is provided in Appendix A. parameters, are provided in Appendix A.
6.1. Control-Client 6.1. Control-Client
Figure 8 shows a configuration example for a Control-Client with Figure 8 shows a configuration example for a Control-Client with
client/admin-state enabled. In a real implementation following client/admin-state enabled. In a real implementation following
Figure 2 this would permit the initiation of TWAMP-Control Figure 2, this would permit the initiation of TWAMP-Control
connections and TWAMP-Test sessions. connections and TWAMP-Test sessions.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</client> </client>
</twamp> </twamp>
</config> </config>
Figure 8: XML instance enabling Control-Client operation. Figure 8: XML Instance Enabling Control-Client Operation
The following example shows a Control-Client with two instances of The following example shows a Control-Client with two instances of
client/ctrl-connection, one called "RouterA" and another called client/ctrl-connection -- one called "RouterA" and another called
"RouterB". Each TWAMP-Control connection is to a different Server. "RouterB". Each TWAMP-Control connection is to a different Server.
The control connection named "RouterA" has two test session requests. The control connection named "RouterA" has two test session requests.
The TWAMP-Control connection named "RouterB" has no TWAMP-Test The TWAMP-Control connection named "RouterB" has no TWAMP-Test
session requests. session requests.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
skipping to change at page 49, line 36 skipping to change at line 2208
</twamp> </twamp>
</config> </config>
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<ctrl-connection> <ctrl-connection>
<name>RouterA</name> <name>RouterA</name>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:db8:203:0:113::1</client-ip>
<server-ip>2001:DB8:203:0:113::2</server-ip> <server-ip>2001:db8:203:0:113::2</server-ip>
<test-session-request> <test-session-request>
<name>Test1</name> <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> <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> <reflector-udp-port>55000</reflector-udp-port>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
<test-session-request> <test-session-request>
<name>Test2</name> <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> <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> <reflector-udp-port>55001</reflector-udp-port>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
<ctrl-connection> <ctrl-connection>
<name>RouterB</name> <name>RouterB</name>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:db8:203:0:113::1</client-ip>
<server-ip>2001:DB8:203:0:113::3</server-ip> <server-ip>2001:db8:203:0:113::3</server-ip>
</ctrl-connection> </ctrl-connection>
</client> </client>
</twamp> </twamp>
</config> </config>
6.2. Server 6.2. Server
Figure 9 shows a configuration example for a Server with server/ Figure 9 shows a configuration example for a Server with
admin-state enabled, which permits a device following Figure 2 to server/admin-state enabled, which permits a device following Figure 2
respond to TWAMP-Control connections and TWAMP-Test sessions. to respond to TWAMP-Control connections and TWAMP-Test sessions.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</server> </server>
</twamp> </twamp>
</config> </config>
Figure 9: XML instance enabling Server operation. Figure 9: XML Instance Enabling Server Operation
The following example presents a Server with the TWAMP-Control The following example presents a Server with the TWAMP-Control
connection corresponding to the control connection name (client/ctrl- connection corresponding to the control connection name
connection/name) "RouterA" presented in Section 6.1. (client/ctrl-connection/name) "RouterA" presented in Section 6.1.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<ctrl-connection> <ctrl-connection>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<client-tcp-port>16341</client-tcp-port> <client-tcp-port>16341</client-tcp-port>
<server-ip>203.0.113.2</server-ip> <server-ip>203.0.113.2</server-ip>
skipping to change at page 51, line 27 skipping to change at line 2279
</server> </server>
</twamp> </twamp>
</data> </data>
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<ctrl-connection> <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> <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> <server-tcp-port>862</server-tcp-port>
<state>active</state> <state>active</state>
</ctrl-connection> </ctrl-connection>
</server> </server>
</twamp> </twamp>
</data> </data>
6.3. Session-Sender 6.3. Session-Sender
Figure 10 shows a configuration example for a Session-Sender with Figure 10 shows a configuration example for a Session-Sender with
skipping to change at page 52, line 14 skipping to change at line 2304
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-sender> <session-sender>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</session-sender> </session-sender>
</twamp> </twamp>
</config> </config>
Figure 10: XML instance enabling Session-Sender operation. Figure 10: XML Instance Enabling Session-Sender Operation
The following configuration example shows a Session-Sender with the The following configuration example shows a Session-Sender with the
two TWAMP-Test sessions presented in Section 6.1. two TWAMP-Test sessions presented in Section 6.1.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-sender> <session-sender>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
skipping to change at page 52, line 43 skipping to change at line 2333
<number-of-packets>900</number-of-packets> <number-of-packets>900</number-of-packets>
<lambda>1</lambda> <lambda>1</lambda>
<max-interval>2</max-interval> <max-interval>2</max-interval>
</test-session> </test-session>
</session-sender> </session-sender>
</twamp> </twamp>
</data> </data>
6.4. Session-Reflector 6.4. Session-Reflector
This configuration example shows a Session-Reflector with session- This configuration example shows a Session-Reflector with
reflector/admin-state enabled, which permits a device following session-reflector/admin-state enabled, which permits a device
Figure 2 to respond to TWAMP-Test sessions. following Figure 2 to respond to TWAMP-Test sessions.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</session-reflector> </session-reflector>
</twamp> </twamp>
</config> </config>
Figure 11: XML instance enabling Session-Reflector operation. Figure 11: XML Instance Enabling Session-Reflector Operation
The following example shows the two Session-Reflector TWAMP-Test The following example shows the two Session-Reflector TWAMP-Test
sessions corresponding to the test sessions presented in Section 6.3. sessions corresponding to the test sessions presented in Section 6.3.
[note: '\' line wrapping is for formatting only] | Note: '\' line wrapping is for formatting only.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
skipping to change at page 54, line 4 skipping to change at line 2384
<last-sent-seq>1</last-sent-seq> <last-sent-seq>1</last-sent-seq>
<last-rcv-seq>1</last-rcv-seq> <last-rcv-seq>1</last-rcv-seq>
</test-session> </test-session>
<test-session> <test-session>
<sender-ip>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.0.2.2</reflector-ip> <reflector-ip>192.0.2.2</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip>203.0.113.1</parent-connection-\ <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip> client-ip>
<parent-connection-client-tcp-port>16341</parent-connection-\ <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port> client-tcp-port>
<parent-connection-server-ip>203.0.113.2</parent-connection-\ <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip> server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<sent-packets>21</sent-packets> <sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets> <rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq> <last-rcv-seq>20</last-rcv-seq>
</test-session> </test-session>
</session-reflector> </session-reflector>
</twamp> </twamp>
</data> </data>
[note: '\' line wrapping is for formatting only] | Note: '\' line wrapping is for formatting only.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
skipping to change at page 55, line 24 skipping to change at line 2452
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq> <last-rcv-seq>20</last-rcv-seq>
</test-session> </test-session>
</session-reflector> </session-reflector>
</twamp> </twamp>
</data> </data>
7. Security Considerations 7. Security Considerations
Virtually all existing measurement systems using TWAMP [RFC5357] are Virtually all existing measurement systems using TWAMP [RFC5357] are
administered by the same network operator. Attacks on the administered by the same network operator. For example, attacks on
measurement infrastructure could be launched by third-parties to the measurement infrastructure could be launched by third parties to
commandeer the packet generation capability, corrupt the commandeer the packet generation capability, corrupt the
measurements, or other examples of nefarious acts. measurements, or perform other nefarious acts.
The YANG module specified in Section 5 of this document defines a
schema for data that is designed to be accessed via network
management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF [RFC6241] layer is the secure transport layer, and
the mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246].
The NETCONF Access Control Module (NACM) [RFC8341] 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.
There are a number of nodes defined in this YANG module which are
writeable. These data nodes may be considered sensitive and
vulnerable to attacks in some network environments. Ability to write
into these nodes without proper protection can have a negative effect
on the devices that support this feature.
If written, the 'admin-state' node can cause unintended test sessions
to be created. If the node 'number-of-packets' that dictates how
many packets are sent in any particular test session is written with
a large value, it can cause a test session to run longer than
expected. 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 which determine whether to discontinue the session
if no packets are received, and nodes 'count' and 'max-count-
exponent' which can cause a long time to be spent on PBKDF2
iterations. In addition, 'dscp' node marked with different DSCP
markings, can cause the test traffic on the network to be skewed, and
the result manipulated. Finally, nodes within 'mode-preference-
chain' which specify the 'mode' and 'priority' values and indicate
the preferred order of use by an operator, can be manipulated to send
unauthenticated or non-encrypted traffic, enabling a MITM attack.
Limiting access to these nodes will limit the ability to launch an
attack in network environments.
The 'token' node defined in the model, containing a concatenation of
a Challenge, AES Session-key used for encryption, and HMAC-SHA1
Session-key used for authentication, is sensitive from a privacy
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.
8. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688].
Following the format in IETF XML Registry [RFC3688], the following
registration is requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-twamp The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
Registrant Contact: The IESG. The Network Configuration Access Control Model (NACM) [RFC8341]
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.
XML: N/A, the requested URI is an XML namespace. There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
This document registers a YANG module in the YANG Module Names * If written, the 'admin-state' node can cause unintended test
registry YANG [RFC6020]. sessions to be created.
name: ietf-twamp * If the node 'number-of-packets', which dictates how many packets
are sent in any particular test session, is written with a large
value, it can cause a test session to run longer than expected.
namespace: urn:ietf:params:xml:ns:yang:ietf-twamp * 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, which determines whether to discontinue the
session if no packets are received; and the nodes 'count' and
'max-count-exponent', which can cause a long time to be spent on
Password-Based Key Derivation Function 2 (PBKDF2) iterations.
prefix: twamp * In addition, a 'dscp' node marked with different DSCP markings can
cause the test traffic on the network to be skewed and the result
manipulated.
reference: RFC XXXX * Finally, nodes within 'mode-preference-chain', which specifies the
'mode' and 'priority' values and indicates the preferred order of
use by an operator, can be manipulated to send unauthenticated or
non-encrypted traffic, enabling an on-path attack.
9. Acknowledgements * Limiting access to these nodes will limit the ability to launch an
attack in network environments.
We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell, Some of the readable data nodes in this YANG module may be considered
Robert Sherman, and Marius Georgescu for their thorough and sensitive or vulnerable in some network environments. It is thus
constructive reviews, comments and text suggestions. 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:
Haoxing Shen contributed to the definition of the YANG module in * The 'token' node defined in the model, containing a concatenation
Section 5. 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 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.
Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG The TWAMP YANG data model does not define RPC operations, as detailed
module and the examples in Appendix A. in Appendix B, 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.
Kostas Pentikousis was partially supported by FP7 UNIFY 8. IANA Considerations
(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.
10. Contributors IANA has registered the following URI in the "IETF XML Registry"
[RFC3688].
Lianshu Zheng. URI: urn:ietf:params:xml:ns:yang:ietf-twamp
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
11. References IANA has registered the following YANG module in the "YANG Module
Names" registry [RFC6020].
11.1. Normative References Name: ietf-twamp
Namespace: urn:ietf:params:xml:ns:yang:ietf-twamp
Prefix: twamp
Reference: RFC 8913
[I-D.ietf-ippm-metric-registry] 9. References
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-14 (work in progress), March 2018.
[I-D.ietf-ippm-port-twamp-test] 9.1. Normative References
Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
Assignments", draft-ietf-ippm-port-twamp-test-01 (work in
progress), March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
DOI 10.17487/RFC3432, November 2002, DOI 10.17487/RFC3432, November 2002,
<https://www.rfc-editor.org/info/rfc3432>. <https://www.rfc-editor.org/info/rfc3432>.
skipping to change at page 58, line 39 skipping to change at line 2589
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<https://www.rfc-editor.org/info/rfc6038>. <https://www.rfc-editor.org/info/rfc6038>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
"IKEv2-Derived Shared Secret Key for the One-Way Active "IKEv2-Derived Shared Secret Key for the One-Way Active
Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7717, Measurement Protocol (TWAMP)", RFC 7717,
DOI 10.17487/RFC7717, December 2015, DOI 10.17487/RFC7717, December 2015,
<https://www.rfc-editor.org/info/rfc7717>. <https://www.rfc-editor.org/info/rfc7717>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port
Assignments for the One-Way Active Measurement Protocol
(OWAMP) and the Two-Way Active Measurement Protocol
(TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019,
<https://www.rfc-editor.org/info/rfc8545>.
[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", RFC 8911,
DOI 10.17487/RFC8911, November 2021,
<https://www.rfc-editor.org/info/rfc8911>.
[UML] ISO/IEC, "Information technology - Open Distributed [UML] ISO/IEC, "Information technology - Open Distributed
Processing - Unified Modeling Language", April 2005. Processing - Unified Modeling Language (UML) Version
1.4.2", ISO/IEC 19501:2005, OMG-UML VER 1.3, April 2005.
11.2. Informative References [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>.
[NSC] John, W., Pentikousis, K., et al., "Research directions in 9.2. Informative References
network service chaining", Proc. SDN for Future Networks
and Services (SDN4FNS), Trento, Italy IEEE, November 2013. [NSC] John, W., Pentikousis, K., Agapiou, G., Jacob, E., Kind,
M., Manzalini, A., Risso, F., Staessens, D., Steinert, R.,
and C. Meirosu, "Research directions in network service
chaining", 2013 IEEE SDN for Future Networks and Services
(SDN4FNS), Trento, Italy,
DOI 10.1109/SDN4FNS.2013.6702549, November 2013,
<https://doi.org/10.1109/SDN4FNS.2013.6702549>.
[PERF-METRICS]
IANA, "Performance Metrics",
<https://www.iana.org/assignments/performance-metrics>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
DOI 10.17487/RFC5618, August 2009, DOI 10.17487/RFC5618, August 2009,
<https://www.rfc-editor.org/info/rfc5618>. <https://www.rfc-editor.org/info/rfc5618>.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control [RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol Feature for the Two-Way Active Measurement Protocol
(TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010,
<https://www.rfc-editor.org/info/rfc5938>. <https://www.rfc-editor.org/info/rfc5938>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312, Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014, DOI 10.17487/RFC7312, August 2014,
<https://www.rfc-editor.org/info/rfc7312>. <https://www.rfc-editor.org/info/rfc7312>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1", Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017, RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>. <https://www.rfc-editor.org/info/rfc8018>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
Appendix A. Detailed Data Model Examples Appendix A. Detailed Data Model Examples
This appendix extends the example presented in Section 6 by This appendix extends the examples presented in Section 6 by
configuring more fields such as authentication parameters, DSCP configuring more fields, such as authentication parameters, DSCP
values and so on. values, and so on.
A.1. Control-Client A.1. Control-Client
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<mode-preference-chain> <mode-preference-chain>
<priority>0</priority> <priority>0</priority>
skipping to change at page 62, line 18 skipping to change at line 2787
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>c2VjcmV0MQ==</secret-key> <secret-key>c2VjcmV0MQ==</secret-key>
</key-chain> </key-chain>
<key-chain> <key-chain>
<key-id>KeyForRouterB</key-id> <key-id>KeyForRouterB</key-id>
<secret-key>c2VjcmV0Mg0K</secret-key> <secret-key>c2VjcmV0Mg0K</secret-key>
</key-chain> </key-chain>
<ctrl-connection> <ctrl-connection>
<name>RouterA</name> <name>RouterA</name>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:db8:203:0:113::1</client-ip>
<server-ip>2001:DB8:203:0:113::2</server-ip> <server-ip>2001:db8:203:0:113::2</server-ip>
<control-packet-dscp>32</control-packet-dscp> <control-packet-dscp>32</control-packet-dscp>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<test-session-request> <test-session-request>
<name>Test1</name> <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> <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> <reflector-udp-port>55000</reflector-udp-port>
<padding-length>64</padding-length> <padding-length>64</padding-length>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
<test-session-request> <test-session-request>
<name>Test2</name> <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> <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> <reflector-udp-port>55001</reflector-udp-port>
<padding-length>128</padding-length> <padding-length>128</padding-length>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
</client> </client>
</twamp> </twamp>
</data> </data>
A.2. Server A.2. Server
skipping to change at page 63, line 49 skipping to change at line 2865
<count>15</count> <count>15</count>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>c2VjcmV0MQ==</secret-key> <secret-key>c2VjcmV0MQ==</secret-key>
</key-chain> </key-chain>
<key-chain> <key-chain>
<key-id>KeyClient10ToRouterA</key-id> <key-id>KeyClient10ToRouterA</key-id>
<secret-key>c2VjcmV0MTANCg==</secret-key> <secret-key>c2VjcmV0MTANCg==</secret-key>
</key-chain> </key-chain>
<ctrl-connection> <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> <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> <server-tcp-port>862</server-tcp-port>
<control-packet-dscp>32</control-packet-dscp> <control-packet-dscp>32</control-packet-dscp>
<selected-mode>unauthenticated</selected-mode> <selected-mode>unauthenticated</selected-mode>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<count>15</count> <count>15</count>
</ctrl-connection> </ctrl-connection>
</server> </server>
</twamp> </twamp>
</data> </data>
skipping to change at page 65, line 7 skipping to change at line 2914
<rcv-packets>21</rcv-packets> <rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq> <last-rcv-seq>20</last-rcv-seq>
</test-session> </test-session>
</session-sender> </session-sender>
</twamp> </twamp>
</data> </data>
A.4. Session-Reflector A.4. Session-Reflector
[note: '\' line wrapping is for formatting only] | Note: '\' line wrapping is for formatting only.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
skipping to change at page 66, line 4 skipping to change at line 2960
client-tcp-port> client-tcp-port>
<parent-connection-server-ip>203.0.113.2</parent-connection-\ <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip> server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<test-packet-dscp>32</test-packet-dscp> <test-packet-dscp>32</test-packet-dscp>
<sent-packets>21</sent-packets> <sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets> <rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq> <last-rcv-seq>20</last-rcv-seq>
</test-session> </test-session>
</session-reflector> </session-reflector>
</twamp> </twamp>
</data> </data>
[note: '\' line wrapping is for formatting only] | Note: '\' line wrapping is for formatting only.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <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> <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> <reflector-udp-port>55000</reflector-udp-port>
<sid>1232</sid> <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> onnection-client-ip>
<parent-connection-client-tcp-port>16341</parent-connection-\ <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port> 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> onnection-server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<test-packet-dscp>32</test-packet-dscp> <test-packet-dscp>32</test-packet-dscp>
<sent-packets>2</sent-packets> <sent-packets>2</sent-packets>
<rcv-packets>2</rcv-packets> <rcv-packets>2</rcv-packets>
<last-sent-seq>1</last-sent-seq> <last-sent-seq>1</last-sent-seq>
<last-rcv-seq>1</last-rcv-seq> <last-rcv-seq>1</last-rcv-seq>
</test-session> </test-session>
<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> <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> <reflector-udp-port>55001</reflector-udp-port>
<sid>178943</sid> <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> onnection-client-ip>
<parent-connection-client-tcp-port>16341</parent-connection-\ <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port> 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> onnection-server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<test-packet-dscp>32</test-packet-dscp> <test-packet-dscp>32</test-packet-dscp>
<sent-packets>21</sent-packets> <sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets> <rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq> <last-rcv-seq>20</last-rcv-seq>
</test-session> </test-session>
</session-reflector> </session-reflector>
</twamp> </twamp>
</data> </data>
Appendix B. TWAMP Operational Commands Appendix B. TWAMP Operational Commands
TWAMP operational commands could be performed programmatically or TWAMP operational commands could be performed programmatically or
manually, e.g. using a command-line interface (CLI). manually, e.g., using a command-line interface (CLI).
With respect to programmability, YANG can be used to define NETCONF With respect to programmability, YANG can be used to define NETCONF
Remote Procedure Calls (RPC), therefore it would be, in principle, Remote Procedure Calls (RPCs); therefore, it would be, in principle,
possible to define TWAMP RPC operations for actions such as starting possible to define TWAMP RPC operations for actions such as starting
or stopping control connections or test sessions or groups of or stopping control connections, test sessions, or groups of
sessions; retrieving results; clearing stored results, and so on. sessions; retrieving results; clearing stored results; and so on.
However, TWAMP [RFC5357] does not attempt to describe such However, TWAMP [RFC5357] does not attempt to describe such
operational actions. Refer also to Section 2 and the unlabeled links operational actions. Refer also to Section 2 and the unlabeled links
in Figure 1. In actual deployments different TWAMP implementations in Figure 1. In actual deployments, different TWAMP implementations
may support different sets of operational commands, with different may support different sets of operational commands, with different
restrictions. Therefore, this document considers it the restrictions. Therefore, this document considers it the
responsibility of the individual implementation to define its responsibility of the individual implementation to define its
corresponding TWAMP operational commands data model. corresponding data model for TWAMP operational commands.
Acknowledgments
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.
Haoxing Shen contributed to the definition of the YANG module in
Section 5.
Jan Lindblad and Ladislav Lhotka did thorough reviews of the YANG
module and the examples in Appendix A.
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.
Contributors
Lianshu Zheng
Authors' Addresses Authors' Addresses
Ruth Civil Ruth Civil
Ciena Corporation Ciena Corporation
307 Legget Drive 307 Legget Drive
Kanata, ON K2K 3C8 Kanata ON K2K 3C8
Canada Canada
Email: gcivil@ciena.com Email: ruthcivil@gmail.com
URI: www.ciena.com URI: www.ciena.com
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown, NJ 07748
USA United States of America
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
Reshad Rahman Reshad Rahman
Cisco Systems
2000 Innovation Drive
Kanata, ON K2K 3E8
Canada Canada
Email: rrahman@cisco.com Email: reshad@yahoo.com
Mahesh Jethanandani Mahesh Jethanandani
Xoriant Corporation Xoriant Corporation
1248 Reamswood Drive 1248 Reamwood Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA United States of America
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Kostas Pentikousis (editor) Kostas Pentikousis (editor)
Travelping Detecon
Siemensdamm 50 Winterfeldtstrasse 21
Berlin 13629 10781 Berlin
Germany Germany
Email: k.pentikousis@travelping.com Email: kostas.pentikousis@detecon.com
 End of changes. 421 change blocks. 
971 lines changed or deleted 949 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/