< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/