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