idnits 2.17.00 (12 Aug 2021) /tmp/idnits34665/draft-ietf-ippm-twamp-yang-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 649 has weird spacing: '...riority uin...' == Line 682 has weird spacing: '...m-index uin...' -- The document date (July 8, 2016) is 2142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-ippm-metric-registry has been published as RFC 8911 == Outdated reference: draft-ietf-netconf-restconf has been published as RFC 8040 == Outdated reference: A later version (-04) exists of draft-unify-nfvrg-challenges-03 == Outdated reference: A later version (-06) exists of draft-unify-nfvrg-devops-04 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM WG R. Civil 3 Internet-Draft Ciena Corporation 4 Intended status: Standards Track A. Morton 5 Expires: January 9, 2017 AT&T Labs 6 R. Rahman 7 M. Jethanandani 8 Cisco Systems 9 K. Pentikousis, Ed. 10 Travelping 11 L. Zheng 12 Huawei Technologies 13 July 8, 2016 15 Two-Way Active Measurement Protocol (TWAMP) Data Model 16 draft-ietf-ippm-twamp-yang-01 18 Abstract 20 This document specifies a data model for client and server 21 implementations of the Two-Way Active Measurement Protocol (TWAMP). 22 We define the TWAMP data model through Unified Modeling Language 23 (UML) class diagrams and formally specify it using YANG. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 9, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.3. Document Organization . . . . . . . . . . . . . . . . . . 3 63 2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4 64 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7 69 4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13 74 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 76 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 77 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 44 78 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 44 79 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 46 80 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 47 81 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 48 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 52 87 10.2. Informative References . . . . . . . . . . . . . . . . . 53 88 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 54 89 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 54 90 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 57 91 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 58 92 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 59 93 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 62 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 96 1. Introduction 98 The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to 99 measure network performance parameters such as latency, bandwidth, 100 and packet loss by sending probe packets and measuring their 101 experience in the network. To date, TWAMP implementations do not 102 come with a standard management framework and, as such, configuration 103 depends on proprietary mechanisms developed by the corresponding 104 TWAMP vendor. This document addresses this gap by formally 105 specifying the TWAMP data model using YANG. 107 1.1. Motivation 109 In current TWAMP deployments the lack of a standardized data model 110 limits the flexibility to dynamically instantiate TWAMP-based 111 measurements across equipment from different vendors. In large, 112 virtualized, and dynamically instantiated infrastructures where 113 network functions are placed according to orchestration algorithms as 114 discussed in [I-D.unify-nfvrg-challenges][I-D.unify-nfvrg-devops], 115 proprietary mechanisms for managing TWAMP measurements pose severe 116 limitations with respect to programmability. 118 Two major trends call for revisiting the standardization on TWAMP 119 management aspects. First, we expect that in the coming years large- 120 scale and multi-vendor TWAMP deployments will become the norm. From 121 an operations perspective, dealing with several vendor-specific TWAMP 122 configuration mechanisms is simply unsustainable in this context. 123 Second, the increasingly software-defined and virtualized nature of 124 network infrastructures, based on dynamic service chains [NSC] and 125 programmable control and management planes [RFC7426] requires a well- 126 defined data model for TWAMP implementations. This document defines 127 such a TWAMP data model and specifies it formally using the YANG data 128 modeling language [RFC6020]. 130 1.2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 1.3. Document Organization 138 The rest of this document is organized as follows. Section 2 139 presents the scope and applicability of this document. Section 3 140 provides a high-level overview of the TWAMP data model. Section 4 141 details the configuration parameters of the data model and Section 5 142 specifies in YANG the TWAMP data model. Section 6 lists illustrative 143 examples which conform to the YANG data model specified in this 144 document. Appendix A elaborates these examples further. 146 2. Scope, Model, and Applicability 148 The purpose of this document is the specification of a vendor- 149 independent data model for TWAMP implementations. 151 Figure 1 illustrates a redrawn version of the TWAMP logical model 152 found in Section 1.2 of [RFC5357]. The figure is annotated with 153 pointers to the UML diagrams provided in this document and associated 154 with the data model of the four logical entities in a TWAMP 155 deployment, namely the TWAMP Control-Client, Server, Session-Sender 156 and Session-Reflector. 158 As per [RFC5357], unlabeled links in Figure 1 are left unspecified 159 and may be proprietary protocols. 161 [Fig. 3] [Fig. 4] 162 +----------------+ +--------+ 163 | Control-Client | <-- TWAMP-Control --> | Server | 164 +----------------+ +--------+ 165 ^ ^ 166 | | 167 V V 168 +----------------+ +-------------------+ 169 | Session-Sender | <-- TWAMP-Test --> | Session-Reflector | 170 +----------------+ +-------------------+ 171 [Fig. 5] [Fig. 6] 173 Figure 1: Annotated TWAMP logical model 175 As per [RFC5357], a TWAMP implementation may follow a simplified 176 logical model, in which the same node acts both as Control-Client and 177 Session-Sender, while another node acts at the same time as TWAMP 178 Server and Session-Reflector. Figure 2 illustrates this simplified 179 logical model and indicates the interaction between the TWAMP 180 configuration client and server using, for instance, NETCONF 181 [RFC6241] or RESTCONF [I-D.ietf-netconf-restconf]. 183 o-------------------o o-------------------o 184 | Config client | | Config client | 185 o-------------------o o-------------------o 186 || || 187 NETCONF || RESTCONF NETCONF || RESTCONF 188 || || 189 o-------------------o o-------------------o 190 | Config server | | Config server | 191 | [Fig. 3, 5] | | [Fig. 4, 6] | 192 +-------------------+ +-------------------+ 193 | Control-Client | <-- TWAMP-Control --> | Server | 194 | | | | 195 | Session-Sender | <-- TWAMP-Test --> | Session-Reflector | 196 +-------------------+ +-------------------+ 198 Figure 2: Simplified TWAMP model and protocols 200 We note that the data model defined in this document is orthogonal to 201 the specific protocol used between the Config client and Config 202 server to communicate the TWAMP configuration parameters. 204 Operational actions such as how TWAMP-Test sessions are started and 205 stopped, how perfmormance measurement results are retrieved, or how 206 stored results are cleared, and so on, are not addressed by the 207 configuration model defined in this docuemnt. As noted above, such 208 operational actions are not part of the TWAMP specification [RFC5357] 209 and hence are out of scope of this document. See also Appendix B. 211 3. Data Model Overview 213 The TWAMP data model includes four categories of configuration items. 215 Global configuration items relate to parameters that are set on a per 216 device level. For example, the administrative status of the device 217 with respect to whether it allows TWAMP sessions and, if so, in what 218 capacity (e.g. Control-Client, Server or both), are typical 219 instances of global configuration items. 221 A second category includes attributes that can be configured on a per 222 TWAMP-Control connection basis, such as the Server IP address. 224 A third category includes attributes related to per TWAMP-Test 225 session attributes, for instance setting different values in the 226 Differentiated Services Code Point (DSCP) field. 228 Finally, the data model includes attributes that relate to the 229 operational state of the TWAMP implementation. 231 As we describe the TWAMP data model in the remaining sections of this 232 document, readers should keep in mind the functional entity grouping 233 illustrated in Figure 1. 235 3.1. Control-Client 237 A TWAMP Control-Client has an administrative status field set at the 238 device level that indicates whether the node is enabled to function 239 as such. 241 Each TWAMP Control-Client is associated with zero or more TWAMP- 242 Control connections. The main configuration parameters of each 243 control connection are: 245 o A name which can be used to uniquely identify at the Control- 246 Client a particular control connection. This name is necessary 247 for programmability reasons because at the time of creation of a 248 TWAMP-Control connection not all IP and TCP port number 249 information needed to uniquely identify the connection is 250 available. 252 o The IP address of the interface the Control-Client will use for 253 connections. 255 o The IP address of the remote TWAMP Server. 257 o Authentication and Encryption attributes such as KeyID, Token and 258 the Client Initialization Vector (Client-IV); see also the last 259 paragraph of Section 6 in [RFC4656] and [RFC4086]. 261 Each TWAMP-Control connection, in turn, is associated with zero or 262 more TWAMP-Test sessions. For each test session we note the 263 following configuration items: 265 o The test session name that uniquely identifies a particular test 266 session at the Control-Client and Session-Sender. Similarly to 267 the control connections above, this unique test session name is 268 needed because at the time of creation of a TWAMP-Test session, 269 for example, the source UDP port number is not known to uniquely 270 identify the test session. 272 o The IP address and UDP port number of the Session-Sender on the 273 path under test by TWAMP. 275 o The IP address and UDP port number of the Session-Reflector on 276 said path. 278 o Information pertaining to the test packet stream, such as the test 279 starting time, which performance metric is to be used 280 [I-D.ietf-ippm-metric-registry], or whether the test should be 281 repeated. 283 3.2. Server 285 Each TWAMP Server has an administrative status field set at the 286 device level to indicate whether the node is enabled to function as a 287 TWAMP Server. 289 Each Server is associated with zero or more TWAMP-Control 290 connections. Each control connection is uniquely identified by the 291 4-tuple {Control-Client IP address, Control-Client TCP port number, 292 Server IP address, Server TCP port}. Control connection configuration 293 items on a TWAMP Server are read-only. 295 3.3. Session-Sender 297 There is one Session-Sender instance for each TWAMP-Test session that 298 is initiated from the sending device. Primary configuration fields 299 include: 301 o The test session name that MUST be identical with the 302 corresponding test session name on the TWAMP Control-Client 303 (Section 3.1) 305 o The control connection name, which along with the test session 306 name uniquely identify the TWAMP Session-Sender instance 308 o Information pertaining to the test packet stream, such as, for 309 example, the number of test packets and the packet distribution to 310 be employed; see also [RFC3432]. 312 3.4. Session-Reflector 314 Each Session-Reflector is associated with zero or more TWAMP-Test 315 sessions. For each test session, the REFWAIT parameter (Section 4.2 316 of [RFC5357] can be configured. 318 Read-only access to other data model parameters, such as the Sender 319 IP address is foreseen. Each test session can be uniquely identified 320 by the 4-tuple mentioned in Section 3.2. 322 4. Data Model Parameters 324 This section defines the TWAMP data model using UML and introduces 325 selected parameters associated with the four TWAMP logical entities. 326 The complete TWAMP data model specification is provided in the YANG 327 module presented in Section 5.2. 329 4.1. Control-Client 331 The client container (see Figure 3) holds items that are related to 332 the configuration of the TWAMP Control-Client logical entity (recall 333 Figure 1). 335 The client container includes an administrative configuration 336 parameter (client/admin-state) that indicates whether the device is 337 allowed to initiate TWAMP-Control connections. 339 +-------------+ 340 | client | 341 +-------------+ 1..* +-----------------------+ 342 | admin-state |<>----------------------| mode-preference-chain | 343 | | +-----------------------+ 344 | | 1..* +------------+ | priority | 345 | |<>-----| key-chain | | mode | 346 +-------------+ +------------+ +-----------------------+ 347 ^ | key-id | 348 V | secret-key | 349 | +------------+ 350 | 0..* 351 +------------------------+ 352 | ctrl-connection | 353 +------------------------+ 354 | name | 355 | client-ip | 356 | server-ip | 357 | server-tcp-port | 0..* +----------------------+ 358 | control-packet-dscp |<>-------| test-session-request | 359 | key-id | +----------------------+ 360 | max-count | | name | 361 | client-tcp-port {ro} | | sender-ip | 362 | server-start-time {ro} | | sender-udp-port | 363 | state {ro} | | reflector-ip | 364 | selected-mode {ro} | | reflector-udp-port | 365 | token {ro} | | timeout | 366 | client-iv {ro} | | padding-length | 367 +------------------------+ | test-packet-dscp | 368 | start-time | 369 +-------------+ 1 | repeat | 370 | pm-reg-list |------<>| repeat-interval | 371 +-------------+ | state {ro} | 372 | pm-index | | sid {ro} | 373 +-------------+ +----------------------+ 375 Figure 3: TWAMP Control-Client UML class diagram 377 The client container holds a list (mode-preference-chain) which 378 specifies the Mode values according to their preferred order of use 379 by the operator of this Control-Client, including the authentication 380 and encryption Modes. Specifically, mode-preference-chain lists each 381 priority (expressed as a 16-bit unsigned integer, where zero is the 382 highest priority and subsequent values monotonically increasing) with 383 their corresponding mode (expressed as a 32-bit Hexadecimal value). 385 Depending on the Modes available in the Server Greeting, the Control- 386 Client MUST choose the highest priority Mode from the configured 387 mode-preference-chain list. 389 Note that the list of preferred Modes may set bit position 390 combinations when necessary, such as when referring to the extended 391 TWAMP features in [RFC5618], [RFC5938], [RFC6038], and [RFC7717]. If 392 the Control-Client cannot determine an acceptable Mode, it MUST 393 respond with zero Mode bits set in the Set-up Response message, 394 indicating it will not continue with the control connection. 396 In addition, the client container holds a list named key-chain which 397 relates KeyIDs with the respective secret keys. Both the Server and 398 the Control-Client use the same mappings from KeyIDs to shared 399 secrets (key-id and secret-key in Figure 3, respectively). The 400 Server, being prepared to conduct sessions with more than one 401 Control-Client, uses KeyIDs to choose the appropriate secret-key; a 402 Control-Client would typically have different secret keys for 403 different Servers. The secret-key is the shared secret, an octet 404 string of arbitrary length whose interpretation as a text string is 405 unspecified. The key-id and secret-key encoding should follow 406 Section 9.4 of [RFC6020]. The derived key length (dkLen in 407 [RFC2898]) MUST be 128-bits for the AES Session-key used for 408 encryption and a 256-bit HMAC-SHA1 Session-key used for 409 authentication (see Section 6.10 of [RFC4656]). 411 Each client container also holds a list of ctrl-connections, where 412 each item in the list describes a TWAMP control connection that will 413 be initiated by this Control-Client. There SHALL be one instance of 414 ctrl-connection per TWAMP-Control (TCP) connection that is to be 415 initiated from this device. 417 Each ctrl-connection holds a list of test-session-request. test- 418 session-request holds information associated with the Control-Client 419 for this test session. This includes information that is associated 420 with the Request-TW-Session/Accept-Session message exchange (see 421 Section 3.5 of [RFC5357]). 423 There SHALL be one instance of test-session-request for each TWAMP- 424 Test session that is to be negotiated by this TWAMP-Control 425 connection via a Request-TW-Session/Accept-Session exchange. 427 The Control-Client is also responsible for scheduling and results 428 collection for TWAMP-Test sessions, so test-session-request will also 429 hold information related to these actions (e.g. pm-index, repeat- 430 interval). 432 4.2. Server 434 The server container (see Figure 4) holds items that are related to 435 the configuration of the TWAMP Server logical entity (recall 436 Figure 1). 438 The server container includes an administrative configuration 439 parameter (server/admin-state) that indicates whether the device is 440 allowed to receive TWAMP-Control connections. 442 A device operating in the Server role cannot configure attributes on 443 a per TWAMP-Control connection basis, as it has no foreknowledge of 444 the incoming TWAMP-Control connections to be received. As such, any 445 parameter that the Server might want to apply to an incoming control 446 connection must be configured at the overall Server level, and will 447 then be applied to all incoming TWAMP-Control connections. 449 +---------------------+ 450 | server | 451 +---------------------+ 452 | admin-state | 1..* +------------+ 453 | server-tcp-port |<>------| key-chain | 454 | servwait | +------------+ 455 | control-packet-dscp | | key-id | 456 | count | | secret-key | 457 | max-count | +------------+ 458 | modes | 459 | | 0..* +--------------------------+ 460 | |<>------| ctrl-connection | 461 +---------------------+ +--------------------------+ 462 | client-ip {ro} | 463 | client-tcp-port {ro} | 464 | server-ip {ro} | 465 | server-tcp-port {ro} | 466 | state {ro} | 467 | control-packet-dscp {ro} | 468 | selected-mode {ro} | 469 | key-id {ro} | 470 | count {ro} | 471 | max-count {ro} | 472 | salt {ro} | 473 | server-iv {ro} | 474 | challenge {ro} | 475 +--------------------------+ 477 Figure 4: TWAMP Server UML class diagram 479 Each server container holds a list named key-chain which relates 480 KeyIDs with the respective secret keys. As mentioned in Section 4.1, 481 both the Server and the Control-Client use the same mappings from 482 KeyIDs to shared secrets. The Server, being prepared to conduct 483 sessions with more than one Control-Client, uses KeyIDs to choose the 484 appropriate secret-key; a Control-Client would typically have 485 different secret keys for different Servers. key-id tells the Server 486 which shared-secret the Control-Client wishes to use for 487 authentication or encryption. 489 Each incoming control connection that is active on the Server will be 490 represented by an instance of a ctrl-connection object. There SHALL 491 be one instance of ctrl-connection per incoming TWAMP-Control (TCP) 492 connection that is received and active on the Server device. 494 All items in the ctrl-connection object are read-only. Each instance 495 of ctrl-connection can be uniquely identified by the 4-tuple {client- 496 ip, client-tcp-port, server-ip, server-tcp-port}. 498 4.3. Session-Sender 500 The session-sender container, illustrated in Figure 5, holds items 501 that are related to the configuration of the TWAMP Session-Sender 502 logical entity. 504 The session-sender container includes an administrative parameter 505 (session-sender/admin-state) that controls whether the device is 506 allowed to initiate TWAMP-Test sessions. 508 +----------------+ 509 | session-sender | 510 +----------------+ 0..* +---------------------------+ 511 | admin-state |<>-----| test-session | 512 +----------------+ +---------------------------+ 513 | name | 514 | ctrl-connection-name {ro} | 515 | fill-mode | 516 | number-of-packets | 517 | state {ro} | 518 | sent-packets {ro} | 519 | rcv-packets {ro} | 520 | last-sent-seq {ro} | 521 | last-rcv-seq {ro} | 522 +---------------------------+ 523 ^ 524 V 525 | 1 526 +---------------------+ 527 | packet-distribution | 528 +---------------------+ 529 | periodic / poisson | 530 +---------------------+ 531 | | 532 +-------------------------+ | 533 | periodic-interval | | 534 | periodic-interval-units | | 535 +-------------------------+ | 536 | 537 +------------------------+ 538 | lambda | 539 | lambda-units | 540 | max-interval | 541 | truncation-point-units | 542 +------------------------+ 544 Figure 5: TWAMP Session-Sender UML class diagram 546 Each TWAMP-Test session initiated by the Session-Sender will be 547 represented by an instance of a test-session object. There SHALL be 548 one instance of test-session for each TWAMP-Test session for which 549 packets are being sent. 551 4.4. Session-Reflector 553 The session-reflector container, illustrated in Figure 6, holds items 554 that are related to the configuration of the TWAMP Session-Reflector 555 logical entity. 557 The session-reflector container includes an administrative parameter 558 (session-reflector/admin-state) that controls whether the device is 559 allowed to respond to incoming TWAMP test sessions. 561 A device operating in the Session-Reflector role cannot configure 562 attributes on a per-session basis, as it has no foreknowledge of what 563 incoming sessions it will receive. As such, any parameter that the 564 Session-Reflector might want to apply to an incoming TWAMP-Test 565 session must be configured at the overall Session-Reflector level, 566 and will then be applied to all incoming sessions. 568 +----=--------------+ 569 | session-reflector | 570 +-------------------+ 571 | admin-state | 572 | refwait | 573 +-------------------+ 574 ^ 575 V 576 | 577 | 0..* 578 +----------------------------------------+ 579 | test-session | 580 +----------------------------------------+ 581 | sid {ro} | 582 | sender-ip {ro} | 583 | sender-udp-port {ro} | 584 | reflector-ip {ro} | 585 | reflector-udp-port {ro} | 586 | parent-connection-client-ip {ro} | 587 | parent-connection-client-tcp-port {ro} | 588 | parent-connection-server-ip {ro} | 589 | parent-connection-server-tcp-port {ro} | 590 | test-packet-dscp {ro} | 591 | sent-packets {ro} | 592 | rcv-packets {ro} | 593 | last-sent-seq {ro} | 594 | last-rcv-seq {ro} | 595 +----------------------------------------+ 597 Figure 6: TWAMP Session-Reflector UML class diagram 599 Each incoming TWAMP-Test session that is active on the Session- 600 Reflector SHALL be represented by an instance of a test-session 601 object. All items in the test-session object are read-only. 603 Instances of test-session are indexed by a session identifier (sid). 604 This value is auto-allocated by the TWAMP Server as test session 605 requests are received, and communicated back to the Control-Client in 606 the SID field of the Accept-Session message; see Section 4.3 of 607 [RFC6038]. 609 When attempting to retrieve operational data for active test sessions 610 from a Session-Reflector device, the user will not know what sessions 611 are currently active on that device, or what SIDs have been auto- 612 allocated for these test sessions. If the user has network access to 613 the Control-Client device, then it is possible to read the data for 614 this session under client/ctrl-connection/test-session-request/sid 615 and obtain the SID (see Figure 3). The user may then use this SID 616 value as an index to retrieve an individual session-reflector/test- 617 session instance on the Session-Reflector device. 619 If the user has no network access to the Control-Client device, then 620 the only option is to retrieve all test-session instances from the 621 Session-Reflector device. This could be problematic if a large 622 number of test sessions are currently active on that device. 624 Each Session-Reflector TWAMP-Test session contains the following 625 4-tuple: {parent-connection-client-ip, parent-connection-client-tcp- 626 port, parent-connection-server-ip, parent-connection-server-tcp- 627 port}. This 4-tuple MUST correspond to the equivalent 4-tuple 628 {client-ip, client-tcp-port, server-ip, server-tcp-port} in the 629 server/ctrl-connection object. This 4-tuple allows the user to trace 630 back from the TWAMP-Test session to the (parent) TWAMP-Control 631 connection that negotiated this test session. 633 5. Data Model 635 This section formally specifies the TWAMP data model using YANG. 637 5.1. YANG Tree Diagram 639 This section presents a simplified graphical representation of the 640 TWAMP data model using a YANG tree diagram. Readers should keep in 641 mind that the limit of 72 characters per line forces us to introduce 642 artificial line breaks in some tree diagram nodes. 644 module: ietf-twamp 645 +--rw twamp 646 +--rw client! {control-client}? 647 | +--rw admin-state boolean 648 | +--rw mode-preference-chain* [priority] 649 | | +--rw priority uint16 650 | | +--rw mode? twamp-modes 651 | +--rw key-chain* [key-id] 652 | | +--rw key-id string 653 | | +--rw secret-key? string 654 | +--rw ctrl-connection* [name] 655 | +--rw name string 656 | +--rw client-ip? inet:ip-address 657 | +--rw server-ip inet:ip-address 658 | +--rw server-tcp-port? inet:port-number 659 | +--rw control-packet-dscp? inet:dscp 660 | +--rw key-id? string 661 | +--rw max-count? uint32 662 | +--ro client-tcp-port? inet:port-number 663 | +--ro server-start-time? uint64 664 | +--ro state? \ 665 control-client-connection-state 666 | +--ro selected-mode? twamp-modes 667 | +--ro token? binary 668 | +--ro client-iv? binary 669 | +--rw test-session-request* [name] 670 | +--rw name string 671 | +--rw sender-ip? inet:ip-address 672 | +--rw sender-udp-port? dynamic-port-number 673 | +--rw reflector-ip inet:ip-address 674 | +--rw reflector-udp-port? dynamic-port-number 675 | +--rw timeout? uint64 676 | +--rw padding-length? uint32 677 | +--rw test-packet-dscp? inet:dscp 678 | +--rw start-time? uint64 679 | +--rw repeat? uint32 680 | +--rw repeat-interval? uint32 681 | +--rw pm-reg-list* [pm-index] 682 | | +--rw pm-index uint16 683 | +--ro state? test-session-state 684 | +--ro sid? string 685 +--rw server! {server}? 686 | +--rw admin-state boolean 687 | +--rw server-tcp-port? inet:port-number 688 | +--rw servwait? uint32 689 | +--rw control-packet-dscp? inet:dscp 690 | +--rw count? uint32 691 | +--rw max-count? uint32 692 | +--rw modes? twamp-modes 693 | +--rw key-chain* [key-id] 694 | | +--rw key-id string 695 | | +--rw secret-key? string 696 | +--ro ctrl-connection* \ 697 [client-ip client-tcp-port server-ip server-tcp-port] 698 | +--ro client-ip inet:ip-address 699 | +--ro client-tcp-port inet:port-number 700 | +--ro server-ip inet:ip-address 701 | +--ro server-tcp-port inet:port-number 702 | +--ro state? server-ctrl-connection-state 703 | +--ro control-packet-dscp? inet:dscp 704 | +--ro selected-mode? twamp-modes 705 | +--ro key-id? string 706 | +--ro count? uint32 707 | +--ro max-count? uint32 708 | +--ro salt? binary 709 | +--ro server-iv? binary 710 | +--ro challenge? binary 711 +--rw session-sender! {session-sender}? 712 | +--rw admin-state boolean 713 | +--rw test-session* [name] 714 | +--rw name string 715 | +--ro ctrl-connection-name? string 716 | +--rw fill-mode? padding-fill-mode 717 | +--rw number-of-packets? uint32 718 | +--rw (packet-distribution)? 719 | | +--:(periodic) 720 | | | +--rw periodic-interval? uint32 721 | | | +--rw periodic-interval-units? time-units 722 | | +--:(poisson) 723 | | +--rw lambda? uint32 724 | | +--rw lambda-units? uint32 725 | | +--rw max-interval? uint32 726 | | +--rw truncation-point-units? time-units 727 | +--ro state? sender-session-state 728 | +--ro sent-packets? uint32 729 | +--ro rcv-packets? uint32 730 | +--ro last-sent-seq? uint32 731 | +--ro last-rcv-seq? uint32 732 +--rw session-reflector! {session-reflector}? 733 +--rw admin-state boolean 734 +--rw refwait? uint32 735 +--ro test-session* \ 736 [sender-ip sender-udp-port \ 737 reflector-ip reflector-udp-port] 738 +--ro sid? string 739 +--ro sender-ip \ 740 inet:ip-address 741 +--ro sender-udp-port \ 742 dynamic-port-number 743 +--ro reflector-ip inet:ip-address 744 +--ro reflector-udp-port \ 745 dynamic-port-number 746 +--ro parent-connection-client-ip?\ 747 inet:ip-address 748 +--ro parent-connection-client-tcp-port? \ 749 inet:port-number 750 +--ro parent-connection-server-ip? \ 751 inet:ip-address 752 +--ro parent-connection-server-tcp-port? \ 753 inet:port-number 754 +--ro test-packet-dscp? inet:dscp 755 +--ro sent-packets? uint32 756 +--ro rcv-packets? uint32 757 +--ro last-sent-seq? uint32 758 +--ro last-rcv-seq? uint32 760 5.2. YANG Module 762 This section presents the YANG module for the TWAMP data model 763 defined in this document. 765 file "ietf-twamp@2016-07-07.yang" 767 module ietf-twamp { 768 //namespace need to be assigned by IANA 769 namespace 770 urn:ietf:params:xml:ns:yang:ietf-twamp; 771 prefix 772 ietf-twamp; 774 import ietf-inet-types { 775 prefix inet; 776 } 778 organization 779 "IETF IPPM (IP Performance Metrics) Working Group"; 781 contact 782 draft-ietf-ippm-twamp-yang@tools.ietf.org; 784 description 785 "This YANG module specifies a vendor-independent data 786 model for the Two-Way Active Measurement Protocol (TWAMP). 788 The data model covers four TWAMP logical entities: 789 Control-Client, Server, Session-Sender, and Session-Reflector. 790 See Fig. 1 of draft-ietf-ippm-twamp-yang for an illustration 791 of the annotated TWAMP logical model. 793 The YANG module uses features to indicate which of the four 794 logical entities are supported by an implementation."; 796 revision 2016-07-07 { 797 description 798 "Revision appearing in draft-ietf-ippm-twamp-yang-01. 799 Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, 800 and draft-ietf-ippm-metric-registry"; 801 reference 802 draft-ietf-ippm-twamp-yang; 803 } 805 /* 806 * Typedefs 807 */ 809 typedef twamp-modes { 810 type bits { 811 bit unauthenticated { 812 position 0; 813 description 814 "Unauthenticated mode. See RFC 7717 Section 7."; 815 } 816 bit authenticated { 817 position 1; 818 description 819 "Authenticated mode. See RFC 7717 Section 7."; 820 } 821 bit encrypted { 822 position 2; 823 description 824 "Encrypted mode. See RFC 7717 Section 7."; 825 } 826 bit unauth-test-encrpyt-control { 827 position 3; 828 description 829 "Mixed Security Mode: TWAMP-Test protocol security 830 mode in Unauthenticated mode, TWAMP-Control protocol 831 in Encrypted mode."; 832 reference 833 "RFC 5618: Mixed Security Mode for the Two-Way Active 834 Measurement Protocol (TWAMP)"; 835 } 836 bit individual-session-control { 837 position 4; 838 description 839 "Individual Session Control."; 840 reference 841 "RFC 5938: Individual Session Control Feature 842 for the Two-Way Active Measurement Protocol (TWAMP)"; 844 } 845 bit reflect-octets { 846 position 5; 847 description 848 "Reflect Octets Capability."; 849 reference 850 "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) 851 Reflect Octets and Symmetrical Size Features"; 852 } 853 bit symmetrical-size { 854 position 6; 855 description 856 "Symmetrical Size Sender Test Packet Format."; 857 reference 858 "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) 859 Reflect Octets and Symmetrical Size Features"; 860 } 861 bit IKEv2Derived { 862 position 7; 863 description 864 "IKEv2Derived Mode Capability."; 865 reference 866 "RFC 7717: IKEv2-Derived Shared Secret Key for 867 the One-Way Active Measurement Protocol (OWAMP) 868 and Two-Way Active Measurement Protocol (TWAMP)"; 869 } 870 } 871 description 872 "Specifies the configurable TWAMP-Modes used during a 873 TWAMP-Control Connection setup between a Control-Client 874 and a Server. RFC 7717 Section 7 summarizes the 875 TWAMP-Modes registry."; 876 } 878 typedef control-client-connection-state { 879 type enumeration { 880 enum active { 881 description 882 "Indicates an active TWAMP-Control connection to Server."; 883 } 884 enum idle { 885 description 886 "Indicates an idle TWAMP-Control connection to Server."; 887 } 888 } 889 description "Control-Client control connection state"; 890 } 891 typedef test-session-state { 892 type enumeration { 893 enum accepted { 894 value 0; 895 description 896 "Indicates that the TWAMP-Test session request 897 is accepted."; 898 } 899 enum failed { 900 value 1; 901 description 902 "Indicates a TWAMP-Test session failure due to 903 some unspecified reason (catch-all)."; 904 } 905 enum internal-error { 906 value 2; 907 description 908 "Indicates a TWAMP-Test session failure due to 909 an internal error."; 910 } 911 enum not-supported { 912 value 3; 913 description 914 "Indicates a TWAMP-Test session failure because 915 some aspect of the TWAMP-Test session request 916 is not supported."; 917 } 918 enum permanent-resource-limit { 919 value 4; 920 description 921 "Indicates a TWAMP-Test session failure due to 922 permanent resource limitations."; 923 } 924 enum temp-resource-limit { 925 value 5; 926 description 927 "Indicates a TWAMP-Test session failure due to 928 temporary resource limitations."; 929 } 930 } 931 description "TWAMP-Test session state"; 932 } 934 typedef server-ctrl-connection-state { 935 type enumeration { 936 enum active { 937 description "Indicates an active TWAMP-Control connection 938 to the Control-Client."; 940 } 941 enum servwait { 942 description "Indicates that the TWAMP-Control connection 943 to the Control-Client is in SERVWAIT according to RFC 5357 944 (Section 3.1): [a] Server MAY discontinue any established 945 control connection when no packet associated with that 946 connection has been received within SERVWAIT seconds."; 947 } 948 } 949 description "Server control connection state"; 950 } 952 typedef sender-session-state { 953 type enumeration { 954 enum active { 955 description 956 "Indicates that the TWAMP-Test session is active."; 957 } 958 enum failure { 959 description 960 "Indicates that the TWAMP-Test session has failed."; 961 } 962 } 963 description "Session-Sender session state."; 964 } 966 typedef padding-fill-mode { 967 type enumeration { 968 enum zero { 969 description "Packets will be padded with 970 all zeros"; 971 } 972 enum random { 973 description "Packets will be padded with 974 pseudo-random numbers"; 975 } 976 } 977 description "Indicates what type of packet padding is 978 to be used for the UDP TWAMP-Test packets."; 979 } 981 typedef time-units { 982 type enumeration { 983 enum s { 984 description "Seconds."; 985 } 986 enum ms { 987 description "Milliseconds."; 989 } 990 enum us { 991 description "Microseconds."; 992 } 993 enum ns { 994 description "Nanoseconds."; 995 } 996 } 997 description "TWAMP configuration parameters time units."; 998 } 1000 typedef dynamic-port-number { 1001 type inet:port-number { 1002 range 49152..65535; 1003 } 1004 description "Dynamic range for port numbers"; 1005 } 1007 /* 1008 * Features 1009 */ 1011 feature control-client { 1012 description 1013 "Indicates that the device supports configuration 1014 of the TWAMP Control-Client."; 1015 } 1017 feature server { 1018 description 1019 "Indicates that the device supports configuration 1020 of the TWAMP Server."; 1021 } 1023 feature session-sender { 1024 description 1025 "Indicates that the device supports configuration 1026 of the TWAMP Session-Sender."; 1027 } 1029 feature session-reflector { 1030 description 1031 "Indicates that the device supports configuration 1032 of the TWAMP Session-Reflector."; 1033 } 1035 /* 1036 * Reusable node groups 1037 */ 1039 grouping key-management { 1041 list key-chain { 1042 key key-id; 1043 leaf key-id { 1044 type string { 1045 length 1..80; 1046 } 1047 description 1048 "KeyID to be used for a TWAMP-Control connection."; 1049 } 1051 leaf secret-key { 1052 type string; 1053 description 1054 "The corresponding secret key for the 1055 TWAMP-Control connection."; 1056 } 1057 description 1058 "Relates KeyIDs with the respective secret keys 1059 for a TWAMP-Control connection."; 1060 } 1061 description "TWAMP-Control key management."; 1062 } 1064 grouping maintenance-statistics { 1066 leaf sent-packets { 1067 type uint32; 1068 config false; 1069 description "Packets sent"; 1070 } 1072 leaf rcv-packets { 1073 type uint32; 1074 config false; 1075 description "Packets received"; 1076 } 1078 leaf last-sent-seq { 1079 type uint32; 1080 config false; 1081 description "Last sent sequence number"; 1082 } 1083 leaf last-rcv-seq { 1084 type uint32; 1085 config false; 1086 description "Last received sequence number"; 1087 } 1088 description "TWAMP-Test maintenance statistics"; 1089 } 1091 /* 1092 * Configuration data nodes 1093 */ 1095 container twamp { 1096 description 1097 "TWAMP logical entity configuration grouping."; 1099 container client { 1100 if-feature control-client; 1101 presence client; 1102 description 1103 "Configuration of the TWAMP Control-Client logical entity."; 1105 leaf admin-state { 1106 type boolean; 1107 mandatory true; 1108 description 1109 "Indicates whether the device is allowed to operate 1110 as a TWAMP Control-Client."; 1111 } 1113 list mode-preference-chain { 1114 key priority; 1115 unique mode; 1116 leaf priority { 1117 type uint16; 1118 description "Priority."; 1119 } 1120 leaf mode { 1121 type twamp-modes; 1122 description "Supported TWAMP Mode."; 1124 } 1125 description 1126 "Indicates the preferred order of use for the 1127 corresponding supported TWAMP Modes"; 1128 } 1129 uses key-management; 1131 list ctrl-connection { 1132 key name; 1133 description 1134 "List of TWAMP Control-Client control connections. 1135 Each item in the list describes a control connection 1136 that will be initiated by this Control-Client"; 1138 leaf name { 1139 type string; 1140 description 1141 "A unique name used as a key to identify this individual 1142 TWAMP control connection on the Control-Client device."; 1143 } 1144 leaf client-ip { 1145 type inet:ip-address; 1146 description 1147 "The IP address of the local Control-Client device, 1148 to be placed in the source IP address field of the 1149 IP header in TWAMP-Control (TCP) packets belonging 1150 to this control connection. If not configured, the 1151 device SHALL choose its own source IP address."; 1152 } 1153 leaf server-ip { 1154 type inet:ip-address; 1155 mandatory true; 1156 description 1157 "The IP address belonging to the remote Server device, 1158 which the TWAMP-Control connection will be 1159 initiated to."; 1160 } 1162 leaf server-tcp-port { 1163 type inet:port-number; 1164 default 862; 1165 description 1166 "This parameter defines the TCP port number that is 1167 to be used by this outgoing TWAMP-Control connection. 1168 Typically, this is the well-known TWAMP port number (862) 1169 as per RFC 5357 However, there are known 1170 realizations of TWAMP in the field that were implemented 1171 before this well-known port number was allocated. These 1172 early implementations allowed the port number to be 1173 configured. This parameter is therefore provided for 1174 backward compatibility reasons."; 1175 } 1176 leaf control-packet-dscp { 1177 type inet:dscp; 1178 default 0; 1179 description 1180 "The DSCP value to be placed in the IP header of 1181 TWAMP-Control (TCP) packets generated by this 1182 Control-Client."; 1183 } 1185 leaf key-id { 1186 type string { 1187 length 1..80; 1188 } 1189 description 1190 "The KeyID value that is selected 1191 for this TWAMP-Control connection."; 1193 } 1195 leaf max-count { 1196 type uint32 { 1197 range 1024..4294967295; 1198 } 1199 default 32768; 1200 description 1201 "This parameter limits the maximum Count value. 1203 If an attacking system sets the maximum value in 1204 Count (2**32), then the system under attack would stall 1205 for a significant period of time while it attempts to 1206 generate keys."; 1207 } 1209 leaf client-tcp-port { 1210 type inet:port-number; 1211 config false; 1212 description 1213 "The source TCP port number used in the TWAMP-Control 1214 packets belonging to this control connection."; 1215 } 1217 leaf server-start-time { 1218 type uint64; 1219 config false; 1220 description 1221 "The Start-Time advertized by the Server in the 1222 Server-Start message (RFC 4656, Section 3.1). This is 1223 a timestamp representing the time when the current 1224 instantiation of the Server started operating."; 1225 } 1227 leaf state { 1228 type control-client-connection-state; 1229 config false; 1230 description 1231 "Indicates the currest state of the TWAMP-Control 1232 connection state."; 1233 } 1235 leaf selected-mode { 1236 type twamp-modes; 1237 config false; 1238 description 1239 "The TWAMP Mode that the Control-Client has chosen for 1240 this control connection as set in the Mode field of the 1241 Set-Up-Response message (RFC 4656, Section 3.1)."; 1242 } 1244 leaf token { 1245 type binary { 1246 length 64; 1247 } 1248 config false; 1249 description 1250 "This parameter holds the 64 octets containing the 1251 concatenation of a 16-octet Challenge, a 16-octet AES 1252 Session-key used for encryption, and a 32-octet 1253 HMAC-SHA1 Session-key used for authentication. 1255 AES Session-key and HMAC Session-key are generated 1256 randomly by the Control-Client. AES Session-key and 1257 HMAC Session-key MUST be generated with sufficient 1258 entropy not to reduce the security of the underlying 1259 cipher. The token itself is encrypted 1260 using the AES (Advanced Encryption Standard) in 1261 Cipher Block Chaining (CBC). Encryption MUST be 1262 performed using an Initialization Vector (IV) 1263 of zero and a key derived from the shared secret 1264 associated with KeyID. Challenge is the same as 1265 transmitted by the Server in the clear; see also the 1266 last paragraph of Section 6 in RFC 4656."; 1267 reference 1268 "RFC 4086: Randomness Requirements for Security"; 1269 } 1271 leaf client-iv { 1272 type binary { 1273 length 16; 1274 } 1275 config false; 1276 description 1277 "The Control-Client Initialization Vector (Client-IV) 1278 is generated randomly by the Control-Client. 1280 Client-IV merely needs to be unique (i.e., it MUST 1281 never be repeated for different sessions using the 1282 same secret key; a simple way to achieve that without 1283 the use of cumbersome state is to generate the 1284 Client-IV values using a cryptographically secure 1285 pseudo-random number source."; 1286 } 1288 list test-session-request { 1289 key name; 1290 description 1291 "Information associated with the Control-Client 1292 for this test session"; 1294 leaf name { 1295 type string; 1296 description 1297 "A unique name to be used for identification of 1298 this TWAMP-Test session on the Control-Client."; 1299 } 1301 leaf sender-ip { 1302 type inet:ip-address; 1303 description 1304 "The IP address of the Session-Sender device, 1305 which is to be placed in the source IP address 1306 field of the IP header in TWAMP-Test (UDP) packets 1307 belonging to this test session. This value will be 1308 used to populate the sender address field of the 1309 Request-TW-Session message. If not configured, 1310 the device SHALL choose its own source IP address."; 1311 } 1313 leaf sender-udp-port { 1314 type dynamic-port-number; 1315 description 1316 "The UDP port number that is to be used by 1317 the Session-Sender for this TWAMP-Test session. 1318 The number is restricted to the dynamic port range. 1319 A value of zero indicates that the Control-Client 1320 SHALL auto-allocate a UDP port number for this 1321 TWAMP-Test session. The configured 1322 (or auto-allocated) value is advertized in the 1323 Sender Port field of the Request-TW-session message 1324 (see also Section 3.5 of RFC 5357. Note that in the 1325 scenario where a device auto-allocates a UDP port 1326 number for a session, and the repeat parameter 1327 for that session indicates that it should be 1328 repeated, the device is free to auto-allocate a 1329 different UDP port number when it negotiates the 1330 next (repeated) iteration of this session."; 1331 } 1333 leaf reflector-ip { 1334 type inet:ip-address; 1335 mandatory true; 1336 description 1337 "The IP address belonging to the remote 1338 Session-Reflector device to which the TWAMP-Test 1339 session will be initiated. This value will be 1340 used to populate the receiver address field of 1341 the Request-TW-Session message."; 1342 } 1344 leaf reflector-udp-port { 1345 type dynamic-port-number; 1346 description 1347 "This parameter defines the UDP port number that 1348 will be used by the Session-Reflector for 1349 this TWAMP-Test session. The number is restricted 1350 to the dynamic port range and is to be placed in 1351 the Receiver Port field of the Request-TW-Session 1352 message. If this value is not set, the device SHALL 1353 use the same port number as defined in the 1354 server-tcp-port parameter of this 1355 test-session-request's parent 1356 twamp/client/ctrl-connection."; 1357 } 1359 leaf timeout { 1360 type uint64; 1361 default 2; 1362 description 1363 "The length of time (in seconds) that the 1364 Session-Reflector should continue to respond to 1365 packets belonging to this TWAMP-Test session after 1366 a Stop-Sessions TWAMP-Control message has been 1367 received (RFC 5357, Section 3.8). 1369 This value will be placed in the Timeout field of 1370 the Request-TW-Session message."; 1371 } 1373 leaf padding-length { 1374 type uint32 { 1375 range 64..4096; 1376 } 1377 description 1378 "The number of padding bytes to be added to the 1379 TWAMP-Test (UDP) packets generated by the 1380 Session-Sender. 1382 This value will be placed in the Padding Length 1383 field of the Request-TW-Session message 1384 (RFC 4656, Section 3.5)."; 1385 } 1387 leaf test-packet-dscp { 1388 type inet:dscp; 1389 description 1390 "The DSCP value to be placed in the IP header 1391 of TWAMP-Test packets generated by the 1392 Session-Sender, and in the UDP header of the 1393 TWAMP-Test response packets generated by the 1394 Session-Reflector for this test session. 1396 This value will be placed in the Type-P Descriptor 1397 field of the Request-TW-Session message (RFC 5357)."; 1398 } 1400 leaf start-time { 1401 type uint64; 1402 default 0; 1403 description 1404 "Time when the session is to be started 1405 (but not before the TWAMP Start-Sessions command 1406 is issued; see RFC 5357, Section 3.4). 1408 The start-time value is placed in the Start Time 1409 field of the Request-TW-Session message. 1411 The default value of 0 indicates that the session 1412 will be started as soon as the Start-Sessions message 1413 is received."; 1414 } 1416 leaf repeat { 1417 type uint32; 1418 default 0; 1419 description 1420 "This value determines if the TWAMP-Test session must 1421 be repeated. When a test session has completed, the 1422 repeat parameter is checked. 1424 The value of 0 indicates that the session MUST NOT be 1425 repeated. 1427 If the value is 1 through 4,294,967,294 then the test 1428 session SHALL be repeated using the information in 1429 repeat-interval parameter, and the parent 1430 TWAMP-Control connection for this test session is 1431 restarted to negotiate a new instance of this 1432 TWAMP-Test session. The implementation MUST decrement 1433 the value of repeat after determining a repeated 1434 session is expected. 1436 The value of 4,294,967,295 indicates that the test 1437 session SHALL be repeated *forever* using the 1438 information in repeat-interval parameter, and 1439 SHALL NOT decrement the value."; 1440 } 1442 leaf repeat-interval { 1443 when "../repeat!='0'" { 1444 description 1445 "This parameter determines the timing of repeated 1446 test sessions when repeat is more than 0. 1448 When the value of repeat-interval is 0, the 1449 negotiation of a new test session SHALL begin 1450 immediately after the previous test session 1451 completes. Otherwise, the Control-Client will 1452 wait for the number of minutes specified in the 1453 repeat-interval parameter before negotiating the 1454 new instance of this TWAMP-Test session."; 1455 } 1456 type uint32; 1457 default 0; 1458 description "Repeat interval (in minutes)"; 1459 } 1461 list pm-reg-list { 1462 key pm-index; 1463 leaf pm-index { 1464 type uint16; 1465 description 1466 "Numerical index value of a Registered Metric 1467 in the Performance Metric Registry 1468 (see ietf-ippm-metric-registry). Output statistics 1469 are specified in the corresponding Registry entry."; 1470 } 1471 description 1472 "A list of one or more Performance Metric Registry 1473 Index values, which communicate packet stream 1474 characteristics along with one or more metrics 1475 to be measured. 1477 All members of the pm-reg-list MUST have the same 1478 stream characteristics, such that they combine 1479 to specify all metrics that shall be measured on 1480 a single stream."; 1481 reference 1482 "ietf-ippm-metric-registry: 1483 Registry for Performance Metrics"; 1484 } 1485 leaf state { 1486 type test-session-state; 1487 config false; 1488 description 1489 "Indicates the TWAMP-Test session state (accepted or 1490 indication of an error); see Section 3.5 of 1491 RFC 5357."; 1492 } 1493 leaf sid { 1494 type string; 1495 config false; 1496 description 1497 "The SID allocated by the Server for this TWAMP-Test 1498 session, and communicated back to the Control-Client 1499 in the SID field of the Accept-Session message; 1500 see Section 4.3 of RFC 6038."; 1501 } 1502 } 1503 } 1504 } 1506 container server { 1507 if-feature server; 1508 presence server; 1509 description 1510 "Configuration of the TWAMP Server logical entity."; 1512 leaf admin-state { 1513 type boolean; 1514 mandatory true; 1515 description 1516 "Indicates whether the device is allowed to operate 1517 as a TWAMP Server."; 1518 } 1520 leaf server-tcp-port { 1521 type inet:port-number; 1522 default 862; 1523 description 1524 "This parameter defines the well known TCP port number 1525 that is used by TWAMP-Control. The Server will listen 1526 on this port number for incoming TWAMP-Control 1527 connections. Although this is defined as a fixed value 1528 (862) in RFC 5357, there are several realizations of 1529 TWAMP in the field that were implemented before this 1530 well-known port number was allocated. These early 1531 implementations allowed the port number to be 1532 configured. This parameter is therefore provided for 1533 backward compatibility reasons."; 1534 } 1536 leaf servwait { 1537 type uint32 { 1538 range 1..604800; 1539 } 1540 default 900; 1541 description 1542 "TWAMP-Control (TCP) session timeout, in seconds 1543 (RFC 5357, Section 3.1))."; 1544 } 1546 leaf control-packet-dscp { 1547 type inet:dscp; 1548 description 1549 "The DSCP value to be placed in the IP header of 1550 TWAMP-Control (TCP) packets generated by the Server. 1552 Section 3.1 of RFC 5357 specifies that the server 1553 SHOULD use the DSCP value from the Control-Client's 1554 TCP SYN. However, for practical purposes TWAMP will 1555 typically be implemented using a general purpose TCP 1556 stack provided by the underlying operating system, 1557 and such a stack may not provide this information to the 1558 user. Consequently, it is not always possible to 1559 implement the behavior described in RFC 5357 in an 1560 OS-portable version of TWAMP. The default behavior if 1561 this item is not set is to use the DSCP value from 1562 the Control-Client's TCP SYN, as per Section 3.1 1563 of RFC 5357."; 1564 } 1566 leaf count { 1567 type uint32 { 1568 range 1024..4294967295; 1569 } 1570 description 1571 "Parameter used in deriving a key from a shared 1572 secret as described in Section 3.1 of RFC 4656, 1573 and are communicated to the Control-Client as part 1574 of the Server Greeting message. 1576 count MUST be a power of 2. 1578 count MUST be at least 1024. 1580 count SHOULD be increased as more computing power 1581 becomes common."; 1582 } 1583 leaf max-count { 1584 type uint32 { 1585 range 1024..4294967295; 1586 } 1587 default 32768; 1588 description 1589 "This parameter limits the maximum Count value. 1591 If an attacking system sets the maximum value in 1592 Count (2**32), then the system under attack would stall 1593 for a significant period of time while it attempts to 1594 generate keys. 1596 TWAMP-compliant systems SHOULD have a configuration 1597 control to limit the maximum count value. The 1598 default max-count value SHOULD be 32768."; 1599 } 1601 leaf modes { 1602 type twamp-modes; 1603 description 1604 "The bit mask of TWAMP Modes this Server instance 1605 is willing to support; see IANA TWAMP Modes Registry."; 1606 } 1608 uses key-management; 1609 list ctrl-connection { 1610 key 1611 "client-ip client-tcp-port server-ip server-tcp-port"; 1612 config false; 1613 description 1614 "List of all incoming TWAMP-Control (TCP) connections"; 1616 leaf client-ip { 1617 type inet:ip-address; 1618 description 1619 "The IP address on the remote Control-Client device, 1620 which is the source IP address used in the 1621 TWAMP-Control (TCP) packets belonging to this control 1622 connection."; 1623 } 1625 leaf client-tcp-port { 1626 type inet:port-number; 1627 description 1628 "The source TCP port number used in the TWAMP-Control 1629 (TCP) packets belonging to this control connection."; 1630 } 1632 leaf server-ip { 1633 type inet:ip-address; 1634 description 1635 "The IP address of the local Server device, which is 1636 the destination IP address used in the 1637 TWAMP-Control (TCP) packets belonging to this control 1638 connection."; 1639 } 1641 leaf server-tcp-port { 1642 type inet:port-number; 1643 description 1644 "The destination TCP port number used in the 1645 TWAMP-Control (TCP) packets belonging to this 1646 control connection. This will usually be the 1647 same value as the server-tcp-port configured 1648 under twamp/server. However, in the event that 1649 the user re-configured server/server-tcp-port 1650 after this control connection was initiated, this 1651 value will indicate the server-tcp-port that is 1652 actually in use for this control connection."; 1653 } 1655 leaf state { 1656 type server-ctrl-connection-state; 1657 description 1658 "Indicates the Server TWAMP-Control connection state."; 1659 } 1661 leaf control-packet-dscp { 1662 type inet:dscp; 1663 description 1664 "The DSCP value used in the IP header of the 1665 TWAMP-Control (TCP) packets sent by the Server 1666 for this control connection. This will usually 1667 be the same value as is configured in the 1668 control-packet-dscp parameter under the twamp/server 1669 container. However, in the event that the user 1670 re-configures server/dscp after this control 1671 connection is already in progress, this read-only 1672 value will show the actual dscp value in use by this 1673 TWAMP-Control connection."; 1674 } 1676 leaf selected-mode { 1677 type twamp-modes; 1678 description 1679 "The Mode that was chosen for this TWAMP-Control 1680 connection as set in the Mode field of the 1681 Set-Up-Response message."; 1682 } 1684 leaf key-id { 1685 type string { 1686 length 1..80; 1687 } 1688 description 1689 "The KeyID value that is in use by this TWAMP-Control 1690 connection as selected by Control-Client."; 1691 } 1693 leaf count { 1694 type uint32 { 1695 range 1024..4294967295; 1696 } 1697 description 1698 "The count value that is in use by this TWAMP-Control 1699 connection. This will usually be the same value 1700 as is configured under twamp/server. However, in the 1701 event that the user re-configured server/count 1702 after this control connection is already in progress, 1703 this read-only value will show the actual count that 1704 is in use for this TWAMP-Control connection."; 1706 } 1708 leaf max-count { 1709 type uint32 { 1710 range 1024..4294967295; 1711 } 1712 description 1713 "The max-count value that is in use by this 1714 TWAMP-Control connection. This will usually be the 1715 same value as is configured under twamp/server. However, 1716 in the event that the user re-configured 1717 server/max-count after this control connection is 1718 already in progress, this read-only value will show the 1719 actual max-count that is in use for this 1720 control connection."; 1721 } 1723 leaf salt { 1724 type binary { 1725 length 16; 1726 } 1727 description 1728 "A parameter used in deriving a key from a 1729 shared secret as described in Section 3.1 of RFC 4656. 1730 Salt MUST be generated pseudo-randomly (independently 1731 of anything else in the RFC) and is communicated to 1732 the Control-Client as part of the Server Greeting 1733 message."; 1734 } 1736 leaf server-iv { 1737 type binary { 1738 length 16; 1739 } 1740 description 1741 "The Server Initialization Vector 1742 (IV) is generated randomly by the Server."; 1743 } 1745 leaf challenge { 1746 type binary { 1747 length 16; 1748 } 1749 description 1750 "A random sequence of octets generated by the Server. 1751 As described in client/token, Challenge is used 1752 by the Control-Client to prove possession of a 1753 shared secret."; 1755 } 1756 } 1757 } 1759 container session-sender { 1760 if-feature session-sender; 1761 presence session-sender; 1762 description 1763 "Configuration of the TWAMP Session-Sender 1764 logical entity"; 1765 leaf admin-state { 1766 type boolean; 1767 mandatory true; 1768 description 1769 "Indicates whether the device is allowed to operate 1770 as a TWAMP Session-Sender."; 1771 } 1773 list test-session{ 1774 key name; 1775 description 1776 "TWAMP Session-Sender test sessions."; 1778 leaf name { 1779 type string; 1780 description 1781 "A unique name for this TWAMP-Test session to be used 1782 for identifying this test session by the Session-Sender 1783 logical entity."; 1784 } 1786 leaf ctrl-connection-name { 1787 type string; 1788 config false; 1789 description 1790 "The name of the parent TWAMP-Control connection that 1791 is responsible for negotiating this TWAMP-Test session."; 1792 } 1794 leaf fill-mode { 1795 type padding-fill-mode; 1796 default zero; 1797 description 1798 "Indicates whether the padding added to the 1799 TWAMP-Test (UDP) packets will contain pseudo-random 1800 numbers, or whether it should consist of all zeroes, 1801 as per Section 4.2.1 of RFC 5357."; 1802 } 1803 leaf number-of-packets { 1804 type uint32; 1805 description 1806 "The overall number of TWAMP-Test (UDP) packets to 1807 be transmitted by the Session-Sender 1808 for this test session."; 1809 } 1811 choice packet-distribution { 1812 description 1813 "Indicates the distribution to be used for transmitting 1814 the TWAMP-Test (UDP) packets."; 1815 case periodic { 1816 leaf periodic-interval { 1817 type uint32; 1818 description 1819 "Indicates the period to wait between the first bits 1820 of TWAMP-Test (UDP) packet transmissions for 1821 this test session"; 1822 } 1823 leaf periodic-interval-units { 1824 type time-units; 1825 description "Periodic interval time unit."; 1826 reference 1827 "RFC 3432: Network performance measurement 1828 with periodic streams"; 1829 } 1830 } 1831 case poisson { 1832 leaf lambda { 1833 type uint32; 1834 description 1835 "Indicates the average packet transmission rate."; 1836 } 1837 leaf lambda-units { 1838 type uint32; 1839 description 1840 "Indicates the units of lambda in 1841 reciprocal seconds."; 1842 reference 1843 "RFC 3432: Network performance measurement 1844 with periodic streams"; 1845 } 1846 leaf max-interval { 1847 type uint32; 1848 description 1849 "Indicates the maximum time between packet 1850 transmissions."; 1852 } 1853 leaf truncation-point-units { 1854 type time-units; 1855 description "Time units to truncate."; 1856 } 1857 } 1858 } 1860 leaf state { 1861 type sender-session-state; 1862 config false; 1863 description 1864 "Indicates the Session-Sender test session state."; 1865 } 1867 uses maintenance-statistics; 1868 } 1869 } 1871 container session-reflector { 1872 if-feature session-reflector; 1873 presence session-reflector; 1874 description 1875 "Configuration of the TWAMP Session-Reflector 1876 logical entity"; 1878 leaf admin-state { 1879 type boolean; 1880 mandatory true; 1881 description 1882 "Indicates whether the device is allowed to operate 1883 as a TWAMP Session-Reflector."; 1884 } 1886 leaf refwait { 1887 type uint32 { 1888 range 1..604800; 1889 } 1890 default 900; 1891 description 1892 "The Session-Reflector MAY discontinue any session 1893 that has been started when no packet associated with 1894 that session has been received for REFWAIT seconds. 1896 The default value of REFWAIT SHALL be 900 seconds, and 1897 this waiting time MAY be configurable. This timeout 1898 allows a Session-Reflector to free up resources in 1899 case of failure."; 1901 } 1903 list test-session { 1904 key 1905 "sender-ip sender-udp-port 1906 reflector-ip reflector-udp-port"; 1907 config false; 1908 description 1909 "TWAMP Session-Reflectortest sessions."; 1911 leaf sid { 1912 type string; 1913 description 1914 "An auto-allocated identifier for this TWAMP-Test 1915 session, that is unique within the context of this 1916 Server/Session-Reflector device only. This value 1917 will be communicated to the Control-Client that 1918 requested the test session in the SID field of the 1919 Accept-Session message."; 1920 } 1922 leaf sender-ip { 1923 type inet:ip-address; 1924 description 1925 "The IP address on the remote device, which is the 1926 source IP address used in the TWAMP-Test 1927 (UDP) packets belonging to this test session."; 1928 } 1930 leaf sender-udp-port { 1931 type dynamic-port-number; 1932 description 1933 "The source UDP port used in the TWAMP-Test packets 1934 belonging to this test session."; 1935 } 1937 leaf reflector-ip { 1938 type inet:ip-address; 1939 description 1940 "The IP address of the local Session-Reflector 1941 device, which is the destination IP address used 1942 in the TWAMP-Test (UDP) packets belonging to this test 1943 session."; 1944 } 1946 leaf reflector-udp-port { 1947 type dynamic-port-number; 1948 description 1949 "The destination UDP port number used in the 1950 TWAMP-Test (UDP) test packets belonging to this 1951 test session."; 1952 } 1954 leaf parent-connection-client-ip { 1955 type inet:ip-address; 1956 description 1957 "The IP address on the Control-Client device, which 1958 is the source IP address used in the TWAMP-Control 1959 (TCP) packets belonging to the parent control 1960 connection that negotiated this test session."; 1961 } 1963 leaf parent-connection-client-tcp-port { 1964 type inet:port-number; 1965 description 1966 "The source TCP port number used in the TWAMP-Control 1967 (TCP) packets belonging to the parent control connection 1968 that negotiated this test session."; 1969 } 1971 leaf parent-connection-server-ip { 1972 type inet:ip-address; 1973 description 1974 "The IP address of the Server device, which is the 1975 destination IP address used in the TWAMP-Control 1976 (TCP) packets belonging to the parent control 1977 connection that negotiated this test session."; 1978 } 1980 leaf parent-connection-server-tcp-port { 1981 type inet:port-number; 1982 description 1983 "The destination TCP port number used in the TWAMP-Control 1984 (TCP) packets belonging to the parent control connection 1985 that negotiated this test session."; 1986 } 1988 leaf test-packet-dscp { 1989 type inet:dscp; 1990 description 1991 "The DSCP value present in the IP header of 1992 TWAMP-Test (UDP) packets belonging to this test 1993 session."; 1994 } 1996 uses maintenance-statistics; 1998 } 1999 } 2000 } 2001 } 2003 2005 6. Data Model Examples 2007 This section presents a simple but complete example of configuring 2008 all four entities in Figure 1, based on the YANG module specified in 2009 Section 5. The example is illustrative in nature, but aims to be 2010 self-contained, i.e. were it to be executed in a real TWAMP 2011 implementation it would lead to a correctly configured test session. 2012 For completeness, examples are provided for both IPv4 and IPv6. 2014 A more elaborated example, which also includes authentication 2015 parameters, is provided in Appendix A. 2017 6.1. Control-Client 2019 The following configuration example shows a Control-Client with 2020 client/admin-state enabled. In a real implementation following 2021 Figure 2 this would permit the initiation of TWAMP-Control 2022 connections and TWAMP-Test sessions. 2024 2025 2026 2027 2028 true 2029 2030 2031 2033 The following configuration example shows a Control-Client with two 2034 instances of client/ctrl-connection, one called "RouterA" and another 2035 called "RouterB". 2037 Each TWAMP-Control connection is to a different Server. The control 2038 connection named "RouterA" has two test session requests. The TWAMP- 2039 Control connection named "RouterB" has no TWAMP-Test session 2040 requests. 2042 2043 2044 2045 2046 true 2047 2048 RouterA 2049 203.0.113.1 2050 203.0.113.2 2051 2052 Test1 2053 10.1.1.1 2054 50000 2055 10.1.1.2 2056 500001 2057 0 2058 2059 2060 Test2 2061 203.0.113.1 2062 4001 2063 203.0.113.2 2064 50001 2065 0 2066 2067 2068 2069 RouterB 2070 203.0.113.1 2071 203.0.113.3 2072 2073 2074 2075 2077 2078 2079 2080 2081 true 2082 2083 RouterA 2084 2001:DB8:203:0:113::1 2085 2001:DB8:203:0:113::2 2086 2087 Test1 2088 2001:DB8:10:1:1::1 2089 4000 2090 2001:DB8:10:1:1::2 2091 5000 2092 0 2094 2095 2096 Test2 2097 2001:DB8:203:0:113::1 2098 4001 2099 2001:DB8:203:0:113::2 2100 5001 2101 0 2102 2103 2104 2105 RouterB 2106 2001:DB8:203:0:113::1 2107 2001:DB8:203:0:113::3 2108 2109 2110 2111 2113 6.2. Server 2115 This configuration example shows a Server with server/admin-state 2116 enabled, which permits a device following Figure 2 to respond to 2117 TWAMP-Control connections and TWAMP-Test sessions. 2119 2120 2121 2122 2123 true 2124 2125 2126 2128 The following example presents a Server with the TWAMP-Control 2129 connection corresponding to the control connection name (client/ctrl- 2130 connection/name) "RouterA" presented in Section 6.1. 2132 2133 2134 2135 2136 true 2137 2138 203.0.113.1 2139 16341 2140 203.0.113.2 2141 862 2142 2143 active 2144 2145 2146 2147 2148 2150 2151 2152 2153 2154 true 2155 2156 2001:DB8:203:0:113::1 2157 16341 2158 2001:DB8:203:0:113::2 2159 862 2160 2161 active 2162 2163 2164 2165 2166 2168 6.3. Session-Sender 2170 The following configuration example shows a Session-Sender with the 2171 two TWAMP-Test sessions presented in Section 6.1. 2173 2174 2175 2176 2177 true 2178 2179 Test1 2180 RouterA 2181 900 2182 1 2183 seconds 2184 setup 2185 2186 2187 Test2 2188 2189 RouterA 2190 2191 900 2192 1 2193 1 2194 2 2195 seconds 2196 setup 2197 2198 2199 2200 2202 6.4. Session-Reflector 2204 The following example shows the two Session-Reflector TWAMP-Test 2205 sessions corresponding to the test sessions presented in Section 6.3. 2207 2208 2209 2210 2211 2212 true 2213 2214 2215 10.1.1.1 2216 4000 2217 10.1.1.2 2218 50001 2219 1232 2220 2221 203.0.113.1 2222 2223 2224 16341 2225 2226 2227 203.0.113.2 2228 2229 2230 862 2231 2232 2 2233 2 2234 1 2235 1 2236 2237 2238 203.0.113.1 2239 50000 2240 192.68.0.2 2241 50001 2242 178943 2243 2244 203.0.113.1 2245 2246 2247 16341 2248 2249 2250 203.0.113.2 2251 2252 2253 862 2254 2255 21 2256 21 2257 20 2258 20 2259 2260 2261 2262 2264 2265 2266 2267 2268 true 2269 2270 10.1.1.1 2271 4000 2272 10.1.1.2 2273 5000 2274 1232 2275 2276 203.0.113.1 2277 2278 2279 16341 2280 2281 2282 203.0.113.2 2283 2284 2285 862 2286 2287 2 2288 2 2289 1 2290 1 2291 2292 2293 203.0.113.1 2294 4001 2295 192.68.0.2 2296 5001 2297 178943 2298 2299 203.0.113.1 2300 2301 2302 16341 2303 2304 2305 203.0.113.2 2306 2307 2308 862 2309 2310 21 2311 21 2312 20 2313 20 2314 2315 2316 2318 2320 7. Security Considerations 2322 The YANG module defined in Section 5 is designed to be accessed, 2323 among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF 2324 use a secure transport layer like SSH that is mandatory to implement. 2325 The NETCONF Access Control Module (NACM) [RFC6536] provides the means 2326 to restrict access for particular users to a pre-configured set of 2327 NETCONF protocol operations and attributes. 2329 There are a number of nodes defined in this YANG module which are 2330 writeable. These data nodes may be considered sensitive and 2331 vulnerable to attacks in some network environments. Ability to write 2332 into these nodes without proper protection can have a negative effect 2333 on the devices that support this feature. 2335 Examples of nodes that are particularly vulnerable include several 2336 timeout values put in the protocol to protect against sessions that 2337 are not active but are consuming resources. 2339 8. IANA Considerations 2341 This document registers a URI in the IETF XML registry [RFC3688]. 2342 Following the format in [RFC3688], the following registration is 2343 requested to be made. 2345 URI: urn:ietf:params:xml:ns:yang:ietf-twamp 2347 Registrant Contact: The IPPM WG of the IETF. 2349 XML: N/A, the requested URI is an XML namespace. 2351 This document registers a YANG module in the YANG Module Names 2352 registry [RFC6020]. 2354 name: ietf-twamp 2356 namespace: urn:ietf:params:xml:ns:yang:ietf-twamp 2358 prefix: twamp 2360 reference: RFC XXXX 2362 9. Acknowledgements 2364 We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell 2365 and Robert Sherman for their thorough and constructive reviews, 2366 comments and text suggestions. 2368 Haoxing Shen contributed to the definition of the YANG module in 2369 Section 5. 2371 Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG 2372 module and the examples in Appendix A. 2374 Kostas Pentikousis is partially supported by FP7 UNIFY 2375 (http://fp7-unify.eu), a research project partially funded by the 2376 European Community under the Seventh Framework Program (grant 2377 agreement no. 619609). The views expressed here are those of the 2378 authors only. The European Commission is not liable for any use that 2379 may be made of the information in this document. 2381 10. References 2383 10.1. Normative References 2385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2386 Requirement Levels", BCP 14, RFC 2119, 2387 DOI 10.17487/RFC2119, March 1997, 2388 . 2390 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2391 performance measurement with periodic streams", RFC 3432, 2392 DOI 10.17487/RFC3432, November 2002, 2393 . 2395 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2396 DOI 10.17487/RFC3688, January 2004, 2397 . 2399 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2400 Zekauskas, "A One-way Active Measurement Protocol 2401 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 2402 . 2404 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2405 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2406 RFC 5357, DOI 10.17487/RFC5357, October 2008, 2407 . 2409 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2410 the Network Configuration Protocol (NETCONF)", RFC 6020, 2411 DOI 10.17487/RFC6020, October 2010, 2412 . 2414 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 2415 Protocol (TWAMP) Reflect Octets and Symmetrical Size 2416 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 2417 . 2419 [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, 2420 "IKEv2-Derived Shared Secret Key for the One-Way Active 2421 Measurement Protocol (OWAMP) and Two-Way Active 2422 Measurement Protocol (TWAMP)", RFC 7717, 2423 DOI 10.17487/RFC7717, December 2015, 2424 . 2426 10.2. Informative References 2428 [I-D.ietf-ippm-metric-registry] 2429 Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. 2430 Akhter, "Registry for Performance Metrics", draft-ietf- 2431 ippm-metric-registry-06 (work in progress), March 2016. 2433 [I-D.ietf-netconf-restconf] 2434 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2435 Protocol", draft-ietf-netconf-restconf-15 (work in 2436 progress), July 2016. 2438 [I-D.unify-nfvrg-challenges] 2439 Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino, 2440 D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud 2441 Networks: Problem Statement and Challenges", draft-unify- 2442 nfvrg-challenges-03 (work in progress), January 2016. 2444 [I-D.unify-nfvrg-devops] 2445 Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G., 2446 Papafili, I., Pentikousis, K., and S. Wright, "DevOps for 2447 Software-Defined Telecom Infrastructures", draft-unify- 2448 nfvrg-devops-04 (work in progress), March 2016. 2450 [NSC] John, W., Pentikousis, K., et al., "Research directions in 2451 network service chaining", Proc. SDN for Future Networks 2452 and Services (SDN4FNS), Trento, Italy IEEE, November 2013. 2454 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 2455 Specification Version 2.0", RFC 2898, 2456 DOI 10.17487/RFC2898, September 2000, 2457 . 2459 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2460 "Randomness Requirements for Security", BCP 106, RFC 4086, 2461 DOI 10.17487/RFC4086, June 2005, 2462 . 2464 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 2465 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 2466 DOI 10.17487/RFC5618, August 2009, 2467 . 2469 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 2470 Feature for the Two-Way Active Measurement Protocol 2471 (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, 2472 . 2474 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2475 and A. Bierman, Ed., "Network Configuration Protocol 2476 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2477 . 2479 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2480 Protocol (NETCONF) Access Control Model", RFC 6536, 2481 DOI 10.17487/RFC6536, March 2012, 2482 . 2484 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 2485 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 2486 Defined Networking (SDN): Layers and Architecture 2487 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2488 2015, . 2490 Appendix A. Detailed Data Model Examples 2492 This appendix extends the example presented in Section 6 by 2493 configuring more fields such as authentication parameters, DSCP 2494 values and so on. 2496 A.1. Control-Client 2498 2499 2500 2501 2502 true 2503 2504 0 2505 authenticated 2506 2507 2508 1 2509 unauthenticated 2510 2511 2512 KeyClient1ToRouterA 2513 secret1 2514 2515 2516 KeyForRouterB 2517 secret2 2518 2519 2520 RouterA 2521 203.0.113.1 2522 203.0.113.2 2523 32 2524 KeyClient1ToRouterA 2525 2526 Test1 2527 10.1.1.1 2528 4000 2529 10.1.1.2 2530 5000 2531 64 2532 0 2533 ok 2534 1232 2535 2536 2537 Test2 2538 203.0.113.1 2539 4001 2540 203.0.113.2 2541 5001 2542 128 2543 0 2544 ok 2545 178943 2546 2547 2548 2549 2551 2553 2554 2555 2556 2557 true 2558 2559 0 2560 authenticated 2561 2562 2563 1 2564 unauthenticated 2565 2566 2567 KeyClient1ToRouterA 2568 secret1 2569 2570 2571 KeyForRouterB 2572 secret2 2573 2574 2575 RouterA 2576 2001:DB8:203:0:113::1 2577 2001:DB8:203:0:113::2 2578 32 2579 KeyClient1ToRouterA 2580 2581 Test1 2582 2001:DB8:10:1:1::1 2583 4000 2584 2001:DB8:10:1:1::2 2585 5000 2586 64 2587 0 2588 ok 2589 1232 2590 2591 2592 Test2 2593 2001:DB8:203:0:113::1 2594 4001 2595 2001:DB8:203:0:113::2 2596 5001 2597 128 2598 0 2599 ok 2600 178943 2601 2602 2603 2604 2605 2607 A.2. Server 2609 2610 2611 2612 2613 true 2614 1800 2615 32 2616 authenticated unauthenticated 2617 1024 2618 2619 KeyClient1ToRouterA 2620 secret1 2621 2622 2623 KeyClient10ToRouterA 2624 secret10 2625 2626 2627 203.0.113.1 2628 16341 2629 203.0.113.2 2630 862 2631 2632 active 2633 2634 32 2635 unauthenticated 2636 KeyClient1ToRouterA 2637 1024 2638 2639 2640 2641 2643 2644 2645 2646 2647 true 2648 1800 2649 32 2650 authenticated unauthenticated 2651 1024 2652 2653 KeyClient1ToRouterA 2654 secret1 2655 2656 2657 KeyClient10ToRouterA 2658 secret10 2659 2660 2661 2001:DB8:203:0:113::1 2662 16341 2663 2001:DB8:203:0:113::2 2664 862 2665 2666 active 2667 2668 32 2669 unauthenticated 2670 KeyClient1ToRouterA 2671 1024 2672 2673 2674 2675 2677 A.3. Session-Sender 2678 2679 2680 2681 2682 true 2683 2684 Test1 2685 RouterA 2686 zero 2687 900 2688 1 2689 2690 seconds 2691 2692 setup 2693 2 2694 2 2695 1 2696 1 2697 2698 2699 Test2 2700 2701 RouterA 2702 2703 random 2704 900 2705 1 2706 1 2707 2 2708 seconds 2709 setup 2710 21 2711 21 2712 20 2713 20 2714 2715 2716 2717 2719 A.4. Session-Reflector 2721 2722 2723 2724 2725 2726 true 2727 2728 2729 10.1.1.1 2730 4000 2731 10.1.1.2 2732 5000 2733 1232 2734 2735 203.0.113.1 2736 2737 2738 16341 2739 2740 2741 203.0.113.2 2742 2743 2744 862 2745 2746 32 2747 2 2748 2 2749 1 2750 1 2751 2752 2753 203.0.113.1 2754 4001 2755 192.68.0.2 2756 5001 2757 178943 2758 2759 203.0.113.1 2760 2761 2762 16341 2763 2764 2765 203.0.113.2 2766 2767 2768 862 2769 2770 32 2771 21 2772 21 2773 20 2774 20 2775 2776 2777 2778 2780 2781 2782 2783 2784 true 2785 2786 2001:DB8:10:1:1::1 2787 4000 2788 2001:DB8:10:1:1::2 2789 5000 2790 1232 2791 2792 2001:DB8:203:0:113::1 2793 2794 2795 16341 2796 2797 2798 2001:DB8:203:0:113::2 2799 2800 2801 862 2802 2803 32 2804 2 2805 2 2806 1 2807 1 2808 2809 2810 2001:DB8:203:0:113::1 2811 4001 2812 2001:DB8:192:68::2 2813 5001 2814 178943 2815 2816 2001:DB8:203:0:113::1 2817 2818 2819 16341 2820 2821 2822 2001:DB8:203:0:113::2 2823 2824 2825 862 2826 2827 32 2828 21 2829 21 2830 20 2831 20 2832 2833 2834 2835 2837 Appendix B. TWAMP Operational Commands 2839 TWAMP operational commands could be performed programmatically or 2840 manually, e.g. using a command-line interface (CLI). 2842 With respect to programmability, YANG can be used to define NETCONF 2843 Remote Procedure Calls (RPC), therefore it would be, in principle, 2844 possible to define TWAMP RPC operations for actions such as starting 2845 or stopping control connections or test sessions or groups of 2846 sessions; retrieving results; clearing stored results, and so on. 2848 However, [RFC5357] does not attempt to describe such operational 2849 actions. Refer also to Section 2 and the unlabeled links in 2850 Figure 1. In actual deployments different TWAMP implementations may 2851 support different sets of operational commands, with different 2852 restrictions. Therefore, this document considers it the 2853 responsibility of the individual implementation to define its 2854 corresponding TWAMP operational commands data model. 2856 Authors' Addresses 2858 Ruth Civil 2859 Ciena Corporation 2860 307 Legget Drive 2861 Kanata, ON K2K 3C8 2862 Canada 2864 Email: gcivil@ciena.com 2865 URI: www.ciena.com 2866 Al Morton 2867 AT&T Labs 2868 200 Laurel Avenue South 2869 Middletown,, NJ 07748 2870 USA 2872 Phone: +1 732 420 1571 2873 Fax: +1 732 368 1192 2874 Email: acmorton@att.com 2876 Reshad Rahman 2877 Cisco Systems 2878 2000 Innovation Drive 2879 Kanata, ON K2K 3E8 2880 Canada 2882 Email: rrahman@cisco.com 2884 Mahesh Jethanandani 2885 Cisco Systems 2886 3700 Cisco Way 2887 San Jose, CA 95134 2888 USA 2890 Email: mjethanandani@gmail.com 2892 Kostas Pentikousis (editor) 2893 Travelping 2894 Koernerstr. 7-10 2895 Berlin 10785 2896 Germany 2898 Email: k.pentikousis@travelping.com 2900 Lianshu Zheng 2901 Huawei Technologies 2902 China 2904 Email: vero.zheng@huawei.com