< draft-ietf-ippm-twamp-yang-11.txt   draft-ietf-ippm-twamp-yang-12.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: November 26, 2018 AT&T Labs Expires: December 28, 2018 AT&T Labs
R. Rahman R. Rahman
Cisco Systems Cisco Systems
M. Jethanandani M. Jethanandani
Xoriant Corporation
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Travelping
May 25, 2018 June 26, 2018
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-11 draft-ietf-ippm-twamp-yang-12
Abstract Abstract
This document specifies a data model for client and server This document specifies a data model for client and server
implementations of the Two-Way Active Measurement Protocol (TWAMP). implementations of the Two-Way Active Measurement Protocol (TWAMP).
The document defines the TWAMP data model through Unified Modeling The document defines the TWAMP data model through Unified Modeling
Language (UML) class diagrams and formally specifies it using YANG. Language (UML) class diagrams and formally specifies it using a NDMA-
compliant YANG model.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 26, 2018. This Internet-Draft will expire on December 28, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . 8 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
skipping to change at page 2, line 39 skipping to change at page 2, line 40
5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19
6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48
6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51
6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.1. Normative References . . . . . . . . . . . . . . . . . . 57 11.1. Normative References . . . . . . . . . . . . . . . . . . 57
11.2. Informative References . . . . . . . . . . . . . . . . . 58 11.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60
A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64
A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64
Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 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, implementers
have no choice except to provide a proprietary mechanism. This have no choice except to provide a proprietary mechanism. This
document addresses this gap by formally specifying the TWAMP data document addresses this gap by defining the model using UML [UML]
model using YANG 1.1 [RFC7950]. class diagrams, and formally specifying a NMDA-complaint [RFC8342]
TWAMP data model using YANG 1.1 [RFC7950].
1.1. Motivation 1.1. Motivation
In current TWAMP deployments the lack of a standardized data model In current TWAMP deployments the lack of a standardized data model
limits the flexibility to dynamically instantiate TWAMP-based limits the flexibility to dynamically instantiate TWAMP-based
measurements across equipment from different vendors. In large, measurements across equipment from different vendors. In large,
virtualized, and dynamically instantiated infrastructures where virtualized, and dynamically instantiated infrastructures where
network functions are placed according to orchestration algorithms as network functions are placed according to orchestration algorithms,
discussed in Unifying Carrier and Cloud Networks: Problem Statement proprietary mechanisms for managing TWAMP measurements pose severe
and Challenges [I-D.unify-nfvrg-challenges], and 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, it is expected that in the coming years large-scale and multi- First, it is expected that in the coming years large-scale and multi-
vendor TWAMP deployments will become the norm. From an operations vendor TWAMP deployments will become the norm. From an operations
perspective, using several vendor-specific TWAMP configuration perspective, using several vendor-specific TWAMP configuration
mechanisms when one standard mechanism could provide an alternative mechanisms when one standard mechanism could provide an alternative
is expensive and inefficient. Second, the increasingly software- is expensive and inefficient. Second, the increasingly software-
defined and virtualized nature of network infrastructures, based on defined and virtualized nature of network infrastructures, based on
dynamic service chains [NSC] and programmable control and management dynamic service chains [NSC] and programmable control and management
planes Software-Defined Networking (SDN): Layers and Architecture planes Software-Defined Networking (SDN): Layers and Architecture
Terminology [RFC7426] requires a well-defined data model for TWAMP Terminology [RFC7426] requires a well-defined data model for TWAMP
implementations. This document defines such a TWAMP data model and implementations. This document defines such a TWAMP data model and
specifies it formally using the YANG 1.1 [RFC7950] data modeling specifies it formally using the YANG 1.1 [RFC7950] data modeling
language. language.
Note to RFC Editor: Note to RFC Editor:
Please replace the date 2018-05-25 in Section 5.2 of the draft with Please replace the date 2018-06-26 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-port-twamp-test with the reference to RFC XXXX, and draft-ietf-ippm-port-twamp-test with the
RFC numbers assigned to the drafts. RFC numbers assigned to the drafts.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 4, line 30 skipping to change at page 4, line 24
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 TWAMP [RFC5357]. The figure is annotated found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated
with pointers to the UML diagrams provided in this document and with pointers to the UML [UML] diagrams provided in this document and
associated with the data model of the four logical entities in a associated with the data model of the four logical entities in a
TWAMP deployment, namely the TWAMP Control-Client, Server, Session- TWAMP deployment, namely the TWAMP Control-Client, Server, Session-
Sender and Session-Reflector. Sender and Session-Reflector. A UML [UML] Notation Guide is
available in Section 5 of the said document.
As per TWAMP [RFC5357], unlabeled links in Figure 1 are left As per TWAMP [RFC5357], unlabeled links in Figure 1 are left
unspecified and may be proprietary protocols. unspecified and may be proprietary protocols.
[Fig. 3] [Fig. 4] [Fig. 3] [Fig. 4]
+----------------+ +--------+ +----------------+ +--------+
| Control-Client | <-- TWAMP-Control --> | Server | | Control-Client | <-- TWAMP-Control --> | Server |
+----------------+ +--------+ +----------------+ +--------+
^ ^ ^ ^
| | | |
skipping to change at page 5, line 40 skipping to change at page 5, line 34
The data model defined in this document is orthogonal to the specific The data model defined in this document is orthogonal to the specific
protocol used between the Config client and Config server to protocol used between the Config client and Config server to
communicate the TWAMP configuration parameters. communicate the TWAMP configuration parameters.
Operational actions such as how TWAMP-Test sessions are started and Operational actions such as how TWAMP-Test sessions are started and
stopped, how performance measurement results are retrieved, or how stopped, how performance measurement results are retrieved, or how
stored results are cleared, and so on, are not addressed by the stored results are cleared, and so on, are not addressed by the
configuration model defined in this document. As noted above, such configuration model defined in this document. As noted above, such
operational actions are not part of the TWAMP specification TWAMP operational actions are not part of the TWAMP specification TWAMP
[RFC5357] and hence are out of scope of this document. See also [RFC5357] and hence are out of scope of this document. See also
Appendix B. Appendix B. In addition, for operational state, current work in
Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], can
be used to develop an independent model for the performance metrics
that need to be captured and retrieved.
3. Data Model Overview 3. Data Model Overview
The TWAMP data model includes four categories of configuration items. The TWAMP data model includes four categories of configuration items.
First, global configuration items relate to parameters that are set First, global configuration items relate to parameters that are set
on a per device level. For example, the administrative status of the on a per device level. For example, the administrative status of the
device with respect to whether it allows TWAMP sessions and, if so, device with respect to whether it allows TWAMP sessions and, if so,
in what capacity (e.g. Control-Client, Server or both), is a typical in what capacity (e.g. Control-Client, Server or both), is a typical
instance of a global configuration item. instance of a global configuration item.
skipping to change at page 6, line 42 skipping to change at page 6, line 39
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 Section 3.1
paragraph of Section 6 in OWAMP [RFC4656] and Randomness in OWAMP [RFC4656] and Randomness Requirements for Security
Requirements for Security [RFC4086]. [RFC4086].
Each TWAMP-Control connection, in turn, is associated with zero or Each TWAMP-Control connection, in turn, is associated with zero or
more TWAMP-Test sessions. For each test session, the following more TWAMP-Test sessions. For each test session, the following
configuration items should be noted: configuration items should be noted:
o The test session name that uniquely identifies a particular test o The test session name uniquely identifies a particular test
session at the Control-Client and Session-Sender. Similarly to session at the Control-Client and Session-Sender. Similar to the
the control connections above, this unique test session name is control connections above, this unique test session name is needed
needed because at the time of creation of a TWAMP-Test session, because at the time of creation of a TWAMP-Test session, for
for example, the source UDP port number is not known to uniquely 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 Registry for starting time, which performance metric is to be used, as defined
Performance Metrics [I-D.ietf-ippm-metric-registry], or whether in Registry for Performance Metrics
the test should be repeated. [I-D.ietf-ippm-metric-registry], or whether 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 41 skipping to change at page 7, line 39
3.3. Session-Sender 3.3. Session-Sender
A TWAMP Session-Sender has an administrative status field set at the A TWAMP Session-Sender has an administrative status field set at the
device level that indicates whether the node is enabled to function device level that indicates whether the node is enabled to function
as such. as such.
There is one Session-Sender instance for each TWAMP-Test session that There is one Session-Sender instance for each TWAMP-Test session that
is initiated from the sending device. Primary configuration fields is initiated from the sending device. Primary configuration fields
include: include:
o The test session name that MUST be identical with the o The test session name MUST be identical to the corresponding test
corresponding test session name on the TWAMP Control-Client 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, the
example, the number of test packets and the packet distribution to number of test packets and the packet distribution to be employed;
be employed; see also Network performence measurement with see also Network performance measurement with periodic streams
periodic streams [RFC3432]. [RFC3432].
3.4. Session-Reflector 3.4. Session-Reflector
Each TWAMP Session-Reflector has an administrative status field set Each TWAMP Session-Reflector has an administrative status field set
at the device level to indicate whether the node is enabled to at the device level to indicate whether the node is enabled to
function as such. function as such.
Each Session-Reflector is associated with zero or more TWAMP-Test Each Session-Reflector is associated with zero or more TWAMP-Test
sessions. For each test session, the REFWAIT timeout parameter which sessions. For each test session, the REFWAIT timeout parameter,
determines whether to discontinue the session if no packets have been which determines whether to discontinue the session if no packets
received (TWAMP [RFC5357], Section 4.2) can be configured. have been 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
by the 4-tuple mentioned in Section 3.2. identified 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 [UML] and
selected parameters associated with the four TWAMP logical entities. introduces selected parameters associated with the four TWAMP logical
The complete TWAMP data model specification is provided in the YANG entities. The complete TWAMP data model specification is provided in
module presented in Section 5.2. the YANG module presented in Section 5.2.
4.1. Control-Client 4.1. Control-Client
The client container (see Figure 3) holds items that are related to The client container (see Figure 3) holds items that are related to
the configuration of the TWAMP Control-Client logical entity (recall the configuration of the TWAMP Control-Client logical entity (recall
Figure 1). Figure 1).
The client container includes an administrative configuration The client container includes an administrative configuration
parameter (client/admin-state) that indicates whether the device is parameter (client/admin-state) that indicates whether the device is
allowed to initiate TWAMP-Control connections. allowed to initiate TWAMP-Control connections.
skipping to change at page 9, line 47 skipping to change at page 9, line 47
+-------------+ | 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 the and encryption Modes. Specifically, mode-preference-chain lists the
mode and its corresponding priority, expressed as a 16-bit unsigned mode and its corresponding priority, as a 16-bit unsigned integer.
integer, where zero is the highest priority and subsequent integers Values for the priority start with zero, the highest priority, and
increase by one. decreasing priority value is indicated by every increase in value by
one.
Depending on the Modes available in the Server Greeting, the Control- Depending on the Modes available in the Server Greeting, the Control-
Client MUST choose the highest priority Mode from the configured Client MUST choose the highest priority Mode from the configured
mode-preference-chain list. mode-preference-chain list.
Note that the list of preferred Modes may set bit position Note that the list of preferred Modes may set multiple bit positions
combinations when necessary, such as when referring to the extended independently, such as when referring to the extended TWAMP features
TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual in Mixed Security Mode for TWAMP [RFC5618], Individual Session
Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and
Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret
Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot
determine an acceptable Mode, it MUST respond with zero Mode bits set determine an acceptable Mode, or when the bit combinations do not
in the Set-up Response message, indicating it will not continue with make sense, e.g., both authenticated and unauthenticated bit are set,
the control connection. 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 key-id with the respective secret-key. Both the Server and
the Control-Client use the same mappings from KeyIDs to shared the Control-Client use the same mappings from key-id to secret-key
secrets (key-id and secret-key in Figure 3, respectively). The (in Figure 3); in order for this to work properly, key-id must be
Server, being prepared to conduct sessions with more than one unique across all systems in the administrative domain. The Server,
Control-Client, uses KeyIDs to choose the appropriate secret-key; a being prepared to conduct sessions with more than one Control-Client,
Control-Client would typically have different secret keys for uses key-id to choose the appropriate secret-key; a Control-Client
different Servers. The secret-key is the shared secret, a sequence would typically have different secret keys for different Servers.
of octets of arbitrary length whose interpretation is unspecified. The secret-key is the shared secret, of type binary and the length
The key-id and secret-key encoding SHOULD follow Section 9.4 of YANG SHOULD contain at least 128 bits of entropy. The key-id and secret-
[RFC7950]. The derived key length (dkLen in PKCS #5: Password-Based key encoding SHOULD follow Section 9.8 of YANG [RFC7950]. The
Cryptography Specification Version 2.1 [RFC8018]) MUST be 16 octets derived key length (dkLen in PKCS #5: Password-Based Cryptography
for the AES Session-key used for encryption and 32 octets for the Specification Version 2.1 [RFC8018]) MUST be 16 octets for the AES
HMAC-SHA1 Session-key used for authentication; see also Section 6.10 Session-key used for encryption and 32 octets for the HMAC-SHA1
of OWAMP [RFC4656]. 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 test-session-request list.
test-session-request holds information associated with the Control- Each test-session-request holds information associated with the
Client for this test session. This includes information associated Control-Client for this test session. This includes information
with the Request-TW-Session/Accept-Session message exchange (see associated with the Request-TW-Session/Accept-Session message
Section 3.5 of TWAMP [RFC5357]). exchange (see Section 3.5 of TWAMP [RFC5357]).
There SHALL be one instance of test-session-request for each TWAMP- There SHALL be one instance of test-session-request for each 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, therefore test-session-request holds information related to
actions (e.g. pm-index, repeat-interval). these actions (e.g. pm-index, repeat-interval).
4.2. Server 4.2. Server
The server container (see Figure 4) holds items that are related to The server container (see Figure 4) holds items that are related to
the configuration of the TWAMP Server logical entity (recall the configuration of the TWAMP Server logical entity (recall
Figure 1). Figure 1).
The server container includes an administrative configuration The server container includes an administrative configuration
parameter (server/admin-state) that indicates whether the device is parameter (server/admin-state) that indicates whether the device is
allowed to receive TWAMP-Control connections. allowed to receive TWAMP-Control connections.
skipping to change at page 12, line 35 skipping to change at page 12, line 35
| key-id {ro} | | key-id {ro} |
| count {ro} | | count {ro} |
| max-count {ro} | | max-count {ro} |
| salt {ro} | | salt {ro} |
| server-iv {ro} | | server-iv {ro} |
| challenge {ro} | | challenge {ro} |
+--------------------------+ +--------------------------+
Figure 4: TWAMP Server UML class diagram Figure 4: TWAMP Server UML class diagram
Each server container holds a list named key-chain which relates Each server container holds a list named key-chain which relates key-
KeyIDs with the respective secret keys. As mentioned in Section 4.1, id with the respective secret-key. As mentioned in Section 4.1, both
both the Server and the Control-Client use the same mappings from the Server and the Control-Client use the same mapping from key-id to
KeyIDs to shared secrets. The Server, being prepared to conduct shared secret-key; in order for this to work properly, key-id must be
sessions with more than one Control-Client, uses KeyIDs to choose the unique across all the systems in the administrative domain. The
appropriate secret-key; a Control-Client would typically have Server, being prepared to conduct sessions with more than one
different secret keys for different Servers. key-id tells the Server Control-Client, uses key-id to choose the appropriate secret-key; a
which shared-secret the Control-Client wishes to use for Control-Client would typically have different secret keys for
authentication or encryption. different Servers. The key-id tells the Server which shared secret-
key the Control-Client wishes to use for authentication or
encryption.
Each incoming control connection active on the Server is represented Each incoming control connection active on the Server is represented
by a ctrl-connection. There SHALL be one ctrl-connection per by a ctrl-connection. There SHALL be one ctrl-connection per
incoming TWAMP-Control (TCP) connection that is received and active incoming TWAMP-Control (TCP) connection that is received and active
on the Server. Each ctrl-connection can be uniquely identified by on the Server. Each ctrl-connection can be uniquely identified by
the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}. the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}.
All items in the ctrl-connection list are read-only. All items in the ctrl-connection list are read-only.
4.3. Session-Sender 4.3. Session-Sender
skipping to change at page 13, line 24 skipping to change at page 13, line 24
+----------------+ +----------------+
| session-sender | | session-sender |
+----------------+ 0..* +---------------------------+ +----------------+ 0..* +---------------------------+
| admin-state |<>-----| test-session | | admin-state |<>-----| test-session |
+----------------+ +---------------------------+ +----------------+ +---------------------------+
| name | | name |
| ctrl-connection-name {ro} | | ctrl-connection-name {ro} |
| fill-mode | | fill-mode |
| number-of-packets | | number-of-packets |
| state {ro} | | state {ro} |
| sent-packets {ro} | | sent-packets {ro} |
| rcv-packets {ro} | | rcv-packets {ro} |
| last-sent-seq {ro} | | last-sent-seq {ro} |
| last-rcv-seq {ro} | | last-rcv-seq {ro} |
+---------------------------+ +---------------------------+
^ ^
V V
| 1 | 1
+---------------------+ +---------------------+
| packet-distribution | | packet-distribution |
skipping to change at page 15, line 5 skipping to change at page 15, line 5
(session-reflector/admin-state) that controls whether the device is (session-reflector/admin-state) that controls whether the device is
allowed to respond to incoming TWAMP-Test sessions. allowed to respond to incoming TWAMP-Test sessions.
A device operating in the Session-Reflector role cannot configure A device operating in the Session-Reflector role cannot configure
attributes on a per-session basis, as it has no foreknowledge of what attributes on a per-session basis, as it has no foreknowledge of what
incoming sessions it will receive. As such, any parameter that the incoming sessions it will receive. As such, any parameter that the
Session-Reflector might want to apply to an incoming TWAMP-Test Session-Reflector might want to apply to an incoming TWAMP-Test
session must be configured at the overall Session-Reflector level and session must be configured at the overall Session-Reflector level and
are applied to all incoming sessions. are applied to all incoming sessions.
+----=--------------+ +-------------------+
| session-reflector | | session-reflector |
+-------------------+ +-------------------+
| admin-state | | admin-state |
| refwait | | refwait |
+-------------------+ +-------------------+
^ ^
V V
| |
| 0..* | 0..*
+----------------------------------------+ +----------------------------------------+
skipping to change at page 17, line 23 skipping to change at page 17, line 23
| +--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? inet:port-number | +--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? uint32
| +--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
skipping to change at page 19, line 9 skipping to change at page 19, line 9
+--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 Common
YANG Data Types [RFC6991], and references NTPv3 Specification YANG Data Types [RFC6991], and references NTPv4 Specification
[RFC5905], Framework for IP Performance Metrics [RFC2330], Randomness [RFC5905], Framework for IP Performance Metrics [RFC2330], Randomness
Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP
[RFC5357], More Features for TWAMP [RFC5618], Individual Session [RFC5357], More Features for TWAMP [RFC5618], Individual Session
Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size
Features [RFC6038], Advances Stream and Sampling Framework [RFC7312], Features [RFC6038], Advances Stream and Sampling Framework [RFC7312],
IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717], and IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717], and
OWAMP and TWAMP Well-Known Port Assignments OWAMP and TWAMP Well-Known Port Assignments
[I-D.ietf-ippm-port-twamp-test]. [I-D.ietf-ippm-port-twamp-test].
<CODE BEGINS> file "ietf-twamp@2018-05-25.yang" <CODE BEGINS> file "ietf-twamp@2018-06-26.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 20, line 26 skipping to change at page 20, line 26
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-05-25 { revision 2018-06-26 {
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 29 skipping to change at page 21, line 29
cryptographic protection against accuracy of cryptographic protection against accuracy of
timestamps.'"; timestamps.'";
reference reference
"RFC 4656: A One-way Active Measurement Protocol "RFC 4656: A One-way Active Measurement Protocol
(OWAMP)"; (OWAMP)";
} }
bit encrypted { bit encrypted {
position 2; position 2;
description description
"Encrypted mode 'makes it impossible to alter "Encrypted mode 'makes it impossible to alter
timestamps undetectably.' See also Section 4 of RFC 7717 timestamps undetectably' [Section 6 of RFC 4656].
and Section 6 of RFC 4656."; See also Section 4 of RFC 7717.";
reference reference
"RFC 4656: A One-way Active Measurement Protocol "RFC 4656: A One-way Active Measurement Protocol
(OWAMP)"; (OWAMP)";
} }
bit unauth-test-encrpyt-control { bit unauth-test-encrpyt-control {
position 3; position 3;
description description
"When using the Mixed Security Mode, the TWAMP-Test "When using the Mixed Security Mode, the TWAMP-Test
protocol follows the Unauthenticated mode and the protocol follows the Unauthenticated mode and the
TWAMP-Control protocol the Encrypted mode."; TWAMP-Control protocol the Encrypted mode.";
skipping to change at page 27, line 16 skipping to change at page 27, line 16
} }
description description
"Used for TWAMP-Test maintenance statistics."; "Used for TWAMP-Test maintenance statistics.";
} }
grouping count { grouping count {
leaf count { leaf count {
type uint8 { type uint8 {
range "10..31"; range "10..31";
} }
default 10; default 15;
description description
"Parameter communicated to the Control-Client as part of "Parameter communicated to the Control-Client as part of
the Server Greeting message and used for deriving a key the Server Greeting message and used for deriving a key
from a shared secret as per Section 3.1 of RFC 4656: from a shared secret as per Section 3.1 of RFC 4656:
MUST be a power of 2 and at least 1024. It is configured MUST be a power of 2 and at least 1024. It is configured
by providing said power. For example, configuring 15 here by providing said power. For example, configuring 20 here
means count 2^15 = 32768. The default is 10, means count 2^20 = 1048576. The default is 15,
meaning 2^10 = 1024."; meaning 2^15 = 32768.";
} }
description description
"Reusable data structure for count, which is used both in the "Reusable data structure for count, which is used both in the
Server and the Control-Client."; Server and the Control-Client.";
} }
grouping max-count-exponent { grouping max-count-exponent {
leaf max-count-exponent { leaf max-count-exponent {
type uint8 { type uint8 {
range 10..31; range 10..31;
} }
default 15; default 20;
description description
"This parameter limits the maximum Count value, which MUST "This parameter limits the maximum Count value, which MUST
be a power of 2 and at least 1024 as per RFC 5357. It is be a power of 2 and at least 1024 as per RFC 5357. It is
configured by providing said power. For example, configured by providing said power. For example,
configuring 10 here means max count 2^10 = 1024. configuring 10 here means max count 2^10 = 1024.
The default is 15, meaning 2^15 = 32768. The default is 20, meaning 2^20 = 1048576.
A TWAMP Server uses this configured value in the A TWAMP Server uses this configured value in the
Server-Greeting message sent to the Control-Client. Server-Greeting message sent to the Control-Client.
A TWAMP Control-Client uses this configured value to A TWAMP Control-Client uses this configured value to
prevent denial-of-service (DOS) attacks by closing the prevent denial-of-service (DOS) attacks by closing the
control connection to the Server if it 'receives a control connection to the Server if it 'receives a
Server-Greeting message with Count greater that its Server-Greeting message with Count greater that its
maximum configured value', as per Section 6 of RFC 5357. maximum configured value', as per Section 6 of RFC 5357.
skipping to change at page 29, line 11 skipping to change at page 29, line 11
"Indicates whether the device is allowed to operate as a "Indicates whether the device is allowed to operate as a
TWAMP Control-Client."; TWAMP Control-Client.";
} }
list mode-preference-chain { list mode-preference-chain {
key priority; key priority;
unique mode; unique mode;
leaf priority { leaf priority {
type uint16; type uint16;
description description
"Indicates the Control-Client Mode preference priority "Indicates the Control-Client Mode preference priority
expressed as a 16-bit unsigned integer, where zero is expressed as a 16-bit unsigned integer. Values for the
the highest priority and subsequent values priority start with zero, the highest priority, and
monotonically increasing."; decreasing priority value is indicated by every increase
in value by one.";
} }
leaf mode { leaf mode {
type twamp-modes; type twamp-modes;
description description
"The supported TWAMP Mode matching the corresponding "The supported TWAMP Mode matching the corresponding
priority."; priority.";
} }
description description
"Indicates the Control-Client preferred order of use of "Indicates the Control-Client preferred order of use of
the supported TWAMP Modes. the supported TWAMP Modes.
Depending on the Modes available in the TWAMP Server Depending on the Modes available in the TWAMP Server
Greeting message (see Fig. 2 of RFC 7717), the Greeting message (see Fig. 2 of RFC 7717), the
this Control-Client MUST choose the highest priority Control-Client MUST choose the highest priority
Mode from the configured mode-preference-chain list."; Mode from the configured mode-preference-chain list.";
} }
uses key-management; uses key-management;
list ctrl-connection { list ctrl-connection {
key name; key name;
description description
"List of TWAMP Control-Client control connections. "List of TWAMP Control-Client control connections.
Each item in the list describes a control connection Each item in the list describes a control connection
skipping to change at page 30, line 50 skipping to change at page 31, line 4
} }
leaf key-id { leaf key-id {
type string { type string {
length 1..80; length 1..80;
} }
description description
"Indicates the KeyID value selected for this "Indicates the KeyID value selected for this
TWAMP-Control connection."; TWAMP-Control connection.";
} }
uses max-count-exponent; uses max-count-exponent;
leaf client-tcp-port { leaf client-tcp-port {
type inet:port-number; type inet:port-number;
config false; config false;
description description
"Indicates the source TCP port number used in the "Indicates the source TCP port number used in the
TWAMP-Control packets belonging to this control TWAMP-Control packets belonging to this control
connection."; connection.";
} }
leaf server-start-time { leaf server-start-time {
type uint64; type uint64;
config false; config false;
description description
"Indicates the Start-Time advertized by the Server in "Indicates the Start-Time advertised by the Server in
the Server-Start message (RFC 4656, Section 3.1), the Server-Start message (RFC 4656, Section 3.1),
representing the time when the current representing the time when the current
instantiation of the Server started operating. instantiation of the Server started operating.
The timestamp format follows RFC 1305 The timestamp format follows RFC 5905
according to Section 4.1.2 of RFC 4656."; according to Section 4.1.2 of RFC 4656.";
reference reference
"RFC 4656: OWAMP, Section 3.1 and 4.1.2, "RFC 4656: OWAMP, Section 3.1 and 4.1.2,
RFC 1305: NTPv3 Specification."; RFC 5905: NTPv4 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 34, line 12 skipping to change at page 34, line 14
default autoallocate; default autoallocate;
description description
"The UDP port number that is to be used by "The UDP port number that is to be used by
the Session-Sender for this TWAMP-Test session. the Session-Sender for this TWAMP-Test session.
The number is restricted to the dynamic port range. The number is restricted to the dynamic port range.
By default the Control-Client SHALL auto-allocate a By default the Control-Client SHALL auto-allocate a
UDP port number for this TWAMP-Test session. UDP port number for this TWAMP-Test session.
The configured (or auto-allocated) value is The configured (or auto-allocated) value is
advertized in the Sender Port field of the advertised in the Sender Port field of the
Request-TW-session message (see Section 3.5 of Request-TW-session message (see Section 3.5 of
RFC 5357). Note that in the scenario where a device RFC 5357). Note that in the scenario where a device
auto-allocates a UDP port number for a session, and auto-allocates a UDP port number for a session, and
the repeat parameter for that session indicates that the repeat parameter for that session indicates that
it should be repeated, the device is free to it should be repeated, the device is free to
auto-allocate a different UDP port number when it auto-allocate a different UDP port number when it
negotiates the next (repeated) iteration of this negotiates the next (repeated) iteration of this
session."; session.";
} }
skipping to change at page 34, line 50 skipping to change at page 35, line 4
will be used by the Session-Reflector for will be used by the Session-Reflector for
this TWAMP-Test session. The default number is this TWAMP-Test session. The default number is
within the dynamic port range and is to be placed within the dynamic port range and is to be placed
in the Receiver Port field of the Request-TW-Session in the Receiver Port field of the Request-TW-Session
message. The well-known port (862) MAY be message. The well-known port (862) MAY be
used."; used.";
reference reference
"draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP "draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP
Well-Known Port Assignments."; 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. received.
This value will be placed in the Timeout field of This value will be placed in the Timeout field of
the Request-TW-Session message."; the Request-TW-Session message.";
reference reference
"RFC 5357: TWAMP, Section 3.8"; "RFC 5357: TWAMP, Section 3.5.";
} }
leaf padding-length { leaf padding-length {
type uint32 { type uint32 {
range 64..4096; range 64..4096;
} }
description description
"The number of padding bytes to be added to the "The number of padding bytes to be added to the
TWAMP-Test (UDP) packets generated by the TWAMP-Test (UDP) packets generated by the
Session-Sender. Session-Sender.
skipping to change at page 35, line 50 skipping to change at page 36, line 4
of TWAMP-Test packets generated by the of TWAMP-Test packets generated by the
Session-Sender, and in the UDP header of the Session-Sender, and in the UDP header of the
TWAMP-Test response packets generated by the TWAMP-Test response packets generated by the
Session-Reflector for this test session. Session-Reflector for this test session.
This value will be placed in the Type-P Descriptor This value will be placed in the Type-P Descriptor
field of the Request-TW-Session message"; field of the Request-TW-Session message";
reference reference
"RFC 5357."; "RFC 5357.";
} }
leaf start-time { leaf start-time {
type uint64; type uint64;
default 0; default 0;
description description
"Time when the session is to be started "Time when the session is to be started
(but not before the TWAMP Start-Sessions command (but not before the TWAMP Start-Sessions command
is issued; see Section 3.4 of RFC 5357). is issued; see Section 3.4 of RFC 5357).
The start-time value is placed in the Start Time The start-time value is placed in the Start Time
field of the Request-TW-Session message. field of the Request-TW-Session message.
The timestamp format follows RFC 1305 as per The timestamp format follows RFC 5905 as per
Section 3.5 of RFC 4656. Section 3.5 of RFC 4656.
The default value of 0 indicates that the session The default value of 0 indicates that the session
will be started as soon as the Start-Sessions will be started as soon as the Start-Sessions
message is received."; message is received.";
} }
leaf repeat { leaf repeat {
type union { type uint32 {
type uint32 { range 0..4294967295;
range 0..4294967294;
}
type enumeration {
enum forever {
description
"Indicates that the test session SHALL be
repeated *forever* using the information in
repeat-interval parameter, and SHALL NOT
decrement the value.";
}
}
} }
default 0; default 0;
description description
"This value determines if the TWAMP-Test session must "This value determines if the TWAMP-Test session must
be repeated. When a test session has completed, the be repeated. When a test session has completed, the
repeat parameter is checked. repeat parameter is checked.
The default value of 0 indicates that the session The default value of 0 indicates that the session
MUST NOT be repeated. MUST NOT be repeated.
If the repeat value is 1 through 4,294,967,294 If the repeat value is 1 through 4,294,967,294
then the test session SHALL be repeated using the then the test session SHALL be repeated using the
information in repeat-interval parameter, and the information in repeat-interval parameter, and the
parent TWAMP-Control connection for this test parent TWAMP-Control connection for this test
session is restarted to negotiate a new instance session is restarted to negotiate a new instance
of this TWAMP-Test session."; of this TWAMP-Test session.
A value of 4,294,967,295 indicates that the test
session SHALL be repeated *forever* using the
information in repeat-interval parameter, and SHALL
NOT decrement the value.";
} }
leaf repeat-interval { leaf repeat-interval {
when "../repeat!='0'" { when "../repeat!='0'" {
description description
"This parameter determines the timing of repeated "This parameter determines the timing of repeated
TWAMP-Test sessions when repeat is more than 0. TWAMP-Test sessions when repeat is more than 0.
When the value of repeat-interval is 0, the When the value of repeat-interval is 0, the
negotiation of a new test session SHALL begin negotiation of a new test session SHALL begin
skipping to change at page 48, line 25 skipping to change at page 48, line 24
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
Figure 8 shows a configuration example for a Control-Client with Figure 8 shows a configuration example for a Control-Client with
client/admin-state enabled. In a real implementation following client/admin-state enabled. In a real implementation following
Figure 2 this would permit the initiation of TWAMP-Control Figure 2 this would permit the initiation of TWAMP-Control
connections and TWAMP-Test sessions. connections and TWAMP-Test sessions.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</client> </client>
</twamp> </twamp>
</config> </config>
Figure 8: XML instance enabling Control-Client operation. Figure 8: XML instance enabling Control-Client operation.
The following example shows a Control-Client with two instances of The following example shows a Control-Client with two instances of
client/ctrl-connection, one called "RouterA" and another called client/ctrl-connection, one called "RouterA" and another called
"RouterB". Each TWAMP-Control connection is to a different Server. "RouterB". Each TWAMP-Control connection is to a different Server.
The control connection named "RouterA" has two test session requests. The control connection named "RouterA" has two test session requests.
The TWAMP-Control connection named "RouterB" has no TWAMP-Test The TWAMP-Control connection named "RouterB" has no TWAMP-Test
session requests. session requests.
[note: '\' line wrapping is for formatting only]
<?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>
skipping to change at page 49, line 35 skipping to change at page 49, line 29
</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>
</client> </client>
</twamp> </twamp>
</config> </config>
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<client> <client>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<ctrl-connection> <ctrl-connection>
<name>RouterA</name> <name>RouterA</name>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:DB8:203:0:113::1</client-ip>
<server-ip>2001:DB8:203:0:113::2</server-ip> <server-ip>2001:DB8:203:0:113::2</server-ip>
<test-session-request> <test-session-request>
skipping to change at page 50, line 30 skipping to change at page 50, line 22
</client> </client>
</twamp> </twamp>
</config> </config>
6.2. Server 6.2. Server
Figure 9 shows a configuration example for a Server with server/ Figure 9 shows a configuration example for a Server with server/
admin-state enabled, which permits a device following Figure 2 to admin-state enabled, which permits a device following Figure 2 to
respond to TWAMP-Control connections and TWAMP-Test sessions. respond to TWAMP-Control connections and TWAMP-Test sessions.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</server> </server>
</twamp> </twamp>
</config> </config>
Figure 9: XML instance enabling Server operation. Figure 9: XML instance enabling Server operation.
The following example presents a Server with the TWAMP-Control The following example presents a Server with the TWAMP-Control
connection corresponding to the control connection name (client/ctrl- connection corresponding to the control connection name (client/ctrl-
connection/name) "RouterA" presented in Section 6.1. connection/name) "RouterA" presented in Section 6.1.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<ctrl-connection> <ctrl-connection>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<client-tcp-port>16341</client-tcp-port> <client-tcp-port>16341</client-tcp-port>
<server-ip>203.0.113.2</server-ip> <server-ip>203.0.113.2</server-ip>
<server-tcp-port>862</server-tcp-port> <server-tcp-port>862</server-tcp-port>
<state>active</state> <state>active</state>
</ctrl-connection> </ctrl-connection>
</server> </server>
</twamp> </twamp>
</data> </data>
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<ctrl-connection> <ctrl-connection>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:DB8:203:0:113::1</client-ip>
<client-tcp-port>16341</client-tcp-port> <client-tcp-port>16341</client-tcp-port>
<server-ip>2001:DB8:203:0:113::2</server-ip> <server-ip>2001:DB8:203:0:113::2</server-ip>
<server-tcp-port>862</server-tcp-port> <server-tcp-port>862</server-tcp-port>
skipping to change at page 52, line 5 skipping to change at page 52, line 5
</server> </server>
</twamp> </twamp>
</data> </data>
6.3. Session-Sender 6.3. Session-Sender
Figure 10 shows a configuration example for a Session-Sender with Figure 10 shows a configuration example for a Session-Sender with
session-sender/admin-state enabled, which permits a device following session-sender/admin-state enabled, which permits a device following
Figure 2 to initiate TWAMP-Test sessions. Figure 2 to initiate TWAMP-Test sessions.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-sender> <session-sender>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</session-sender> </session-sender>
</twamp> </twamp>
</config> </config>
Figure 10: XML instance enabling Session-Sender operation. Figure 10: XML instance enabling Session-Sender operation.
The following configuration example shows a Session-Sender with the The following configuration example shows a Session-Sender with the
two TWAMP-Test sessions presented in Section 6.1. two TWAMP-Test sessions presented in Section 6.1.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-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>
skipping to change at page 53, line 5 skipping to change at page 53, line 5
</session-sender> </session-sender>
</twamp> </twamp>
</data> </data>
6.4. Session-Reflector 6.4. Session-Reflector
This configuration example shows a Session-Reflector with session- This configuration example shows a Session-Reflector with session-
reflector/admin-state enabled, which permits a device following reflector/admin-state enabled, which permits a device following
Figure 2 to respond to TWAMP-Test sessions. Figure 2 to respond to TWAMP-Test sessions.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
</session-reflector> </session-reflector>
</twamp> </twamp>
</config> </config>
Figure 11: XML instance enabling Session-Reflector operation. Figure 11: XML instance enabling Session-Reflector operation.
skipping to change at page 53, line 50 skipping to change at page 53, line 48
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<sent-packets>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>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip> <reflector-ip>192.0.2.2</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip>203.0.113.1</parent-connection-\ <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip> client-ip>
<parent-connection-client-tcp-port>16341</parent-connection-\ <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port> client-tcp-port>
<parent-connection-server-ip>203.0.113.2</parent-connection-\ <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip> server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<sent-packets>21</sent-packets> <sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets> <rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq> <last-sent-seq>20</last-sent-seq>
skipping to change at page 54, line 51 skipping to change at page 54, line 50
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
<sent-packets>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>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip> <reflector-ip>192.0.2.2</reflector-ip>
<reflector-udp-port>55001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip>203.0.113.1</parent-connection-\ <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip> client-ip>
<parent-connection-client-tcp-port>16341</parent-connection-\ <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port> client-tcp-port>
<parent-connection-server-ip>203.0.113.2</parent-connection-\ <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip> server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
skipping to change at page 55, line 25 skipping to change at page 55, line 23
<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 specified in Section 5 this document defines a schema Virtually all existing measurement systems using TWAMP [RFC5357] are
for data that is designed to be accessed via network management administered by the same network operator. Attacks on the
protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The measurement infrastructure could be launched by third-parties to
lowest NETCONF [RFC6241] layer is the secure transport layer, and the commandeer the packet generation capability, corrupt the
mandatory-to-implement secure transport is Secure Shell (SSH) measurements, or other examples of nefarious acts.
The YANG module specified in Section 5 of this document defines a
schema for data that is designed to be accessed via network
management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF [RFC6241] layer is the secure transport layer, and
the mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246]. 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 NETCONF or RESTCONF users to a to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.. 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 Nodes such as 'admin-state' that cause test sessions to be created,
timeout values put in the protocol to protect against sessions that or 'number-of-packets' that dictate how many packets are sent in any
are not active but are consuming resources. Limiting access to these particular test session are obvious. Examples of nodes that are
nodes will limit the ability to launch an attack in network particularly vulnerable include several timeout values put in the
environments. protocol to protect against sessions that are not active but are
consuming resources. Examples include the REFWAIT timeout parameter
which determine whether to discontinue the session if no packets are
received. Nodes like 'count' and 'max-count-exponent' can cause a
long time to be spent on PBKDF2 iterations. In addition, nodes such
as 'dscp' marked with different DSCP markings, can cause the test
traffic on the network to be skewed, and the result manipulated.
Finally, nodes within 'mode-preference-chain' which specify the
'mode' and 'priority' values and indicate the preferred order of use
by an operator, can for example, be manipulated to send
unauthenticated or non-encrypted traffic, enabling a MITM attack.
Limiting access to these nodes will limit the ability to launch an
attack in network environments.
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 IETF XML Registry [RFC3688], the following Following the format in IETF XML Registry [RFC3688], the following
registration is 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 IESG.
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 YANG [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
skipping to change at page 58, line 34 skipping to change at page 58, line 49
<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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References [UML] ISO/IEC, "Information technology - Open Distributed
Processing - Unified Modeling Language", April 2005.
[I-D.unify-nfvrg-challenges]
Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,
D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud
Networks: Problem Statement and Challenges", draft-unify-
nfvrg-challenges-04 (work in progress), July 2016.
[I-D.unify-nfvrg-devops] 11.2. Informative References
Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G.,
Pentikousis, K., Wright, S., Lynch, P., and W. John,
"DevOps for Software-Defined Telecom Infrastructures",
draft-unify-nfvrg-devops-06 (work in progress), July 2016.
[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.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
skipping to change at page 60, line 14 skipping to change at page 60, line 23
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [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>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
Appendix A. Detailed Data Model Examples Appendix A. Detailed Data Model Examples
This appendix extends the example presented in Section 6 by This appendix extends the 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.
A.1. Control-Client A.1. Control-Client
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<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>
</mode-preference-chain> </mode-preference-chain>
<mode-preference-chain> <mode-preference-chain>
skipping to change at page 61, line 25 skipping to change at page 61, line 37
<reflector-ip>203.0.113.2</reflector-ip> <reflector-ip>203.0.113.2</reflector-ip>
<reflector-udp-port>55001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<padding-length>128</padding-length> <padding-length>128</padding-length>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
</client> </client>
</twamp> </twamp>
</data> </data>
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<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>
</mode-preference-chain> </mode-preference-chain>
<mode-preference-chain> <mode-preference-chain>
skipping to change at page 62, line 31 skipping to change at page 62, line 41
<padding-length>128</padding-length> <padding-length>128</padding-length>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
</client> </client>
</twamp> </twamp>
</data> </data>
A.2. Server A.2. Server
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<servwait>1800</servwait> <servwait>1800</servwait>
<control-packet-dscp>32</control-packet-dscp> <control-packet-dscp>32</control-packet-dscp>
<modes>authenticated unauthenticated</modes> <modes>authenticated unauthenticated</modes>
<count>30</count> <count>15</count>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>c2VjcmV0MQ==</secret-key> <secret-key>c2VjcmV0MQ==</secret-key>
</key-chain> </key-chain>
<key-chain> <key-chain>
<key-id>KeyClient10ToRouterA</key-id> <key-id>KeyClient10ToRouterA</key-id>
<secret-key>c2VjcmV0MTANCg==</secret-key> <secret-key>c2VjcmV0MTANCg==</secret-key>
</key-chain> </key-chain>
<ctrl-connection> <ctrl-connection>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<client-tcp-port>16341</client-tcp-port> <client-tcp-port>16341</client-tcp-port>
<server-ip>203.0.113.2</server-ip> <server-ip>203.0.113.2</server-ip>
<server-tcp-port>862</server-tcp-port> <server-tcp-port>862</server-tcp-port>
<control-packet-dscp>32</control-packet-dscp> <control-packet-dscp>32</control-packet-dscp>
<selected-mode>unauthenticated</selected-mode> <selected-mode>unauthenticated</selected-mode>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<count>30</count> <count>15</count>
</ctrl-connection> </ctrl-connection>
</server> </server>
</twamp> </twamp>
</data> </data>
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<server> <server>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<servwait>1800</servwait> <servwait>1800</servwait>
<control-packet-dscp>32</control-packet-dscp> <control-packet-dscp>32</control-packet-dscp>
<modes>authenticated unauthenticated</modes> <modes>authenticated unauthenticated</modes>
<count>30</count> <count>15</count>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>c2VjcmV0MQ==</secret-key> <secret-key>c2VjcmV0MQ==</secret-key>
</key-chain> </key-chain>
<key-chain> <key-chain>
<key-id>KeyClient10ToRouterA</key-id> <key-id>KeyClient10ToRouterA</key-id>
<secret-key>c2VjcmV0MTANCg==</secret-key> <secret-key>c2VjcmV0MTANCg==</secret-key>
</key-chain> </key-chain>
<ctrl-connection> <ctrl-connection>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:DB8:203:0:113::1</client-ip>
<client-tcp-port>16341</client-tcp-port> <client-tcp-port>16341</client-tcp-port>
<server-ip>2001:DB8:203:0:113::2</server-ip> <server-ip>2001:DB8:203:0:113::2</server-ip>
<server-tcp-port>862</server-tcp-port> <server-tcp-port>862</server-tcp-port>
<control-packet-dscp>32</control-packet-dscp> <control-packet-dscp>32</control-packet-dscp>
<selected-mode>unauthenticated</selected-mode> <selected-mode>unauthenticated</selected-mode>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<count>30</count> <count>15</count>
</ctrl-connection> </ctrl-connection>
</server> </server>
</twamp> </twamp>
</data> </data>
A.3. Session-Sender A.3. Session-Sender
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-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>
skipping to change at page 65, line 25 skipping to change at page 65, line 28
rver-tcp-port> rver-tcp-port>
<test-packet-dscp>32</test-packet-dscp> <test-packet-dscp>32</test-packet-dscp>
<sent-packets>2</sent-packets> <sent-packets>2</sent-packets>
<rcv-packets>2</rcv-packets> <rcv-packets>2</rcv-packets>
<last-sent-seq>1</last-sent-seq> <last-sent-seq>1</last-sent-seq>
<last-rcv-seq>1</last-rcv-seq> <last-rcv-seq>1</last-rcv-seq>
</test-session> </test-session>
<test-session> <test-session>
<sender-ip>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip> <reflector-ip>192.0.2.2</reflector-ip>
<reflector-udp-port>55001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<sid>178943</sid> <sid>178943</sid>
<parent-connection-client-ip>203.0.113.1</parent-connection-\ <parent-connection-client-ip>203.0.113.1</parent-connection-\
client-ip> client-ip>
<parent-connection-client-tcp-port>16341</parent-connection-\ <parent-connection-client-tcp-port>16341</parent-connection-\
client-tcp-port> client-tcp-port>
<parent-connection-server-ip>203.0.113.2</parent-connection-\ <parent-connection-server-ip>203.0.113.2</parent-connection-\
server-ip> server-ip>
<parent-connection-server-tcp-port>862</parent-connection-se\ <parent-connection-server-tcp-port>862</parent-connection-se\
rver-tcp-port> rver-tcp-port>
skipping to change at page 68, line 13 skipping to change at page 68, line 13
Email: acmorton@att.com Email: acmorton@att.com
Reshad Rahman Reshad Rahman
Cisco Systems Cisco Systems
2000 Innovation Drive 2000 Innovation Drive
Kanata, ON K2K 3E8 Kanata, ON K2K 3E8
Canada Canada
Email: rrahman@cisco.com Email: rrahman@cisco.com
Mahesh Jethanandani Mahesh Jethanandani
Xoriant Corporation
1248 Reamswood Drive
Sunnyvale, CA 94089
USA
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Kostas Pentikousis (editor) Kostas Pentikousis (editor)
Travelping Travelping
Siemensdamm 50 Siemensdamm 50
Berlin 13629 Berlin 13629
Germany Germany
Email: k.pentikousis@travelping.com Email: k.pentikousis@travelping.com
 End of changes. 88 change blocks. 
189 lines changed or deleted 181 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/