< draft-ietf-ippm-twamp-yang-02.txt   draft-ietf-ippm-twamp-yang-03.txt >
IPPM WG R. Civil IPPM WG R. Civil
Internet-Draft Ciena Corporation Internet-Draft Ciena Corporation
Intended status: Standards Track A. Morton Intended status: Standards Track A. Morton
Expires: June 26, 2017 AT&T Labs Expires: August 26, 2017 AT&T Labs
R. Rahman R. Rahman
M. Jethanandani M. Jethanandani
Cisco Systems Cisco Systems
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Travelping
L. Zheng February 22, 2017
Huawei Technologies
December 23, 2016
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-02 draft-ietf-ippm-twamp-yang-03
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).
We define the TWAMP data model through Unified Modeling Language We define the TWAMP data model through Unified Modeling Language
(UML) class diagrams and formally specify it using YANG. (UML) class diagrams and formally specify it using YANG.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 26, 2017. This Internet-Draft will expire on August 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 30
3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7 3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7
3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7 3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7
4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8
4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8 4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8
4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 12 4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 12
4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13 4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18
6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 44 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 45
6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 44 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 45
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 47 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 48
6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 48 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 49
7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . 52 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.2. Informative References . . . . . . . . . . . . . . . . . 53 11.1. Normative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 54 11.2. Informative References . . . . . . . . . . . . . . . . . 55
A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 54 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 56
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 57 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 56
A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 58 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 59 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 60
Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 62 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
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, configuration come with a standard management framework and, as such, configuration
depends on proprietary mechanisms developed by the corresponding depends on proprietary mechanisms developed by the corresponding
TWAMP vendor. This document addresses this gap by formally TWAMP vendor. This document addresses this gap by formally
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 as network functions are placed according to orchestration algorithms as
discussed in [I-D.unify-nfvrg-challenges][I-D.unify-nfvrg-devops], discussed in [I-D.unify-nfvrg-challenges][I-D.unify-nfvrg-devops],
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 revisiting the standardization on TWAMP Two major trends call for standardizing TWAMP management aspects.
management aspects. First, we expect that in the coming years large- First, we expect that in the coming years large-scale and multi-
scale and multi-vendor TWAMP deployments will become the norm. From vendor TWAMP deployments will become the norm. From an operations
an operations perspective, dealing with several vendor-specific TWAMP perspective, dealing with several vendor-specific TWAMP configuration
configuration mechanisms is simply unsustainable in this context. mechanisms is simply unsustainable in this context. Second, the
Second, the increasingly software-defined and virtualized nature of increasingly software-defined and virtualized nature of network
network infrastructures, based on dynamic service chains [NSC] and infrastructures, based on dynamic service chains [NSC] and
programmable control and management planes [RFC7426] requires a well- programmable control and management planes [RFC7426] requires a well-
defined data model for TWAMP implementations. This document defines defined data model for TWAMP implementations. This document defines
such a TWAMP data model and specifies it formally using the YANG data such a TWAMP data model and specifies it formally using the YANG data
modeling language [RFC6020]. modeling language [RFC6020].
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 5, line 22 skipping to change at page 5, line 22
| Config server | | Config server | | Config server | | Config server |
| [Fig. 3, 5] | | [Fig. 4, 6] | | [Fig. 3, 5] | | [Fig. 4, 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
We note that the data model defined in this document is orthogonal to The data model defined in this document is orthogonal to the specific
the specific protocol used between the Config client and Config protocol used between the Config client and Config server to
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 perfmormance 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 docuemnt. As noted above, such configuration model defined in this document. As noted above, such
operational actions are not part of the TWAMP specification [RFC5357] operational actions are not part of the TWAMP specification [RFC5357]
and hence are out of scope of this document. See also Appendix B. and hence are out of scope of this document. See also Appendix B.
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.
Global configuration items relate to parameters that are set on a per First, global configuration items relate to parameters that are set
device level. For example, the administrative status of the device on a per device level. For example, the administrative status of the
with respect to whether it allows TWAMP sessions and, if so, in what device with respect to whether it allows TWAMP sessions and, if so,
capacity (e.g. Control-Client, Server or both), are typical in what capacity (e.g. Control-Client, Server or both), is a typical
instances of global configuration items. 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 per
TWAMP-Control connection basis, such as the Server IP address. 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.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
for programmability reasons because at the time of creation of a for 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 o The IP address of the interface the Control-Client will use for
connections. connections.
o The IP address of the remote TWAMP Server. o The IP address of the remote TWAMP Server.
o Authentication and Encryption attributes such as KeyID, Token and o Authentication and encryption attributes such as KeyID, Token and
the Client Initialization Vector (Client-IV); see also the last the Client Initialization Vector (Client-IV); see also the last
paragraph of Section 6 in [RFC4656] and [RFC4086]. paragraph of Section 6 in [RFC4656] and [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 we note the more TWAMP-Test sessions. For each test session we note the
following configuration items: following configuration items:
o The test session name that uniquely identifies a particular test o The test session name that uniquely identifies a particular test
session at the Control-Client and Session-Sender. Similarly to session at the Control-Client and Session-Sender. Similarly to
the control connections above, this unique test session name is the control connections above, this unique test session name is
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 that MUST be identical with the o The test session name that MUST be identical with the
corresponding test session name on the TWAMP Control-Client corresponding test session name on the TWAMP Control-Client
(Section 3.1) (Section 3.1).
o The control connection name, which along with the test session o The control connection name, which along with the test session
name uniquely identify the TWAMP Session-Sender instance name uniquely identify the TWAMP Session-Sender instance.
o Information pertaining to the test packet stream, such as, for o Information pertaining to the test packet stream, such as, for
example, the number of test packets and the packet distribution to example, the number of test packets and the packet distribution to
be employed; see also [RFC3432]. be employed; see also [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 parameter (Section 4.2 sessions. For each test session, the REFWAIT timeout parameter which
of [RFC5357] can be configured. determines whether to discontinue the session if no packets have been
received ([RFC5357], Section 4.2) can be configured.
Read-only access to other data model parameters, such as the Sender Read-only access to other data model parameters, such as the Sender
IP address is foreseen. Each test session can be uniquely identified IP address is foreseen. Each test session can be uniquely identified
by the 4-tuple mentioned in Section 3.2. by the 4-tuple mentioned in Section 3.2.
4. Data Model Parameters 4. Data Model Parameters
This section defines the TWAMP data model using UML and introduces This section defines the TWAMP data model using UML and introduces
selected parameters associated with the four TWAMP logical entities. selected parameters associated with the four TWAMP logical entities.
The complete TWAMP data model specification is provided in the YANG The complete TWAMP data model specification is provided in the YANG
skipping to change at page 9, line 46 skipping to change at page 9, line 46
| 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) which
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 each and encryption Modes. Specifically, mode-preference-chain lists the
priority (expressed as a 16-bit unsigned integer, where zero is the mode and its corresponding priority, expressed as a 16-bit unsigned
highest priority and subsequent values monotonically increasing) with integer, where zero is the highest priority and subsequent values are
their corresponding mode (expressed as a 32-bit Hexadecimal value). monotonically increasing.
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 bit position Note that the list of preferred Modes may set bit position
combinations when necessary, such as when referring to the extended combinations when necessary, such as when referring to the extended
TWAMP features in [RFC5618], [RFC5938], [RFC6038], and [RFC7717]. If TWAMP features in [RFC5618], [RFC5938], [RFC6038], and [RFC7717]. If
the Control-Client cannot determine an acceptable Mode, it MUST the Control-Client cannot determine an acceptable Mode, it MUST
respond with zero Mode bits set in the Set-up Response message, respond with zero Mode bits set in the Set-up Response message,
skipping to change at page 10, line 25 skipping to change at page 10, line 25
In addition, the client container holds a list named key-chain which In addition, the client container holds a list named key-chain which
relates KeyIDs with the respective secret keys. Both the Server and relates KeyIDs with the respective secret keys. Both the Server and
the Control-Client use the same mappings from KeyIDs to shared the Control-Client use the same mappings from KeyIDs to shared
secrets (key-id and secret-key in Figure 3, respectively). The secrets (key-id and secret-key in Figure 3, respectively). The
Server, being prepared to conduct sessions with more than one Server, being prepared to conduct sessions with more than one
Control-Client, uses KeyIDs to choose the appropriate secret-key; a Control-Client, uses KeyIDs to choose the appropriate secret-key; a
Control-Client would typically have different secret keys for Control-Client would typically have different secret keys for
different Servers. The secret-key is the shared secret, an octet different Servers. The secret-key is the shared secret, an octet
string of arbitrary length whose interpretation as a text string is string of arbitrary length whose interpretation as a text string is
unspecified. The key-id and secret-key encoding should follow unspecified. The key-id and secret-key encoding SHOULD follow
Section 9.4 of [RFC6020]. The derived key length (dkLen in Section 9.4 of [RFC6020]. The derived key length (dkLen in
[RFC2898]) MUST be 128-bits for the AES Session-key used for [RFC2898]) MUST be 16 octets for the AES Session-key used for
encryption and a 256-bit HMAC-SHA1 Session-key used for encryption and 32 octets for the HMAC-SHA1 Session-key used for
authentication (see Section 6.10 of [RFC4656]). authentication; see also Section 6.10 of [RFC4656].
Each client container also holds a list of ctrl-connections, where Each client container also holds a list of control connections, where
each item in the list describes a TWAMP control connection that will each item in the list describes a TWAMP control connection initiated
be initiated by this Control-Client. There SHALL be one instance of by this Control-Client. There SHALL be one ctrl-connection per
ctrl-connection per TWAMP-Control (TCP) connection that is to be TWAMP-Control (TCP) connection that is to be initiated from this
initiated from this device. device.
In turn, each ctrl-connection holds a list of test-session-request. In turn, each ctrl-connection holds a list of test-session-request.
test-session-request holds information associated with the Control- test-session-request holds information associated with the Control-
Client for this test session. This includes information that is Client for this test session. This includes information associated
associated with the Request-TW-Session/Accept-Session message with the Request-TW-Session/Accept-Session message exchange (see
exchange (see Section 3.5 of [RFC5357]). Section 3.5 of [RFC5357]).
There SHALL be one instance of test-session-request for each TWAMP- There SHALL be one instance of test-session-request for each TWAMP-
Test session that is to be negotiated by this TWAMP-Control 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 and collecting the respective results, so test-session- sessions so test-session-request holds information related to these
request holds information related to these actions (e.g. pm-index, actions (e.g. pm-index, repeat-interval).
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
are 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 | +------------+
skipping to change at page 12, line 15 skipping to change at page 12, line 15
Each server container holds a list named key-chain which relates Each server container holds a list named key-chain which relates
KeyIDs with the respective secret keys. As mentioned in Section 4.1, KeyIDs with the respective secret keys. As mentioned in Section 4.1,
both the Server and the Control-Client use the same mappings from both the Server and the Control-Client use the same mappings from
KeyIDs to shared secrets. The Server, being prepared to conduct KeyIDs to shared secrets. The Server, being prepared to conduct
sessions with more than one Control-Client, uses KeyIDs to choose the sessions with more than one Control-Client, uses KeyIDs to choose the
appropriate secret-key; a Control-Client would typically have appropriate secret-key; a Control-Client would typically have
different secret keys for different Servers. key-id tells the Server different secret keys for different Servers. key-id tells the Server
which shared-secret the Control-Client wishes to use for which shared-secret the Control-Client wishes to use for
authentication or encryption. authentication or encryption.
Each incoming control connection that is active on the Server will be Each incoming control connection active on the Server is represented
represented by an instance of a ctrl-connection object. There SHALL by a ctrl-connection. There SHALL be one ctrl-connection per
be one instance of ctrl-connection per incoming TWAMP-Control (TCP) incoming TWAMP-Control (TCP) connection that is received and active
connection that is received and active on the Server device. on the Server. Each ctrl-connection can be uniquely identified by
the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}.
All items in the ctrl-connection object are read-only. Each instance All items in the ctrl-connection list are read-only.
of ctrl-connection can be uniquely identified by the 4-tuple {client-
ip, client-tcp-port, server-ip, server-tcp-port}.
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.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
+---------------------------+ +---------------------------+
^ ^
V V
| 1 | 1
+---------------------+ +---------------------+
| packet-distribution | | packet-distribution |
+---------------------+ +---------------------+
| periodic / poisson | | periodic / poisson |
+---------------------+ +---------------------+
| | | |
+-------------------------+ | +-------------------+ |
| periodic-interval | | | periodic-interval | |
| periodic-interval-units | | +-------------------+ |
+-------------------------+ |
| |
+------------------------+ +--------------+
| lambda | | lambda |
| lambda-units | | max-interval |
| max-interval | +--------------+
| truncation-point-units |
+------------------------+
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
skipping to change at page 15, line 27 skipping to change at page 15, line 27
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. This could be problematic if a large Session-Reflector device. This could be problematic if a large
number of test sessions are currently active on that device. 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 the {client-ip, client-tcp-port, server-ip, server-tcp-port} in server/
server/ctrl-connection object. This 4-tuple allows the user to trace ctrl-connection. This 4-tuple allows the user to trace back from the
back from the TWAMP-Test session to the (parent) TWAMP-Control TWAMP-Test session to the (parent) TWAMP-Control connection that
connection that negotiated this test session. 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. artificial line breaks in some tree diagram nodes.
module: ietf-twamp 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 binary
| | +--rw secret-key? string | | +--rw secret-key? binary
| +--rw ctrl-connection* [name] | +--rw ctrl-connection* [name]
| +--rw name string | +--rw name string
| +--rw client-ip? inet:ip-address | +--rw client-ip? inet:ip-address
| +--rw server-ip inet:ip-address | +--rw server-ip inet:ip-address
| +--rw server-tcp-port? inet:port-number | +--rw server-tcp-port? inet:port-number
| +--rw control-packet-dscp? inet:dscp | +--rw control-packet-dscp? inet:dscp
| +--rw key-id? string | +--rw key-id? string
| +--rw max-count? uint32 | +--rw max-count? uint8
| +--ro client-tcp-port? inet:port-number | +--ro client-tcp-port? inet:port-number
| +--ro server-start-time? uint64 | +--ro server-start-time? uint64
| +--ro state? \ | +--ro state? \
control-client-connection-state control-client-connection-state
| +--ro selected-mode? twamp-modes | +--ro selected-mode? twamp-modes
| +--ro token? binary | +--ro token? binary
| +--ro client-iv? binary | +--ro client-iv? binary
| +--rw test-session-request* [name] | +--rw test-session-request* [name]
| +--rw name string | +--rw name string
| +--rw sender-ip? inet:ip-address | +--rw sender-ip? inet:ip-address
| +--rw sender-udp-port? dynamic-port-number | +--rw sender-udp-port? union
| +--rw reflector-ip inet:ip-address | +--rw reflector-ip inet:ip-address
| +--rw reflector-udp-port? dynamic-port-number | +--rw reflector-udp-port? dynamic-port-number
| +--rw timeout? uint64 | +--rw timeout? uint64
| +--rw padding-length? uint32 | +--rw padding-length? uint32
| +--rw test-packet-dscp? inet:dscp | +--rw test-packet-dscp? inet:dscp
| +--rw start-time? uint64 | +--rw start-time? uint64
| +--rw repeat? uint32 | +--rw repeat? union
| +--rw repeat-interval? uint32 | +--rw repeat-interval? uint32
| +--rw pm-reg-list* [pm-index] | +--rw pm-reg-list* [pm-index]
| | +--rw pm-index uint16 | | +--rw pm-index uint16
| +--ro state? test-session-state | +--ro state? test-session-state
| +--ro sid? string | +--ro sid? string
+--rw server! {server}? +--rw server! {server}?
| +--rw admin-state boolean | +--rw admin-state boolean
| +--rw server-tcp-port? inet:port-number | +--rw server-tcp-port? inet:port-number
| +--rw servwait? uint32 | +--rw servwait? uint32
| +--rw control-packet-dscp? inet:dscp | +--rw control-packet-dscp? inet:dscp
| +--rw count? uint32 | +--rw count? uint8
| +--rw max-count? uint32 | +--rw max-count? uint8
| +--rw modes? twamp-modes | +--rw modes? twamp-modes
| +--rw key-chain* [key-id] | +--rw key-chain* [key-id]
| | +--rw key-id string | | +--rw key-id binary
| | +--rw secret-key? string | | +--rw secret-key? binary
| +--ro ctrl-connection* \ | +--ro ctrl-connection* \
[client-ip client-tcp-port server-ip server-tcp-port] [client-ip client-tcp-port server-ip server-tcp-port]
| +--ro client-ip inet:ip-address | +--ro client-ip inet:ip-address
| +--ro client-tcp-port inet:port-number | +--ro client-tcp-port inet:port-number
| +--ro server-ip inet:ip-address | +--ro server-ip inet:ip-address
| +--ro server-tcp-port inet:port-number | +--ro server-tcp-port inet:port-number
| +--ro state? server-ctrl-connection-state | +--ro state? server-ctrl-connection-state
| +--ro control-packet-dscp? inet:dscp | +--ro control-packet-dscp? inet:dscp
| +--ro selected-mode? twamp-modes | +--ro selected-mode? twamp-modes
| +--ro key-id? string | +--ro key-id? string
| +--ro count? uint32 | +--ro count? uint8
| +--ro max-count? uint32 | +--ro max-count? uint8
| +--ro salt? binary | +--ro salt? binary
| +--ro server-iv? binary | +--ro server-iv? binary
| +--ro challenge? binary | +--ro challenge? binary
+--rw session-sender! {session-sender}? +--rw session-sender! {session-sender}?
| +--rw admin-state boolean | +--rw admin-state boolean
| +--rw test-session* [name] | +--rw test-session* [name]
| +--rw name string | +--rw name string
| +--ro ctrl-connection-name? string | +--ro ctrl-connection-name? string
| +--rw fill-mode? padding-fill-mode | +--rw fill-mode? padding-fill-mode
| +--rw number-of-packets? uint32 | +--rw number-of-packets uint32
| +--rw (packet-distribution)? | +--rw (packet-distribution)?
| | +--:(periodic) | | +--:(periodic)
| | | +--rw periodic-interval? uint32 | | | +--rw periodic-interval decimal64
| | | +--rw periodic-interval-units? time-units
| | +--:(poisson) | | +--:(poisson)
| | +--rw lambda? uint32 | | +--rw lambda decimal64
| | +--rw lambda-units? uint32 | | +--rw max-interval? decimal64
| | +--rw max-interval? uint32 | +--ro state? sender-session-state
| | +--rw truncation-point-units? time-units | +--ro sent-packets? uint32
| +--ro state? sender-session-state | +--ro rcv-packets? uint32
| +--ro sent-packets? uint32 | +--ro last-sent-seq? uint32
| +--ro rcv-packets? uint32 | +--ro last-rcv-seq? uint32
| +--ro last-sent-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 \ [sender-ip sender-udp-port \
reflector-ip reflector-udp-port] reflector-ip reflector-udp-port]
+--ro sid? string +--ro sid? string
+--ro sender-ip \ +--ro sender-ip inet:ip-address
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 \ +--ro reflector-udp-port \
dynamic-port-number dynamic-port-number
+--ro parent-connection-client-ip?\ +--ro parent-connection-client-ip? inet:ip-address
inet:ip-address
+--ro parent-connection-client-tcp-port? \ +--ro parent-connection-client-tcp-port? \
inet:port-number inet:port-number
+--ro parent-connection-server-ip? \ +--ro parent-connection-server-ip? inet:ip-address
inet:ip-address
+--ro parent-connection-server-tcp-port? \ +--ro parent-connection-server-tcp-port? \
inet:port-number inet:port-number
+--ro test-packet-dscp? inet:dscp +--ro test-packet-dscp? inet:dscp
+--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
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. defined in this document.
<CODE BEGINS> file "2016-12-23" <CODE BEGINS> file "ietf-twamp@2017-02-22.yang"
module ietf-twamp {
namespace
urn:ietf:params:xml:ns:yang:ietf-twamp;
module ietf-twamp { prefix
//namespace need to be assigned by IANA ietf-twamp;
namespace
urn:ietf:params:xml:ns:yang:ietf-twamp;
prefix
ietf-twamp;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
"IETF IPPM (IP Performance Metrics) Working Group"; "IETF IPPM (IP Performance Metrics) Working Group";
contact contact
draft-ietf-ippm-twamp-yang@tools.ietf.org; draft-ietf-ippm-twamp-yang@tools.ietf.org;
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: The data model covers four TWAMP logical entities, namely,
Control-Client, Server, Session-Sender, and Session-Reflector. Control-Client, Server, Session-Sender, and Session-Reflector,
See Fig. 1 of draft-ietf-ippm-twamp-yang for an illustration as illustrated in the annotated TWAMP logical model (Fig. 1
of the annotated TWAMP logical model. of draft-ietf-ippm-twamp-yang).
The 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 an implementation."; logical entities are supported by a TWAMP implementation.";
revision 2016-07-07 { revision 2017-02-22 {
description description
"Revision appearing in draft-ietf-ippm-twamp-yang-01. "Revision appearing in draft-ietf-ippm-twamp-yang-03.
Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717,
and draft-ietf-ippm-metric-registry";
reference
draft-ietf-ippm-twamp-yang;
}
/* Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and
* Typedefs draft-ietf-ippm-metric-registry";
*/
typedef twamp-modes { reference
type bits { draft-ietf-ippm-twamp-yang;
bit unauthenticated { }
position 0;
description
"Unauthenticated mode, in which no encryption or
authentication is applied. See RFC 7717 Section 7.";
}
bit authenticated {
position 1;
description
"Authenticated mode. See RFC 7717 Section 7
and RFC 4656 Section 6.";
}
bit encrypted {
position 2;
description
"Encrypted mode. See RFC 7717 Section 7 and
RFC 4656 Section 6.";
}
bit unauth-test-encrpyt-control {
position 3;
description
"Mixed Security Mode: TWAMP-Test protocol security
mode in Unauthenticated mode, TWAMP-Control protocol
in Encrypted mode.";
reference
"RFC 5618: Mixed Security Mode for the Two-Way Active
Measurement Protocol (TWAMP)";
}
bit individual-session-control {
position 4;
description
"Individual Session Control.";
reference /*
"RFC 5938: Individual Session Control Feature * Typedefs
for the Two-Way Active Measurement Protocol (TWAMP)"; */
}
bit reflect-octets { typedef twamp-modes {
position 5; type bits {
description bit unauthenticated {
"Reflect Octets Capability."; position 0;
reference description
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP) "Unauthenticated mode, in which no encryption or
Reflect Octets and Symmetrical Size Features"; authentication is applied in TWAMP-Control and TWAMP-Test.
} KeyID, Token, and Client-IV are not used in the
bit symmetrical-size { Set-Up-Response message. See Section 3.1 of RFC 4656.";
position 6; reference
description "RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
"Symmetrical Size Sender Test Packet Format."; }
reference bit authenticated {
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP) position 1;
Reflect Octets and Symmetrical Size Features"; description
} "Authenticated mode, in which the Control-Client and Server
bit IKEv2Derived { possess a shared secret thus prohibiting 'theft of service'.
position 7; As per Section 6 of RFC 4656, in 'authenticated mode, the
description timestamp is in the clear and is not protected
"IKEv2Derived Mode Capability."; cryptographically in any way, while the rest of the message
reference has the same protection as in encrypted mode. This mode
"RFC 7717: IKEv2-Derived Shared Secret Key for allows one to trade off cryptographic protection against
the One-Way Active Measurement Protocol (OWAMP) accuracy of timestamps.'";
and Two-Way Active Measurement Protocol (TWAMP)"; reference
} "RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
}
bit encrypted {
position 2;
description
"Encrypted mode 'makes it impossible to alter
timestamps undetectably.' See also Section 4 of RFC 7717
and Section 6 of RFC 4656.";
reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
}
bit unauth-test-encrpyt-control {
position 3;
description
"When using the Mixed Security Mode, the TWAMP-Test
protocol follows the Unauthenticated mode and the
TWAMP-Control protocol the Encrypted mode.";
reference
"RFC 5618: Mixed Security Mode for the Two-Way Active
Measurement Protocol (TWAMP)";
}
bit individual-session-control {
position 4;
description
"This mode enables individual test sessions using
Session Identifiers.";
reference
"RFC 5938: Individual Session Control Feature
for the Two-Way Active Measurement Protocol (TWAMP)";
}
bit reflect-octets {
position 5;
description
"This mode indicates the reflect octets capability.";
reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features";
}
bit symmetrical-size {
position 6;
description
"This mode indicates support for the symmetrical size
sender test packet format.";
reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features";
}
bit IKEv2Derived {
position 7;
description
"In this mode the the shared key is derived
from an IKEv2 security association (SA).";
reference
"RFC 7717: IKEv2-Derived Shared Secret Key for
the One-Way Active Measurement Protocol (OWAMP)
and Two-Way Active Measurement Protocol (TWAMP)";
} }
description
"Specifies the configurable TWAMP-Modes used during a
TWAMP-Control Connection setup between a Control-Client
and a Server. RFC 7717 Section 7 summarizes the
TWAMP-Modes registry.";
} }
description
"Specifies the configurable TWAMP-Modes supported during a
TWAMP-Control Connection setup between a Control-Client
and a Server. Section 7 of RFC 7717 summarizes the
TWAMP-Modes registry and points to their 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 Server."; "Indicates an active TWAMP-Control connection to Server.";
} }
enum idle { enum idle {
description description
"Indicates an idle TWAMP-Control connection to Server."; "Indicates an idle TWAMP-Control connection to Server.";
}
} }
description "Control-Client control connection state";
} }
description
"Indicates the Control-Client TWAMP-Control connection state.";
}
typedef test-session-state { typedef test-session-state {
type enumeration { type enumeration {
enum accepted { enum accepted {
value 0; value 0;
description description
"Indicates that the TWAMP-Test session request "Indicates that accepted TWAMP-Test session request.";
is accepted."; }
} enum failed {
enum failed { value 1;
value 1; description
description "Indicates a TWAMP-Test session failure due to
"Indicates a TWAMP-Test session failure due to some unspecified reason (catch-all).";
some unspecified reason (catch-all)."; }
} enum internal-error {
enum internal-error { value 2;
value 2; description
description "Indicates a TWAMP-Test session failure due to
"Indicates a TWAMP-Test session failure due to an internal error.";
an internal error."; }
} enum not-supported {
enum not-supported { value 3;
value 3; description
description "Indicates a TWAMP-Test session failure because
"Indicates a TWAMP-Test session failure because some aspect of the TWAMP-Test session request
some aspect of the TWAMP-Test session request is not supported.";
is not supported."; }
} enum permanent-resource-limit {
enum permanent-resource-limit { value 4;
value 4; description
description "Indicates a TWAMP-Test session failure due to
"Indicates a TWAMP-Test session failure due to permanent resource limitations.";
permanent resource limitations."; }
} 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 "TWAMP-Test session state";
} }
description
"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 "Indicates an active TWAMP-Control connection description
"Indicates an active TWAMP-Control connection
to the Control-Client."; to the Control-Client.";
}
enum servwait {
description "Indicates that the TWAMP-Control connection
to the Control-Client is in SERVWAIT according to RFC 5357
(Section 3.1): [a] Server MAY discontinue any established
control connection when no packet associated with that
connection has been received within SERVWAIT seconds.";
}
} }
description "Server control connection state"; enum servwait {
description
"Indicates that the TWAMP-Control connection to the
Control-Client is in SERVWAIT as per the definition of
Section 3.1 of RFC 5357.";
}
} }
description
"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
"Indicates that the TWAMP-Test session is active."; "Indicates that the TWAMP-Test session is active.";
} }
enum failure { enum failure {
description description
"Indicates that the TWAMP-Test session has failed."; "Indicates that the TWAMP-Test session has failed.";
}
} }
description "Session-Sender session state.";
} }
description
"Indicates the Session-Sender TWAMP-Test session state.";
}
typedef padding-fill-mode { typedef padding-fill-mode {
type enumeration { type enumeration {
enum zero { enum zero {
description "Packets will be padded with description
all zeros"; "TWAMP-Test packets are padded with all zeros.";
} }
enum random { enum random {
description "Packets will be padded with description
pseudo-random numbers"; "TWAMP-Test packets are padded with pseudo-random
} numbers.";
} }
description "Indicates what type of packet padding is
to be used for the UDP TWAMP-Test packets.";
} }
description
"Indicates what type of packet padding is used in the
TWAMP-Test packets.";
}
typedef time-units { typedef dynamic-port-number {
type enumeration { type inet:port-number {
enum s { range 49152..65535;
description "Seconds."; }
description "Dynamic range for port numbers.";
}
/*
* Features
*/
feature control-client {
description
"Indicates that the device supports configuration of the
TWAMP Control-Client logical entity.";
}
feature server {
description
"Indicates that the device supports configuration of the
TWAMP Server logical entity.";
}
feature session-sender {
description
"Indicates that the device supports configuration of the
TWAMP Session-Sender logical entity.";
}
feature session-reflector {
description
"Indicates that the device supports configuration of the
TWAMP Session-Reflector logical entity.";
}
/*
* Reusable node groups
*/
grouping key-management {
list key-chain {
key key-id;
leaf key-id {
type binary {
length 1..80;
} }
enum ms { description
description "Milliseconds."; "KeyID used for a TWAMP-Control connection. As per
} Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
enum us { 80 octets in length' and is used to select which 'shared
description "Microseconds."; shared secret the [Control-Client] wishes to use to
authenticate or encrypt'.";
} }
enum ns { leaf secret-key {
description "Nanoseconds."; type binary;
description
"The secret key corresponding to the KeyID for this
TWAMP-Control connection.";
} }
} description
description "TWAMP configuration parameters time units."; "Relates KeyIDs with their respective secret keys
in a TWAMP-Control connection.";
} }
description
"Used by the Control-Client and Server for TWAMP-Control
key management.";
}
typedef dynamic-port-number { grouping maintenance-statistics {
type inet:port-number { leaf sent-packets {
range 49152..65535; type uint32;
} config false;
description "Dynamic range for port numbers"; description "Indicates the number of packets sent.";
} }
/* leaf rcv-packets {
* Features type uint32;
*/ config false;
description "Indicates the number of packets received.";
feature control-client { }
description leaf last-sent-seq {
"Indicates that the device supports configuration type uint32;
of the TWAMP Control-Client."; config false;
description "Indicates the last sent sequence number.";
} }
feature server { leaf last-rcv-seq {
description type uint32;
"Indicates that the device supports configuration config false;
of the TWAMP Server."; description "Indicates the last received sequence number.";
} }
description "Used for TWAMP-Test maintenance statistics.";
}
feature session-sender { grouping count {
leaf count {
type uint8 {
range "10..31";
}
default 10;
description description
"Indicates that the device supports configuration "Parameter communicated to the Control-Client as part of the
of the TWAMP Session-Sender."; Server Greeting message and used for deriving a key from a
} shared secret as per Section 3.1 of RFC 4656: MUST be a
power of 2 and at least 1024; SHOULD be increased as more
computing power becomes common.";
}
description
"Reusable data structure for count which is used both in the
Server container.";
}
feature session-reflector { grouping max-count {
leaf max-count {
type uint8 {
range "10..31";
}
default 15;
description description
"Indicates that the device supports configuration "This parameter limits the maximum Count value, which MUST
of the TWAMP Session-Reflector."; be a power of 2 and at least 1024 as per RFC 5357. It is
} configured by providing said power. For example,
/* configuring 10 here means max count 2^10 = 1024.
* Reusable node groups The default is 15, meaning 2^15 = 32768.
*/
grouping key-management { A TWAMP Server uses this configured value in the
Server-Greeting message sent to the Control-Client.
list key-chain { A TWAMP Control-Client uses this configured value to prevent
key key-id; denial-of-service (DOS) attacks by closing the control
leaf key-id { connection to the Server if it 'receives a Server-Greeting
type string { message with Count greater that its maximum configured value',
length 1..80; as per Section 6 of RFC 5357.
}
description
"KeyID to be used for a TWAMP-Control connection.";
}
leaf secret-key { Further, note that according to Section 6 of RFC 5357:
type string;
description
"The corresponding secret key for the
TWAMP-Control connection.";
}
description
"Relates KeyIDs with the respective secret keys
for a TWAMP-Control connection.";
}
description "TWAMP-Control key management.";
}
grouping maintenance-statistics { 'If an attacking system sets the maximum value in
Count (2**32), then the system under attack would stall
for a significant period of time while it attempts to
generate keys.
leaf sent-packets { TWAMP-compliant systems SHOULD have a configuration
type uint32; control to limit the maximum count value. The default
config false; max-count value SHOULD be 32768.'
description "Packets sent";
}
leaf rcv-packets { RFC 5357 does not qualify 'significant period' in terms of
type uint32; time, but it is clear that this depends on the processing
config false; capacity available and operators need to pay attention to
description "Packets received"; this security consideration.";
} }
description
"Reusable data structure for max-count which is used both at
the Control-Client and the Server containers.";
}
leaf last-sent-seq { /*
type uint32; * Configuration data nodes
config false; */
description "Last sent sequence number";
}
leaf last-rcv-seq {
type uint32;
config false;
description "Last received sequence number";
}
description "TWAMP-Test maintenance statistics";
}
/* container twamp {
* Configuration data nodes description
*/ "TWAMP logical entity configuration grouping of four models
which correspond to the four TWAMP logical entities
Control-Client, Server, Session-Sender, and Session-Reflector
as illustrated in Fig. 1 of draft-ietf-ippm-twamp-yang.";
container twamp { container client {
if-feature control-client;
presence "Enables TWAMP Control-Client functionality.";
description description
"TWAMP logical entity configuration grouping."; "Configuration of the TWAMP Control-Client logical entity.";
container client { leaf admin-state {
if-feature control-client; type boolean;
presence client; mandatory true;
description description
"Configuration of the TWAMP Control-Client logical entity."; "Indicates whether the device is allowed to operate as a
TWAMP Control-Client.";
}
leaf admin-state { list mode-preference-chain {
type boolean; key priority;
unique mode;
leaf priority {
type uint16;
description
"Indicates the Control-Client Mode preference priority
expressed as a 16-bit unsigned integer, where zero is the
highest priority and subsequent values monotonically
increasing.";
}
leaf mode {
type twamp-modes;
description
"The supported TWAMP Mode matching the corresponding
priority.";
}
description
"Indicates the Control-Client preferred order of use of
the supported TWAMP Modes.
Depending on the Modes available in the TWAMP Server
Greeting message (see Fig. 2 of RFC 7717), the
this Control-Client MUST choose the highest priority Mode
from the configured mode-preference-chain list.";
}
uses key-management;
list ctrl-connection {
key name;
description
"List of TWAMP Control-Client control connections.
Each item in the list describes a control connection
that will be initiated by this Control-Client";
leaf name {
type string;
description
"A unique name used as a key to identify this individual
TWAMP-Control connection on the Control-Client device.";
}
leaf client-ip {
type inet:ip-address;
description
"The IP address of the local Control-Client device,
to be placed in the source IP address field of the
IP header in TWAMP-Control (TCP) packets belonging
to this control connection. If not configured, the
device SHALL choose its own source IP address.";
}
leaf server-ip {
type inet:ip-address;
mandatory true; mandatory true;
description description
"Indicates whether the device is allowed to operate "The IP address of the remote Server device, which the
as a TWAMP Control-Client."; TWAMP-Control connection will be initiated to.";
} }
list mode-preference-chain { leaf server-tcp-port {
key priority; type inet:port-number;
unique mode; default 862;
leaf priority { description
type uint16; "This parameter defines the TCP port number that is
description "Priority."; to be used by this outgoing TWAMP-Control connection.
Typically, this is the well-known TWAMP-Control
port number (862) as per RFC 5357 However, there are known
realizations of TWAMP in the field that were implemented
before this well-known port number was allocated. These
early implementations allowed the port number to be
configured. This parameter is therefore provided for
backward compatibility reasons.";
}
leaf control-packet-dscp {
type inet:dscp;
default 0;
description
"The DSCP value to be placed in the IP header of
TWAMP-Control (TCP) packets generated by this
Control-Client.";
}
leaf key-id {
type string {
length 1..80;
} }
leaf mode { description
type twamp-modes; "Indicates the KeyID value selected for this
description "Supported TWAMP Mode."; TWAMP-Control connection.";
}
uses max-count;
leaf client-tcp-port {
type inet:port-number;
config false;
description
"Indicates the source TCP port number used in the
TWAMP-Control packets belonging to this control
connection.";
}
leaf server-start-time {
type uint64;
config false;
description
"Indicates the Start-Time advertized by the Server in the
Server-Start message (RFC 4656, Section 3.1),
representing the time when the current
instantiation of the Server started operating.
The timestamp format follows RFC 1305
according to Section 4.1.2 of RFC 4656.";
}
leaf state {
type control-client-connection-state;
config false;
description
"Indicates the current state of the TWAMP-Control
connection state.";
}
leaf selected-mode {
type twamp-modes;
config false;
description
"The TWAMP Mode that the Control-Client has chosen for
this control connection as set in the Mode field of the
Set-Up-Response message (RFC 4656, Section 3.1).";
}
leaf token {
type binary {
length 64;
} }
config false;
description description
"Indicates the preferred order of use for the "This parameter holds the 64 octets containing the
corresponding supported TWAMP Modes"; concatenation of a 16-octet Challenge, a 16-octet AES
Session-key used for encryption, and a 32-octet
HMAC-SHA1 Session-key used for authentication; see also
the last paragraph of Section 6 in RFC 4656.
If the Mode defined in RFC 7717 is selected (selected-mode),
Token is limited to 16 octets.";
reference
"RFC 4086: Randomness Requirements for Security
RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way
Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)";
} }
uses key-management;
list ctrl-connection { leaf client-iv {
type binary {
length 16;
}
config false;
description
"Indicates the Control-Client Initialization Vector
(Client-IV), that is generated randomly by the
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 (selected-mode),
Client-IV is limited to 12 octets.";
reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)
RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way
Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)"; }
list test-session-request {
key name; key name;
description description
"List of TWAMP Control-Client control connections. "Information associated with the Control-Client
Each item in the list describes a control connection for this test session";
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 individual "A unique name to be used for identification of
TWAMP control connection on the Control-Client device."; this TWAMP-Test session on the Control-Client.";
}
leaf client-ip {
type inet:ip-address;
description
"The IP address of the local Control-Client device,
to be placed in the source IP address field of the
IP header in TWAMP-Control (TCP) packets belonging
to this control connection. If not configured, the
device SHALL choose its own source IP address.";
} }
leaf server-ip {
leaf sender-ip {
type inet:ip-address; type inet:ip-address;
mandatory true;
description description
"The IP address belonging to the remote Server device, "The IP address of the Session-Sender device,
which the TWAMP-Control connection will be which is to be placed in the source IP address
initiated to."; field of the IP header in TWAMP-Test (UDP) packets
} belonging to this test session. This value will be
used to populate the sender address field of the
Request-TW-Session message.
leaf server-tcp-port { If not configured, the device SHALL choose its own
type inet:port-number; source IP address.";
default 862;
description
"This parameter defines the TCP port number that is
to be used by this outgoing TWAMP-Control connection.
Typically, this is the well-known TWAMP port number (862)
as per RFC 5357 However, there are known
realizations of TWAMP in the field that were implemented
before this well-known port number was allocated. These
early implementations allowed the port number to be
configured. This parameter is therefore provided for
backward compatibility reasons.";
}
leaf control-packet-dscp {
type inet:dscp;
default 0;
description
"The DSCP value to be placed in the IP header of
TWAMP-Control (TCP) packets generated by this
Control-Client.";
} }
leaf key-id { leaf sender-udp-port {
type string { type union {
length 1..80; type dynamic-port-number;
type enumeration {
enum autoallocate {
description
"Indicates that the Contol-Client will
auto-allocate the TWAMP-Test (UDP) port number
from the dynamic port range.";
}
}
} }
default autoallocate;
description description
"The KeyID value that is selected "The UDP port number that is to be used by
for this TWAMP-Control connection."; the Session-Sender for this TWAMP-Test session.
The number is restricted to the dynamic port range.
}
leaf max-count { By default the Control-Client SHALL auto-allocate a
type uint32 { UDP port number for this TWAMP-Test session.
range 1024..4294967295;
}
default 32768;
description
"This parameter limits the maximum Count value.
If an attacking system sets the maximum value in The configured (or auto-allocated) value is advertized
Count (2**32), then the system under attack would stall in the Sender Port field of the Request-TW-session
for a significant period of time while it attempts to message (see Section 3.5 of RFC 5357). Note that
generate keys."; in the scenario where a device auto-allocates a UDP
port number for a session, and the repeat parameter
for that session indicates that it should be
repeated, the device is free to auto-allocate a
different UDP port number when it negotiates the
next (repeated) iteration of this session.";
} }
leaf client-tcp-port { leaf reflector-ip {
type inet:port-number; type inet:ip-address;
config false; mandatory true;
description description
"The source TCP port number used in the TWAMP-Control "The IP address belonging to the remote
packets belonging to this control connection."; Session-Reflector device to which the TWAMP-Test
session will be initiated. This value will be
used to populate the receiver address field of
the Request-TW-Session message.";
} }
leaf server-start-time { leaf reflector-udp-port {
type uint64; type dynamic-port-number;
config false;
description description
"The Start-Time advertized by the Server in the "This parameter defines the UDP port number that
Server-Start message (RFC 4656, Section 3.1). This is will be used by the Session-Reflector for
a timestamp representing the time when the current this TWAMP-Test session. The number is restricted
instantiation of the Server started operating."; to the dynamic port range and is to be placed in
the Receiver Port field of the Request-TW-Session
message.";
} }
leaf state { leaf timeout {
type control-client-connection-state; type uint64;
config false; units seconds;
default 2;
description description
"Indicates the currest state of the TWAMP-Control "The length of time (in seconds) that the
connection state."; Session-Reflector should continue to respond to
} packets belonging to this TWAMP-Test session after
a Stop-Sessions TWAMP-Control message has been
received (RFC 5357, Section 3.8).
leaf selected-mode { This value will be placed in the Timeout field of
type twamp-modes; the Request-TW-Session message.";
config false;
description
"The TWAMP Mode that the Control-Client has chosen for
this control connection as set in the Mode field of the
Set-Up-Response message (RFC 4656, Section 3.1).";
} }
leaf token { leaf padding-length {
type binary { type uint32 {
length 64; range 64..4096;
} }
config false;
description description
"This parameter holds the 64 octets containing the "The number of padding bytes to be added to the
concatenation of a 16-octet Challenge, a 16-octet AES TWAMP-Test (UDP) packets generated by the
Session-key used for encryption, and a 32-octet Session-Sender.
HMAC-SHA1 Session-key used for authentication.
AES Session-key and HMAC Session-key are generated This value will be placed in the Padding Length
randomly by the Control-Client. AES Session-key and field of the Request-TW-Session message
HMAC Session-key MUST be generated with sufficient (RFC 4656, Section 3.5).";
entropy not to reduce the security of the underlying
cipher. The token itself is encrypted
using the AES (Advanced Encryption Standard) in
Cipher Block Chaining (CBC). Encryption MUST be
performed using an Initialization Vector (IV)
of zero and a key derived from the shared secret
associated with KeyID. Challenge is the same as
transmitted by the Server in the clear; see also the
last paragraph of Section 6 in RFC 4656.";
reference
"RFC 4086: Randomness Requirements for Security";
} }
leaf client-iv { leaf test-packet-dscp {
type binary { type inet:dscp;
length 16; default 0;
}
config false;
description description
"The Control-Client Initialization Vector (Client-IV) "The DSCP value to be placed in the IP header
is generated randomly by the Control-Client. of TWAMP-Test packets generated by the
Session-Sender, and in the UDP header of the
TWAMP-Test response packets generated by the
Session-Reflector for this test session.
Client-IV merely needs to be unique (i.e., it MUST This value will be placed in the Type-P Descriptor
never be repeated for different sessions using the field of the Request-TW-Session message (RFC 5357).";
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.";
} }
list test-session-request { leaf start-time {
key name; type uint64;
default 0;
description description
"Information associated with the Control-Client "Time when the session is to be started
for this test session"; (but not before the TWAMP Start-Sessions command
is issued; see Section 3.4 of RFC 5357).
leaf name {
type string;
description
"A unique name to be used for identification of
this TWAMP-Test session on the Control-Client.";
}
leaf sender-ip { The start-time value is placed in the Start Time
type inet:ip-address; field of the Request-TW-Session message.
description
"The IP address of the Session-Sender device,
which is to be placed in the source IP address
field of the IP header in TWAMP-Test (UDP) packets
belonging to this test session. This value will be
used to populate the sender address field of the
Request-TW-Session message. If not configured,
the device SHALL choose its own source IP address.";
}
leaf sender-udp-port { The timestamp format follows RFC 1305 as per
type dynamic-port-number; Section 3.5 of RFC 4656.
description
"The UDP port number that is to be used by
the Session-Sender for this TWAMP-Test session.
The number is restricted to the dynamic port range.
A value of zero indicates that the Control-Client
SHALL auto-allocate a UDP port number for this
TWAMP-Test session. The configured
(or auto-allocated) value is advertized in the
Sender Port field of the Request-TW-session message
(see also Section 3.5 of RFC 5357. Note that in the
scenario where a device auto-allocates a UDP port
number for a session, and the repeat parameter
for that session indicates that it should be
repeated, the device is free to auto-allocate a
different UDP port number when it negotiates the
next (repeated) iteration of this session.";
}
leaf reflector-ip { The default value of 0 indicates that the session
type inet:ip-address; will be started as soon as the Start-Sessions message
mandatory true; is received.";
description }
"The IP address belonging to the remote
Session-Reflector device to which the TWAMP-Test
session will be initiated. This value will be
used to populate the receiver address field of
the Request-TW-Session message.";
}
leaf reflector-udp-port { leaf repeat {
type dynamic-port-number; type union {
description type uint32 {
"This parameter defines the UDP port number that range 0..4294967294;
will be used by the Session-Reflector for }
this TWAMP-Test session. The number is restricted type enumeration {
to the dynamic port range and is to be placed in enum forever {
the Receiver Port field of the Request-TW-Session description
message. If this value is not set, the device SHALL "Indicates that the test session SHALL be
use the same port number as defined in the repeated *forever* using the information in
server-tcp-port parameter of this repeat-interval parameter, and SHALL NOT
test-session-request's parent decrement the value.";
twamp/client/ctrl-connection."; }
}
} }
default 0;
description
"This value determines if the TWAMP-Test session must
be repeated. When a test session has completed, the
repeat parameter is checked.
leaf timeout { The default value of 0 indicates that the session
type uint64; MUST NOT be repeated.
default 2;
description
"The length of time (in seconds) that the
Session-Reflector should continue to respond to
packets belonging to this TWAMP-Test session after
a Stop-Sessions TWAMP-Control message has been
received (RFC 5357, Section 3.8).
This value will be placed in the Timeout field of If the repeat value is 1 through 4,294,967,294
the Request-TW-Session message."; then the test session SHALL be repeated using the
} information in repeat-interval parameter, and the
parent TWAMP-Control connection for this test
session is restarted to negotiate a new instance
of this TWAMP-Test session. The implementation
MUST decrement the value of repeat after
determining a repeated session is expected.";
}
leaf padding-length { leaf repeat-interval {
type uint32 { when "../repeat!='0'" {
range 64..4096;
}
description description
"The number of padding bytes to be added to the "This parameter determines the timing of repeated
TWAMP-Test (UDP) packets generated by the TWAMP-Test sessions when repeat is more than 0.
Session-Sender.
This value will be placed in the Padding Length When the value of repeat-interval is 0, the
field of the Request-TW-Session message negotiation of a new test session SHALL begin
(RFC 4656, Section 3.5)."; immediately after the previous test session
completes. Otherwise, the Control-Client will
wait for the number of seconds specified in the
repeat-interval parameter before negotiating the
new instance of this TWAMP-Test session.";
} }
type uint32;
units seconds;
default 0;
description "Repeat interval (in seconds).";
}
leaf test-packet-dscp { list pm-reg-list {
type inet:dscp; key pm-index;
leaf pm-index {
type uint16;
description description
"The DSCP value to be placed in the IP header "Numerical index value of a Registered Metric
of TWAMP-Test packets generated by the in the Performance Metric Registry
Session-Sender, and in the UDP header of the (see ietf-ippm-metric-registry). Output statistics
TWAMP-Test response packets generated by the are specified in the corresponding Registry entry.";
Session-Reflector for this test session.
This value will be placed in the Type-P Descriptor
field of the Request-TW-Session message (RFC 5357).";
} }
description
"A list of one or more Performance Metric Registry
Index values, which communicate packet stream
characteristics along with one or more metrics
to be measured.
leaf start-time { All members of the pm-reg-list MUST have the same
type uint64; stream characteristics, such that they combine
default 0; to specify all metrics that shall be measured on
description a single stream.";
"Time when the session is to be started reference
(but not before the TWAMP Start-Sessions command "ietf-ippm-metric-registry:
is issued; see RFC 5357, Section 3.4). Registry for Performance Metrics";
}
leaf state {
type test-session-state;
config false;
description
"Indicates the TWAMP-Test session state (accepted or
indication of an error); see Section 3.5 of
RFC 5357.";
}
leaf sid {
type string;
config false;
description
"The SID allocated by the Server for this TWAMP-Test
session, and communicated back to the Control-Client
in the SID field of the Accept-Session message;
see Section 4.3 of RFC 6038.";
}
}
}
}
The start-time value is placed in the Start Time container server {
field of the Request-TW-Session message. if-feature server;
presence "Enables TWAMP Server functionality.";
description "Configuration of the TWAMP Server logical entity.";
leaf admin-state {
type boolean;
mandatory true;
description
"Indicates whether the device is allowed to operate
as a TWAMP Server.";
}
The default value of 0 indicates that the session leaf server-tcp-port {
will be started as soon as the Start-Sessions message type inet:port-number;
is received."; default 862;
} description
"This parameter defines the well known TCP port number
that is used by TWAMP-Control. The Server will listen
on this port number for incoming TWAMP-Control
connections. Although this is defined as a fixed value
(862) in RFC 5357, there are several realizations of
TWAMP in the field that were implemented before this
well-known port number was allocated. These early
implementations allowed the port number to be
configured. This parameter is therefore provided for
backward compatibility reasons.";
}
leaf repeat { leaf servwait {
type uint32; type uint32 {
default 0; range 1..604800;
description }
"This value determines if the TWAMP-Test session must units seconds;
be repeated. When a test session has completed, the default 900;
repeat parameter is checked. description
"TWAMP-Control (TCP) session timeout, in seconds.
According to Section 3.1 of RFC 5357,
The value of 0 indicates that the session MUST NOT be Server MAY discontinue any established control
repeated. connection when no packet associated with that
connection has been received within SERVWAIT seconds.";
}
If the value is 1 through 4,294,967,294 then the test leaf control-packet-dscp {
session SHALL be repeated using the information in type inet:dscp;
repeat-interval parameter, and the parent description
TWAMP-Control connection for this test session is "The DSCP value to be placed in the IP header of
restarted to negotiate a new instance of this TWAMP-Control (TCP) packets generated by the Server.
TWAMP-Test session. The implementation MUST decrement
the value of repeat after determining a repeated
session is expected.
The value of 4,294,967,295 indicates that the test Section 3.1 of RFC 5357 specifies that the server
session SHALL be repeated *forever* using the SHOULD use the DSCP value from the Control-Client's
information in repeat-interval parameter, and TCP SYN. However, for practical purposes TWAMP will
SHALL NOT decrement the value."; typically be implemented using a general purpose TCP
} stack provided by the underlying operating system,
and such a stack may not provide this information to the
user. Consequently, it is not always possible to
implement the behavior described in RFC 5357 in an
OS-portable version of TWAMP.
leaf repeat-interval { The default behavior if this item is not set is to use
when "../repeat!='0'" { the DSCP value from the Control-Client's TCP SYN,
description as per Section 3.1 of RFC 5357.";
"This parameter determines the timing of repeated }
test sessions when repeat is more than 0.
When the value of repeat-interval is 0, the uses count;
negotiation of a new test session SHALL begin
immediately after the previous test session
completes. Otherwise, the Control-Client will
wait for the number of minutes specified in the
repeat-interval parameter before negotiating the
new instance of this TWAMP-Test session.";
}
type uint32;
default 0;
description "Repeat interval (in minutes)";
}
list pm-reg-list { uses max-count;
key pm-index;
leaf pm-index {
type uint16;
description
"Numerical index value of a Registered Metric
in the Performance Metric Registry
(see ietf-ippm-metric-registry). Output statistics
are specified in the corresponding Registry entry.";
}
description
"A list of one or more Performance Metric Registry
Index values, which communicate packet stream
characteristics along with one or more metrics
to be measured.
All members of the pm-reg-list MUST have the same leaf modes {
stream characteristics, such that they combine type twamp-modes;
to specify all metrics that shall be measured on description
a single stream."; "The bit mask of TWAMP Modes this Server instance
reference is willing to support; see IANA TWAMP Modes Registry.";
"ietf-ippm-metric-registry:
Registry for Performance Metrics";
}
leaf state {
type test-session-state;
config false;
description
"Indicates the TWAMP-Test session state (accepted or
indication of an error); see Section 3.5 of
RFC 5357.";
}
leaf sid {
type string;
config false;
description
"The SID allocated by the Server for this TWAMP-Test
session, and communicated back to the Control-Client
in the SID field of the Accept-Session message;
see Section 4.3 of RFC 6038.";
}
}
}
} }
container server { uses key-management;
if-feature server;
presence server; list ctrl-connection {
key "client-ip client-tcp-port server-ip server-tcp-port";
config false;
description description
"Configuration of the TWAMP Server logical entity."; "List of all incoming TWAMP-Control (TCP) connections.";
leaf admin-state { leaf client-ip {
type boolean; type inet:ip-address;
mandatory true;
description description
"Indicates whether the device is allowed to operate "The IP address on the remote Control-Client device,
as a TWAMP Server."; which is the source IP address used in the
TWAMP-Control (TCP) packets belonging to this control
connection.";
}
leaf client-tcp-port {
type inet:port-number;
description
"The source TCP port number used in the TWAMP-Control
(TCP) packets belonging to this control connection.";
}
leaf server-ip {
type inet:ip-address;
description
"The IP address of the local Server device, which is
the destination IP address used in the
TWAMP-Control (TCP) packets belonging to this control
connection.";
} }
leaf server-tcp-port { leaf server-tcp-port {
type inet:port-number; type inet:port-number;
default 862;
description description
"This parameter defines the well known TCP port number "The destination TCP port number used in the
that is used by TWAMP-Control. The Server will listen TWAMP-Control (TCP) packets belonging to this
on this port number for incoming TWAMP-Control control connection. This will usually be the
connections. Although this is defined as a fixed value same value as the server-tcp-port configured
(862) in RFC 5357, there are several realizations of under twamp/server. However, in the event that
TWAMP in the field that were implemented before this the user re-configured server/server-tcp-port
well-known port number was allocated. These early after this control connection was initiated, this
implementations allowed the port number to be value will indicate the server-tcp-port that is
configured. This parameter is therefore provided for actually in use for this control connection.";
backward compatibility reasons.";
} }
leaf servwait { leaf state {
type uint32 { type server-ctrl-connection-state;
range 1..604800;
}
default 900;
description description
"TWAMP-Control (TCP) session timeout, in seconds "Indicates the Server TWAMP-Control connection state.";
(RFC 5357, Section 3.1)).";
} }
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 used in the IP header of the
TWAMP-Control (TCP) packets generated by the Server. TWAMP-Control (TCP) packets sent by the Server
for this control connection. This will usually
Section 3.1 of RFC 5357 specifies that the server be the same value as is configured in the
SHOULD use the DSCP value from the Control-Client's control-packet-dscp parameter under the twamp/server
TCP SYN. However, for practical purposes TWAMP will container. However, in the event that the user
typically be implemented using a general purpose TCP re-configures server/dscp after this control
stack provided by the underlying operating system, connection is already in progress, this read-only
and such a stack may not provide this information to the value will show the actual dscp value in use by this
user. Consequently, it is not always possible to TWAMP-Control connection.";
implement the behavior described in RFC 5357 in an
OS-portable version of TWAMP. The default behavior if
this item is not set is to use the DSCP value from
the Control-Client's TCP SYN, as per Section 3.1
of RFC 5357.";
} }
leaf count { leaf selected-mode {
type uint32 { type twamp-modes;
range 1024..4294967295;
}
description description
"Parameter used in deriving a key from a shared "The Mode that was chosen for this TWAMP-Control
secret as described in Section 3.1 of RFC 4656, connection as set in the Mode field of the
and are communicated to the Control-Client as part Set-Up-Response message.";
of the Server Greeting message.
count MUST be a power of 2.
count MUST be at least 1024.
count SHOULD be increased as more computing power
becomes common.";
} }
leaf max-count {
type uint32 { leaf key-id {
range 1024..4294967295; type string {
length 1..80;
} }
default 32768;
description description
"This parameter limits the maximum Count value. "The KeyID value that is in use by this TWAMP-Control
connection as selected by Control-Client.";
If an attacking system sets the maximum value in
Count (2**32), then the system under attack would stall
for a significant period of time while it attempts to
generate keys.
TWAMP-compliant systems SHOULD have a configuration
control to limit the maximum count value. The
default max-count value SHOULD be 32768.";
} }
leaf modes { uses count {
type twamp-modes;
description description
"The bit mask of TWAMP Modes this Server instance "The count value that is in use by this TWAMP-Control
is willing to support; see IANA TWAMP Modes Registry."; connection. This will usually be the same value
as is configured under twamp/server. However, in the
event that the user re-configured server/count
after this control connection is already in progress,
this read-only value will show the actual count that
is in use for this TWAMP-Control connection.";
} }
uses key-management; uses max-count {
list ctrl-connection {
key
"client-ip client-tcp-port server-ip server-tcp-port";
config false;
description description
"List of all incoming TWAMP-Control (TCP) connections"; "This read-only value indicates the actual max-count in use
for this control connection. Usually this would be the
leaf client-ip { same value as configured under twamp/server.";
type inet:ip-address; }
description
"The IP address on the remote Control-Client device,
which is the source IP address used in the
TWAMP-Control (TCP) packets belonging to this control
connection.";
}
leaf client-tcp-port {
type inet:port-number;
description
"The source TCP port number used in the TWAMP-Control
(TCP) packets belonging to this control connection.";
}
leaf server-ip {
type inet:ip-address;
description
"The IP address of the local Server device, which is
the destination IP address used in the
TWAMP-Control (TCP) packets belonging to this control
connection.";
}
leaf server-tcp-port {
type inet:port-number;
description
"The destination TCP port number used in the
TWAMP-Control (TCP) packets belonging to this
control connection. This will usually be the
same value as the server-tcp-port configured
under twamp/server. However, in the event that
the user re-configured server/server-tcp-port
after this control connection was initiated, this
value will indicate the server-tcp-port that is
actually in use for this control connection.";
}
leaf state {
type server-ctrl-connection-state;
description
"Indicates the Server TWAMP-Control connection state.";
}
leaf control-packet-dscp {
type inet:dscp;
description
"The DSCP value used in the IP header of the
TWAMP-Control (TCP) packets sent by the Server
for this control connection. This will usually
be the same value as is configured in the
control-packet-dscp parameter under the twamp/server
container. However, in the event that the user
re-configures server/dscp after this control
connection is already in progress, this read-only
value will show the actual dscp value in use by this
TWAMP-Control connection.";
}
leaf selected-mode { leaf salt {
type twamp-modes; type binary {
description length 16;
"The Mode that was chosen for this TWAMP-Control
connection as set in the Mode field of the
Set-Up-Response message.";
} }
description
"A parameter used in deriving a key from a
shared secret as described in Section 3.1 of RFC 4656.
It is communicated to the Control-Client as part of
the Server Greeting message.";
}
leaf key-id { leaf server-iv {
type string { type binary {
length 1..80; length 16;
}
description
"The KeyID value that is in use by this TWAMP-Control
connection as selected by Control-Client.";
} }
description
"The Server Initialization Vector
(IV) generated randomly by the Server.";
leaf count { }
type uint32 {
range 1024..4294967295;
}
description
"The count value that is in use by this TWAMP-Control
connection. This will usually be the same value
as is configured under twamp/server. However, in the
event that the user re-configured server/count
after this control connection is already in progress,
this read-only value will show the actual count that
is in use for this TWAMP-Control connection.";
}
leaf max-count { leaf challenge {
type uint32 { type binary {
range 1024..4294967295; length 16;
}
description
"The max-count value that is in use by this
TWAMP-Control connection. This will usually be the
same value as is configured under twamp/server. However,
in the event that the user re-configured
server/max-count after this control connection is
already in progress, this read-only value will show the
actual max-count that is in use for this
control connection.";
} }
description
"A random sequence of octets generated by the Server.
As described in client/token, Challenge is used
by the Control-Client to prove possession of a
shared secret.";
}
}
}
leaf salt { container session-sender {
type binary { if-feature session-sender;
length 16; presence "Enables TWAMP Session-Sender functionality.";
} description
description "Configuration of the TWAMP Session-Sender logical entity";
"A parameter used in deriving a key from a leaf admin-state {
shared secret as described in Section 3.1 of RFC 4656. type boolean;
Salt MUST be generated pseudo-randomly (independently mandatory true;
of anything else in the RFC) and is communicated to description
the Control-Client as part of the Server Greeting "Indicates whether the device is allowed to operate
message."; as a TWAMP Session-Sender.";
} }
leaf server-iv { list test-session{
type binary { key name;
length 16; description "List of TWAMP Session-Sender test sessions.";
}
description
"The Server Initialization Vector
(IV) is generated randomly by the Server.";
}
leaf challenge { leaf name {
type binary { type string;
length 16; description
} "A unique name for this TWAMP-Test session to be used
description for identifying this test session by the Session-Sender
"A random sequence of octets generated by the Server. logical entity.";
As described in client/token, Challenge is used }
by the Control-Client to prove possession of a
shared secret.";
} leaf ctrl-connection-name {
type string;
config false;
description
"The name of the parent TWAMP-Control connection that
is responsible for negotiating this TWAMP-Test session.";
}
leaf fill-mode {
type padding-fill-mode;
default zero;
description
"Indicates whether the padding added to the
TWAMP-Test (UDP) packets will contain pseudo-random
numbers, or whether it should consist of all zeroes,
as per Section 4.2.1 of RFC 5357.";
} }
}
container session-sender { leaf number-of-packets {
if-feature session-sender; type uint32;
presence session-sender;
description
"Configuration of the TWAMP Session-Sender
logical entity";
leaf admin-state {
type boolean;
mandatory true; mandatory true;
description description
"Indicates whether the device is allowed to operate "The overall number of TWAMP-Test (UDP) packets to be
as a TWAMP Session-Sender."; transmitted by the Session-Sender for this test session.";
} }
list test-session{ choice packet-distribution {
key name;
description description
"TWAMP Session-Sender test sessions."; "Indicates the distribution to be used for transmitting
the TWAMP-Test (UDP) packets.";
leaf name { case periodic {
type string; leaf periodic-interval {
description type decimal64 {
"A unique name for this TWAMP-Test session to be used fraction-digits 5;
for identifying this test session by the Session-Sender
logical entity.";
}
leaf ctrl-connection-name {
type string;
config false;
description
"The name of the parent TWAMP-Control connection that
is responsible for negotiating this TWAMP-Test session.";
}
leaf fill-mode {
type padding-fill-mode;
default zero;
description
"Indicates whether the padding added to the
TWAMP-Test (UDP) packets will contain pseudo-random
numbers, or whether it should consist of all zeroes,
as per Section 4.2.1 of RFC 5357.";
}
leaf number-of-packets {
type uint32;
description
"The overall number of TWAMP-Test (UDP) packets to
be transmitted by the Session-Sender
for this test session.";
}
choice packet-distribution {
description
"Indicates the distribution to be used for transmitting
the TWAMP-Test (UDP) packets.";
case periodic {
leaf periodic-interval {
type uint32;
description
"Indicates the period to wait between the first bits
of TWAMP-Test (UDP) packet transmissions for
this test session";
} }
leaf periodic-interval-units { units seconds;
type time-units; mandatory true;
description "Periodic interval time unit."; description
reference "Indicates the time to wait (in seconds) between the
first bits of TWAMP-Test (UDP) packet transmissions for
this test session";
reference
"RFC 3432: Network performance measurement "RFC 3432: Network performance measurement
with periodic streams"; with periodic streams";
}
} }
case poisson { }
leaf lambda { case poisson {
type uint32; leaf lambda {
description type decimal64 {
"Indicates the average packet transmission rate."; fraction-digits 5;
}
leaf lambda-units {
type uint32;
description
"Indicates the units of lambda in
reciprocal seconds.";
reference
"RFC 3432: Network performance measurement
with periodic streams";
} }
leaf max-interval { units seconds;
type uint32; mandatory true;
description description
"Indicates the maximum time between packet "Indicates the average time interval (in seconds)
transmissions."; between packets in the Poisson distribution.
The packet is calculated using the reciprocal of lambda
and the TWAMP-Test packet size (which depends on the
selected Mode and the packet padding).";
reference
"RFC 2330: Framework for IP Performance Metrics";
}
leaf max-interval {
type decimal64 {
fraction-digits 5;
} }
leaf truncation-point-units { units seconds;
type time-units; description
description "Time units to truncate."; "Indicates the maximum time (in seconds)
} between packet transmissions.";
reference
"RFC 7312: Advanced Stream and Sampling Framework
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;
presence session-reflector; presence "Enables TWAMP Session-Reflector functionality.";
description
"Configuration of the TWAMP Session-Reflector logical entity";
leaf admin-state {
type boolean;
mandatory true;
description description
"Configuration of the TWAMP Session-Reflector "Indicates whether the device is allowed to operate
logical entity"; as a TWAMP Session-Reflector.";
}
leaf admin-state { leaf refwait {
type boolean; type uint32 {
mandatory true; range 1..604800;
description
"Indicates whether the device is allowed to operate
as a TWAMP Session-Reflector.";
} }
units seconds;
default 900;
description
"The Session-Reflector MAY discontinue any session that has
been started when no packet associated with that session has
been received for REFWAIT seconds. As per Section 3.1 of
RFC 5357, this timeout allows a Session-Reflector to free up
resources in case of failure.";
}
leaf refwait { list test-session {
type uint32 { key
range 1..604800; "sender-ip sender-udp-port
} reflector-ip reflector-udp-port";
default 900; config false;
description description "TWAMP Session-Reflectortest sessions.";
"The Session-Reflector MAY discontinue any session
that has been started when no packet associated with
that session has been received for REFWAIT seconds.
The default value of REFWAIT SHALL be 900 seconds, and
this waiting time MAY be configurable. This timeout
allows a Session-Reflector to free up resources in
case of failure.";
leaf sid {
type string;
description
"An auto-allocated identifier for this TWAMP-Test
session that is unique within the context of this
Server/Session-Reflector device only. This value
is communicated to the Control-Client that
requested the test session in the SID field of the
Accept-Session message.";
} }
list test-session { leaf sender-ip {
key type inet:ip-address;
"sender-ip sender-udp-port
reflector-ip reflector-udp-port";
config false;
description description
"TWAMP Session-Reflectortest sessions."; "The IP address on the remote device, which is the
source IP address used in the TWAMP-Test (UDP) packets
leaf sid { belonging to this test session.";
type string; }
description
"An auto-allocated identifier for this TWAMP-Test
session, that is unique within the context of this
Server/Session-Reflector device only. This value
will be communicated to the Control-Client that
requested the test session in the SID field of the
Accept-Session message.";
}
leaf sender-ip {
type inet:ip-address;
description
"The IP address on the remote device, which is the
source IP address used in the TWAMP-Test
(UDP) packets belonging to this test session.";
}
leaf sender-udp-port {
type dynamic-port-number;
description
"The source UDP port used in the TWAMP-Test packets
belonging to this test session.";
}
leaf reflector-ip {
type inet:ip-address;
description
"The IP address of the local Session-Reflector
device, which is the destination IP address used
in the TWAMP-Test (UDP) packets belonging to this test
session.";
}
leaf reflector-udp-port {
type dynamic-port-number;
description
"The destination UDP port number used in the
TWAMP-Test (UDP) test packets belonging to this
test session.";
}
leaf parent-connection-client-ip { leaf sender-udp-port {
type inet:ip-address; type dynamic-port-number;
description description
"The IP address on the Control-Client device, which "The source UDP port used in the TWAMP-Test packets
is the source IP address used in the TWAMP-Control belonging to this test session.";
(TCP) packets belonging to the parent control }
connection that negotiated this test session.";
}
leaf parent-connection-client-tcp-port { leaf reflector-ip {
type inet:port-number; type inet:ip-address;
description description
"The source TCP port number used in the TWAMP-Control "The IP address of the local Session-Reflector
(TCP) packets belonging to the parent control connection device, which is the destination IP address used
that negotiated this test session."; in the TWAMP-Test (UDP) packets belonging to this test
} session.";
}
leaf parent-connection-server-ip { leaf reflector-udp-port {
type inet:ip-address; type dynamic-port-number;
description description
"The IP address of the Server device, which is the "The destination UDP port number used in the
destination IP address used in the TWAMP-Control TWAMP-Test (UDP) test packets belonging to this
(TCP) packets belonging to the parent control test session.";
connection that negotiated this test session."; }
}
leaf parent-connection-server-tcp-port { leaf parent-connection-client-ip {
type inet:port-number; type inet:ip-address;
description description
"The destination TCP port number used in the TWAMP-Control "The IP address on the Control-Client device, which
(TCP) packets belonging to the parent control connection is the source IP address used in the TWAMP-Control
that negotiated this test session."; (TCP) packets belonging to the parent control
} connection that negotiated this test session.";
}
leaf test-packet-dscp { leaf parent-connection-client-tcp-port {
type inet:dscp; type inet:port-number;
description description
"The DSCP value present in the IP header of "The source TCP port number used in the TWAMP-Control
TWAMP-Test (UDP) packets belonging to this test (TCP) packets belonging to the parent control connection
session."; that negotiated this test session.";
} }
uses maintenance-statistics; leaf parent-connection-server-ip {
type inet:ip-address;
description
"The IP address of the Server device, which is the
destination IP address used in the TWAMP-Control
(TCP) packets belonging to the parent control
connection that negotiated this test session.";
}
leaf parent-connection-server-tcp-port {
type inet:port-number;
description
"The destination TCP port number used in the TWAMP-Control
(TCP) packets belonging to the parent control connection
that negotiated this test session.";
}
leaf test-packet-dscp {
type inet:dscp;
description
"The DSCP value present in the IP header of
TWAMP-Test (UDP) packets belonging to this session.";
} }
uses maintenance-statistics;
} }
} }
} }
}
<CODE ENDS> <CODE ENDS>
6. Data Model Examples 6. Data Model Examples
This section presents a simple but complete example of configuring This section presents a simple but complete example of configuring
all four entities in Figure 1, based on the YANG module specified in all 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 example is illustrative in nature, but aims to be
self-contained, i.e. were it to be executed in a real TWAMP self-contained, i.e. were it to be executed in a real TWAMP
implementation it would lead to a correctly configured test session. implementation it would lead to a correctly configured test session.
For completeness, examples are provided for both IPv4 and IPv6. For completeness, examples are provided for both IPv4 and IPv6.
A more elaborated example, which also includes authentication A more elaborated example, which also includes authentication
parameters, is provided in Appendix A. parameters, is provided in Appendix A.
6.1. Control-Client 6.1. Control-Client
The following configuration example shows 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>
The following configuration example shows a Control-Client with two Figure 8: XML instance enabling Control-Client operation.
instances of client/ctrl-connection, one called "RouterA" and another
called "RouterB".
Each TWAMP-Control connection is to a different Server. The control The following example shows a Control-Client with two instances of
connection named "RouterA" has two test session requests. The TWAMP- client/ctrl-connection, one called "RouterA" and another called
Control connection named "RouterB" has no TWAMP-Test session "RouterB". Each TWAMP-Control connection is to a different Server.
requests. The control connection named "RouterA" has two test session requests.
The TWAMP-Control connection named "RouterB" has no TWAMP-Test
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>
<ctrl-connection> <ctrl-connection>
<name>RouterA</name> <name>RouterA</name>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<server-ip>203.0.113.2</server-ip> <server-ip>203.0.113.2</server-ip>
<test-session-request> <test-session-request>
<name>Test1</name> <name>Test1</name>
<sender-ip>10.1.1.1</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>50000</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>10.1.1.2</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>500001</reflector-udp-port> <reflector-udp-port>50001</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>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>4001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>203.0.113.2</reflector-ip> <reflector-ip>203.0.113.2</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</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>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<server-ip>203.0.113.3</server-ip> <server-ip>203.0.113.3</server-ip>
</ctrl-connection> </ctrl-connection>
skipping to change at page 45, line 47 skipping to change at page 47, line 7
<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:10:1:1::1</sender-ip> <sender-ip>2001:DB8:203:1:113::3</sender-ip>
<sender-udp-port>4000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>2001:DB8:10:1:1::2</reflector-ip> <reflector-ip>2001:DB8:203:1:113::4</reflector-ip>
<reflector-udp-port>5000</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>4001</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>5001</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
This configuration example shows a Server with server/admin-state Figure 9 shows a configuration example for a Server with server/
enabled, which permits a device following Figure 2 to respond to admin-state enabled, which permits a device following Figure 2 to
TWAMP-Control connections and TWAMP-Test sessions. 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.
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 (client/ctrl-
connection/name) "RouterA" presented in Section 6.1. 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>
skipping to change at page 47, line 43 skipping to change at page 48, line 43
<state> <state>
active active
</state> </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
session-sender/admin-state enabled, which permits a device following
Figure 2 to initiate TWAMP-Test sessions.
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-sender>
<admin-state>true</admin-state>
</session-sender>
</twamp>
</config>
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>
<name>Test1</name> <name>Test1</name>
<ctrl-connection-name>RouterA</ctrl-connection-name> <ctrl-connection-name>RouterA</ctrl-connection-name>
<number-of-packets>900</number-of-packets> <number-of-packets>900</number-of-packets>
<periodic-interval>1</periodic-interval> <periodic-interval>1</periodic-interval>
<periodic-interval-units>seconds</periodic-interval-units>
<state>setup</state> <state>setup</state>
</test-session> </test-session>
<test-session> <test-session>
<name>Test2</name> <name>Test2</name>
<ctrl-connection-name> <ctrl-connection-name>
RouterA RouterA
</ctrl-connection-name> </ctrl-connection-name>
<number-of-packets>900</number-of-packets> <number-of-packets>900</number-of-packets>
<lambda>1</lambda> <lambda>1</lambda>
<lambda-units>1</lambda-units>
<max-interval>2</max-interval> <max-interval>2</max-interval>
<truncation-point-units>seconds</truncation-point-units>
<state>setup</state> <state>setup</state>
</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-
reflector/admin-state enabled, which permits a device following
Figure 2 to respond to TWAMP-Test sessions.
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector>
<admin-state>true</admin-state>
</session-reflector>
</twamp>
</config>
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.
<?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> <admin-state>true</admin-state>
true
</admin-state>
<test-session> <test-session>
<sender-ip>10.1.1.1</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>4000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>10.1.1.2</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
203.0.113.1 203.0.113.1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
203.0.113.2 203.0.113.2
skipping to change at page 49, line 22 skipping to change at page 50, line 49
<parent-connection-server-tcp-port> <parent-connection-server-tcp-port>
862 862
</parent-connection-server-tcp-port> </parent-connection-server-tcp-port>
<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>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>50000</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip> <reflector-ip>192.68.0.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> <parent-connection-client-ip>
203.0.113.1 203.0.113.1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
skipping to change at page 50, line 5 skipping to change at page 51, line 31
</session-reflector> </session-reflector>
</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">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>10.1.1.1</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>4000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>10.1.1.2</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>5000</reflector-udp-port> <reflector-udp-port>54001</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
203.0.113.1 203.0.113.1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
203.0.113.2 203.0.113.2
</parent-connection-server-ip> </parent-connection-server-ip>
skipping to change at page 50, line 26 skipping to change at page 52, line 4
<parent-connection-server-ip> <parent-connection-server-ip>
203.0.113.2 203.0.113.2
</parent-connection-server-ip> </parent-connection-server-ip>
<parent-connection-server-tcp-port> <parent-connection-server-tcp-port>
862 862
</parent-connection-server-tcp-port> </parent-connection-server-tcp-port>
<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>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>4001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip> <reflector-ip>192.68.0.2</reflector-ip>
<reflector-udp-port>5001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
203.0.113.1 203.0.113.1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
203.0.113.2 203.0.113.2
</parent-connection-server-ip> </parent-connection-server-ip>
skipping to change at page 52, line 7 skipping to change at page 53, line 30
name: ietf-twamp name: ietf-twamp
namespace: urn:ietf:params:xml:ns:yang:ietf-twamp namespace: urn:ietf:params:xml:ns:yang:ietf-twamp
prefix: twamp prefix: twamp
reference: RFC XXXX reference: RFC XXXX
9. Acknowledgements 9. Acknowledgements
We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell,
and Robert Sherman for their thorough and constructive reviews, Robert Sherman, and Marius Georgescu for their thorough and
comments and text suggestions. constructive reviews, comments and text suggestions.
Haoxing Shen contributed to the definition of the YANG module in Haoxing Shen contributed to the definition of the YANG module in
Section 5. Section 5.
Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG
module and the examples in Appendix A. module and the examples in Appendix A.
Kostas Pentikousis is partially supported by FP7 UNIFY Kostas Pentikousis was partially supported by FP7 UNIFY
(http://fp7-unify.eu), a research project partially funded by the (http://fp7-unify.eu), a research project partially funded by the
European Community under the Seventh Framework Program (grant European Community under the Seventh Framework Program (grant
agreement no. 619609). The views expressed here are those of the agreement no. 619609). The views expressed here are those of the
authors only. The European Commission is not liable for any use that authors only. The European Commission is not liable for any use that
may be made of the information in this document. may be made of the information in this document.
10. References 10. Contributors
10.1. Normative References Lianshu Zheng, Huawei Technologies, China
Email: vero.zheng@huawei.com
11. References
11.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc3432>. <http://www.rfc-editor.org/info/rfc3432>.
skipping to change at page 53, line 22 skipping to change at page 55, line 5
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<http://www.rfc-editor.org/info/rfc6038>. <http://www.rfc-editor.org/info/rfc6038>.
[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,
<http://www.rfc-editor.org/info/rfc7717>. <http://www.rfc-editor.org/info/rfc7717>.
10.2. Informative References 11.2. Informative References
[I-D.ietf-ippm-metric-registry] [I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf- Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-10 (work in progress), November 2016. ippm-metric-registry-10 (work in progress), November 2016.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016. progress), October 2016.
skipping to change at page 55, line 29 skipping to change at page 57, line 9
<secret-key>secret2</secret-key> <secret-key>secret2</secret-key>
</key-chain> </key-chain>
<ctrl-connection> <ctrl-connection>
<name>RouterA</name> <name>RouterA</name>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<server-ip>203.0.113.2</server-ip> <server-ip>203.0.113.2</server-ip>
<dscp>32</dscp> <dscp>32</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>10.1.1.1</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>4000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>10.1.1.2</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>5000</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>
<state>ok</state> <state>ok</state>
<sid>1232</sid> <sid>1232</sid>
</test-session-request> </test-session-request>
<test-session-request> <test-session-request>
<name>Test2</name> <name>Test2</name>
<sender-ip>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>4001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>203.0.113.2</reflector-ip> <reflector-ip>203.0.113.2</reflector-ip>
<reflector-udp-port>5001</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>
<state>ok</state> <state>ok</state>
<sid>178943</sid> <sid>178943</sid>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
</client> </client>
</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">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<mode-preference-chain> <mode-preference-chain>
<priority>0</priority> <priority>0</priority>
<mode>authenticated</mode> <mode>authenticated</mode>
skipping to change at page 56, line 37 skipping to change at page 58, line 16
</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>
<dscp>32</dscp> <dscp>32</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>4000</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>5000</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>
<state>ok</state> <state>ok</state>
<sid>1232</sid> <sid>1232</sid>
</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>4001</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>5001</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>
<state>ok</state> <state>ok</state>
<sid>178943</sid> <sid>178943</sid>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
</client> </client>
</twamp> </twamp>
</data> </data>
skipping to change at page 59, line 4 skipping to change at page 60, line 16
<dscp>32</dscp> <dscp>32</dscp>
<selected-mode>unauthenticated</selected-mode> <selected-mode>unauthenticated</selected-mode>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<count>1024</count> <count>1024</count>
</ctrl-connection> </ctrl-connection>
</server> </server>
</twamp> </twamp>
</data> </data>
A.3. Session-Sender A.3. Session-Sender
<?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>
<name>Test1</name> <name>Test1</name>
<ctrl-connection-name>RouterA</ctrl-connection-name> <ctrl-connection-name>RouterA</ctrl-connection-name>
<fill-mode>zero</fill-mode> <fill-mode>zero</fill-mode>
<number-of-packets>900</number-of-packets> <number-of-packets>900</number-of-packets>
<periodic-interval>1</periodic-interval> <periodic-interval>1</periodic-interval>
<periodic-interval-units>
seconds
</periodic-interval-units>
<state>setup</state> <state>setup</state>
<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>
<name>Test2</name> <name>Test2</name>
<ctrl-connection-name> <ctrl-connection-name>
RouterA RouterA
</ctrl-connection-name> </ctrl-connection-name>
<fill-mode>random</fill-mode> <fill-mode>random</fill-mode>
<number-of-packets>900</number-of-packets> <number-of-packets>900</number-of-packets>
<lambda>1</lambda> <lambda>1</lambda>
<lambda-units>1</lambda-units>
<max-interval>2</max-interval> <max-interval>2</max-interval>
<truncation-point-units>seconds</truncation-point-units>
<state>setup</state> <state>setup</state>
<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-sender> </session-sender>
</twamp> </twamp>
</data> </data>
A.4. Session-Reflector A.4. Session-Reflector
<?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> <admin-state>
true true
</admin-state> </admin-state>
<test-session> <test-session>
<sender-ip>10.1.1.1</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>4000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>10.1.1.2</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>5000</reflector-udp-port> <reflector-udp-port>55000</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
203.0.113.1 203.0.113.1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
203.0.113.2 203.0.113.2
</parent-connection-server-ip> </parent-connection-server-ip>
skipping to change at page 60, line 32 skipping to change at page 61, line 40
862 862
</parent-connection-server-tcp-port> </parent-connection-server-tcp-port>
<dscp>32</dscp> <dscp>32</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>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>4001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip> <reflector-ip>192.68.0.2</reflector-ip>
<reflector-udp-port>5001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
203.0.113.1 203.0.113.1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
203.0.113.2 203.0.113.2
</parent-connection-server-ip> </parent-connection-server-ip>
skipping to change at page 61, line 17 skipping to change at page 62, line 24
</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">
<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>4000</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>5000</reflector-udp-port> <reflector-udp-port>55000</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
2001:DB8:203:0:113::1 2001:DB8:203:0:113::1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
2001:DB8:203:0:113::2 2001:DB8:203:0:113::2
</parent-connection-server-ip> </parent-connection-server-ip>
skipping to change at page 61, line 41 skipping to change at page 62, line 48
862 862
</parent-connection-server-tcp-port> </parent-connection-server-tcp-port>
<dscp>32</dscp> <dscp>32</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>4001</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>5001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip> <parent-connection-client-ip>
2001:DB8:203:0:113::1 2001:DB8:203:0:113::1
</parent-connection-client-ip> </parent-connection-client-ip>
<parent-connection-client-tcp-port> <parent-connection-client-tcp-port>
16341 16341
</parent-connection-client-tcp-port> </parent-connection-client-tcp-port>
<parent-connection-server-ip> <parent-connection-server-ip>
2001:DB8:203:0:113::2 2001:DB8:203:0:113::2
</parent-connection-server-ip> </parent-connection-server-ip>
skipping to change at page 63, line 37 skipping to change at line 2984
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Kostas Pentikousis (editor) Kostas Pentikousis (editor)
Travelping Travelping
Koernerstr. 7-10 Koernerstr. 7-10
Berlin 10785 Berlin 10785
Germany Germany
Email: k.pentikousis@travelping.com Email: k.pentikousis@travelping.com
Lianshu Zheng
Huawei Technologies
China
Email: vero.zheng@huawei.com
 End of changes. 273 change blocks. 
1232 lines changed or deleted 1307 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/