draft-ietf-ippm-twamp-yang-07.txt   draft-ietf-ippm-twamp-yang-08.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: October 10, 2018 AT&T Labs Expires: October 16, 2018 AT&T Labs
R. Rahman R. Rahman
Cisco Systems Cisco Systems
M. Jethanandani M. Jethanandani
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Travelping
April 8, 2018 April 14, 2018
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-07 draft-ietf-ippm-twamp-yang-08
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 40 skipping to change at page 1, line 40
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 October 10, 2018. This Internet-Draft will expire on October 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 1.3. Document Organization . . . . . . . . . . . . . . . . . . 4
2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4 2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4
3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5
3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6 3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6
3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7 3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7
3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7 3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 13
4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13 4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 14
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19
6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 46 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48
6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 47 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 50 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51
6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 51 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52
7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.1. Normative References . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . 57
11.2. Informative References . . . . . . . . . . . . . . . . . 57 11.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 58 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60
A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 58 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 62 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 63
A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 62 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64
Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 65 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
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, implementors come with a standard management framework, and, as such, implementors
have no choice except to provide a proprietary mechanism. This have no choice except to provide a proprietary mechanism. This
document addresses this gap by formally specifying the TWAMP data document addresses this gap by formally specifying the TWAMP data
model using YANG. model using YANG [RFC7950].
1.1. Motivation 1.1. Motivation
In current TWAMP deployments the lack of a standardized data model In current TWAMP deployments the lack of a standardized data model
limits the flexibility to dynamically instantiate TWAMP-based limits the flexibility to dynamically instantiate TWAMP-based
measurements across equipment from different vendors. In large, measurements across equipment from different vendors. In large,
virtualized, and dynamically instantiated infrastructures where virtualized, and dynamically instantiated infrastructures where
network functions are placed according to orchestration algorithms as network functions are placed according to orchestration algorithms as
discussed in [I-D.unify-nfvrg-challenges][I-D.unify-nfvrg-devops], discussed in Unifying Carrier and Cloud Networks: Problem Statement
proprietary mechanisms for managing TWAMP measurements pose severe and Challenges [I-D.unify-nfvrg-challenges]DevOps For Software-
limitations with respect to programmability. Defined Telecom Infrastructures [I-D.unify-nfvrg-devops], proprietary
mechanisms for managing TWAMP measurements pose severe limitations
with respect to programmability.
Two major trends call for standardizing TWAMP management aspects. Two major trends call for standardizing TWAMP management aspects.
First, we expect that in the coming years large-scale and multi- First, we expect that in the coming years large-scale and multi-
vendor TWAMP deployments will become the norm. From an operations vendor TWAMP deployments will become the norm. From an operations
perspective, using several vendor-specific TWAMP configuration perspective, using several vendor-specific TWAMP configuration
mechanisms when one standard mechanism could provide an alternative mechanisms when one standard mechanism could provide an alternative
is expensive and inefficient. Second, the increasingly software- is expensive and inefficient. Second, the increasingly software-
defined and virtualized nature of network infrastructures, based on defined and virtualized nature of network infrastructures, based on
dynamic service chains [NSC] and programmable control and management dynamic service chains [NSC] and programmable control and management
planes [RFC7426] requires a well-defined data model for TWAMP planes Software-Defined Networking (SDN): Layers and Architecture
Terminology [RFC7426] requires a well-defined data model for TWAMP
implementations. This document defines such a TWAMP data model and implementations. This document defines such a TWAMP data model and
specifies it formally using the YANG data modeling language specifies it formally using the YANG [RFC7950] data modeling
[RFC7950]. language.
Note to RFC Editor: Note to RFC Editor:
Please replace the date 2018-04-08 in Section 5.2 of the draft with Please replace the date 2018-04-16 in Section 5.2 of the draft with
the date of publication of this draft as a RFC. Also, replace the date of publication of this draft as a RFC. Also, replace
reference to RFC XXXX, and draft-ietf-ippm-metric-registry with the reference to RFC XXXX, and draft-ietf-port-twamp-test with the RFC
RFC numbers assigned to the draft. numbers assigned to the drafts.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Document Organization 1.3. Document Organization
skipping to change at page 4, line 23 skipping to change at page 4, line 29
specifies in YANG the TWAMP data model. Section 6 lists illustrative specifies in YANG the TWAMP data model. Section 6 lists illustrative
examples which conform to the YANG data model specified in this examples which conform to the YANG data model specified in this
document. Appendix A elaborates these examples further. document. Appendix A elaborates these examples further.
2. Scope, Model, and Applicability 2. Scope, Model, and Applicability
The purpose of this document is the specification of a vendor- The purpose of this document is the specification of a vendor-
independent data model for TWAMP implementations. independent data model for TWAMP implementations.
Figure 1 illustrates a redrawn version of the TWAMP logical model Figure 1 illustrates a redrawn version of the TWAMP logical model
found in Section 1.2 of [RFC5357]. The figure is annotated with found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated
pointers to the UML diagrams provided in this document and associated with pointers to the UML diagrams provided in this document and
with the data model of the four logical entities in a TWAMP associated with the data model of the four logical entities in a
deployment, namely the TWAMP Control-Client, Server, Session-Sender TWAMP deployment, namely the TWAMP Control-Client, Server, Session-
and Session-Reflector. Sender and Session-Reflector.
As per [RFC5357], unlabeled links in Figure 1 are left unspecified As per TWAMP [RFC5357], unlabeled links in Figure 1 are left
and may be proprietary protocols. unspecified and may be proprietary protocols.
[Fig. 3] [Fig. 4] [Fig. 3] [Fig. 4]
+----------------+ +--------+ +----------------+ +--------+
| Control-Client | <-- TWAMP-Control --> | Server | | Control-Client | <-- TWAMP-Control --> | Server |
+----------------+ +--------+ +----------------+ +--------+
^ ^ ^ ^
| | | |
V V V V
+----------------+ +-------------------+ +----------------+ +-------------------+
| Session-Sender | <-- TWAMP-Test --> | Session-Reflector | | Session-Sender | <-- TWAMP-Test --> | Session-Reflector |
+----------------+ +-------------------+ +----------------+ +-------------------+
[Fig. 5] [Fig. 6] [Fig. 5] [Fig. 6]
Figure 1: Annotated TWAMP logical model Figure 1: Annotated TWAMP logical model
As per [RFC5357], a TWAMP implementation may follow a simplified As per TWAMP [RFC5357], a TWAMP implementation may follow a
logical model, in which the same node acts both as Control-Client and simplified logical model, in which the same node acts both as
Session-Sender, while another node acts at the same time as TWAMP Control-Client and Session-Sender, while another node acts at the
Server and Session-Reflector. Figure 2 illustrates this simplified same time as TWAMP Server and Session-Reflector. Figure 2
logical model and indicates the interaction between the TWAMP illustrates this simplified logical model and indicates the
configuration client and server using, for instance, NETCONF interaction between the TWAMP configuration client and server using,
[RFC6241] or RESTCONF [RFC8040]. for instance, NETCONF [RFC6241] or RESTCONF [RFC8040].
o-------------------o o-------------------o o-------------------o o-------------------o
| Config client | | Config client | | Config client | | Config client |
o-------------------o o-------------------o o-------------------o o-------------------o
|| || || ||
NETCONF || RESTCONF NETCONF || RESTCONF NETCONF || RESTCONF NETCONF || RESTCONF
|| || || ||
o-------------------o o-------------------o o-------------------o o-------------------o
| Config server | | Config server | | Config server | | Config server |
| [Fig. 3, 5] | | [Fig. 4, 6] | | [Fig. 3, 5] | | [Fig. 4, 6] |
skipping to change at page 5, line 32 skipping to change at page 5, line 38
Figure 2: Simplified TWAMP model and protocols Figure 2: Simplified TWAMP model and protocols
The data model defined in this document is orthogonal to the specific The data model defined in this document is orthogonal to the specific
protocol used between the Config client and Config server to protocol used between the Config client and Config server to
communicate the TWAMP configuration parameters. communicate the TWAMP configuration parameters.
Operational actions such as how TWAMP-Test sessions are started and Operational actions such as how TWAMP-Test sessions are started and
stopped, how performance measurement results are retrieved, or how stopped, how performance measurement results are retrieved, or how
stored results are cleared, and so on, are not addressed by the stored results are cleared, and so on, are not addressed by the
configuration model defined in this document. As noted above, such configuration model defined in this document. As noted above, such
operational actions are not part of the TWAMP specification [RFC5357] operational actions are not part of the TWAMP specification TWAMP
and hence are out of scope of this document. See also Appendix B. [RFC5357] 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.
First, global configuration items relate to parameters that are set First, global configuration items relate to parameters that are set
on a per device level. For example, the administrative status of the on a per device level. For example, the administrative status of the
device with respect to whether it allows TWAMP sessions and, if so, device with respect to whether it allows TWAMP sessions and, if so,
in what capacity (e.g. Control-Client, Server or both), is a typical in what capacity (e.g. Control-Client, Server or both), is a typical
instance of a global configuration item. instance of a global configuration item.
skipping to change at page 6, line 36 skipping to change at page 6, line 43
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 OWAMP [RFC4656] and Randomness
Requirements for Security [RFC4086].
Each TWAMP-Control connection, in turn, is associated with zero or Each TWAMP-Control connection, in turn, is associated with zero or
more TWAMP-Test sessions. For each test session 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
needed because at the time of creation of a TWAMP-Test session, needed because at the time of creation of a TWAMP-Test session,
for example, the source UDP port number is not known to uniquely for example, the source UDP port number is not known to uniquely
identify the test session. identify the test session.
o The IP address and UDP port number of the Session-Sender on the o The IP address and UDP port number of the Session-Sender on the
path under test by TWAMP. path under test by TWAMP.
o The IP address and UDP port number of the Session-Reflector on o The IP address and UDP port number of the Session-Reflector on
said path. said path.
o Information pertaining to the test packet stream, such as the test o Information pertaining to the test packet stream, such as the test
starting time, which performance metric is to be used starting time, which performance metric is to be used Registry for
[I-D.ietf-ippm-metric-registry], or whether the test should be Performance Metrics [I-D.ietf-ippm-metric-registry], or whether
repeated. the test should be repeated.
3.2. Server 3.2. Server
Each TWAMP Server has an administrative status field set at the Each TWAMP Server has an administrative status field set at the
device level to indicate whether the node is enabled to function as a device level to indicate whether the node is enabled to function as a
TWAMP Server. TWAMP Server.
Each Server is associated with zero or more TWAMP-Control Each Server is associated with zero or more TWAMP-Control
connections. Each control connection is uniquely identified by the connections. Each control connection is uniquely identified by the
4-tuple {Control-Client IP address, Control-Client TCP port number, 4-tuple {Control-Client IP address, Control-Client TCP port number,
skipping to change at page 7, line 44 skipping to change at page 7, line 50
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 Network performence measurement with
periodic streams [RFC3432].
3.4. Session-Reflector 3.4. Session-Reflector
Each TWAMP Session-Reflector has an administrative status field set Each TWAMP Session-Reflector has an administrative status field set
at the device level to indicate whether the node is enabled to at the device level to indicate whether the node is enabled to
function as such. function as such.
Each Session-Reflector is associated with zero or more TWAMP-Test Each Session-Reflector is associated with zero or more TWAMP-Test
sessions. For each test session, the REFWAIT timeout parameter which sessions. For each test session, the REFWAIT timeout parameter which
determines whether to discontinue the session if no packets have been determines whether to discontinue the session if no packets have been
received ([RFC5357], Section 4.2) can be configured. received (TWAMP [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 10, line 11 skipping to change at page 10, line 11
mode and its corresponding priority, expressed as a 16-bit unsigned mode and its corresponding priority, expressed as a 16-bit unsigned
integer, where zero is the highest priority and subsequent values are integer, where zero is the highest priority and subsequent values are
monotonically increasing. 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 Mixed Security Mode for TWAMP [RFC5618], Individual
the Control-Client cannot determine an acceptable Mode, it MUST Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and
respond with zero Mode bits set in the Set-up Response message, Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret
indicating it will not continue with the control connection. Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot
determine an acceptable Mode, it MUST respond with zero Mode bits set
in the Set-up Response message, indicating it will not continue with
the control connection.
In addition, the client container holds a list named key-chain which In addition, the client container holds a list named key-chain 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 [RFC7950]. The derived key length (dkLen in Section 9.4 of YANG [RFC7950]. The derived key length (dkLen in PKCS
[RFC8018]) MUST be 16 octets for the AES Session-key used for #5: Password-Based Cryptography Specification Version 2.1 [RFC8018])
encryption and 32 octets for the HMAC-SHA1 Session-key used for MUST be 16 octets for the AES Session-key used for encryption and 32
authentication; see also Section 6.10 of [RFC4656]. octets for the HMAC-SHA1 Session-key used for authentication; see
also Section 6.10 of OWAMP [RFC4656].
Each client container also holds a list of control connections, where Each client container also holds a list of control connections, where
each item in the list describes a TWAMP control connection initiated each item in the list describes a TWAMP control connection initiated
by this Control-Client. There SHALL be one ctrl-connection per by this Control-Client. There SHALL be one ctrl-connection per
TWAMP-Control (TCP) connection that is to be initiated from this TWAMP-Control (TCP) connection that is to be initiated from this
device. device.
In turn, each ctrl-connection holds a 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 associated Client for this test session. This includes information associated
with the Request-TW-Session/Accept-Session message exchange (see with the Request-TW-Session/Accept-Session message exchange (see
Section 3.5 of [RFC5357]). Section 3.5 of TWAMP [RFC5357]).
There SHALL be one instance of test-session-request for each TWAMP- There SHALL be one instance of test-session-request for each 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 so test-session-request holds information related to these sessions so test-session-request holds information related to these
actions (e.g. pm-index, repeat-interval). actions (e.g. pm-index, repeat-interval).
4.2. Server 4.2. Server
skipping to change at page 15, line 5 skipping to change at page 15, line 43
Figure 6: TWAMP Session-Reflector UML class diagram Figure 6: TWAMP Session-Reflector UML class diagram
Each incoming TWAMP-Test session that is active on the Session- Each incoming TWAMP-Test session that is active on the Session-
Reflector SHALL be represented by an instance of a test-session Reflector SHALL be represented by an instance of a test-session
object. All items in the test-session object are read-only. object. All items in the test-session object are read-only.
Instances of test-session are indexed by a session identifier (sid). Instances of test-session are indexed by a session identifier (sid).
This value is auto-allocated by the TWAMP Server as test session This value is auto-allocated by the TWAMP Server as test session
requests are received, and communicated back to the Control-Client in requests are received, and communicated back to the Control-Client in
the SID field of the Accept-Session message; see Section 4.3 of the SID field of the Accept-Session message; see Section 4.3 of TWAMP
[RFC6038]. Reflect Octets and Symmetrical Size Features [RFC6038].
When attempting to retrieve operational data for active test sessions When attempting to retrieve operational data for active test sessions
from a Session-Reflector device, the user will not know what sessions from a Session-Reflector device, the user will not know what sessions
are currently active on that device, or what SIDs have been auto- are currently active on that device, or what SIDs have been auto-
allocated for these test sessions. If the user has network access to allocated for these test sessions. If the user has network access to
the Control-Client device, then it is possible to read the data for the Control-Client device, then it is possible to read the data for
this session under client/ctrl-connection/test-session-request/sid this session under client/ctrl-connection/test-session-request/sid
and obtain the SID (see Figure 3). The user may then use this SID and obtain the SID (see Figure 3). The user may then use this SID
value as an index to retrieve an individual session-reflector/test- value as an index to retrieve an individual session-reflector/test-
session instance on the Session-Reflector device. session instance on the Session-Reflector device.
skipping to change at page 15, line 42 skipping to change at page 16, line 31
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. Tree diagrams
used in this document follow the notation defined in YANG Tree
Diagrams [RFC8340].
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 string
| | +--rw secret-key? binary | | +--rw secret-key? string
| +--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? uint8 | +--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
skipping to change at page 16, line 27 skipping to change at page 17, line 18
| +--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? union | +--rw sender-udp-port? union
| +--rw reflector-ip inet:ip-address | +--rw reflector-ip inet:ip-address
| +--rw reflector-udp-port? uint32 | +--rw reflector-udp-port? inet: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? union | +--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? uint8 | +--rw count? uint8
| +--rw max-count? uint8 | +--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 string
| | +--rw secret-key? binary | | +--rw secret-key? string
| +--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? uint8 | +--ro count? uint8
| +--ro max-count? uint8 | +--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 decimal64 | | | +--rw periodic-interval decimal64
| | +--:(poisson) | | +--:(poisson)
| | +--rw lambda decimal64 | | +--rw lambda decimal64
| | +--rw max-interval? decimal64 | | +--rw max-interval? decimal64
| +--ro state? sender-session-state | +--ro state? sender-session-state
| +--ro sent-packets? uint32 | +--ro sent-packets? uint32
| +--ro rcv-packets? uint32 | +--ro rcv-packets? uint32
| +--ro last-sent-seq? uint32 | +--ro last-sent-seq? uint32
| +--ro last-rcv-seq? uint32 | +--ro last-rcv-seq? uint32
+--rw session-reflector! {session-reflector}? +--rw session-reflector {session-reflector}?
+--rw admin-state boolean +--rw admin-state? boolean
+--rw refwait? uint32 +--rw refwait? uint32
+--ro test-session* +--ro test-session*
[sender-ip sender-udp-port reflector-ip reflector-udp [sender-ip sender-udp-port reflector-ip reflector-udp
-port] -port]
+--ro sid? string +--ro sid? string
+--ro sender-ip inet:ip-address +--ro sender-ip inet:ip-address
+--ro sender-udp-port +--ro sender-udp-port
| dynamic-port-number | dynamic-port-number
+--ro reflector-ip inet:ip-address +--ro reflector-ip inet:ip-address
+--ro reflector-udp-port uint32 +--ro reflector-udp-port inet:port-numbe
r
+--ro parent-connection-client-ip? inet:ip-address +--ro parent-connection-client-ip? inet:ip-address
+--ro parent-connection-client-tcp-port? inet:port-numbe +--ro parent-connection-client-tcp-port? inet:port-numbe
r r
+--ro parent-connection-server-ip? inet:ip-address +--ro parent-connection-server-ip? inet:ip-address
+--ro parent-connection-server-tcp-port? inet:port-numbe +--ro parent-connection-server-tcp-port? inet:port-numbe
r r
+--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. Figure 7: YANG Tree Diagram.
5.2. YANG Module 5.2. YANG Module
This section presents the YANG module for the TWAMP data model This section presents the YANG module for the TWAMP data model
defined in this document. The module imports definitions from Common defined in this document. The module imports definitions from NTPv3
YANG Data Types [RFC6991]. Specification [RFC1305], Randomness Requirements for Security
[RFC4086], OWAMP [RFC4656], TWAMP [RFC5357], More Features for TWAMP
[RFC5618], Individual Session Control Feature [RFC5938], TWAMP
Reflect Octets and Symmetrical Size Features [RFC6038], Common YANG
Data Types [RFC6991], Advances Stream and Sampling Framework
[RFC7312], IKEv2-Derived Shared Secret Key for OWAMP and TWAMP
[RFC7717], and OWAMP and TWAMP Well-Known Port Assignments
[I-D.ietf-ippm-port-twamp-test].
<CODE BEGINS> file "ietf-twamp@2018-04-08.yang" <CODE BEGINS> file "ietf-twamp@2018-04-16.yang"
module ietf-twamp { module ietf-twamp {
yang-version 1.1; yang-version 1.1;
namespace urn:ietf:params:xml:ns:yang:ietf-twamp; namespace urn:ietf:params:xml:ns:yang:ietf-twamp;
prefix ietf-twamp; prefix ietf-twamp;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Types."; "RFC 6991: Common YANG Types.";
skipping to change at page 19, line 4 skipping to change at page 19, line 51
acmorton@att.com acmorton@att.com
Editor: Reshad Rehman Editor: Reshad Rehman
rrahman@cisco.com rrahman@cisco.com
Editor: Mahesh Jethanandani Editor: Mahesh Jethanandani
mjethanandani@gmail.com mjethanandani@gmail.com
Editor: Kostas Pentikousis Editor: Kostas Pentikousis
k.pentikousis@travelping.com"; k.pentikousis@travelping.com";
description description
"This YANG module specifies a vendor-independent data "This YANG module specifies a vendor-independent data
model for the Two-Way Active Measurement Protocol (TWAMP). model for the Two-Way Active Measurement Protocol (TWAMP).
The data model covers four TWAMP logical entities, namely, The data model covers four TWAMP logical entities, namely,
Control-Client, Server, Session-Sender, and Session-Reflector, Control-Client, Server, Session-Sender, and Session-Reflector,
as illustrated in the annotated TWAMP logical model (Fig. 1 as illustrated in the annotated TWAMP logical model (Fig. 1
of RFC XXXX). of RFC XXXX).
This YANG module uses features to indicate which of the four This YANG module uses features to indicate which of the four
logical entities are supported by a TWAMP implementation."; logical entities are supported by a TWAMP implementation.
revision 2018-04-08 { Copyright (c) 2018 IETF Trust and the persons identified as
the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2018-04-16 {
description description
"Initial Revision. "Initial Revision.
Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and
draft-ietf-ippm-metric-registry"; draft-ietf-ippm-metric-registry";
reference reference
"RFC XXXX: TWAMP YANG Data Model."; "RFC XXXX: TWAMP YANG Data Model.";
} }
skipping to change at page 21, line 51 skipping to change at page 23, line 13
description description
"Indicates the Control-Client TWAMP-Control connection "Indicates the Control-Client TWAMP-Control connection
state."; state.";
} }
typedef test-session-state { typedef test-session-state {
type enumeration { type enumeration {
enum accepted { enum accepted {
value 0; value 0;
description description
"Indicates that accepted TWAMP-Test session request."; "Indicates an accepted TWAMP-Test session request.";
} }
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
skipping to change at page 24, line 49 skipping to change at page 26, line 11
length 1..80; length 1..80;
} }
description description
"KeyID used for a TWAMP-Control connection. As per "KeyID used for a TWAMP-Control connection. As per
Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
80 octets in length' and is used to select which 'shared 80 octets in length' and is used to select which 'shared
shared secret the [Control-Client] wishes to use to shared secret the [Control-Client] wishes to use to
authenticate or encrypt'."; authenticate or encrypt'.";
} }
leaf secret-key { leaf secret-key {
type binary; type string;
description description
"The secret key corresponding to the KeyID for this "The secret key corresponding to the KeyID for this
TWAMP-Control connection."; TWAMP-Control connection.";
} }
description description
"Relates KeyIDs with their respective secret keys "Relates KeyIDs with their respective secret keys
in a TWAMP-Control connection."; in a TWAMP-Control connection.";
} }
description description
"Used by the Control-Client and Server for TWAMP-Control "Used by the Control-Client and Server for TWAMP-Control
skipping to change at page 26, line 17 skipping to change at page 27, line 26
description description
"Parameter communicated to the Control-Client as part of "Parameter communicated to the Control-Client as part of
the Server Greeting message and used for deriving a key the Server Greeting message and used for deriving a key
from a shared secret as per Section 3.1 of RFC 4656: from a shared secret as per Section 3.1 of RFC 4656:
MUST be a power of 2 and at least 1024. It is configured MUST be a power of 2 and at least 1024. It is configured
by providing said power. For example, configuring 15 here by providing said power. For example, configuring 15 here
means count 2^15 = 32768. The default is 10, means count 2^15 = 32768. The default is 10,
meaning 2^10 = 1024."; meaning 2^10 = 1024.";
} }
description description
"Reusable data structure for count which is used both in the "Reusable data structure for count, which is used both in the
Server container."; Server and the Control-Client.";
} }
grouping max-count { grouping max-count-exponent {
leaf max-count { leaf max-count {
type uint8 { type uint8 {
range 10..31; range 10..31;
} }
default 15; default 15;
description description
"This parameter limits the maximum Count value, which MUST "This parameter limits the maximum Count value, which MUST
be a power of 2 and at least 1024 as per RFC 5357. It is be a power of 2 and at least 1024 as per RFC 5357. It is
configured by providing said power. For example, configured by providing said power. For example,
configuring 10 here means max count 2^10 = 1024. configuring 10 here means max count 2^10 = 1024.
skipping to change at page 27, line 27 skipping to change at page 28, line 37
container twamp { container twamp {
description description
"TWAMP logical entity configuration grouping of four models "TWAMP logical entity configuration grouping of four models
which correspond to the four TWAMP logical entities which correspond to the four TWAMP logical entities
Control-Client, Server, Session-Sender, and Session-Reflector Control-Client, Server, Session-Sender, and Session-Reflector
as illustrated in Fig. 1 of RFC XXXX."; as illustrated in Fig. 1 of RFC XXXX.";
container client { container client {
if-feature control-client; if-feature control-client;
presence "Enables TWAMP Control-Client functionality.";
description description
"Configuration of the TWAMP Control-Client logical "Configuration of the TWAMP Control-Client logical
entity."; entity.";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
mandatory true; default true;
description description
"Indicates whether the device is allowed to operate as a "Indicates whether the device is allowed to operate as a
TWAMP Control-Client."; TWAMP Control-Client.";
} }
list mode-preference-chain { list mode-preference-chain {
key priority; key priority;
unique mode; unique mode;
leaf priority { leaf priority {
type uint16; type uint16;
skipping to change at page 29, line 41 skipping to change at page 30, line 48
leaf key-id { leaf key-id {
type string { type string {
length 1..80; length 1..80;
} }
description description
"Indicates the KeyID value selected for this "Indicates the KeyID value selected for this
TWAMP-Control connection."; TWAMP-Control connection.";
} }
uses max-count; uses max-count-exponent;
leaf client-tcp-port { leaf client-tcp-port {
type inet:port-number; type inet:port-number;
config false; config false;
description description
"Indicates the source TCP port number used in the "Indicates the source TCP port number used in the
TWAMP-Control packets belonging to this control TWAMP-Control packets belonging to this control
connection."; connection.";
} }
leaf server-start-time { leaf server-start-time {
type uint64; type uint64;
config false; config false;
description description
"Indicates the Start-Time advertized by the Server in "Indicates the Start-Time advertized by the Server in
the Server-Start message (RFC 4656, Section 3.1), the Server-Start message (RFC 4656, Section 3.1),
representing the time when the current representing the time when the current
instantiation of the Server started operating. instantiation of the Server started operating.
The timestamp format follows RFC 1305 The timestamp format follows RFC 1305
according to Section 4.1.2 of RFC 4656."; according to Section 4.1.2 of RFC 4656.";
reference
"RFC 4656: OWAMP, Section 3.1 and 4.1.2,
RFC 1305: NTPv3 Specification.";
} }
leaf repeat-count { leaf repeat-count {
type uint64; type uint64;
config false; config false;
description description
"Indicates how many times the test session has been "Indicates how many times the test session has been
repeated. When a test is running, this value will be repeated. When a test is running, this value will be
greater than 0. If the repeat parameter is non-zero, greater than 0. If the repeat parameter is non-zero,
this value is smaller than or equal to the repeat this value is smaller than or equal to the repeat
skipping to change at page 33, line 22 skipping to change at page 34, line 34
mandatory true; mandatory true;
description description
"The IP address belonging to the remote "The IP address belonging to the remote
Session-Reflector device to which the TWAMP-Test Session-Reflector device to which the TWAMP-Test
session will be initiated. This value will be session will be initiated. This value will be
used to populate the receiver address field of used to populate the receiver address field of
the Request-TW-Session message."; the Request-TW-Session message.";
} }
leaf reflector-udp-port { leaf reflector-udp-port {
type uint32 { type inet:port-number {
range "862 | 49152..65535"; range "862 | 49152..65535";
} }
description description
"This parameter defines the UDP port number that "This parameter defines the UDP port number that
will be used by the Session-Reflector for will be used by the Session-Reflector for
this TWAMP-Test session. The default number is this TWAMP-Test session. The default number is
within to the dynamic port range and is to be placed within the dynamic port range and is to be placed
in the Receiver Port field of the Request-TW-Session in the Receiver Port field of the Request-TW-Session
message. The new well-known port (862) MAY be message. The well-known port (862) MAY be
used."; used.";
reference
"draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP
Well-Known Port Assignments.";
} }
leaf timeout { leaf timeout {
type uint64; type uint64;
units seconds; units seconds;
default 2; default 2;
description description
"The length of time (in seconds) that the "The length of time (in seconds) that the
Session-Reflector should continue to respond to Session-Reflector should continue to respond to
packets belonging to this TWAMP-Test session after packets belonging to this TWAMP-Test session after
a Stop-Sessions TWAMP-Control message has been a Stop-Sessions TWAMP-Control message has been
received (RFC 5357, Section 3.8). received.
This value will be placed in the Timeout field of This value will be placed in the Timeout field of
the Request-TW-Session message."; the Request-TW-Session message.";
reference
"RFC 5357: TWAMP, Section 3.8";
} }
leaf padding-length { leaf padding-length {
type uint32 { type uint32 {
range 64..4096; range 64..4096;
} }
description description
"The number of padding bytes to be added to the "The number of padding bytes to be added to the
TWAMP-Test (UDP) packets generated by the TWAMP-Test (UDP) packets generated by the
Session-Sender. Session-Sender.
skipping to change at page 37, line 12 skipping to change at page 38, line 28
in the SID field of the Accept-Session message"; in the SID field of the Accept-Session message";
reference reference
"Section 4.3 of RFC 6038."; "Section 4.3 of RFC 6038.";
} }
} }
} }
} }
container server { container server {
if-feature server; if-feature server;
presence "Enables TWAMP Server functionality.";
description description
"Configuration of the TWAMP Server logical entity."; "Configuration of the TWAMP Server logical entity.";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
mandatory true; default true;
description description
"Indicates whether the device is allowed to operate "Indicates whether the device is allowed to operate
as a TWAMP Server."; as a TWAMP Server.";
} }
leaf server-tcp-port { leaf server-tcp-port {
type inet:port-number; type inet:port-number;
default 862; default 862;
description description
"This parameter defines the well known TCP port number "This parameter defines the well known TCP port number
skipping to change at page 38, line 31 skipping to change at page 39, line 46
OS-portable version of TWAMP. OS-portable version of TWAMP.
The default behavior if this item is not set is to use The default behavior if this item is not set is to use
the DSCP value from the Control-Clients TCP SYN."; the DSCP value from the Control-Clients TCP SYN.";
reference reference
"Section 3.1 of RFC 5357."; "Section 3.1 of RFC 5357.";
} }
uses count; uses count;
uses max-count; uses max-count-exponent;
leaf modes { leaf modes {
type twamp-modes; type twamp-modes;
description description
"The bit mask of TWAMP Modes this Server instance "The bit mask of TWAMP Modes this Server instance
is willing to support; see IANA TWAMP Modes Registry."; is willing to support; see IANA TWAMP Modes Registry.";
} }
uses key-management; uses key-management;
skipping to change at page 40, line 40 skipping to change at page 42, line 7
description description
"The count value that is in use by this TWAMP-Control "The count value that is in use by this TWAMP-Control
connection. This will usually be the same value connection. This will usually be the same value
as is configured under twamp/server. However, in the as is configured under twamp/server. However, in the
event that the user re-configured server/count event that the user re-configured server/count
after this control connection is already in progress, after this control connection is already in progress,
this read-only value will show the actual count that this read-only value will show the actual count that
is in use for this TWAMP-Control connection."; is in use for this TWAMP-Control connection.";
} }
uses max-count { uses max-count-exponent {
description description
"This read-only value indicates the actual max-count in "This read-only value indicates the actual max-count in
use for this control connection. Usually this would be use for this control connection. Usually this would be
the same value as configured under twamp/server."; the same value as configured under twamp/server.";
} }
leaf salt { leaf salt {
type binary { type binary {
length 16; length 16;
} }
skipping to change at page 41, line 34 skipping to change at page 42, line 49
"A random sequence of octets generated by the Server. "A random sequence of octets generated by the Server.
As described in client/token, Challenge is used As described in client/token, Challenge is used
by the Control-Client to prove possession of a by the Control-Client to prove possession of a
shared secret."; shared secret.";
} }
} }
} }
container session-sender { container session-sender {
if-feature session-sender; if-feature session-sender;
presence "Enables TWAMP Session-Sender functionality.";
description description
"Configuration of the TWAMP Session-Sender logical entity"; "Configuration of the TWAMP Session-Sender logical entity";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
mandatory true; default true;
description description
"Indicates whether the device is allowed to operate "Indicates whether the device is allowed to operate
as a TWAMP Session-Sender."; as a TWAMP Session-Sender.";
} }
list test-session{ list test-session{
key name; key name;
description description
"List of TWAMP Session-Sender test sessions."; "List of TWAMP Session-Sender test sessions.";
skipping to change at page 44, line 4 skipping to change at page 45, line 19
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 "Enables TWAMP Session-Reflector functionality.";
description description
"Configuration of the TWAMP Session-Reflector logical "Configuration of the TWAMP Session-Reflector logical
entity"; entity";
leaf admin-state { leaf admin-state {
type boolean; type boolean;
mandatory true; default true;
description description
"Indicates whether the device is allowed to operate "Indicates whether the device is allowed to operate
as a TWAMP Session-Reflector."; as a TWAMP Session-Reflector.";
} }
leaf refwait { leaf refwait {
type uint32 { type uint32 {
range 1..604800; range 1..604800;
} }
units seconds; units seconds;
skipping to change at page 45, line 29 skipping to change at page 46, line 45
leaf reflector-ip { leaf reflector-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the local Session-Reflector "The IP address of the local Session-Reflector
device, which is the destination IP address used device, which is the destination IP address used
in the TWAMP-Test (UDP) packets belonging to this test in the TWAMP-Test (UDP) packets belonging to this test
session."; session.";
} }
leaf reflector-udp-port { leaf reflector-udp-port {
type uint32 { type inet:port-number {
range "862 | 49152..65535"; range "862 | 49152..65535";
} }
description description
"The destination UDP port number used in the "The destination UDP port number used in the
TWAMP-Test (UDP) test packets belonging to this TWAMP-Test (UDP) test packets belonging to this
test session."; test session.";
} }
leaf parent-connection-client-ip { leaf parent-connection-client-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address on the Control-Client device, which "The IP address on the Control-Client device, which
is the source IP address used in the TWAMP-Control is the source IP address used in the TWAMP-Control
(TCP) packets belonging to the parent control (TCP) packets belonging to the parent control
connection that negotiated this test session."; connection that negotiated this test session.";
} }
leaf parent-connection-client-tcp-port { leaf parent-connection-client-tcp-port {
skipping to change at page 54, line 25 skipping to change at page 55, line 25
<rcv-packets>21</rcv-packets> <rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq> <last-rcv-seq>20</last-rcv-seq>
</test-session> </test-session>
</session-reflector> </session-reflector>
</twamp> </twamp>
</data> </data>
7. Security Considerations 7. Security Considerations
The YANG module defined in Section 5 is designed to be accessed, The YANG module specified in Section 5 this document defines a schema
among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF for data that is designed to be accessed via network management
use a secure transport layer like SSH that is mandatory to implement. protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The
lowest NETCONF [RFC6241] layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246].
The NETCONF Access Control Module (NACM) [RFC8341] provides the means The NETCONF Access Control Module (NACM) [RFC8341] provides the means
to restrict access for particular users to a pre-configured set of to restrict access for particular NETCONF or RESTCONF users to a
NETCONF protocol operations and attributes. preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content..
There are a number of nodes defined in this YANG module which are There are a number of nodes defined in this YANG module which are
writeable. These data nodes may be considered sensitive and writeable. These data nodes may be considered sensitive and
vulnerable to attacks in some network environments. Ability to write vulnerable to attacks in some network environments. Ability to write
into these nodes without proper protection can have a negative effect into these nodes without proper protection can have a negative effect
on the devices that support this feature. on the devices that support this feature.
Examples of nodes that are particularly vulnerable include several Examples of nodes that are particularly vulnerable include several
timeout values put in the protocol to protect against sessions that timeout values put in the protocol to protect against sessions that
are not active but are consuming resources. are not active but are consuming resources.
8. IANA Considerations 8. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is Following the format in IETF XML Registry [RFC3688], the following
requested to be made. registration is requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-twamp URI: urn:ietf:params:xml:ns:yang:ietf-twamp
Registrant Contact: The IPPM WG of the IETF. Registrant Contact: The IPPM WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. registry YANG [RFC6020].
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
skipping to change at page 55, line 45 skipping to change at page 57, line 9
may be made of the information in this document. may be made of the information in this document.
10. Contributors 10. Contributors
Lianshu Zheng. Lianshu Zheng.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ippm-port-twamp-test]
Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
Assignments", draft-ietf-ippm-port-twamp-test-01 (work in
progress), March 2018.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
DOI 10.17487/RFC3432, November 2002, DOI 10.17487/RFC3432, November 2002,
<https://www.rfc-editor.org/info/rfc3432>. <https://www.rfc-editor.org/info/rfc3432>.
skipping to change at page 56, line 38 skipping to change at page 58, line 9
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<https://www.rfc-editor.org/info/rfc6038>. <https://www.rfc-editor.org/info/rfc6038>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014,
<https://www.rfc-editor.org/info/rfc7312>.
[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
"IKEv2-Derived Shared Secret Key for the One-Way Active "IKEv2-Derived Shared Secret Key for the One-Way Active
Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7717, Measurement Protocol (TWAMP)", RFC 7717,
DOI 10.17487/RFC7717, December 2015, DOI 10.17487/RFC7717, December 2015,
<https://www.rfc-editor.org/info/rfc7717>. <https://www.rfc-editor.org/info/rfc7717>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
skipping to change at page 57, line 33 skipping to change at page 59, line 10
[NSC] John, W., Pentikousis, K., et al., "Research directions in [NSC] John, W., Pentikousis, K., et al., "Research directions in
network service chaining", Proc. SDN for Future Networks network service chaining", Proc. SDN for Future Networks
and Services (SDN4FNS), Trento, Italy IEEE, November 2013. and Services (SDN4FNS), Trento, Italy IEEE, November 2013.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
DOI 10.17487/RFC5618, August 2009, DOI 10.17487/RFC5618, August 2009,
<https://www.rfc-editor.org/info/rfc5618>. <https://www.rfc-editor.org/info/rfc5618>.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control [RFC5938] Morton, A. and M. Chiba, "Individual Session Control
Feature for the Two-Way Active Measurement Protocol Feature for the Two-Way Active Measurement Protocol
(TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010,
<https://www.rfc-editor.org/info/rfc5938>. <https://www.rfc-editor.org/info/rfc5938>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1", Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017, RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>. <https://www.rfc-editor.org/info/rfc8018>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
Appendix A. Detailed Data Model Examples Appendix A. Detailed Data Model Examples
This appendix extends the example presented in Section 6 by This appendix extends the example presented in Section 6 by
configuring more fields such as authentication parameters, DSCP configuring more fields such as authentication parameters, DSCP
values and so on. values and so on.
skipping to change at page 65, line 16 skipping to change at page 67, line 16
TWAMP operational commands could be performed programmatically or TWAMP operational commands could be performed programmatically or
manually, e.g. using a command-line interface (CLI). manually, e.g. using a command-line interface (CLI).
With respect to programmability, YANG can be used to define NETCONF With respect to programmability, YANG can be used to define NETCONF
Remote Procedure Calls (RPC), therefore it would be, in principle, Remote Procedure Calls (RPC), therefore it would be, in principle,
possible to define TWAMP RPC operations for actions such as starting possible to define TWAMP RPC operations for actions such as starting
or stopping control connections or test sessions or groups of or stopping control connections or test sessions or groups of
sessions; retrieving results; clearing stored results, and so on. sessions; retrieving results; clearing stored results, and so on.
However, [RFC5357] does not attempt to describe such operational However, TWAMP [RFC5357] does not attempt to describe such
actions. Refer also to Section 2 and the unlabeled links in operational actions. Refer also to Section 2 and the unlabeled links
Figure 1. In actual deployments different TWAMP implementations may in Figure 1. In actual deployments different TWAMP implementations
support different sets of operational commands, with different may support different sets of operational commands, with different
restrictions. Therefore, this document considers it the restrictions. Therefore, this document considers it the
responsibility of the individual implementation to define its responsibility of the individual implementation to define its
corresponding TWAMP operational commands data model. corresponding TWAMP operational commands data model.
Authors' Addresses Authors' Addresses
Ruth Civil Ruth Civil
Ciena Corporation Ciena Corporation
307 Legget Drive 307 Legget Drive
Kanata, ON K2K 3C8 Kanata, ON K2K 3C8
 End of changes. 75 change blocks. 
132 lines changed or deleted 201 lines changed or added

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