draft-ietf-ippm-twamp-yang-06.txt   draft-ietf-ippm-twamp-yang-07.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: August 17, 2018 AT&T Labs Expires: October 10, 2018 AT&T Labs
R. Rahman R. Rahman
Cisco Systems Cisco Systems
M. Jethanandani M. Jethanandani
K. Pentikousis, Ed. K. Pentikousis, Ed.
Travelping Travelping
February 13, 2018 April 8, 2018
Two-Way Active Measurement Protocol (TWAMP) Data Model Two-Way Active Measurement Protocol (TWAMP) Data Model
draft-ietf-ippm-twamp-yang-06 draft-ietf-ippm-twamp-yang-07
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 August 17, 2018. This Internet-Draft will expire on October 10, 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7 3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7
4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8
4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8 4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8
4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 12 4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 12
4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13 4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18
6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 46 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 46
6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 46 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 47
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 49 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 50
6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 50 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.1. Normative References . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . 55
11.2. Informative References . . . . . . . . . . . . . . . . . 56 11.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 57 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 58
A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 57 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 58
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 61 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 62
A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 62 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 62
Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 64 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to
measure network performance parameters such as latency, bandwidth, measure network performance parameters such as latency, bandwidth,
and packet loss by sending probe packets and measuring their and packet loss by sending probe packets and measuring their
experience in the network. To date, TWAMP implementations do not experience in the network. To date, TWAMP implementations do not
come with a standard management framework and, as such, configuration come with a standard management framework, and, as such, implementors
depends on proprietary mechanisms developed by the corresponding have no choice except to provide a proprietary mechanism. This
TWAMP vendor. This document addresses this gap by formally document addresses this gap by formally specifying the TWAMP data
specifying the TWAMP data model using YANG. model using YANG.
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 [I-D.unify-nfvrg-challenges][I-D.unify-nfvrg-devops],
proprietary mechanisms for managing TWAMP measurements pose severe proprietary mechanisms for managing TWAMP measurements pose severe
limitations with respect to programmability. limitations with respect to programmability.
Two major trends call for 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, dealing with several vendor-specific TWAMP configuration perspective, using several vendor-specific TWAMP configuration
mechanisms is simply unsustainable in this context. Second, the mechanisms when one standard mechanism could provide an alternative
increasingly software-defined and virtualized nature of network is expensive and inefficient. Second, the increasingly software-
infrastructures, based on dynamic service chains [NSC] and defined and virtualized nature of network infrastructures, based on
programmable control and management planes [RFC7426] requires a well- dynamic service chains [NSC] and programmable control and management
defined data model for TWAMP implementations. This document defines planes [RFC7426] requires a well-defined data model for TWAMP
such a TWAMP data model and specifies it formally using the YANG data implementations. This document defines such a TWAMP data model and
modeling language [RFC6020]. specifies it formally using the YANG data modeling language
[RFC7950].
Note to RFC Editor: Note to RFC Editor:
Please replace the date in the draft of the format 2018-02-13 with Please replace the date 2018-04-08 in Section 5.2 of the draft with
the date of publication of this draft. Also, replace reference to the date of publication of this draft as a RFC. Also, replace
draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with reference to RFC XXXX, and draft-ietf-ippm-metric-registry with the
the RFC numbers assigned to the draft. RFC numbers assigned to the draft.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. Document Organization 1.3. Document Organization
The rest of this document is organized as follows. Section 2 The rest of this document is organized as follows. Section 2
presents the scope and applicability of this document. Section 3 presents the scope and applicability of this document. Section 3
provides a high-level overview of the TWAMP data model. Section 4 provides a high-level overview of the TWAMP data model. Section 4
details the configuration parameters of the data model and Section 5 details the configuration parameters of the data model and Section 5
specifies in YANG the TWAMP data model. Section 6 lists illustrative specifies in YANG the TWAMP data model. Section 6 lists illustrative
examples which conform to the YANG data model specified in this examples which conform to the YANG data model specified in this
document. Appendix A elaborates these examples further. document. Appendix A elaborates these examples further.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
In addition, the client container holds a list named key-chain which In addition, the client container holds a list named key-chain which
relates KeyIDs with the respective secret keys. Both the Server and relates KeyIDs with the respective secret keys. Both the Server and
the Control-Client use the same mappings from KeyIDs to shared the Control-Client use the same mappings from KeyIDs to shared
secrets (key-id and secret-key in Figure 3, respectively). The secrets (key-id and secret-key in Figure 3, respectively). The
Server, being prepared to conduct sessions with more than one Server, being prepared to conduct sessions with more than one
Control-Client, uses KeyIDs to choose the appropriate secret-key; a Control-Client, uses KeyIDs to choose the appropriate secret-key; a
Control-Client would typically have different secret keys for Control-Client would typically have different secret keys for
different Servers. The secret-key is the shared secret, an octet different Servers. The secret-key is the shared secret, an octet
string of arbitrary length whose interpretation as a text string is string of arbitrary length whose interpretation as a text string is
unspecified. The key-id and secret-key encoding SHOULD follow unspecified. The key-id and secret-key encoding SHOULD follow
Section 9.4 of [RFC6020]. The derived key length (dkLen in Section 9.4 of [RFC7950]. The derived key length (dkLen in
[RFC2898]) MUST be 16 octets for the AES Session-key used for [RFC8018]) MUST be 16 octets for the AES Session-key used for
encryption and 32 octets for the HMAC-SHA1 Session-key used for encryption and 32 octets for the HMAC-SHA1 Session-key used for
authentication; see also Section 6.10 of [RFC4656]. authentication; see also Section 6.10 of [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.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
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.
If the user has no network access to the Control-Client device, then If the user has no network access to the Control-Client device, then
the only option is to retrieve all test-session instances from the the only option is to retrieve all test-session instances from the
Session-Reflector device. This could be problematic if a large Session-Reflector device, and then pick out specific test-session
number of test sessions are currently active on that device. instances of interest to the user. This could be problematic if a
large number of test sessions are currently active on that device.
Each Session-Reflector TWAMP-Test session contains the following Each Session-Reflector TWAMP-Test session contains the following
4-tuple: {parent-connection-client-ip, parent-connection-client-tcp- 4-tuple: {parent-connection-client-ip, parent-connection-client-tcp-
port, parent-connection-server-ip, parent-connection-server-tcp- port, parent-connection-server-ip, parent-connection-server-tcp-
port}. This 4-tuple MUST correspond to the equivalent 4-tuple port}. This 4-tuple MUST correspond to the equivalent 4-tuple
{client-ip, client-tcp-port, server-ip, server-tcp-port} in server/ {client-ip, client-tcp-port, server-ip, server-tcp-port} in server/
ctrl-connection. This 4-tuple allows the user to trace back from the ctrl-connection. This 4-tuple allows the user to trace back from the
TWAMP-Test session to the (parent) TWAMP-Control connection that TWAMP-Test session to the (parent) TWAMP-Control connection that
negotiated this test session. negotiated this test session.
skipping to change at page 18, line 14 skipping to change at page 18, line 15
+--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. defined in this document. The module imports definitions from Common
YANG Data Types [RFC6991].
<CODE BEGINS> file "ietf-twamp@2018-02-13.yang"
module ietf-twamp {
namespace
urn:ietf:params:xml:ns:yang:ietf-twamp;
prefix
ietf-twamp;
import ietf-inet-types {
prefix inet;
}
organization <CODE BEGINS> file "ietf-twamp@2018-04-08.yang"
"IETF IPPM (IP Performance Metrics) Working Group";
contact module ietf-twamp {
draft-ietf-ippm-twamp-yang@tools.ietf.org; yang-version 1.1;
namespace urn:ietf:params:xml:ns:yang:ietf-twamp;
prefix ietf-twamp;
description import ietf-inet-types {
"This YANG module specifies a vendor-independent data prefix inet;
model for the Two-Way Active Measurement Protocol (TWAMP). reference
"RFC 6991: Common YANG Types.";
}
The data model covers four TWAMP logical entities, namely, organization
Control-Client, Server, Session-Sender, and Session-Reflector, "IETF IPPM (IP Performance Metrics) Working Group";
as illustrated in the annotated TWAMP logical model (Fig. 1
of draft-ietf-ippm-twamp-yang).
This YANG module uses features to indicate which of the four contact
logical entities are supported by a TWAMP implementation."; "WG Web: http://tools.ietf.org/wg/ippm/
WG List: ippm@ietf.org
revision 2018-02-13 { Editor: Ruth Civil
description gcivil@ciena.com
"Initial Revision. Editor: Al Morton
acmorton@att.com
Editor: Reshad Rehman
rrahman@cisco.com
Editor: Mahesh Jethanandani
mjethanandani@gmail.com
Editor: Kostas Pentikousis
k.pentikousis@travelping.com";
Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and description
draft-ietf-ippm-metric-registry"; "This YANG module specifies a vendor-independent data
model for the Two-Way Active Measurement Protocol (TWAMP).
reference The data model covers four TWAMP logical entities, namely,
draft-ietf-ippm-twamp-yang; Control-Client, Server, Session-Sender, and Session-Reflector,
} as illustrated in the annotated TWAMP logical model (Fig. 1
of RFC XXXX).
/* This YANG module uses features to indicate which of the four
* Typedefs logical entities are supported by a TWAMP implementation.";
*/
typedef twamp-modes { revision 2018-04-08 {
type bits { description
bit unauthenticated { "Initial Revision.
position 0;
description
"Unauthenticated mode, in which no encryption or
authentication is applied in TWAMP-Control and TWAMP-Test.
KeyID, Token, and Client-IV are not used in the
Set-Up-Response message. See Section 3.1 of RFC 4656.";
reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
}
bit authenticated {
position 1;
description
"Authenticated mode, in which the Control-Client and Server
possess a shared secret thus prohibiting 'theft of service'.
As per Section 6 of RFC 4656, in 'authenticated mode, the
timestamp is in the clear and is not protected
cryptographically in any way, while the rest of the message
has the same protection as in encrypted mode. This mode
allows one to trade off cryptographic protection against
accuracy of timestamps.'";
reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
}
bit encrypted {
position 2;
description
"Encrypted mode 'makes it impossible to alter
timestamps undetectably.' See also Section 4 of RFC 7717
and Section 6 of RFC 4656.";
reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
}
bit unauth-test-encrpyt-control {
position 3;
description
"When using the Mixed Security Mode, the TWAMP-Test
protocol follows the Unauthenticated mode and the
TWAMP-Control protocol the Encrypted mode.";
reference
"RFC 5618: Mixed Security Mode for the Two-Way Active
Measurement Protocol (TWAMP)";
}
bit individual-session-control {
position 4;
description
"This mode enables individual test sessions using
Session Identifiers.";
reference
"RFC 5938: Individual Session Control Feature
for the Two-Way Active Measurement Protocol (TWAMP)";
}
bit reflect-octets {
position 5;
description
"This mode indicates the reflect octets capability.";
reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features";
}
bit symmetrical-size {
position 6;
description
"This mode indicates support for the symmetrical size
sender test packet format.";
reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features";
}
bit IKEv2Derived {
position 7;
description
"In this mode the the shared key is derived
from an IKEv2 security association (SA).";
reference
"RFC 7717: IKEv2-Derived Shared Secret Key for
the One-Way Active Measurement Protocol (OWAMP)
and Two-Way Active Measurement Protocol (TWAMP)";
}
}
description
"Specifies the configurable TWAMP-Modes supported during a
TWAMP-Control Connection setup between a Control-Client
and a Server. Section 7 of RFC 7717 summarizes the
TWAMP-Modes registry and points to their formal
specification.";
}
typedef control-client-connection-state { Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and
type enumeration { draft-ietf-ippm-metric-registry";
enum active {
description
"Indicates an active TWAMP-Control connection to Server.";
}
enum idle {
description
"Indicates an idle TWAMP-Control connection to Server.";
}
}
description
"Indicates the Control-Client TWAMP-Control connection state.";
}
typedef test-session-state { reference
type enumeration { "RFC XXXX: TWAMP YANG Data Model.";
enum accepted { }
value 0;
description
"Indicates that accepted TWAMP-Test session request.";
}
enum failed {
value 1;
description
"Indicates a TWAMP-Test session failure due to
some unspecified reason (catch-all).";
}
enum internal-error {
value 2;
description
"Indicates a TWAMP-Test session failure due to
an internal error.";
}
enum not-supported {
value 3;
description
"Indicates a TWAMP-Test session failure because
some aspect of the TWAMP-Test session request
is not supported.";
}
enum permanent-resource-limit {
value 4;
description
"Indicates a TWAMP-Test session failure due to
permanent resource limitations.";
}
enum temp-resource-limit {
value 5;
description
"Indicates a TWAMP-Test session failure due to
temporary resource limitations.";
}
}
description
"Indicates the Control-Client TWAMP-Test session state.";
}
typedef server-ctrl-connection-state { /*
type enumeration { * Typedefs
enum active { */
description
"Indicates an active TWAMP-Control connection
to the Control-Client.";
}
enum servwait {
description
"Indicates that the TWAMP-Control connection to the
Control-Client is in SERVWAIT as per the definition of
Section 3.1 of RFC 5357.";
}
}
description
"Indicates the Server TWAMP-Control connection state.";
}
typedef sender-session-state { typedef twamp-modes {
type enumeration { type bits {
enum active { bit unauthenticated {
description position 0;
"Indicates that the TWAMP-Test session is active."; description
} "Unauthenticated mode, in which no encryption or
enum failure { authentication is applied in TWAMP-Control and
description TWAMP-Test. KeyID, Token, and Client-IV are not used in
"Indicates that the TWAMP-Test session has failed."; the Set-Up-Response message. See Section 3.1 of
} RFC 4656.";
} reference
description "RFC 4656: A One-way Active Measurement Protocol
"Indicates the Session-Sender TWAMP-Test session state."; (OWAMP)";
} }
typedef padding-fill-mode { bit authenticated {
type enumeration { position 1;
enum zero { description
description "Authenticated mode, in which the Control-Client and
"TWAMP-Test packets are padded with all zeros."; Server possess a shared secret thus prohibiting
} 'theft of service'. As per Section 6 of RFC 4656,
enum random { in 'authenticated mode, the timestamp is in the clear
description and is not protected cryptographically in any way,
"TWAMP-Test packets are padded with pseudo-random while the rest of the message has the same protection
numbers."; as in encrypted mode. This mode allows one to trade off
} cryptographic protection against accuracy of
} timestamps.'";
description reference
"Indicates what type of packet padding is used in the "RFC 4656: A One-way Active Measurement Protocol
TWAMP-Test packets."; (OWAMP)";
} }
bit encrypted {
position 2;
description
"Encrypted mode 'makes it impossible to alter
timestamps undetectably.' See also Section 4 of RFC 7717
and Section 6 of RFC 4656.";
reference
"RFC 4656: A One-way Active Measurement Protocol
(OWAMP)";
}
bit unauth-test-encrpyt-control {
position 3;
description
"When using the Mixed Security Mode, the TWAMP-Test
protocol follows the Unauthenticated mode and the
TWAMP-Control protocol the Encrypted mode.";
reference
"RFC 5618: Mixed Security Mode for the Two-Way Active
Measurement Protocol (TWAMP)";
}
bit individual-session-control {
position 4;
description
"This mode enables individual test sessions using
Session Identifiers.";
reference
"RFC 5938: Individual Session Control Feature
for the Two-Way Active Measurement Protocol (TWAMP)";
}
bit reflect-octets {
position 5;
description
"This mode indicates the reflect octets capability.";
reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features";
}
bit symmetrical-size {
position 6;
description
"This mode indicates support for the symmetrical size
sender test packet format.";
reference
"RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
Reflect Octets and Symmetrical Size Features";
}
bit IKEv2Derived {
position 7;
description
"In this mode the the shared key is derived
from an IKEv2 security association (SA).";
reference
"RFC 7717: IKEv2-Derived Shared Secret Key for
the One-Way Active Measurement Protocol (OWAMP)
and Two-Way Active Measurement Protocol (TWAMP)";
}
}
description
"Specifies the configurable TWAMP-Modes supported during a
TWAMP-Control Connection setup between a Control-Client
and a Server. Section 7 of RFC 7717 summarizes the
TWAMP-Modes registry and points to their formal
specification.";
}
typedef dynamic-port-number { typedef control-client-connection-state {
type inet:port-number { type enumeration {
range 49152..65535; enum active {
} description
description "Dynamic range for port numbers."; "Indicates an active TWAMP-Control connection to
} Server.";
}
enum idle {
description
"Indicates an idle TWAMP-Control connection to Server.";
}
}
description
"Indicates the Control-Client TWAMP-Control connection
state.";
}
/* typedef test-session-state {
* Features type enumeration {
*/ enum accepted {
value 0;
description
"Indicates that accepted TWAMP-Test session request.";
feature control-client { }
description enum failed {
"Indicates that the device supports configuration of the value 1;
TWAMP Control-Client logical entity."; description
} "Indicates a TWAMP-Test session failure due to
some unspecified reason (catch-all).";
}
enum internal-error {
value 2;
description
"Indicates a TWAMP-Test session failure due to
an internal error.";
}
enum not-supported {
value 3;
description
"Indicates a TWAMP-Test session failure because
some aspect of the TWAMP-Test session request
is not supported.";
}
enum permanent-resource-limit {
value 4;
description
"Indicates a TWAMP-Test session failure due to
permanent resource limitations.";
}
enum temp-resource-limit {
value 5;
description
"Indicates a TWAMP-Test session failure due to
temporary resource limitations.";
}
}
description
"Indicates the Control-Client TWAMP-Test session state.";
}
feature server { typedef server-ctrl-connection-state {
description type enumeration {
"Indicates that the device supports configuration of the enum active {
TWAMP Server logical entity."; description
} "Indicates an active TWAMP-Control connection
to the Control-Client.";
}
enum servwait {
description
"Indicates that the TWAMP-Control connection to the
Control-Client is in SERVWAIT as per the definition of
Section 3.1 of RFC 5357.";
}
}
description
"Indicates the Server TWAMP-Control connection state.";
}
feature session-sender { typedef sender-session-state {
description type enumeration {
"Indicates that the device supports configuration of the enum active {
TWAMP Session-Sender logical entity."; description
} "Indicates that the TWAMP-Test session is active.";
}
enum failure {
description
"Indicates that the TWAMP-Test session has failed.";
}
}
description
"Indicates the Session-Sender TWAMP-Test session state.";
}
feature session-reflector { typedef padding-fill-mode {
description type enumeration {
"Indicates that the device supports configuration of the enum zero {
TWAMP Session-Reflector logical entity."; description
} "TWAMP-Test packets are padded with all zeros.";
}
enum random {
description
"TWAMP-Test packets are padded with pseudo-random
numbers.";
}
}
description
"Indicates what type of packet padding is used in the
TWAMP-Test packets.";
}
/* typedef dynamic-port-number {
* Reusable node groups type inet:port-number {
*/ range 49152..65535;
}
description "Dynamic range for port numbers.";
}
grouping key-management { /*
list key-chain { * Features
key key-id; */
leaf key-id {
type string {
length 1..80;
}
description
"KeyID used for a TWAMP-Control connection. As per
Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
80 octets in length' and is used to select which 'shared
shared secret the [Control-Client] wishes to use to
authenticate or encrypt'.";
}
leaf secret-key {
type binary;
description
"The secret key corresponding to the KeyID for this
TWAMP-Control connection.";
}
description
"Relates KeyIDs with their respective secret keys
in a TWAMP-Control connection.";
}
description
"Used by the Control-Client and Server for TWAMP-Control
key management.";
}
grouping maintenance-statistics { feature control-client {
leaf sent-packets { description
type uint32; "Indicates that the device supports configuration of the
config false; TWAMP Control-Client logical entity.";
description }
"Indicates the number of packets sent.";
}
leaf rcv-packets { feature server {
type uint32; description
config false; "Indicates that the device supports configuration of the
description TWAMP Server logical entity.";
"Indicates the number of packets received."; }
}
leaf last-sent-seq { feature session-sender {
type uint32; description
config false; "Indicates that the device supports configuration of the
description TWAMP Session-Sender logical entity.";
"Indicates the last sent sequence number."; }
}
leaf last-rcv-seq { feature session-reflector {
type uint32; description
config false; "Indicates that the device supports configuration of the
description TWAMP Session-Reflector logical entity.";
"Indicates the last received sequence number."; }
}
description
"Used for TWAMP-Test maintenance statistics.";
}
grouping count { /*
leaf count { * Reusable node groups
type uint8 { */
range "10..31";
}
default 10;
description
"Parameter communicated to the Control-Client as part of the
Server Greeting message and used for deriving a key from a
shared secret as per Section 3.1 of RFC 4656: MUST be a
power of 2 and at least 1024. It is configured by providing
said power. For example, configuring 15 here means count
2^15 = 32768. The default is 10, meaning 2^10 = 1024.";
} grouping key-management {
description list key-chain {
"Reusable data structure for count which is used both in the key key-id;
Server container."; leaf key-id {
} type string {
length 1..80;
}
description
"KeyID used for a TWAMP-Control connection. As per
Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
80 octets in length' and is used to select which 'shared
shared secret the [Control-Client] wishes to use to
authenticate or encrypt'.";
}
leaf secret-key {
type binary;
description
"The secret key corresponding to the KeyID for this
TWAMP-Control connection.";
}
description
"Relates KeyIDs with their respective secret keys
in a TWAMP-Control connection.";
}
description
"Used by the Control-Client and Server for TWAMP-Control
key management.";
}
grouping max-count { grouping maintenance-statistics {
leaf max-count { leaf sent-packets {
type uint8 { type uint32;
range 10..31; config false;
} description
default 15; "Indicates the number of packets sent.";
description }
"This parameter limits the maximum Count value, which MUST
be a power of 2 and at least 1024 as per RFC 5357. It is
configured by providing said power. For example,
configuring 10 here means max count 2^10 = 1024.
The default is 15, meaning 2^15 = 32768.
A TWAMP Server uses this configured value in the leaf rcv-packets {
Server-Greeting message sent to the Control-Client. type uint32;
config false;
description
"Indicates the number of packets received.";
}
A TWAMP Control-Client uses this configured value to prevent leaf last-sent-seq {
denial-of-service (DOS) attacks by closing the control type uint32;
connection to the Server if it 'receives a Server-Greeting config false;
message with Count greater that its maximum configured value', description
as per Section 6 of RFC 5357. "Indicates the last sent sequence number.";
}
Further, note that according to Section 6 of RFC 5357: leaf last-rcv-seq {
type uint32;
config false;
description
"Indicates the last received sequence number.";
}
description
"Used for TWAMP-Test maintenance statistics.";
}
'If an attacking system sets the maximum value in grouping count {
Count (2**32), then the system under attack would stall leaf count {
for a significant period of time while it attempts to type uint8 {
generate keys. range "10..31";
TWAMP-compliant systems SHOULD have a configuration }
control to limit the maximum count value. The default default 10;
max-count value SHOULD be 32768.' description
"Parameter communicated to the Control-Client as part of
the Server Greeting message and used for deriving a key
from a shared secret as per Section 3.1 of RFC 4656:
MUST be a power of 2 and at least 1024. It is configured
by providing said power. For example, configuring 15 here
means count 2^15 = 32768. The default is 10,
meaning 2^10 = 1024.";
}
description
"Reusable data structure for count which is used both in the
Server container.";
}
RFC 5357 does not qualify 'significant period' in terms of grouping max-count {
time, but it is clear that this depends on the processing leaf max-count {
capacity available and operators need to pay attention to type uint8 {
this security consideration."; range 10..31;
} }
description default 15;
"Reusable data structure for max-count which is used both at description
the Control-Client and the Server containers."; "This parameter limits the maximum Count value, which MUST
} be a power of 2 and at least 1024 as per RFC 5357. It is
configured by providing said power. For example,
configuring 10 here means max count 2^10 = 1024.
The default is 15, meaning 2^15 = 32768.
/* A TWAMP Server uses this configured value in the
* Configuration data nodes Server-Greeting message sent to the Control-Client.
*/
container twamp { A TWAMP Control-Client uses this configured value to
description prevent denial-of-service (DOS) attacks by closing the
"TWAMP logical entity configuration grouping of four models control connection to the Server if it 'receives a
which correspond to the four TWAMP logical entities Server-Greeting message with Count greater that its
Control-Client, Server, Session-Sender, and Session-Reflector maximum configured value', as per Section 6 of RFC 5357.
as illustrated in Fig. 1 of draft-ietf-ippm-twamp-yang.";
container client { Further, note that according to Section 6 of RFC 5357:
if-feature control-client;
presence "Enables TWAMP Control-Client functionality.";
description
"Configuration of the TWAMP Control-Client logical entity.";
leaf admin-state { 'If an attacking system sets the maximum value in
type boolean; Count (2**32), then the system under attack would stall
mandatory true; for a significant period of time while it attempts to
description generate keys.
"Indicates whether the device is allowed to operate as a
TWAMP Control-Client.";
}
list mode-preference-chain { TWAMP-compliant systems SHOULD have a configuration
key priority; control to limit the maximum count value. The default
unique mode; max-count value SHOULD be 32768.'
leaf priority { RFC 5357 does not qualify 'significant period' in terms of
type uint16; time, but it is clear that this depends on the processing
description capacity available and operators need to pay attention to
"Indicates the Control-Client Mode preference priority this security consideration.";
expressed as a 16-bit unsigned integer, where zero is the }
highest priority and subsequent values monotonically description
increasing."; "Reusable data structure for max-count which is used both at
} the Control-Client and the Server containers.";
leaf mode { }
type twamp-modes;
description
"The supported TWAMP Mode matching the corresponding
priority.";
} /*
description * Configuration data nodes
"Indicates the Control-Client preferred order of use of */
the supported TWAMP Modes.
Depending on the Modes available in the TWAMP Server container twamp {
Greeting message (see Fig. 2 of RFC 7717), the description
this Control-Client MUST choose the highest priority Mode "TWAMP logical entity configuration grouping of four models
from the configured mode-preference-chain list."; which correspond to the four TWAMP logical entities
} Control-Client, Server, Session-Sender, and Session-Reflector
as illustrated in Fig. 1 of RFC XXXX.";
uses key-management; container client {
if-feature control-client;
presence "Enables TWAMP Control-Client functionality.";
description
"Configuration of the TWAMP Control-Client logical
entity.";
list ctrl-connection { leaf admin-state {
key name; type boolean;
description mandatory true;
"List of TWAMP Control-Client control connections. description
"Indicates whether the device is allowed to operate as a
TWAMP Control-Client.";
}
Each item in the list describes a control connection list mode-preference-chain {
that will be initiated by this Control-Client"; key priority;
unique mode;
leaf priority {
type uint16;
description
"Indicates the Control-Client Mode preference priority
expressed as a 16-bit unsigned integer, where zero is
the highest priority and subsequent values
monotonically increasing.";
}
leaf mode {
type twamp-modes;
description
"The supported TWAMP Mode matching the corresponding
priority.";
leaf name { }
type string; description
description "Indicates the Control-Client preferred order of use of
"A unique name used as a key to identify this individual the supported TWAMP Modes.
TWAMP-Control connection on the Control-Client device.";
}
leaf client-ip {
type inet:ip-address;
description
"The IP address of the local Control-Client device,
to be placed in the source IP address field of the
IP header in TWAMP-Control (TCP) packets belonging
to this control connection. If not configured, the
device SHALL choose its own source IP address.";
}
leaf server-ip {
type inet:ip-address;
mandatory true;
description
"The IP address of the remote Server device, which the
TWAMP-Control connection will be initiated to.";
}
leaf server-tcp-port { Depending on the Modes available in the TWAMP Server
type inet:port-number; Greeting message (see Fig. 2 of RFC 7717), the
default 862; this Control-Client MUST choose the highest priority
description Mode from the configured mode-preference-chain list.";
"This parameter defines the TCP port number that is }
to be used by this outgoing TWAMP-Control connection.
Typically, this is the well-known TWAMP-Control
port number (862) as per RFC 5357 However, there are known
realizations of TWAMP in the field that were implemented
before this well-known port number was allocated. These
early implementations allowed the port number to be
configured. This parameter is therefore provided for
backward compatibility reasons.";
}
leaf control-packet-dscp { uses key-management;
type inet:dscp;
default 0;
description
"The DSCP value to be placed in the IP header of
TWAMP-Control (TCP) packets generated by this
Control-Client.";
} list ctrl-connection {
key name;
description
"List of TWAMP Control-Client control connections.
Each item in the list describes a control connection
that will be initiated by this Control-Client";
leaf key-id { leaf name {
type string { type string;
length 1..80; description
} "A unique name used as a key to identify this
description individual TWAMP-Control connection on the
"Indicates the KeyID value selected for this Control-Client device.";
TWAMP-Control connection."; }
leaf client-ip {
type inet:ip-address;
description
"The IP address of the local Control-Client device,
to be placed in the source IP address field of the
IP header in TWAMP-Control (TCP) packets belonging
to this control connection. If not configured, the
device SHALL choose its own source IP address.";
}
leaf server-ip {
type inet:ip-address;
mandatory true;
description
"The IP address of the remote Server device, which the
TWAMP-Control connection will be initiated to.";
} }
uses max-count; leaf server-tcp-port {
type inet:port-number;
default 862;
description
"This parameter defines the TCP port number that is
to be used by this outgoing TWAMP-Control connection.
Typically, this is the well-known TWAMP-Control
port number (862) as per RFC 5357 However, there are
known realizations of TWAMP in the field that were
implemented before this well-known port number was
allocated. These early implementations allowed the
port number to be configured. This parameter is
therefore provided for backward compatibility
reasons.";
}
leaf client-tcp-port { leaf control-packet-dscp {
type inet:port-number; type inet:dscp;
config false; default 0;
description description
"Indicates the source TCP port number used in the "The DSCP value to be placed in the IP header of
TWAMP-Control packets belonging to this control TWAMP-Control (TCP) packets generated by this
connection."; Control-Client.";
} }
leaf server-start-time { leaf key-id {
type uint64; type string {
config false; length 1..80;
description }
"Indicates the Start-Time advertized by the Server in the description
Server-Start message (RFC 4656, Section 3.1), "Indicates the KeyID value selected for this
representing the time when the current TWAMP-Control connection.";
instantiation of the Server started operating. }
The timestamp format follows RFC 1305
according to Section 4.1.2 of RFC 4656.";
}
leaf repeat-count { uses max-count;
type uint64;
config false;
description
"Indicates how many times the test session has been
repeated. When a test is running, this value will be
greater than 0. If the repeat parameter is non-zero,
this value is smaller than or equal to the repeat
parameter.";
}
leaf state {
type control-client-connection-state;
config false;
description
"Indicates the current state of the TWAMP-Control
connection state.";
}
leaf selected-mode { leaf client-tcp-port {
type twamp-modes; type inet:port-number;
config false; config false;
description description
"The TWAMP Mode that the Control-Client has chosen for "Indicates the source TCP port number used in the
this control connection as set in the Mode field of the TWAMP-Control packets belonging to this control
Set-Up-Response message"; connection.";
reference }
"RFC 4656, Section 3.1.";
}
leaf token { leaf server-start-time {
type binary { type uint64;
length 64; config false;
} description
config false; "Indicates the Start-Time advertized by the Server in
description the Server-Start message (RFC 4656, Section 3.1),
"This parameter holds the 64 octets containing the representing the time when the current
concatenation of a 16-octet Challenge, a 16-octet AES instantiation of the Server started operating.
Session-key used for encryption, and a 32-octet The timestamp format follows RFC 1305
HMAC-SHA1 Session-key used for authentication; see also according to Section 4.1.2 of RFC 4656.";
the last paragraph of Section 6 in RFC 4656. }
If the Mode defined in RFC 7717 is selected leaf repeat-count {
(selected-mode), Token is limited to 16 octets."; type uint64;
reference config false;
"RFC 4086: Randomness Requirements for Security description
"Indicates how many times the test session has been
repeated. When a test is running, this value will be
greater than 0. If the repeat parameter is non-zero,
this value is smaller than or equal to the repeat
parameter.";
}
leaf state {
type control-client-connection-state;
config false;
description
"Indicates the current state of the TWAMP-Control
connection state.";
}
RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way leaf selected-mode {
Active Measurement Protocol (OWAMP) and Two-Way Active type twamp-modes;
Measurement Protocol (TWAMP)"; config false;
} description
"The TWAMP Mode that the Control-Client has chosen for
this control connection as set in the Mode field of
the Set-Up-Response message";
reference
"RFC 4656, Section 3.1.";
}
leaf client-iv { leaf token {
type binary { type binary {
length 16; length 64;
} }
config false; config false;
description description
"Indicates the Control-Client Initialization Vector "This parameter holds the 64 octets containing the
(Client-IV), that is generated randomly by the concatenation of a 16-octet Challenge, a 16-octet AES
Control-Client. As per RFC 4656: Session-key used for encryption, and a 32-octet
HMAC-SHA1 Session-key used for authentication; see
also the last paragraph of Section 6 in RFC 4656.
Client-IV merely needs to be unique (i.e., it MUST If the Mode defined in RFC 7717 is selected
never be repeated for different sessions using the (selected-mode), Token is limited to 16 octets.";
same secret key; a simple way to achieve that without reference
the use of cumbersome state is to generate the "RFC 4086: Randomness Requirements for Security
Client-IV values using a cryptographically secure
pseudo-random number source.
If the Mode defined in RFC 7717 is selected RFC 7717: IKEv2-Derived Shared Secret Key for the
(selected-mode), Client-IV is limited to 12 octets."; One-Way Active Measurement Protocol (OWAMP) and
reference Two-Way Active Measurement Protocol (TWAMP)";
"RFC 4656: A One-way Active Measurement Protocol (OWAMP) }
RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way leaf client-iv {
Active Measurement Protocol (OWAMP) and Two-Way Active type binary {
Measurement Protocol (TWAMP)"; length 16;
} }
config false;
description
"Indicates the Control-Client Initialization Vector
(Client-IV), that is generated randomly by the
Control-Client. As per RFC 4656:
list test-session-request { Client-IV merely needs to be unique (i.e., it MUST
key name; never be repeated for different sessions using the
description same secret key; a simple way to achieve that without
"Information associated with the Control-Client the use of cumbersome state is to generate the
for this test session"; Client-IV values using a cryptographically secure
pseudo-random number source.
leaf name { If the Mode defined in RFC 7717 is selected
type string; (selected-mode), Client-IV is limited to 12 octets.";
description reference
"A unique name to be used for identification of "RFC 4656: A One-way Active Measurement Protocol
this TWAMP-Test session on the Control-Client."; (OWAMP).
}
leaf sender-ip { RFC 7717: IKEv2-Derived Shared Secret Key for the
type inet:ip-address; One-Way Active Measurement Protocol (OWAMP) and
description Two-Way Active Measurement Protocol (TWAMP)";
"The IP address of the Session-Sender device, }
which is to be placed in the source IP address
field of the IP header in TWAMP-Test (UDP) packets
belonging to this test session. This value will be
used to populate the sender address field of the
Request-TW-Session message.
If not configured, the device SHALL choose its own list test-session-request {
source IP address."; key name;
} description
"Information associated with the Control-Client
for this test session";
leaf sender-udp-port { leaf name {
type union { type string;
type dynamic-port-number; description
type enumeration { "A unique name to be used for identification of
enum autoallocate { this TWAMP-Test session on the Control-Client.";
description }
"Indicates that the Contol-Client will
auto-allocate the TWAMP-Test (UDP) port number
from the dynamic port range.";
}
}
}
default autoallocate;
description
"The UDP port number that is to be used by
the Session-Sender for this TWAMP-Test session.
The number is restricted to the dynamic port range.
By default the Control-Client SHALL auto-allocate a leaf sender-ip {
UDP port number for this TWAMP-Test session. type inet:ip-address;
description
"The IP address of the Session-Sender device,
which is to be placed in the source IP address
field of the IP header in TWAMP-Test (UDP) packets
belonging to this test session. This value will be
used to populate the sender address field of the
Request-TW-Session message.
The configured (or auto-allocated) value is advertized If not configured, the device SHALL choose its own
in the Sender Port field of the Request-TW-session source IP address.";
message (see Section 3.5 of RFC 5357). Note that }
in the scenario where a device auto-allocates a UDP
port number for a session, and the repeat parameter
for that session indicates that it should be
repeated, the device is free to auto-allocate a
different UDP port number when it negotiates the
next (repeated) iteration of this session.";
}
leaf reflector-ip { leaf sender-udp-port {
type inet:ip-address; type union {
mandatory true; type dynamic-port-number;
description type enumeration {
"The IP address belonging to the remote enum autoallocate {
Session-Reflector device to which the TWAMP-Test description
session will be initiated. This value will be "Indicates that the Contol-Client will
used to populate the receiver address field of auto-allocate the TWAMP-Test (UDP) port number
the Request-TW-Session message."; from the dynamic port range.";
} }
}
}
default autoallocate;
description
"The UDP port number that is to be used by
the Session-Sender for this TWAMP-Test session.
The number is restricted to the dynamic port range.
leaf reflector-udp-port { By default the Control-Client SHALL auto-allocate a
type uint32 { UDP port number for this TWAMP-Test session.
range "862 | 49152..65535";
}
description
"This parameter defines the UDP port number that
will be used by the Session-Reflector for
this TWAMP-Test session. The default number is within
to the dynamic port range and is to be placed in
the Receiver Port field of the Request-TW-Session
message. The new well-known port (862) MAY be used.";
}
leaf timeout { The configured (or auto-allocated) value is
type uint64; advertized in the Sender Port field of the
units seconds; Request-TW-session message (see Section 3.5 of
default 2; RFC 5357). Note that in the scenario where a device
description auto-allocates a UDP port number for a session, and
"The length of time (in seconds) that the the repeat parameter for that session indicates that
Session-Reflector should continue to respond to it should be repeated, the device is free to
packets belonging to this TWAMP-Test session after auto-allocate a different UDP port number when it
a Stop-Sessions TWAMP-Control message has been negotiates the next (repeated) iteration of this
received (RFC 5357, Section 3.8). session.";
}
This value will be placed in the Timeout field of leaf reflector-ip {
the Request-TW-Session message."; type inet:ip-address;
} mandatory true;
description
"The IP address belonging to the remote
Session-Reflector device to which the TWAMP-Test
session will be initiated. This value will be
used to populate the receiver address field of
the Request-TW-Session message.";
}
leaf padding-length { leaf reflector-udp-port {
type uint32 { type uint32 {
range 64..4096; range "862 | 49152..65535";
} }
description description
"The number of padding bytes to be added to the "This parameter defines the UDP port number that
TWAMP-Test (UDP) packets generated by the will be used by the Session-Reflector for
Session-Sender. this TWAMP-Test session. The default number is
within to the dynamic port range and is to be placed
in the Receiver Port field of the Request-TW-Session
message. The new well-known port (862) MAY be
used.";
}
This value will be placed in the Padding Length leaf timeout {
field of the Request-TW-Session message."; type uint64;
reference units seconds;
"RFC 4656, Section 3.5."; default 2;
} description
"The length of time (in seconds) that the
Session-Reflector should continue to respond to
packets belonging to this TWAMP-Test session after
a Stop-Sessions TWAMP-Control message has been
received (RFC 5357, Section 3.8).
leaf test-packet-dscp { This value will be placed in the Timeout field of
type inet:dscp; the Request-TW-Session message.";
default 0; }
description
"The DSCP value to be placed in the IP header
of TWAMP-Test packets generated by the
Session-Sender, and in the UDP header of the
TWAMP-Test response packets generated by the
Session-Reflector for this test session.
This value will be placed in the Type-P Descriptor leaf padding-length {
field of the Request-TW-Session message"; type uint32 {
reference range 64..4096;
"RFC 5357."; }
description
"The number of padding bytes to be added to the
TWAMP-Test (UDP) packets generated by the
Session-Sender.
} This value will be placed in the Padding Length
field of the Request-TW-Session message.";
reference
"RFC 4656, Section 3.5.";
}
leaf start-time { leaf test-packet-dscp {
type uint64; type inet:dscp;
default 0; default 0;
description description
"Time when the session is to be started "The DSCP value to be placed in the IP header
(but not before the TWAMP Start-Sessions command of TWAMP-Test packets generated by the
is issued; see Section 3.4 of RFC 5357). Session-Sender, and in the UDP header of the
TWAMP-Test response packets generated by the
Session-Reflector for this test session.
The start-time value is placed in the Start Time 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
"RFC 5357.";
}
The timestamp format follows RFC 1305 as per leaf start-time {
Section 3.5 of RFC 4656. type uint64;
default 0;
description
"Time when the session is to be started
(but not before the TWAMP Start-Sessions command
is issued; see Section 3.4 of RFC 5357).
The default value of 0 indicates that the session The start-time value is placed in the Start Time
will be started as soon as the Start-Sessions message field of the Request-TW-Session message.
is received.";
}
leaf repeat { The timestamp format follows RFC 1305 as per
type union { Section 3.5 of RFC 4656.
type uint32 {
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;
description
"This value determines if the TWAMP-Test session must
be repeated. When a test session has completed, the
repeat parameter is checked.
The default value of 0 indicates that the session The default value of 0 indicates that the session
MUST NOT be repeated. will be started as soon as the Start-Sessions
message is received.";
}
leaf repeat {
type union {
type uint32 {
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;
description
"This value determines if the TWAMP-Test session must
be repeated. When a test session has completed, the
repeat parameter is checked.
If the repeat value is 1 through 4,294,967,294 The default value of 0 indicates that the session
then the test session SHALL be repeated using the MUST NOT be repeated.
information in repeat-interval parameter, and the
parent TWAMP-Control connection for this test
session is restarted to negotiate a new instance
of this TWAMP-Test session.";
}
leaf repeat-interval { If the repeat value is 1 through 4,294,967,294
when "../repeat!='0'" { then the test session SHALL be repeated using the
description information in repeat-interval parameter, and the
"This parameter determines the timing of repeated parent TWAMP-Control connection for this test
TWAMP-Test sessions when repeat is more than 0. session is restarted to negotiate a new instance
of this TWAMP-Test session.";
}
When the value of repeat-interval is 0, the leaf repeat-interval {
negotiation of a new test session SHALL begin when "../repeat!='0'" {
immediately after the previous test session description
completes. Otherwise, the Control-Client will "This parameter determines the timing of repeated
wait for the number of seconds specified in the TWAMP-Test sessions when repeat is more than 0.
repeat-interval parameter before negotiating the
new instance of this TWAMP-Test session.";
}
type uint32;
units seconds;
default 0;
description
"Repeat interval (in seconds).";
}
list pm-reg-list { When the value of repeat-interval is 0, the
key pm-index; negotiation of a new test session SHALL begin
leaf pm-index { immediately after the previous test session
type uint16; completes. Otherwise, the Control-Client will
description wait for the number of seconds specified in the
"Numerical index value of a Registered Metric repeat-interval parameter before negotiating the
in the Performance Metric Registry new instance of this TWAMP-Test session.";
(see ietf-ippm-metric-registry). Output statistics }
are specified in the corresponding Registry entry."; type uint32;
} units seconds;
description default 0;
"A list of one or more Performance Metric Registry description
Index values, which communicate packet stream "Repeat interval (in seconds).";
characteristics along with one or more metrics }
to be measured.
All members of the pm-reg-list MUST have the same list pm-reg-list {
stream characteristics, such that they combine key pm-index;
to specify all metrics that shall be measured on leaf pm-index {
a single stream."; type uint16;
reference description
"ietf-ippm-metric-registry: Registry for "Numerical index value of a Registered Metric
Performance Metrics"; in the Performance Metric Registry
} (see ietf-ippm-metric-registry). Output statistics
are specified in the corresponding Registry
entry.";
}
description
"A list of one or more Performance Metric Registry
Index values, which communicate packet stream
characteristics along with one or more metrics
to be measured.
leaf state { All members of the pm-reg-list MUST have the same
type test-session-state; stream characteristics, such that they combine
config false; to specify all metrics that shall be measured on
description a single stream.";
"Indicates the TWAMP-Test session state, accepted or reference
indication of an error."; "ietf-ippm-metric-registry: Registry for
reference Performance Metrics";
"Section 3.5 of RFC 5357."; }
}
leaf sid {
type string;
config false;
description
"The SID allocated by the Server for this TWAMP-Test
session, and communicated back to the Control-Client
in the SID field of the Accept-Session message";
reference
"Section 4.3 of RFC 6038.";
}
}
}
}
container server { leaf state {
if-feature server; type test-session-state;
presence "Enables TWAMP Server functionality."; config false;
description description
"Configuration of the TWAMP Server logical entity."; "Indicates the TWAMP-Test session state, accepted or
indication of an error.";
reference
"Section 3.5 of RFC 5357.";
}
leaf sid {
type string;
config false;
description
"The SID allocated by the Server for this TWAMP-Test
session, and communicated back to the Control-Client
in the SID field of the Accept-Session message";
reference
"Section 4.3 of RFC 6038.";
}
}
}
}
leaf admin-state { container server {
type boolean; if-feature server;
mandatory true; presence "Enables TWAMP Server functionality.";
description description
"Indicates whether the device is allowed to operate "Configuration of the TWAMP Server logical entity.";
as a TWAMP Server.";
}
leaf server-tcp-port { leaf admin-state {
type inet:port-number; type boolean;
default 862; mandatory true;
description description
"This parameter defines the well known TCP port number "Indicates whether the device is allowed to operate
that is used by TWAMP-Control. The Server will listen as a TWAMP Server.";
on this port number for incoming TWAMP-Control }
connections. Although this is defined as a fixed value
(862) in RFC 5357, there are several realizations of
TWAMP in the field that were implemented before this
well-known port number was allocated. These early
implementations allowed the port number to be
configured. This parameter is therefore provided for
backward compatibility reasons.";
}
leaf servwait { leaf server-tcp-port {
type uint32 { type inet:port-number;
range 1..604800; default 862;
} description
units seconds; "This parameter defines the well known TCP port number
default 900; that is used by TWAMP-Control. The Server will listen
description on this port number for incoming TWAMP-Control
"TWAMP-Control (TCP) session timeout, in seconds. connections. Although this is defined as a fixed value
According to Section 3.1 of RFC 5357, (862) in RFC 5357, there are several realizations of
TWAMP in the field that were implemented before this
well-known port number was allocated. These early
implementations allowed the port number to be
configured. This parameter is therefore provided for
backward compatibility reasons.";
}
Server MAY discontinue any established control leaf servwait {
connection when no packet associated with that type uint32 {
connection has been received within SERVWAIT seconds."; range 1..604800;
} }
units seconds;
default 900;
description
"TWAMP-Control (TCP) session timeout, in seconds.
According to Section 3.1 of RFC 5357,
leaf control-packet-dscp { Server MAY discontinue any established control
type inet:dscp; connection when no packet associated with that
description connection has been received within SERVWAIT seconds.";
"The DSCP value to be placed in the IP header of }
TWAMP-Control (TCP) packets generated by the Server.
Section 3.1 of RFC 5357 specifies that the server leaf control-packet-dscp {
SHOULD use the DSCP value from the Control-Clients type inet:dscp;
TCP SYN. However, for practical purposes TWAMP will description
typically be implemented using a general purpose TCP "The DSCP value to be placed in the IP header of
stack provided by the underlying operating system, TWAMP-Control (TCP) packets generated by the Server.
and such a stack may not provide this information to the
user. Consequently, it is not always possible to
implement the behavior described in RFC 5357 in an
OS-portable version of TWAMP.
The default behavior if this item is not set is to use Section 3.1 of RFC 5357 specifies that the server
the DSCP value from the Control-Clients TCP SYN."; SHOULD use the DSCP value from the Control-Clients
reference TCP SYN. However, for practical purposes TWAMP will
"Section 3.1 of RFC 5357."; typically be implemented using a general purpose TCP
} stack provided by the underlying operating system,
and such a stack may not provide this information to the
user. Consequently, it is not always possible to
implement the behavior described in RFC 5357 in an
OS-portable version of TWAMP.
uses count; The default behavior if this item is not set is to use
the DSCP value from the Control-Clients TCP SYN.";
reference
"Section 3.1 of RFC 5357.";
}
uses max-count; uses count;
leaf modes {
type twamp-modes;
description
"The bit mask of TWAMP Modes this Server instance
is willing to support; see IANA TWAMP Modes Registry.";
}
uses key-management; uses max-count;
list ctrl-connection { leaf modes {
key "client-ip client-tcp-port server-ip server-tcp-port"; type twamp-modes;
config false; description
description "The bit mask of TWAMP Modes this Server instance
"List of all incoming TWAMP-Control (TCP) connections."; is willing to support; see IANA TWAMP Modes Registry.";
}
leaf client-ip { uses key-management;
type inet:ip-address;
description
"The IP address on the remote Control-Client device,
which is the source IP address used in the
TWAMP-Control (TCP) packets belonging to this control
connection.";
}
leaf client-tcp-port { list ctrl-connection {
type inet:port-number; key "client-ip client-tcp-port server-ip server-tcp-port";
description config false;
"The source TCP port number used in the TWAMP-Control description
(TCP) packets belonging to this control connection."; "List of all incoming TWAMP-Control (TCP) connections.";
}
leaf server-ip { leaf client-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the local Server device, which is "The IP address on the remote Control-Client device,
the destination IP address used in the which is the source IP address used in the
TWAMP-Control (TCP) packets belonging to this control TWAMP-Control (TCP) packets belonging to this control
connection."; connection.";
} }
leaf server-tcp-port { leaf client-tcp-port {
type inet:port-number; type inet:port-number;
description description
"The destination TCP port number used in the "The source TCP port number used in the TWAMP-Control
TWAMP-Control (TCP) packets belonging to this (TCP) packets belonging to this control connection.";
control connection. This will usually be the }
same value as the server-tcp-port configured
under twamp/server. However, in the event that
the user re-configured server/server-tcp-port
after this control connection was initiated, this
value will indicate the server-tcp-port that is
actually in use for this control connection.";
}
leaf state { leaf server-ip {
type server-ctrl-connection-state; type inet:ip-address;
description description
"Indicates the Server TWAMP-Control connection state."; "The IP address of the local Server device, which is
} the destination IP address used in the
TWAMP-Control (TCP) packets belonging to this control
connection.";
}
leaf control-packet-dscp { leaf server-tcp-port {
type inet:dscp; type inet:port-number;
description description
"The DSCP value used in the IP header of the "The destination TCP port number used in the
TWAMP-Control (TCP) packets sent by the Server TWAMP-Control (TCP) packets belonging to this
for this control connection. This will usually control connection. This will usually be the
be the same value as is configured in the same value as the server-tcp-port configured
control-packet-dscp parameter under the twamp/server under twamp/server. However, in the event that
container. However, in the event that the user the user re-configured server/server-tcp-port
re-configures server/dscp after this control after this control connection was initiated, this
connection is already in progress, this read-only value will indicate the server-tcp-port that is
value will show the actual dscp value in use by this actually in use for this control connection.";
TWAMP-Control connection."; }
}
leaf selected-mode { leaf state {
type twamp-modes; type server-ctrl-connection-state;
description description
"The Mode that was chosen for this TWAMP-Control "Indicates the Server TWAMP-Control connection state.";
connection as set in the Mode field of the }
Set-Up-Response message.";
}
leaf key-id { leaf control-packet-dscp {
type string { type inet:dscp;
length 1..80; description
} "The DSCP value used in the IP header of the
description TWAMP-Control (TCP) packets sent by the Server
"The KeyID value that is in use by this TWAMP-Control for this control connection. This will usually
connection as selected by Control-Client."; be the same value as is configured in the
} control-packet-dscp parameter under the twamp/server
container. However, in the event that the user
re-configures server/dscp after this control
connection is already in progress, this read-only
value will show the actual dscp value in use by this
TWAMP-Control connection.";
}
uses count { leaf selected-mode {
description type twamp-modes;
"The count value that is in use by this TWAMP-Control description
connection. This will usually be the same value "The Mode that was chosen for this TWAMP-Control
as is configured under twamp/server. However, in the connection as set in the Mode field of the
event that the user re-configured server/count Set-Up-Response message.";
after this control connection is already in progress, }
this read-only value will show the actual count that
is in use for this TWAMP-Control connection.";
}
uses max-count { leaf key-id {
description type string {
"This read-only value indicates the actual max-count in length 1..80;
use for this control connection. Usually this would be }
the same value as configured under twamp/server."; description
} "The KeyID value that is in use by this TWAMP-Control
connection as selected by Control-Client.";
}
leaf salt { uses count {
type binary { description
length 16; "The count value that is in use by this TWAMP-Control
} connection. This will usually be the same value
description as is configured under twamp/server. However, in the
"A parameter used in deriving a key from a event that the user re-configured server/count
shared secret as described in Section 3.1 of RFC 4656. after this control connection is already in progress,
It is communicated to the Control-Client as part of this read-only value will show the actual count that
the Server Greeting message."; is in use for this TWAMP-Control connection.";
} }
leaf server-iv { uses max-count {
type binary { description
length 16; "This read-only value indicates the actual max-count in
} use for this control connection. Usually this would be
description the same value as configured under twamp/server.";
"The Server Initialization Vector }
(IV) generated randomly by the Server.";
}
leaf challenge { leaf salt {
type binary { type binary {
length 16; length 16;
} }
description description
"A random sequence of octets generated by the Server. "A parameter used in deriving a key from a
As described in client/token, Challenge is used shared secret as described in Section 3.1 of RFC 4656.
by the Control-Client to prove possession of a It is communicated to the Control-Client as part of
shared secret."; the Server Greeting message.";
} }
}
}
container session-sender { leaf server-iv {
if-feature session-sender; type binary {
presence "Enables TWAMP Session-Sender functionality."; length 16;
description }
"Configuration of the TWAMP Session-Sender logical entity"; description
leaf admin-state { "The Server Initialization Vector
type boolean; (IV) generated randomly by the Server.";
mandatory true; }
description
"Indicates whether the device is allowed to operate
as a TWAMP Session-Sender.";
}
list test-session{ leaf challenge {
key name; type binary {
description length 16;
"List of TWAMP Session-Sender test sessions."; }
description
"A random sequence of octets generated by the Server.
As described in client/token, Challenge is used
by the Control-Client to prove possession of a
shared secret.";
}
}
}
leaf name { container session-sender {
type string; if-feature session-sender;
description presence "Enables TWAMP Session-Sender functionality.";
"A unique name for this TWAMP-Test session to be used description
for identifying this test session by the Session-Sender "Configuration of the TWAMP Session-Sender logical entity";
logical entity."; leaf admin-state {
} type boolean;
mandatory true;
description
"Indicates whether the device is allowed to operate
as a TWAMP Session-Sender.";
}
leaf ctrl-connection-name { list test-session{
type string; key name;
config false; description
description "List of TWAMP Session-Sender test sessions.";
"The name of the parent TWAMP-Control connection that
is responsible for negotiating this TWAMP-Test session.";
}
leaf fill-mode { leaf name {
type padding-fill-mode; type string;
default zero; description
description "A unique name for this TWAMP-Test session to be used
"Indicates whether the padding added to the for identifying this test session by the
TWAMP-Test (UDP) packets will contain pseudo-random Session-Sender logical entity.";
numbers, or whether it should consist of all zeroes, }
as per Section 4.2.1 of RFC 5357.";
}
leaf number-of-packets { leaf ctrl-connection-name {
type uint32; type string;
mandatory true; config false;
description description
"The overall number of TWAMP-Test (UDP) packets to be "The name of the parent TWAMP-Control connection that
transmitted by the Session-Sender for this test session."; is responsible for negotiating this TWAMP-Test
} session.";
}
choice packet-distribution { leaf fill-mode {
description type padding-fill-mode;
"Indicates the distribution to be used for transmitting default zero;
the TWAMP-Test (UDP) packets."; description
case periodic { "Indicates whether the padding added to the
leaf periodic-interval { TWAMP-Test (UDP) packets will contain pseudo-random
type decimal64 { numbers, or whether it should consist of all zeroes,
fraction-digits 5; as per Section 4.2.1 of RFC 5357.";
} }
units seconds;
mandatory true;
description
"Indicates the time to wait (in seconds) between the
first bits of TWAMP-Test (UDP) packet transmissions for
this test session.";
reference
"RFC 3432: Network performance measurement
with periodic streams";
}
}
case poisson {
leaf lambda {
type decimal64 {
fraction-digits 5;
}
units seconds;
mandatory true;
description
"Indicates the average time interval (in seconds)
between packets in the Poisson distribution.
The packet is calculated using the reciprocal of lambda
and the TWAMP-Test packet size (which depends on the
selected Mode and the packet padding).";
reference
"RFC 2330: Framework for IP Performance Metrics";
}
leaf max-interval {
type decimal64 {
fraction-digits 5;
}
units seconds;
description
"Indicates the maximum time (in seconds)
between packet transmissions.";
reference
"RFC 7312: Advanced Stream and Sampling Framework
for IP Performance Metrics (IPPM)";
}
}
}
leaf state { leaf number-of-packets {
type sender-session-state; type uint32;
config false; mandatory true;
description description
"Indicates the Session-Sender test session state."; "The overall number of TWAMP-Test (UDP) packets to be
} transmitted by the Session-Sender for this test
session.";
}
uses maintenance-statistics; choice packet-distribution {
} description
} "Indicates the distribution to be used for transmitting
the TWAMP-Test (UDP) packets.";
case periodic {
leaf periodic-interval {
type decimal64 {
fraction-digits 5;
}
units seconds;
mandatory true;
description
"Indicates the time to wait (in seconds) between
the first bits of TWAMP-Test (UDP) packet
transmissions for this test session.";
reference
"RFC 3432: Network performance measurement
with periodic streams";
}
}
case poisson {
leaf lambda {
type decimal64 {
fraction-digits 5;
}
units seconds;
mandatory true;
description
"Indicates the average time interval (in seconds)
between packets in the Poisson distribution.
The packet is calculated using the reciprocal of
lambda and the TWAMP-Test packet size (which
depends on the selected Mode and the packet
padding).";
reference
"RFC 2330: Framework for IP Performance Metrics";
}
leaf max-interval {
type decimal64 {
fraction-digits 5;
}
units seconds;
description
"Indicates the maximum time (in seconds)
between packet transmissions.";
reference
"RFC 7312: Advanced Stream and Sampling Framework
for IP Performance Metrics (IPPM)";
}
}
}
container session-reflector { leaf state {
if-feature session-reflector; type sender-session-state;
presence "Enables TWAMP Session-Reflector functionality."; config false;
description description
"Configuration of the TWAMP Session-Reflector logical entity"; "Indicates the Session-Sender test session state.";
}
leaf admin-state { uses maintenance-statistics;
type boolean; }
mandatory true; }
description container session-reflector {
"Indicates whether the device is allowed to operate if-feature session-reflector;
as a TWAMP Session-Reflector."; presence "Enables TWAMP Session-Reflector functionality.";
} description
"Configuration of the TWAMP Session-Reflector logical
entity";
leaf refwait { leaf admin-state {
type uint32 { type boolean;
range 1..604800; mandatory true;
} description
units seconds; "Indicates whether the device is allowed to operate
default 900; as a TWAMP Session-Reflector.";
description }
"The Session-Reflector MAY discontinue any session that has
been started when no packet associated with that session has
been received for REFWAIT seconds. As per Section 3.1 of
RFC 5357, this timeout allows a Session-Reflector to free up
resources in case of failure.";
}
list test-session { leaf refwait {
key type uint32 {
"sender-ip sender-udp-port range 1..604800;
reflector-ip reflector-udp-port"; }
config false; units seconds;
description default 900;
"TWAMP Session-Reflectortest sessions."; description
"The Session-Reflector MAY discontinue any session that
has been started when no packet associated with that
session has been received for REFWAIT seconds. As per
Section 3.1 of RFC 5357, this timeout allows a
Session-Reflector to free up resources in case of
failure.";
}
leaf sid { list test-session {
type string; key
description "sender-ip sender-udp-port
"An auto-allocated identifier for this TWAMP-Test reflector-ip reflector-udp-port";
session that is unique within the context of this config false;
Server/Session-Reflector device only. This value description
is communicated to the Control-Client that "TWAMP Session-Reflectortest sessions.";
requested the test session in the SID field of the
Accept-Session message.";
}
leaf sender-ip { leaf sid {
type inet:ip-address; type string;
description description
"The IP address on the remote device, which is the "An auto-allocated identifier for this TWAMP-Test
source IP address used in the TWAMP-Test (UDP) packets session that is unique within the context of this
belonging to this test session."; Server/Session-Reflector device only. This value
} is communicated to the Control-Client that
requested the test session in the SID field of the
Accept-Session message.";
}
leaf sender-ip {
type inet:ip-address;
description
"The IP address on the remote device, which is the
source IP address used in the TWAMP-Test (UDP) packets
belonging to this test session.";
}
leaf sender-udp-port { leaf sender-udp-port {
type dynamic-port-number; type dynamic-port-number;
description description
"The source UDP port used in the TWAMP-Test packets "The source UDP port used in the TWAMP-Test packets
belonging to this test session."; belonging to this test session.";
} }
leaf reflector-ip { leaf reflector-ip {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the local Session-Reflector "The IP address of the local Session-Reflector
device, which is the destination IP address used device, which is the destination IP address used
in the TWAMP-Test (UDP) packets belonging to this test in the TWAMP-Test (UDP) packets belonging to this test
session."; session.";
} }
leaf reflector-udp-port { leaf reflector-udp-port {
type uint32 { type uint32 {
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 {
type inet:ip-address;
description
"The IP address on the Control-Client device, which
is the source IP address used in the TWAMP-Control
(TCP) packets belonging to the parent control
connection that negotiated this test session.";
}
leaf parent-connection-client-ip { leaf parent-connection-client-tcp-port {
type inet:ip-address; type inet:port-number;
description description
"The IP address on the Control-Client device, which "The source TCP port number 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-server-ip {
type inet:port-number; type inet:ip-address;
description description
"The source TCP port number used in the TWAMP-Control "The IP address of the Server device, which is the
(TCP) packets belonging to the parent control connection destination IP address used in the TWAMP-Control
that negotiated this test session."; (TCP) packets belonging to the parent control
} connection that negotiated this test session.";
}
leaf parent-connection-server-ip { leaf parent-connection-server-tcp-port {
type inet:ip-address; type inet:port-number;
description description
"The IP address of the Server device, which is the "The destination TCP port number used in the
destination IP address used in the TWAMP-Control TWAMP-Control (TCP) packets belonging to the parent
(TCP) packets belonging to the parent control control connection that negotiated this test
connection that negotiated this test session."; session.";
} }
leaf parent-connection-server-tcp-port { leaf test-packet-dscp {
type inet:port-number; type inet:dscp;
description description
"The destination TCP port number used in the TWAMP-Control "The DSCP value present in the IP header of
(TCP) packets belonging to the parent control connection TWAMP-Test (UDP) packets belonging to this session.";
that negotiated this test session."; }
}
leaf test-packet-dscp { uses maintenance-statistics;
type inet:dscp; }
description }
"The DSCP value present in the IP header of }
TWAMP-Test (UDP) packets belonging to this session."; }
}
uses maintenance-statistics; <CODE ENDS>
}
}
}
}
<CODE ENDS>
6. Data Model Examples 6. Data Model Examples
This section presents a simple but complete example of configuring This section presents a simple but complete example of configuring
all four entities in Figure 1, based on the YANG module specified in all four entities in Figure 1, based on the YANG module specified in
Section 5. The example is illustrative in nature, but aims to be Section 5. The example is illustrative in nature, but aims to be
self-contained, i.e. were it to be executed in a real TWAMP self-contained, i.e. were it to be executed in a real TWAMP
implementation it would lead to a correctly configured test session. implementation it would lead to a correctly configured test session.
For completeness, examples are provided for both IPv4 and IPv6. For completeness, examples are provided for both IPv4 and IPv6.
A more elaborated example, which also includes authentication A more elaborated example, which also includes authentication
parameters, is provided in Appendix A. parameters, is provided in Appendix A.
6.1. Control-Client 6.1. Control-Client
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>
<name>Test1</name> <name>Test1</name>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</reflector-udp-port>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
<test-session-request> <test-session-request>
<name>Test2</name> <name>Test2</name>
<sender-ip>203.0.113.1</sender-ip> <sender-ip>203.0.113.1</sender-ip>
<sender-udp-port>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>203.0.113.2</reflector-ip> <reflector-ip>203.0.113.2</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</reflector-udp-port>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
<ctrl-connection> <ctrl-connection>
<name>RouterB</name> <name>RouterB</name>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<server-ip>203.0.113.3</server-ip> <server-ip>203.0.113.3</server-ip>
</ctrl-connection> </ctrl-connection>
</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>
<name>Test1</name> <name>Test1</name>
<sender-ip>2001:DB8:203:1:113::3</sender-ip> <sender-ip>2001:DB8:203:1:113::3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>2001:DB8:203:1:113::4</reflector-ip> <reflector-ip>2001:DB8:203:1:113::4</reflector-ip>
<reflector-udp-port>55000</reflector-udp-port> <reflector-udp-port>55000</reflector-udp-port>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
<test-session-request> <test-session-request>
<name>Test2</name> <name>Test2</name>
<sender-ip>2001:DB8:203:0:113::1</sender-ip> <sender-ip>2001:DB8:203:0:113::1</sender-ip>
<sender-udp-port>54001</sender-udp-port> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>2001:DB8:203:0:113::2</reflector-ip> <reflector-ip>2001:DB8:203:0:113::2</reflector-ip>
<reflector-udp-port>55001</reflector-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<start-time>0</start-time> <start-time>0</start-time>
</test-session-request> </test-session-request>
</ctrl-connection> </ctrl-connection>
<ctrl-connection> <ctrl-connection>
<name>RouterB</name> <name>RouterB</name>
<client-ip>2001:DB8:203:0:113::1</client-ip> <client-ip>2001:DB8:203:0:113::1</client-ip>
<server-ip>2001:DB8:203:0:113::3</server-ip> <server-ip>2001:DB8:203:0:113::3</server-ip>
</ctrl-connection> </ctrl-connection>
</client> </client>
</twamp> </twamp>
</config> </config>
6.2. Server 6.2. Server
Figure 9 shows a configuration example for a Server with server/ Figure 9 shows a configuration example for a Server with 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> <state>active</state>
active </ctrl-connection>
</state> </server>
</ctrl-connection> </twamp>
</server>
</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>
<state> <state>active</state>
active </ctrl-connection>
</state> </server>
</ctrl-connection> </twamp>
</server>
</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>
<state>setup</state> </test-session>
</test-session> <test-session>
<test-session> <name>Test2</name>
<name>Test2</name> <ctrl-connection-name>RouterA</ctrl-connection-name>
<ctrl-connection-name> <number-of-packets>900</number-of-packets>
RouterA <lambda>1</lambda>
</ctrl-connection-name> <max-interval>2</max-interval>
<number-of-packets>900</number-of-packets> </test-session>
<lambda>1</lambda> </session-sender>
<max-interval>2</max-interval>
<state>setup</state>
</test-session>
</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.
The following example shows the two Session-Reflector TWAMP-Test The following example shows the two Session-Reflector TWAMP-Test
sessions corresponding to the test sessions presented in Section 6.3. sessions corresponding to the test sessions presented in Section 6.3.
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>50001</reflector-udp-port> <reflector-udp-port>50001</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>203.0.113.1</parent-connection-\
203.0.113.1 client-ip>
</parent-connection-client-ip> <parent-connection-client-tcp-port>16341</parent-connection-\
<parent-connection-client-tcp-port> client-tcp-port>
16341 <parent-connection-server-ip>203.0.113.2</parent-connection-\
</parent-connection-client-tcp-port> server-ip>
<parent-connection-server-ip> <parent-connection-server-tcp-port>862</parent-connection-se\
203.0.113.2 rver-tcp-port>
</parent-connection-server-ip> <sent-packets>2</sent-packets>
<parent-connection-server-tcp-port> <rcv-packets>2</rcv-packets>
862 <last-sent-seq>1</last-sent-seq>
</parent-connection-server-tcp-port> <last-rcv-seq>1</last-rcv-seq>
<sent-packets>2</sent-packets> </test-session>
<rcv-packets>2</rcv-packets> <test-session>
<last-sent-seq>1</last-sent-seq> <sender-ip>203.0.113.1</sender-ip>
<last-rcv-seq>1</last-rcv-seq> <sender-udp-port>54001</sender-udp-port>
</test-session> <reflector-ip>192.68.0.2</reflector-ip>
<test-session> <reflector-udp-port>50001</reflector-udp-port>
<sender-ip>203.0.113.1</sender-ip> <sid>178943</sid>
<sender-udp-port>54001</sender-udp-port> <parent-connection-client-ip>203.0.113.1</parent-connection-\
<reflector-ip>192.68.0.2</reflector-ip> client-ip>
<reflector-udp-port>50001</reflector-udp-port> <parent-connection-client-tcp-port>16341</parent-connection-\
<sid>178943</sid> client-tcp-port>
<parent-connection-client-ip> <parent-connection-server-ip>203.0.113.2</parent-connection-\
203.0.113.1 server-ip>
</parent-connection-client-ip> <parent-connection-server-tcp-port>862</parent-connection-se\
<parent-connection-client-tcp-port> rver-tcp-port>
16341 <sent-packets>21</sent-packets>
</parent-connection-client-tcp-port> <rcv-packets>21</rcv-packets>
<parent-connection-server-ip> <last-sent-seq>20</last-sent-seq>
203.0.113.2 <last-rcv-seq>20</last-rcv-seq>
</parent-connection-server-ip> </test-session>
<parent-connection-server-tcp-port> </session-reflector>
862 </twamp>
</parent-connection-server-tcp-port>
<sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq>
</test-session>
</session-reflector>
</twamp>
</data> </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">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>54001</reflector-udp-port> <reflector-udp-port>54001</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>203.0.113.1</parent-connection-\
203.0.113.1 client-ip>
</parent-connection-client-ip> <parent-connection-client-tcp-port>16341</parent-connection-\
<parent-connection-client-tcp-port> client-tcp-port>
16341 <parent-connection-server-ip>203.0.113.2</parent-connection-\
</parent-connection-client-tcp-port> server-ip>
<parent-connection-server-ip> <parent-connection-server-tcp-port>862</parent-connection-se\
203.0.113.2 rver-tcp-port>
</parent-connection-server-ip> <sent-packets>2</sent-packets>
<parent-connection-server-tcp-port> <rcv-packets>2</rcv-packets>
862 <last-sent-seq>1</last-sent-seq>
</parent-connection-server-tcp-port> <last-rcv-seq>1</last-rcv-seq>
<sent-packets>2</sent-packets> </test-session>
<rcv-packets>2</rcv-packets> <test-session>
<last-sent-seq>1</last-sent-seq> <sender-ip>203.0.113.1</sender-ip>
<last-rcv-seq>1</last-rcv-seq> <sender-udp-port>54001</sender-udp-port>
<reflector-ip>192.68.0.2</reflector-ip>
</test-session> <reflector-udp-port>55001</reflector-udp-port>
<test-session> <sid>178943</sid>
<sender-ip>203.0.113.1</sender-ip> <parent-connection-client-ip>203.0.113.1</parent-connection-\
<sender-udp-port>54001</sender-udp-port> client-ip>
<reflector-ip>192.68.0.2</reflector-ip> <parent-connection-client-tcp-port>16341</parent-connection-\
<reflector-udp-port>55001</reflector-udp-port> client-tcp-port>
<sid>178943</sid> <parent-connection-server-ip>203.0.113.2</parent-connection-\
<parent-connection-client-ip> server-ip>
203.0.113.1 <parent-connection-server-tcp-port>862</parent-connection-se\
</parent-connection-client-ip> rver-tcp-port>
<parent-connection-client-tcp-port> <sent-packets>21</sent-packets>
16341 <rcv-packets>21</rcv-packets>
</parent-connection-client-tcp-port> <last-sent-seq>20</last-sent-seq>
<parent-connection-server-ip> <last-rcv-seq>20</last-rcv-seq>
203.0.113.2 </test-session>
</parent-connection-server-ip> </session-reflector>
<parent-connection-server-tcp-port> </twamp>
862
</parent-connection-server-tcp-port>
<sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq>
</test-session>
</session-reflector>
</twamp>
</data> </data>
7. Security Considerations 7. Security Considerations
The YANG module defined in Section 5 is designed to be accessed, The YANG module defined in Section 5 is designed to be accessed,
among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF
use a secure transport layer like SSH that is mandatory to implement. use a secure transport layer like SSH that is mandatory to implement.
The NETCONF Access Control Module (NACM) [RFC6536] 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 users to a pre-configured set of
NETCONF protocol operations and attributes. NETCONF protocol operations and attributes.
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
skipping to change at page 54, line 49 skipping to change at page 55, line 39
Kostas Pentikousis was partially supported by FP7 UNIFY Kostas Pentikousis was partially supported by FP7 UNIFY
(http://fp7-unify.eu), a research project partially funded by the (http://fp7-unify.eu), a research project partially funded by the
European Community under the Seventh Framework Program (grant European Community under the Seventh Framework Program (grant
agreement no. 619609). The views expressed here are those of the agreement no. 619609). The views expressed here are those of the
authors only. The European Commission is not liable for any use that authors only. The European Commission is not liable for any use that
may be made of the information in this document. may be made of the information in this document.
10. Contributors 10. Contributors
Lianshu Zheng, Huawei Technologies, China Lianshu Zheng.
Email: vero.zheng@huawei.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 55, line 43 skipping to change at page 56, line 34
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<https://www.rfc-editor.org/info/rfc6038>. <https://www.rfc-editor.org/info/rfc6038>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
"IKEv2-Derived Shared Secret Key for the One-Way Active "IKEv2-Derived Shared Secret Key for the One-Way Active
Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7717, Measurement Protocol (TWAMP)", RFC 7717,
DOI 10.17487/RFC7717, December 2015, DOI 10.17487/RFC7717, December 2015,
<https://www.rfc-editor.org/info/rfc7717>. <https://www.rfc-editor.org/info/rfc7717>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ippm-metric-registry] [I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf- Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-13 (work in progress), October 2017. ippm-metric-registry-14 (work in progress), March 2018.
[I-D.unify-nfvrg-challenges] [I-D.unify-nfvrg-challenges]
Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino, Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,
D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud
Networks: Problem Statement and Challenges", draft-unify- Networks: Problem Statement and Challenges", draft-unify-
nfvrg-challenges-04 (work in progress), July 2016. nfvrg-challenges-04 (work in progress), July 2016.
[I-D.unify-nfvrg-devops] [I-D.unify-nfvrg-devops]
Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G., Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G.,
Pentikousis, K., Wright, S., Lynch, P., and W. John, Pentikousis, K., Wright, S., Lynch, P., and W. John,
"DevOps for Software-Defined Telecom Infrastructures", "DevOps for Software-Defined Telecom Infrastructures",
draft-unify-nfvrg-devops-06 (work in progress), July 2016. 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.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000,
<https://www.rfc-editor.org/info/rfc2898>.
[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>.
[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>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>.
[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:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
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>
<priority>1</priority> <priority>1</priority>
<mode>unauthenticated</mode> <mode>unauthenticated</mode>
</mode-preference-chain> </mode-preference-chain>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>secret1</secret-key> <secret-key>c2VjcmV0MQ==</secret-key>
</key-chain> </key-chain>
<key-chain> <key-chain>
<key-id>KeyForRouterB</key-id> <key-id>KeyForRouterB</key-id>
<secret-key>secret2</secret-key> <secret-key>c2VjcmV0Mg0K</secret-key>
</key-chain> </key-chain>
<ctrl-connection> <ctrl-connection>
<name>RouterA</name> <name>RouterA</name>
<client-ip>203.0.113.1</client-ip> <client-ip>203.0.113.1</client-ip>
<server-ip>203.0.113.2</server-ip> <server-ip>203.0.113.2</server-ip>
<dscp>32</dscp> <control-packet-dscp>32</control-packet-dscp>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<test-session-request> <test-session-request>
<name>Test1</name> <name>Test1</name>
<sender-ip>203.0.113.3</sender-ip> <sender-ip>203.0.113.3</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <reflector-ip>203.0.113.4</reflector-ip>
<reflector-udp-port>55000</reflector-udp-port> <reflector-udp-port>55000</reflector-udp-port>
<padding-length>64</padding-length> <padding-length>64</padding-length>
<start-time>0</start-time> <start-time>0</start-time>
<state>ok</state> </test-session-request>
<sid>1232</sid> <test-session-request>
</test-session-request> <name>Test2</name>
<test-session-request> <sender-ip>203.0.113.1</sender-ip>
<name>Test2</name> <sender-udp-port>54001</sender-udp-port>
<sender-ip>203.0.113.1</sender-ip> <reflector-ip>203.0.113.2</reflector-ip>
<sender-udp-port>54001</sender-udp-port> <reflector-udp-port>55001</reflector-udp-port>
<reflector-ip>203.0.113.2</reflector-ip> <padding-length>128</padding-length>
<reflector-udp-port>55001</reflector-udp-port> <start-time>0</start-time>
<padding-length>128</padding-length> </test-session-request>
<start-time>0</start-time> </ctrl-connection>
<state>ok</state> </client>
<sid>178943</sid> </twamp>
</test-session-request>
</ctrl-connection>
</client>
</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>
<priority>1</priority> <priority>1</priority>
<mode>unauthenticated</mode> <mode>unauthenticated</mode>
</mode-preference-chain> </mode-preference-chain>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>secret1</secret-key> <secret-key>c2VjcmV0MQ==</secret-key>
</key-chain> </key-chain>
<key-chain> <key-chain>
<key-id>KeyForRouterB</key-id> <key-id>KeyForRouterB</key-id>
<secret-key>secret2</secret-key> <secret-key>c2VjcmV0Mg0K</secret-key>
</key-chain>
<ctrl-connection> </key-chain>
<name>RouterA</name> <ctrl-connection>
<client-ip>2001:DB8:203:0:113::1</client-ip> <name>RouterA</name>
<server-ip>2001:DB8:203:0:113::2</server-ip> <client-ip>2001:DB8:203:0:113::1</client-ip>
<dscp>32</dscp> <server-ip>2001:DB8:203:0:113::2</server-ip>
<key-id>KeyClient1ToRouterA</key-id> <control-packet-dscp>32</control-packet-dscp>
<test-session-request> <key-id>KeyClient1ToRouterA</key-id>
<name>Test1</name> <test-session-request>
<sender-ip>2001:DB8:10:1:1::1</sender-ip> <name>Test1</name>
<sender-udp-port>54000</sender-udp-port> <sender-ip>2001:DB8:10:1:1::1</sender-ip>
<reflector-ip>2001:DB8:10:1:1::2</reflector-ip> <sender-udp-port>54000</sender-udp-port>
<reflector-udp-port>55000</reflector-udp-port> <reflector-ip>2001:DB8:10:1:1::2</reflector-ip>
<padding-length>64</padding-length> <reflector-udp-port>55000</reflector-udp-port>
<start-time>0</start-time> <padding-length>64</padding-length>
<state>ok</state> <start-time>0</start-time>
<sid>1232</sid> </test-session-request>
</test-session-request> <test-session-request>
<test-session-request> <name>Test2</name>
<name>Test2</name> <sender-ip>2001:DB8:203:0:113::1</sender-ip>
<sender-ip>2001:DB8:203:0:113::1</sender-ip> <sender-udp-port>54001</sender-udp-port>
<sender-udp-port>54001</sender-udp-port> <reflector-ip>2001:DB8:203:0:113::2</reflector-ip>
<reflector-ip>2001:DB8:203:0:113::2</reflector-ip> <reflector-udp-port>55001</reflector-udp-port>
<reflector-udp-port>55001</reflector-udp-port> <padding-length>128</padding-length>
<padding-length>128</padding-length> <start-time>0</start-time>
<start-time>0</start-time> </test-session-request>
<state>ok</state> </ctrl-connection>
<sid>178943</sid> </client>
</test-session-request> </twamp>
</ctrl-connection>
</client>
</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>
<dscp>32</dscp> <control-packet-dscp>32</control-packet-dscp>
<modes>authenticated unauthenticated</modes> <modes>authenticated unauthenticated</modes>
<count>1024</count> <count>30</count>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>secret1</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>secret10</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>
<state> <control-packet-dscp>32</control-packet-dscp>
active <selected-mode>unauthenticated</selected-mode>
</state> <key-id>KeyClient1ToRouterA</key-id>
<dscp>32</dscp> <count>30</count>
<selected-mode>unauthenticated</selected-mode> </ctrl-connection>
<key-id>KeyClient1ToRouterA</key-id> </server>
<count>1024</count> </twamp>
</ctrl-connection>
</server>
</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>
<dscp>32</dscp> <control-packet-dscp>32</control-packet-dscp>
<modes>authenticated unauthenticated</modes> <modes>authenticated unauthenticated</modes>
<count>1024</count> <count>30</count>
<key-chain> <key-chain>
<key-id>KeyClient1ToRouterA</key-id> <key-id>KeyClient1ToRouterA</key-id>
<secret-key>secret1</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>secret10</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>
<state> <control-packet-dscp>32</control-packet-dscp>
active <selected-mode>unauthenticated</selected-mode>
</state> <key-id>KeyClient1ToRouterA</key-id>
<count>30</count>
</ctrl-connection>
</server>
<dscp>32</dscp> </twamp>
<selected-mode>unauthenticated</selected-mode>
<key-id>KeyClient1ToRouterA</key-id>
<count>1024</count>
</ctrl-connection>
</server>
</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>
<periodic-interval>1</periodic-interval> <periodic-interval>1</periodic-interval>
<state>setup</state> <sent-packets>2</sent-packets>
<sent-packets>2</sent-packets> <rcv-packets>2</rcv-packets>
<rcv-packets>2</rcv-packets> <last-sent-seq>1</last-sent-seq>
<last-sent-seq>1</last-sent-seq> <last-rcv-seq>1</last-rcv-seq>
<last-rcv-seq>1</last-rcv-seq> </test-session>
</test-session> <test-session>
<test-session> <name>Test2</name>
<name>Test2</name> <ctrl-connection-name>RouterA</ctrl-connection-name>
<ctrl-connection-name> <fill-mode>random</fill-mode>
RouterA <number-of-packets>900</number-of-packets>
</ctrl-connection-name> <lambda>1</lambda>
<fill-mode>random</fill-mode> <max-interval>2</max-interval>
<number-of-packets>900</number-of-packets> <sent-packets>21</sent-packets>
<lambda>1</lambda> <rcv-packets>21</rcv-packets>
<max-interval>2</max-interval> <last-sent-seq>20</last-sent-seq>
<state>setup</state> <last-rcv-seq>20</last-rcv-seq>
<sent-packets>21</sent-packets> </test-session>
<rcv-packets>21</rcv-packets> </session-sender>
<last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq>
</test-session>
</session-sender>
</twamp> </twamp>
</data> </data>
A.4. Session-Reflector A.4. Session-Reflector
[note: '\' line wrapping is for formatting only]
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp"> <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
<session-reflector> <session-reflector>
<admin-state> <admin-state>true</admin-state>
true <test-session>
</admin-state> <sender-ip>203.0.113.3</sender-ip>
<test-session> <sender-udp-port>54000</sender-udp-port>
<sender-ip>203.0.113.3</sender-ip> <reflector-ip>203.0.113.4</reflector-ip>
<sender-udp-port>54000</sender-udp-port> <reflector-udp-port>55000</reflector-udp-port>
<reflector-ip>203.0.113.4</reflector-ip> <sid>1232</sid>
<reflector-udp-port>55000</reflector-udp-port> <parent-connection-client-ip>203.0.113.1</parent-connection-\
<sid>1232</sid> client-ip>
<parent-connection-client-ip> <parent-connection-client-tcp-port>16341</parent-connection-\
203.0.113.1 client-tcp-port>
</parent-connection-client-ip> <parent-connection-server-ip>203.0.113.2</parent-connection-\
<parent-connection-client-tcp-port> server-ip>
16341 <parent-connection-server-tcp-port>862</parent-connection-se\
</parent-connection-client-tcp-port> rver-tcp-port>
<parent-connection-server-ip> <test-packet-dscp>32</test-packet-dscp>
203.0.113.2 <sent-packets>2</sent-packets>
</parent-connection-server-ip> <rcv-packets>2</rcv-packets>
<parent-connection-server-tcp-port> <last-sent-seq>1</last-sent-seq>
862 <last-rcv-seq>1</last-rcv-seq>
</parent-connection-server-tcp-port> </test-session>
<dscp>32</dscp> <test-session>
<sent-packets>2</sent-packets> <sender-ip>203.0.113.1</sender-ip>
<rcv-packets>2</rcv-packets> <sender-udp-port>54001</sender-udp-port>
<last-sent-seq>1</last-sent-seq> <reflector-ip>192.68.0.2</reflector-ip>
<last-rcv-seq>1</last-rcv-seq> <reflector-udp-port>55001</reflector-udp-port>
</test-session> <sid>178943</sid>
<test-session> <parent-connection-client-ip>203.0.113.1</parent-connection-\
<sender-ip>203.0.113.1</sender-ip> client-ip>
<sender-udp-port>54001</sender-udp-port> <parent-connection-client-tcp-port>16341</parent-connection-\
<reflector-ip>192.68.0.2</reflector-ip> client-tcp-port>
<reflector-udp-port>55001</reflector-udp-port> <parent-connection-server-ip>203.0.113.2</parent-connection-\
<sid>178943</sid> server-ip>
<parent-connection-client-ip> <parent-connection-server-tcp-port>862</parent-connection-se\
203.0.113.1 rver-tcp-port>
</parent-connection-client-ip> <test-packet-dscp>32</test-packet-dscp>
<parent-connection-client-tcp-port> <sent-packets>21</sent-packets>
16341 <rcv-packets>21</rcv-packets>
</parent-connection-client-tcp-port> <last-sent-seq>20</last-sent-seq>
<parent-connection-server-ip> <last-rcv-seq>20</last-rcv-seq>
203.0.113.2 </test-session>
</parent-connection-server-ip> </session-reflector>
<parent-connection-server-tcp-port> </twamp>
862
</parent-connection-server-tcp-port>
<dscp>32</dscp>
<sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq>
</test-session>
</session-reflector>
</twamp>
</data> </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">
<session-reflector> <session-reflector>
<admin-state>true</admin-state> <admin-state>true</admin-state>
<test-session> <test-session>
<sender-ip>2001:DB8:10:1:1::1</sender-ip> <sender-ip>2001:DB8:10:1:1::1</sender-ip>
<sender-udp-port>54000</sender-udp-port> <sender-udp-port>54000</sender-udp-port>
<reflector-ip>2001:DB8:10:1:1::2</reflector-ip> <reflector-ip>2001:DB8:10:1:1::2</reflector-ip>
<reflector-udp-port>55000</reflector-udp-port> <reflector-udp-port>55000</reflector-udp-port>
<sid>1232</sid> <sid>1232</sid>
<parent-connection-client-ip> <parent-connection-client-ip>2001:DB8:203:0:113::1</parent-c\
2001:DB8:203:0:113::1 onnection-client-ip>
</parent-connection-client-ip> <parent-connection-client-tcp-port>16341</parent-connection-\
<parent-connection-client-tcp-port> client-tcp-port>
16341 <parent-connection-server-ip>2001:DB8:203:0:113::2</parent-c\
</parent-connection-client-tcp-port> onnection-server-ip>
<parent-connection-server-ip> <parent-connection-server-tcp-port>862</parent-connection-se\
2001:DB8:203:0:113::2 rver-tcp-port>
</parent-connection-server-ip> <test-packet-dscp>32</test-packet-dscp>
<parent-connection-server-tcp-port> <sent-packets>2</sent-packets>
862 <rcv-packets>2</rcv-packets>
</parent-connection-server-tcp-port> <last-sent-seq>1</last-sent-seq>
<dscp>32</dscp> <last-rcv-seq>1</last-rcv-seq>
<sent-packets>2</sent-packets> </test-session>
<rcv-packets>2</rcv-packets> <test-session>
<last-sent-seq>1</last-sent-seq> <sender-ip>2001:DB8:203:0:113::1</sender-ip>
<last-rcv-seq>1</last-rcv-seq> <sender-udp-port>54001</sender-udp-port>
</test-session> <reflector-ip>2001:DB8:192:68::2</reflector-ip>
<test-session> <reflector-udp-port>55001</reflector-udp-port>
<sender-ip>2001:DB8:203:0:113::1</sender-ip> <sid>178943</sid>
<sender-udp-port>54001</sender-udp-port> <parent-connection-client-ip>2001:DB8:203:0:113::1</parent-c\
<reflector-ip>2001:DB8:192:68::2</reflector-ip> onnection-client-ip>
<reflector-udp-port>55001</reflector-udp-port> <parent-connection-client-tcp-port>16341</parent-connection-\
<sid>178943</sid> client-tcp-port>
<parent-connection-client-ip> <parent-connection-server-ip>2001:DB8:203:0:113::2</parent-c\
2001:DB8:203:0:113::1 onnection-server-ip>
</parent-connection-client-ip> <parent-connection-server-tcp-port>862</parent-connection-se\
<parent-connection-client-tcp-port> rver-tcp-port>
16341 <test-packet-dscp>32</test-packet-dscp>
</parent-connection-client-tcp-port> <sent-packets>21</sent-packets>
<parent-connection-server-ip> <rcv-packets>21</rcv-packets>
2001:DB8:203:0:113::2 <last-sent-seq>20</last-sent-seq>
</parent-connection-server-ip> <last-rcv-seq>20</last-rcv-seq>
<parent-connection-server-tcp-port> </test-session>
862 </session-reflector>
</parent-connection-server-tcp-port> </twamp>
<dscp>32</dscp>
<sent-packets>21</sent-packets>
<rcv-packets>21</rcv-packets>
<last-sent-seq>20</last-sent-seq>
<last-rcv-seq>20</last-rcv-seq>
</test-session>
</session-reflector>
</twamp>
</data> </data>
Appendix B. TWAMP Operational Commands Appendix B. TWAMP Operational Commands
TWAMP operational commands could be performed programmatically or TWAMP operational commands could be performed programmatically or
manually, e.g. using a command-line interface (CLI). manually, e.g. using a command-line interface (CLI).
With respect to programmability, YANG can be used to define NETCONF With respect to programmability, YANG can be used to define NETCONF
Remote Procedure Calls (RPC), therefore it would be, in principle, Remote Procedure Calls (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
 End of changes. 202 change blocks. 
1782 lines changed or deleted 1801 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/