idnits 2.17.1 draft-ietf-ippm-twamp-yang-04.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 684 has weird spacing: '...m-index uin...' -- The document date (August 22, 2017) is 2438 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: February 23, 2018 AT&T Labs 6 R. Rahman 7 M. Jethanandani 8 Cisco Systems 9 K. Pentikousis, Ed. 10 Travelping 11 August 22, 2017 13 Two-Way Active Measurement Protocol (TWAMP) Data Model 14 draft-ietf-ippm-twamp-yang-04 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 http://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 February 23, 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 48 79 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 49 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 54 86 11.2. Informative References . . . . . . . . . . . . . . . . . 55 87 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 56 88 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 56 89 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 58 90 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 60 91 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 61 92 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 63 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 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 [I-D.ietf-netconf-restconf]. 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 binary 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 state? \ 667 control-client-connection-state 668 | +--ro selected-mode? twamp-modes 669 | +--ro token? binary 670 | +--ro client-iv? binary 671 | +--rw test-session-request* [name] 672 | +--rw name string 673 | +--rw sender-ip? inet:ip-address 674 | +--rw sender-udp-port? union 675 | +--rw reflector-ip inet:ip-address 676 | +--rw reflector-udp-port? dynamic-port-number 677 | +--rw timeout? uint64 678 | +--rw padding-length? uint32 679 | +--rw test-packet-dscp? inet:dscp 680 | +--rw start-time? uint64 681 | +--rw repeat? union 682 | +--rw repeat-interval? uint32 683 | +--rw pm-reg-list* [pm-index] 684 | | +--rw pm-index uint16 685 | +--ro state? test-session-state 686 | +--ro sid? string 687 +--rw server! {server}? 688 | +--rw admin-state boolean 689 | +--rw server-tcp-port? inet:port-number 690 | +--rw servwait? uint32 691 | +--rw control-packet-dscp? inet:dscp 692 | +--rw count? uint8 693 | +--rw max-count? uint8 694 | +--rw modes? twamp-modes 695 | +--rw key-chain* [key-id] 696 | | +--rw key-id binary 697 | | +--rw secret-key? binary 698 | +--ro ctrl-connection* \ 699 [client-ip client-tcp-port server-ip server-tcp-port] 700 | +--ro client-ip inet:ip-address 701 | +--ro client-tcp-port inet:port-number 702 | +--ro server-ip inet:ip-address 703 | +--ro server-tcp-port inet:port-number 704 | +--ro state? server-ctrl-connection-state 705 | +--ro control-packet-dscp? inet:dscp 706 | +--ro selected-mode? twamp-modes 707 | +--ro key-id? string 708 | +--ro count? uint8 709 | +--ro max-count? uint8 710 | +--ro salt? binary 711 | +--ro server-iv? binary 712 | +--ro challenge? binary 713 +--rw session-sender! {session-sender}? 714 | +--rw admin-state boolean 715 | +--rw test-session* [name] 716 | +--rw name string 717 | +--ro ctrl-connection-name? string 718 | +--rw fill-mode? padding-fill-mode 719 | +--rw number-of-packets uint32 720 | +--rw (packet-distribution)? 721 | | +--:(periodic) 722 | | | +--rw periodic-interval decimal64 723 | | +--:(poisson) 724 | | +--rw lambda decimal64 725 | | +--rw max-interval? decimal64 726 | +--ro state? sender-session-state 727 | +--ro sent-packets? uint32 728 | +--ro rcv-packets? uint32 729 | +--ro last-sent-seq? uint32 730 | +--ro last-rcv-seq? uint32 731 +--rw session-reflector! {session-reflector}? 732 +--rw admin-state boolean 733 +--rw refwait? uint32 734 +--ro test-session* \ 735 [sender-ip sender-udp-port \ 736 reflector-ip reflector-udp-port] 737 +--ro sid? string 738 +--ro sender-ip inet:ip-address 739 +--ro sender-udp-port \ 740 dynamic-port-number 741 +--ro reflector-ip inet:ip-address 742 +--ro reflector-udp-port \ 743 dynamic-port-number 744 +--ro parent-connection-client-ip? inet:ip-address 745 +--ro parent-connection-client-tcp-port? \ 746 inet:port-number 747 +--ro parent-connection-server-ip? inet:ip-address 748 +--ro parent-connection-server-tcp-port? \ 749 inet:port-number 750 +--ro test-packet-dscp? inet:dscp 751 +--ro sent-packets? uint32 752 +--ro rcv-packets? uint32 753 +--ro last-sent-seq? uint32 754 +--ro last-rcv-seq? uint32 756 Figure 7: YANG Tree Diagram. 758 5.2. YANG Module 760 This section presents the YANG module for the TWAMP data model 761 defined in this document. 763 file "ietf-twamp@2017-02-22.yang" 764 module ietf-twamp { 765 namespace 766 urn:ietf:params:xml:ns:yang:ietf-twamp; 768 prefix 769 ietf-twamp; 771 import ietf-inet-types { 772 prefix inet; 773 } 775 organization 776 "IETF IPPM (IP Performance Metrics) Working Group"; 778 contact 779 draft-ietf-ippm-twamp-yang@tools.ietf.org; 781 description 782 "This YANG module specifies a vendor-independent data 783 model for the Two-Way Active Measurement Protocol (TWAMP). 785 The data model covers four TWAMP logical entities, namely, 786 Control-Client, Server, Session-Sender, and Session-Reflector, 787 as illustrated in the annotated TWAMP logical model (Fig. 1 788 of draft-ietf-ippm-twamp-yang). 790 This YANG module uses features to indicate which of the four 791 logical entities are supported by a TWAMP implementation."; 793 revision 2017-02-22 { 794 description 795 "Revision appearing in draft-ietf-ippm-twamp-yang-03. 797 Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and 798 draft-ietf-ippm-metric-registry"; 800 reference 801 draft-ietf-ippm-twamp-yang; 802 } 804 /* 805 * Typedefs 806 */ 808 typedef twamp-modes { 809 type bits { 810 bit unauthenticated { 811 position 0; 812 description 813 "Unauthenticated mode, in which no encryption or 814 authentication is applied in TWAMP-Control and TWAMP-Test. 815 KeyID, Token, and Client-IV are not used in the 816 Set-Up-Response message. See Section 3.1 of RFC 4656."; 817 reference 818 "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; 819 } 820 bit authenticated { 821 position 1; 822 description 823 "Authenticated mode, in which the Control-Client and Server 824 possess a shared secret thus prohibiting 'theft of service'. 825 As per Section 6 of RFC 4656, in 'authenticated mode, the 826 timestamp is in the clear and is not protected 827 cryptographically in any way, while the rest of the message 828 has the same protection as in encrypted mode. This mode 829 allows one to trade off cryptographic protection against 830 accuracy of timestamps.'"; 831 reference 832 "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; 833 } 834 bit encrypted { 835 position 2; 836 description 837 "Encrypted mode 'makes it impossible to alter 838 timestamps undetectably.' See also Section 4 of RFC 7717 839 and Section 6 of RFC 4656."; 840 reference 841 "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; 842 } 843 bit unauth-test-encrpyt-control { 844 position 3; 845 description 846 "When using the Mixed Security Mode, the TWAMP-Test 847 protocol follows the Unauthenticated mode and the 848 TWAMP-Control protocol the Encrypted mode."; 849 reference 850 "RFC 5618: Mixed Security Mode for the Two-Way Active 851 Measurement Protocol (TWAMP)"; 852 } 853 bit individual-session-control { 854 position 4; 855 description 856 "This mode enables individual test sessions using 857 Session Identifiers."; 858 reference 859 "RFC 5938: Individual Session Control Feature 860 for the Two-Way Active Measurement Protocol (TWAMP)"; 861 } 862 bit reflect-octets { 863 position 5; 864 description 865 "This mode indicates the reflect octets capability."; 866 reference 867 "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) 868 Reflect Octets and Symmetrical Size Features"; 869 } 870 bit symmetrical-size { 871 position 6; 872 description 873 "This mode indicates support for the symmetrical size 874 sender test packet format."; 875 reference 876 "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) 877 Reflect Octets and Symmetrical Size Features"; 878 } 879 bit IKEv2Derived { 880 position 7; 881 description 882 "In this mode the the shared key is derived 883 from an IKEv2 security association (SA)."; 884 reference 885 "RFC 7717: IKEv2-Derived Shared Secret Key for 886 the One-Way Active Measurement Protocol (OWAMP) 887 and Two-Way Active Measurement Protocol (TWAMP)"; 888 } 889 } 890 description 891 "Specifies the configurable TWAMP-Modes supported during a 892 TWAMP-Control Connection setup between a Control-Client 893 and a Server. Section 7 of RFC 7717 summarizes the 894 TWAMP-Modes registry and points to their formal 895 specification."; 896 } 898 typedef control-client-connection-state { 899 type enumeration { 900 enum active { 901 description 902 "Indicates an active TWAMP-Control connection to Server."; 903 } 904 enum idle { 905 description 906 "Indicates an idle TWAMP-Control connection to Server."; 907 } 908 } 909 description 910 "Indicates the Control-Client TWAMP-Control connection state."; 911 } 913 typedef test-session-state { 914 type enumeration { 915 enum accepted { 916 value 0; 917 description 918 "Indicates that accepted TWAMP-Test session request."; 919 } 920 enum failed { 921 value 1; 922 description 923 "Indicates a TWAMP-Test session failure due to 924 some unspecified reason (catch-all)."; 925 } 926 enum internal-error { 927 value 2; 928 description 929 "Indicates a TWAMP-Test session failure due to 930 an internal error."; 931 } 932 enum not-supported { 933 value 3; 934 description 935 "Indicates a TWAMP-Test session failure because 936 some aspect of the TWAMP-Test session request 937 is not supported."; 938 } 939 enum permanent-resource-limit { 940 value 4; 941 description 942 "Indicates a TWAMP-Test session failure due to 943 permanent resource limitations."; 944 } 945 enum temp-resource-limit { 946 value 5; 947 description 948 "Indicates a TWAMP-Test session failure due to 949 temporary resource limitations."; 950 } 951 } 952 description 953 "Indicates the Control-Client TWAMP-Test session state."; 954 } 956 typedef server-ctrl-connection-state { 957 type enumeration { 958 enum active { 959 description 960 "Indicates an active TWAMP-Control connection 961 to the Control-Client."; 962 } 963 enum servwait { 964 description 965 "Indicates that the TWAMP-Control connection to the 966 Control-Client is in SERVWAIT as per the definition of 967 Section 3.1 of RFC 5357."; 968 } 969 } 970 description 971 "Indicates the Server TWAMP-Control connection state."; 972 } 974 typedef sender-session-state { 975 type enumeration { 976 enum active { 977 description 978 "Indicates that the TWAMP-Test session is active."; 979 } 980 enum failure { 981 description 982 "Indicates that the TWAMP-Test session has failed."; 983 } 984 } 985 description 986 "Indicates the Session-Sender TWAMP-Test session state."; 987 } 989 typedef padding-fill-mode { 990 type enumeration { 991 enum zero { 992 description 993 "TWAMP-Test packets are padded with all zeros."; 994 } 995 enum random { 996 description 997 "TWAMP-Test packets are padded with pseudo-random 998 numbers."; 999 } 1000 } 1001 description 1002 "Indicates what type of packet padding is used in the 1003 TWAMP-Test packets."; 1004 } 1006 typedef dynamic-port-number { 1007 type inet:port-number { 1008 range 49152..65535; 1009 } 1010 description "Dynamic range for port numbers."; 1011 } 1013 /* 1014 * Features 1015 */ 1017 feature control-client { 1018 description 1019 "Indicates that the device supports configuration of the 1020 TWAMP Control-Client logical entity."; 1021 } 1023 feature server { 1024 description 1025 "Indicates that the device supports configuration of the 1026 TWAMP Server logical entity."; 1027 } 1029 feature session-sender { 1030 description 1031 "Indicates that the device supports configuration of the 1032 TWAMP Session-Sender logical entity."; 1033 } 1035 feature session-reflector { 1036 description 1037 "Indicates that the device supports configuration of the 1038 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 binary { 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 } 1087 leaf last-sent-seq { 1088 type uint32; 1089 config false; 1090 description "Indicates the last sent sequence number."; 1091 } 1093 leaf last-rcv-seq { 1094 type uint32; 1095 config false; 1096 description "Indicates the last received sequence number."; 1097 } 1098 description "Used for TWAMP-Test maintenance statistics."; 1099 } 1101 grouping count { 1102 leaf count { 1103 type uint8 { 1104 range "10..31"; 1105 } 1106 default 10; 1107 description 1108 "Parameter communicated to the Control-Client as part of the 1109 Server Greeting message and used for deriving a key from a 1110 shared secret as per Section 3.1 of RFC 4656: MUST be a 1111 power of 2 and at least 1024; SHOULD be increased as more 1112 computing power becomes common."; 1113 } 1114 description 1115 "Reusable data structure for count which is used both in the 1116 Server container."; 1117 } 1119 grouping max-count { 1120 leaf max-count { 1121 type uint8 { 1122 range "10..31"; 1123 } 1124 default 15; 1125 description 1126 "This parameter limits the maximum Count value, which MUST 1127 be a power of 2 and at least 1024 as per RFC 5357. It is 1128 configured by providing said power. For example, 1129 configuring 10 here means max count 2^10 = 1024. 1130 The default is 15, meaning 2^15 = 32768. 1132 A TWAMP Server uses this configured value in the 1133 Server-Greeting message sent to the Control-Client. 1135 A TWAMP Control-Client uses this configured value to prevent 1136 denial-of-service (DOS) attacks by closing the control 1137 connection to the Server if it 'receives a Server-Greeting 1138 message with Count greater that its maximum configured value', 1139 as per Section 6 of RFC 5357. 1141 Further, note that according to Section 6 of RFC 5357: 1143 'If an attacking system sets the maximum value in 1144 Count (2**32), then the system under attack would stall 1145 for a significant period of time while it attempts to 1146 generate keys. 1148 TWAMP-compliant systems SHOULD have a configuration 1149 control to limit the maximum count value. The default 1150 max-count value SHOULD be 32768.' 1152 RFC 5357 does not qualify 'significant period' in terms of 1153 time, but it is clear that this depends on the processing 1154 capacity available and operators need to pay attention to 1155 this security consideration."; 1156 } 1157 description 1158 "Reusable data structure for max-count which is used both at 1159 the Control-Client and the Server containers."; 1160 } 1162 /* 1163 * Configuration data nodes 1164 */ 1166 container twamp { 1167 description 1168 "TWAMP logical entity configuration grouping of four models 1169 which correspond to the four TWAMP logical entities 1170 Control-Client, Server, Session-Sender, and Session-Reflector 1171 as illustrated in Fig. 1 of draft-ietf-ippm-twamp-yang."; 1173 container client { 1174 if-feature control-client; 1175 presence "Enables TWAMP Control-Client functionality."; 1176 description 1177 "Configuration of the TWAMP Control-Client logical entity."; 1179 leaf admin-state { 1180 type boolean; 1181 mandatory true; 1182 description 1183 "Indicates whether the device is allowed to operate as a 1184 TWAMP Control-Client."; 1185 } 1187 list mode-preference-chain { 1188 key priority; 1189 unique mode; 1190 leaf priority { 1191 type uint16; 1192 description 1193 "Indicates the Control-Client Mode preference priority 1194 expressed as a 16-bit unsigned integer, where zero is the 1195 highest priority and subsequent values monotonically 1196 increasing."; 1197 } 1198 leaf mode { 1199 type twamp-modes; 1200 description 1201 "The supported TWAMP Mode matching the corresponding 1202 priority."; 1204 } 1205 description 1206 "Indicates the Control-Client preferred order of use of 1207 the supported TWAMP Modes. 1209 Depending on the Modes available in the TWAMP Server 1210 Greeting message (see Fig. 2 of RFC 7717), the 1211 this Control-Client MUST choose the highest priority Mode 1212 from the configured mode-preference-chain list."; 1213 } 1215 uses key-management; 1217 list ctrl-connection { 1218 key name; 1219 description 1220 "List of TWAMP Control-Client control connections. 1221 Each item in the list describes a control connection 1222 that will be initiated by this Control-Client"; 1224 leaf name { 1225 type string; 1226 description 1227 "A unique name used as a key to identify this individual 1228 TWAMP-Control connection on the Control-Client device."; 1229 } 1230 leaf client-ip { 1231 type inet:ip-address; 1232 description 1233 "The IP address of the local Control-Client device, 1234 to be placed in the source IP address field of the 1235 IP header in TWAMP-Control (TCP) packets belonging 1236 to this control connection. If not configured, the 1237 device SHALL choose its own source IP address."; 1238 } 1239 leaf server-ip { 1240 type inet:ip-address; 1241 mandatory true; 1242 description 1243 "The IP address of the remote Server device, which the 1244 TWAMP-Control connection will be initiated to."; 1245 } 1247 leaf server-tcp-port { 1248 type inet:port-number; 1249 default 862; 1250 description 1251 "This parameter defines the TCP port number that is 1252 to be used by this outgoing TWAMP-Control connection. 1253 Typically, this is the well-known TWAMP-Control 1254 port number (862) as per RFC 5357 However, there are known 1255 realizations of TWAMP in the field that were implemented 1256 before this well-known port number was allocated. These 1257 early implementations allowed the port number to be 1258 configured. This parameter is therefore provided for 1259 backward compatibility reasons."; 1260 } 1262 leaf control-packet-dscp { 1263 type inet:dscp; 1264 default 0; 1265 description 1266 "The DSCP value to be placed in the IP header of 1267 TWAMP-Control (TCP) packets generated by this 1268 Control-Client."; 1269 } 1271 leaf key-id { 1272 type string { 1273 length 1..80; 1274 } 1275 description 1276 "Indicates the KeyID value selected for this 1277 TWAMP-Control connection."; 1279 } 1281 uses max-count; 1283 leaf client-tcp-port { 1284 type inet:port-number; 1285 config false; 1286 description 1287 "Indicates the source TCP port number used in the 1288 TWAMP-Control packets belonging to this control 1289 connection."; 1290 } 1292 leaf server-start-time { 1293 type uint64; 1294 config false; 1295 description 1296 "Indicates the Start-Time advertized by the Server in the 1297 Server-Start message (RFC 4656, Section 3.1), 1298 representing the time when the current 1299 instantiation of the Server started operating. 1300 The timestamp format follows RFC 1305 1301 according to Section 4.1.2 of RFC 4656."; 1302 } 1304 leaf state { 1305 type control-client-connection-state; 1306 config false; 1307 description 1308 "Indicates the current state of the TWAMP-Control 1309 connection state."; 1310 } 1312 leaf selected-mode { 1313 type twamp-modes; 1314 config false; 1315 description 1316 "The TWAMP Mode that the Control-Client has chosen for 1317 this control connection as set in the Mode field of the 1318 Set-Up-Response message (RFC 4656, Section 3.1)."; 1319 } 1321 leaf token { 1322 type binary { 1323 length 64; 1324 } 1325 config false; 1326 description 1327 "This parameter holds the 64 octets containing the 1328 concatenation of a 16-octet Challenge, a 16-octet AES 1329 Session-key used for encryption, and a 32-octet 1330 HMAC-SHA1 Session-key used for authentication; see also 1331 the last paragraph of Section 6 in RFC 4656. 1333 If the Mode defined in RFC 7717 is selected (selected-mode), 1334 Token is limited to 16 octets."; 1335 reference 1336 "RFC 4086: Randomness Requirements for Security 1338 RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way 1339 Active Measurement Protocol (OWAMP) and Two-Way Active 1340 Measurement Protocol (TWAMP)"; 1341 } 1343 leaf client-iv { 1344 type binary { 1345 length 16; 1346 } 1347 config false; 1348 description 1349 "Indicates the Control-Client Initialization Vector 1350 (Client-IV), that is generated randomly by the 1351 Control-Client. As per RFC 4656: 1353 Client-IV merely needs to be unique (i.e., it MUST 1354 never be repeated for different sessions using the 1355 same secret key; a simple way to achieve that without 1356 the use of cumbersome state is to generate the 1357 Client-IV values using a cryptographically secure 1358 pseudo-random number source. 1360 If the Mode defined in RFC 7717 is selected (selected-mode), 1361 Client-IV is limited to 12 octets."; 1362 reference 1363 "RFC 4656: A One-way Active Measurement Protocol (OWAMP) 1365 RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way 1366 Active Measurement Protocol (OWAMP) and Two-Way Active 1367 Measurement Protocol (TWAMP)"; } 1369 list test-session-request { 1370 key name; 1371 description 1372 "Information associated with the Control-Client 1373 for this test session"; 1375 leaf name { 1376 type string; 1377 description 1378 "A unique name to be used for identification of 1379 this TWAMP-Test session on the Control-Client."; 1380 } 1382 leaf sender-ip { 1383 type inet:ip-address; 1384 description 1385 "The IP address of the Session-Sender device, 1386 which is to be placed in the source IP address 1387 field of the IP header in TWAMP-Test (UDP) packets 1388 belonging to this test session. This value will be 1389 used to populate the sender address field of the 1390 Request-TW-Session message. 1392 If not configured, the device SHALL choose its own 1393 source IP address."; 1394 } 1396 leaf sender-udp-port { 1397 type union { 1398 type dynamic-port-number; 1399 type enumeration { 1400 enum autoallocate { 1401 description 1402 "Indicates that the Contol-Client will 1403 auto-allocate the TWAMP-Test (UDP) port number 1404 from the dynamic port range."; 1405 } 1406 } 1407 } 1408 default autoallocate; 1409 description 1410 "The UDP port number that is to be used by 1411 the Session-Sender for this TWAMP-Test session. 1412 The number is restricted to the dynamic port range. 1414 By default the Control-Client SHALL auto-allocate a 1415 UDP port number for this TWAMP-Test session. 1417 The configured (or auto-allocated) value is advertized 1418 in the Sender Port field of the Request-TW-session 1419 message (see Section 3.5 of RFC 5357). Note that 1420 in the scenario where a device auto-allocates a UDP 1421 port number for a session, and the repeat parameter 1422 for that session indicates that it should be 1423 repeated, the device is free to auto-allocate a 1424 different UDP port number when it negotiates the 1425 next (repeated) iteration of this session."; 1426 } 1428 leaf reflector-ip { 1429 type inet:ip-address; 1430 mandatory true; 1431 description 1432 "The IP address belonging to the remote 1433 Session-Reflector device to which the TWAMP-Test 1434 session will be initiated. This value will be 1435 used to populate the receiver address field of 1436 the Request-TW-Session message."; 1437 } 1439 leaf reflector-udp-port { 1440 type dynamic-port-number; 1441 description 1442 "This parameter defines the UDP port number that 1443 will be used by the Session-Reflector for 1444 this TWAMP-Test session. The number is restricted 1445 to the dynamic port range and is to be placed in 1446 the Receiver Port field of the Request-TW-Session 1447 message."; 1448 } 1450 leaf timeout { 1451 type uint64; 1452 units seconds; 1453 default 2; 1454 description 1455 "The length of time (in seconds) that the 1456 Session-Reflector should continue to respond to 1457 packets belonging to this TWAMP-Test session after 1458 a Stop-Sessions TWAMP-Control message has been 1459 received (RFC 5357, Section 3.8). 1461 This value will be placed in the Timeout field of 1462 the Request-TW-Session message."; 1463 } 1465 leaf padding-length { 1466 type uint32 { 1467 range 64..4096; 1468 } 1469 description 1470 "The number of padding bytes to be added to the 1471 TWAMP-Test (UDP) packets generated by the 1472 Session-Sender. 1474 This value will be placed in the Padding Length 1475 field of the Request-TW-Session message 1476 (RFC 4656, Section 3.5)."; 1477 } 1479 leaf test-packet-dscp { 1480 type inet:dscp; 1481 default 0; 1482 description 1483 "The DSCP value to be placed in the IP header 1484 of TWAMP-Test packets generated by the 1485 Session-Sender, and in the UDP header of the 1486 TWAMP-Test response packets generated by the 1487 Session-Reflector for this test session. 1489 This value will be placed in the Type-P Descriptor 1490 field of the Request-TW-Session message (RFC 5357)."; 1491 } 1493 leaf start-time { 1494 type uint64; 1495 default 0; 1496 description 1497 "Time when the session is to be started 1498 (but not before the TWAMP Start-Sessions command 1499 is issued; see Section 3.4 of RFC 5357). 1501 The start-time value is placed in the Start Time 1502 field of the Request-TW-Session message. 1504 The timestamp format follows RFC 1305 as per 1505 Section 3.5 of RFC 4656. 1507 The default value of 0 indicates that the session 1508 will be started as soon as the Start-Sessions message 1509 is received."; 1510 } 1512 leaf repeat { 1513 type union { 1514 type uint32 { 1515 range 0..4294967294; 1516 } 1517 type enumeration { 1518 enum forever { 1519 description 1520 "Indicates that the test session SHALL be 1521 repeated *forever* using the information in 1522 repeat-interval parameter, and SHALL NOT 1523 decrement the value."; 1524 } 1525 } 1526 } 1527 default 0; 1528 description 1529 "This value determines if the TWAMP-Test session must 1530 be repeated. When a test session has completed, the 1531 repeat parameter is checked. 1533 The default value of 0 indicates that the session 1534 MUST NOT be repeated. 1536 If the repeat value is 1 through 4,294,967,294 1537 then the test session SHALL be repeated using the 1538 information in repeat-interval parameter, and the 1539 parent TWAMP-Control connection for this test 1540 session is restarted to negotiate a new instance 1541 of this TWAMP-Test session. The implementation 1542 MUST decrement the value of repeat after 1543 determining a repeated session is expected."; 1544 } 1546 leaf repeat-interval { 1547 when "../repeat!='0'" { 1548 description 1549 "This parameter determines the timing of repeated 1550 TWAMP-Test sessions when repeat is more than 0. 1552 When the value of repeat-interval is 0, the 1553 negotiation of a new test session SHALL begin 1554 immediately after the previous test session 1555 completes. Otherwise, the Control-Client will 1556 wait for the number of seconds specified in the 1557 repeat-interval parameter before negotiating the 1558 new instance of this TWAMP-Test session."; 1559 } 1560 type uint32; 1561 units seconds; 1562 default 0; 1563 description "Repeat interval (in seconds)."; 1564 } 1566 list pm-reg-list { 1567 key pm-index; 1568 leaf pm-index { 1569 type uint16; 1570 description 1571 "Numerical index value of a Registered Metric 1572 in the Performance Metric Registry 1573 (see ietf-ippm-metric-registry). Output statistics 1574 are specified in the corresponding Registry entry."; 1575 } 1576 description 1577 "A list of one or more Performance Metric Registry 1578 Index values, which communicate packet stream 1579 characteristics along with one or more metrics 1580 to be measured. 1582 All members of the pm-reg-list MUST have the same 1583 stream characteristics, such that they combine 1584 to specify all metrics that shall be measured on 1585 a single stream."; 1586 reference 1587 "ietf-ippm-metric-registry: 1588 Registry for Performance Metrics"; 1589 } 1590 leaf state { 1591 type test-session-state; 1592 config false; 1593 description 1594 "Indicates the TWAMP-Test session state (accepted or 1595 indication of an error); see Section 3.5 of 1596 RFC 5357."; 1597 } 1598 leaf sid { 1599 type string; 1600 config false; 1601 description 1602 "The SID allocated by the Server for this TWAMP-Test 1603 session, and communicated back to the Control-Client 1604 in the SID field of the Accept-Session message; 1605 see Section 4.3 of RFC 6038."; 1606 } 1607 } 1608 } 1609 } 1611 container server { 1612 if-feature server; 1613 presence "Enables TWAMP Server functionality."; 1614 description "Configuration of the TWAMP Server logical entity."; 1615 leaf admin-state { 1616 type boolean; 1617 mandatory true; 1618 description 1619 "Indicates whether the device is allowed to operate 1620 as a TWAMP Server."; 1621 } 1623 leaf server-tcp-port { 1624 type inet:port-number; 1625 default 862; 1626 description 1627 "This parameter defines the well known TCP port number 1628 that is used by TWAMP-Control. The Server will listen 1629 on this port number for incoming TWAMP-Control 1630 connections. Although this is defined as a fixed value 1631 (862) in RFC 5357, there are several realizations of 1632 TWAMP in the field that were implemented before this 1633 well-known port number was allocated. These early 1634 implementations allowed the port number to be 1635 configured. This parameter is therefore provided for 1636 backward compatibility reasons."; 1637 } 1639 leaf servwait { 1640 type uint32 { 1641 range 1..604800; 1642 } 1643 units seconds; 1644 default 900; 1645 description 1646 "TWAMP-Control (TCP) session timeout, in seconds. 1647 According to Section 3.1 of RFC 5357, 1649 Server MAY discontinue any established control 1650 connection when no packet associated with that 1651 connection has been received within SERVWAIT seconds."; 1652 } 1654 leaf control-packet-dscp { 1655 type inet:dscp; 1656 description 1657 "The DSCP value to be placed in the IP header of 1658 TWAMP-Control (TCP) packets generated by the Server. 1660 Section 3.1 of RFC 5357 specifies that the server 1661 SHOULD use the DSCP value from the Control-Client's 1662 TCP SYN. However, for practical purposes TWAMP will 1663 typically be implemented using a general purpose TCP 1664 stack provided by the underlying operating system, 1665 and such a stack may not provide this information to the 1666 user. Consequently, it is not always possible to 1667 implement the behavior described in RFC 5357 in an 1668 OS-portable version of TWAMP. 1670 The default behavior if this item is not set is to use 1671 the DSCP value from the Control-Client's TCP SYN, 1672 as per Section 3.1 of RFC 5357."; 1673 } 1675 uses count; 1677 uses max-count; 1679 leaf modes { 1680 type twamp-modes; 1681 description 1682 "The bit mask of TWAMP Modes this Server instance 1683 is willing to support; see IANA TWAMP Modes Registry."; 1684 } 1686 uses key-management; 1688 list ctrl-connection { 1689 key "client-ip client-tcp-port server-ip server-tcp-port"; 1690 config false; 1691 description 1692 "List of all incoming TWAMP-Control (TCP) connections."; 1694 leaf client-ip { 1695 type inet:ip-address; 1696 description 1697 "The IP address on the remote Control-Client device, 1698 which is the source IP address used in the 1699 TWAMP-Control (TCP) packets belonging to this control 1700 connection."; 1701 } 1703 leaf client-tcp-port { 1704 type inet:port-number; 1705 description 1706 "The source TCP port number used in the TWAMP-Control 1707 (TCP) packets belonging to this control connection."; 1708 } 1710 leaf server-ip { 1711 type inet:ip-address; 1712 description 1713 "The IP address of the local Server device, which is 1714 the destination IP address used in the 1715 TWAMP-Control (TCP) packets belonging to this control 1716 connection."; 1717 } 1719 leaf server-tcp-port { 1720 type inet:port-number; 1721 description 1722 "The destination TCP port number used in the 1723 TWAMP-Control (TCP) packets belonging to this 1724 control connection. This will usually be the 1725 same value as the server-tcp-port configured 1726 under twamp/server. However, in the event that 1727 the user re-configured server/server-tcp-port 1728 after this control connection was initiated, this 1729 value will indicate the server-tcp-port that is 1730 actually in use for this control connection."; 1731 } 1733 leaf state { 1734 type server-ctrl-connection-state; 1735 description 1736 "Indicates the Server TWAMP-Control connection state."; 1737 } 1739 leaf control-packet-dscp { 1740 type inet:dscp; 1741 description 1742 "The DSCP value used in the IP header of the 1743 TWAMP-Control (TCP) packets sent by the Server 1744 for this control connection. This will usually 1745 be the same value as is configured in the 1746 control-packet-dscp parameter under the twamp/server 1747 container. However, in the event that the user 1748 re-configures server/dscp after this control 1749 connection is already in progress, this read-only 1750 value will show the actual dscp value in use by this 1751 TWAMP-Control connection."; 1752 } 1754 leaf selected-mode { 1755 type twamp-modes; 1756 description 1757 "The Mode that was chosen for this TWAMP-Control 1758 connection as set in the Mode field of the 1759 Set-Up-Response message."; 1760 } 1762 leaf key-id { 1763 type string { 1764 length 1..80; 1765 } 1766 description 1767 "The KeyID value that is in use by this TWAMP-Control 1768 connection as selected by Control-Client."; 1769 } 1771 uses count { 1772 description 1773 "The count value that is in use by this TWAMP-Control 1774 connection. This will usually be the same value 1775 as is configured under twamp/server. However, in the 1776 event that the user re-configured server/count 1777 after this control connection is already in progress, 1778 this read-only value will show the actual count that 1779 is in use for this TWAMP-Control connection."; 1780 } 1782 uses max-count { 1783 description 1784 "This read-only value indicates the actual max-count in use 1785 for this control connection. Usually this would be the 1786 same value as configured under twamp/server."; 1787 } 1789 leaf salt { 1790 type binary { 1791 length 16; 1792 } 1793 description 1794 "A parameter used in deriving a key from a 1795 shared secret as described in Section 3.1 of RFC 4656. 1796 It is communicated to the Control-Client as part of 1797 the Server Greeting message."; 1798 } 1800 leaf server-iv { 1801 type binary { 1802 length 16; 1803 } 1804 description 1805 "The Server Initialization Vector 1806 (IV) generated randomly by the Server."; 1808 } 1810 leaf challenge { 1811 type binary { 1812 length 16; 1813 } 1814 description 1815 "A random sequence of octets generated by the Server. 1816 As described in client/token, Challenge is used 1817 by the Control-Client to prove possession of a 1818 shared secret."; 1819 } 1820 } 1821 } 1823 container session-sender { 1824 if-feature session-sender; 1825 presence "Enables TWAMP Session-Sender functionality."; 1826 description 1827 "Configuration of the TWAMP Session-Sender logical entity"; 1828 leaf admin-state { 1829 type boolean; 1830 mandatory true; 1831 description 1832 "Indicates whether the device is allowed to operate 1833 as a TWAMP Session-Sender."; 1834 } 1836 list test-session{ 1837 key name; 1838 description "List of TWAMP Session-Sender test sessions."; 1840 leaf name { 1841 type string; 1842 description 1843 "A unique name for this TWAMP-Test session to be used 1844 for identifying this test session by the Session-Sender 1845 logical entity."; 1846 } 1848 leaf ctrl-connection-name { 1849 type string; 1850 config false; 1851 description 1852 "The name of the parent TWAMP-Control connection that 1853 is responsible for negotiating this TWAMP-Test session."; 1854 } 1855 leaf fill-mode { 1856 type padding-fill-mode; 1857 default zero; 1858 description 1859 "Indicates whether the padding added to the 1860 TWAMP-Test (UDP) packets will contain pseudo-random 1861 numbers, or whether it should consist of all zeroes, 1862 as per Section 4.2.1 of RFC 5357."; 1863 } 1865 leaf number-of-packets { 1866 type uint32; 1867 mandatory true; 1868 description 1869 "The overall number of TWAMP-Test (UDP) packets to be 1870 transmitted by the Session-Sender for this test session."; 1871 } 1873 choice packet-distribution { 1874 description 1875 "Indicates the distribution to be used for transmitting 1876 the TWAMP-Test (UDP) packets."; 1877 case periodic { 1878 leaf periodic-interval { 1879 type decimal64 { 1880 fraction-digits 5; 1881 } 1882 units seconds; 1883 mandatory true; 1884 description 1885 "Indicates the time to wait (in seconds) between the 1886 first bits of TWAMP-Test (UDP) packet transmissions for 1887 this test session"; 1888 reference 1889 "RFC 3432: Network performance measurement 1890 with periodic streams"; 1891 } 1892 } 1893 case poisson { 1894 leaf lambda { 1895 type decimal64 { 1896 fraction-digits 5; 1897 } 1898 units seconds; 1899 mandatory true; 1900 description 1901 "Indicates the average time interval (in seconds) 1902 between packets in the Poisson distribution. 1904 The packet is calculated using the reciprocal of lambda 1905 and the TWAMP-Test packet size (which depends on the 1906 selected Mode and the packet padding)."; 1907 reference 1908 "RFC 2330: Framework for IP Performance Metrics"; 1909 } 1910 leaf max-interval { 1911 type decimal64 { 1912 fraction-digits 5; 1913 } 1914 units seconds; 1915 description 1916 "Indicates the maximum time (in seconds) 1917 between packet transmissions."; 1918 reference 1919 "RFC 7312: Advanced Stream and Sampling Framework 1920 for IP Performance Metrics (IPPM)"; 1921 } 1922 } 1923 } 1925 leaf state { 1926 type sender-session-state; 1927 config false; 1928 description 1929 "Indicates the Session-Sender test session state."; 1930 } 1932 uses maintenance-statistics; 1933 } 1934 } 1936 container session-reflector { 1937 if-feature session-reflector; 1938 presence "Enables TWAMP Session-Reflector functionality."; 1939 description 1940 "Configuration of the TWAMP Session-Reflector logical entity"; 1942 leaf admin-state { 1943 type boolean; 1944 mandatory true; 1945 description 1946 "Indicates whether the device is allowed to operate 1947 as a TWAMP Session-Reflector."; 1948 } 1950 leaf refwait { 1951 type uint32 { 1952 range 1..604800; 1953 } 1954 units seconds; 1955 default 900; 1956 description 1957 "The Session-Reflector MAY discontinue any session that has 1958 been started when no packet associated with that session has 1959 been received for REFWAIT seconds. As per Section 3.1 of 1960 RFC 5357, this timeout allows a Session-Reflector to free up 1961 resources in case of failure."; 1962 } 1964 list test-session { 1965 key 1966 "sender-ip sender-udp-port 1967 reflector-ip reflector-udp-port"; 1968 config false; 1969 description "TWAMP Session-Reflectortest sessions."; 1971 leaf sid { 1972 type string; 1973 description 1974 "An auto-allocated identifier for this TWAMP-Test 1975 session that is unique within the context of this 1976 Server/Session-Reflector device only. This value 1977 is communicated to the Control-Client that 1978 requested the test session in the SID field of the 1979 Accept-Session message."; 1980 } 1982 leaf sender-ip { 1983 type inet:ip-address; 1984 description 1985 "The IP address on the remote device, which is the 1986 source IP address used in the TWAMP-Test (UDP) packets 1987 belonging to this test session."; 1988 } 1990 leaf sender-udp-port { 1991 type dynamic-port-number; 1992 description 1993 "The source UDP port used in the TWAMP-Test packets 1994 belonging to this test session."; 1995 } 1997 leaf reflector-ip { 1998 type inet:ip-address; 1999 description 2000 "The IP address of the local Session-Reflector 2001 device, which is the destination IP address used 2002 in the TWAMP-Test (UDP) packets belonging to this test 2003 session."; 2004 } 2006 leaf reflector-udp-port { 2007 type dynamic-port-number; 2008 description 2009 "The destination UDP port number used in the 2010 TWAMP-Test (UDP) test packets belonging to this 2011 test session."; 2012 } 2014 leaf parent-connection-client-ip { 2015 type inet:ip-address; 2016 description 2017 "The IP address on the Control-Client device, which 2018 is the source IP address used in the TWAMP-Control 2019 (TCP) packets belonging to the parent control 2020 connection that negotiated this test session."; 2021 } 2023 leaf parent-connection-client-tcp-port { 2024 type inet:port-number; 2025 description 2026 "The source TCP port number used in the TWAMP-Control 2027 (TCP) packets belonging to the parent control connection 2028 that negotiated this test session."; 2029 } 2031 leaf parent-connection-server-ip { 2032 type inet:ip-address; 2033 description 2034 "The IP address of the Server device, which is the 2035 destination IP address used in the TWAMP-Control 2036 (TCP) packets belonging to the parent control 2037 connection that negotiated this test session."; 2038 } 2040 leaf parent-connection-server-tcp-port { 2041 type inet:port-number; 2042 description 2043 "The destination TCP port number used in the TWAMP-Control 2044 (TCP) packets belonging to the parent control connection 2045 that negotiated this test session."; 2046 } 2047 leaf test-packet-dscp { 2048 type inet:dscp; 2049 description 2050 "The DSCP value present in the IP header of 2051 TWAMP-Test (UDP) packets belonging to this session."; 2052 } 2054 uses maintenance-statistics; 2055 } 2056 } 2057 } 2058 } 2060 2062 6. Data Model Examples 2064 This section presents a simple but complete example of configuring 2065 all four entities in Figure 1, based on the YANG module specified in 2066 Section 5. The example is illustrative in nature, but aims to be 2067 self-contained, i.e. were it to be executed in a real TWAMP 2068 implementation it would lead to a correctly configured test session. 2069 For completeness, examples are provided for both IPv4 and IPv6. 2071 A more elaborated example, which also includes authentication 2072 parameters, is provided in Appendix A. 2074 6.1. Control-Client 2076 Figure 8 shows a configuration example for a Control-Client with 2077 client/admin-state enabled. In a real implementation following 2078 Figure 2 this would permit the initiation of TWAMP-Control 2079 connections and TWAMP-Test sessions. 2081 2082 2083 2084 2085 true 2086 2087 2088 2090 Figure 8: XML instance enabling Control-Client operation. 2092 The following example shows a Control-Client with two instances of 2093 client/ctrl-connection, one called "RouterA" and another called 2094 "RouterB". Each TWAMP-Control connection is to a different Server. 2095 The control connection named "RouterA" has two test session requests. 2096 The TWAMP-Control connection named "RouterB" has no TWAMP-Test 2097 session requests. 2099 2100 2101 2102 2103 true 2104 2105 RouterA 2106 203.0.113.1 2107 203.0.113.2 2108 2109 Test1 2110 203.0.113.3 2111 54001 2112 203.0.113.4 2113 50001 2114 0 2115 2116 2117 Test2 2118 203.0.113.1 2119 54001 2120 203.0.113.2 2121 50001 2122 0 2123 2124 2125 2126 RouterB 2127 203.0.113.1 2128 203.0.113.3 2129 2130 2131 2132 2134 2135 2136 2137 2138 true 2139 2140 RouterA 2141 2001:DB8:203:0:113::1 2142 2001:DB8:203:0:113::2 2143 2144 Test1 2145 2001:DB8:203:1:113::3 2146 54000 2147 2001:DB8:203:1:113::4 2148 55000 2149 0 2150 2151 2152 Test2 2153 2001:DB8:203:0:113::1 2154 54001 2155 2001:DB8:203:0:113::2 2156 55001 2157 0 2158 2159 2160 2161 RouterB 2162 2001:DB8:203:0:113::1 2163 2001:DB8:203:0:113::3 2164 2165 2166 2167 2169 6.2. Server 2171 Figure 9 shows a configuration example for a Server with server/ 2172 admin-state enabled, which permits a device following Figure 2 to 2173 respond to TWAMP-Control connections and TWAMP-Test sessions. 2175 2176 2177 2178 2179 true 2180 2181 2182 2184 Figure 9: XML instance enabling Server operation. 2186 The following example presents a Server with the TWAMP-Control 2187 connection corresponding to the control connection name (client/ctrl- 2188 connection/name) "RouterA" presented in Section 6.1. 2190 2191 2192 2193 2194 true 2195 2196 203.0.113.1 2197 16341 2198 203.0.113.2 2199 862 2200 2201 active 2202 2203 2204 2205 2206 2208 2209 2210 2211 2212 true 2213 2214 2001:DB8:203:0:113::1 2215 16341 2216 2001:DB8:203:0:113::2 2217 862 2218 2219 active 2220 2221 2222 2223 2224 2226 6.3. Session-Sender 2228 Figure 10 shows a configuration example for a Session-Sender with 2229 session-sender/admin-state enabled, which permits a device following 2230 Figure 2 to initiate TWAMP-Test sessions. 2232 2233 2234 2235 2236 true 2237 2238 2239 2241 Figure 10: XML instance enabling Session-Sender operation. 2243 The following configuration example shows a Session-Sender with the 2244 two TWAMP-Test sessions presented in Section 6.1. 2246 2247 2248 2249 2250 true 2251 2252 Test1 2253 RouterA 2254 900 2255 1 2256 setup 2257 2258 2259 Test2 2260 2261 RouterA 2262 2263 900 2264 1 2265 2 2266 setup 2267 2268 2269 2270 2272 6.4. Session-Reflector 2274 This configuration example shows a Session-Reflector with session- 2275 reflector/admin-state enabled, which permits a device following 2276 Figure 2 to respond to TWAMP-Test sessions. 2278 2279 2280 2281 2282 true 2283 2284 2285 2287 Figure 11: XML instance enabling Session-Reflector operation. 2289 The following example shows the two Session-Reflector TWAMP-Test 2290 sessions corresponding to the test sessions presented in Section 6.3. 2292 2293 2294 2295 2296 true 2297 2298 203.0.113.3 2299 54000 2300 203.0.113.4 2301 50001 2302 1232 2303 2304 203.0.113.1 2305 2306 2307 16341 2308 2309 2310 203.0.113.2 2311 2312 2313 862 2314 2315 2 2316 2 2317 1 2318 1 2319 2320 2321 203.0.113.1 2322 54001 2323 192.68.0.2 2324 50001 2325 178943 2326 2327 203.0.113.1 2328 2329 2330 16341 2331 2332 2333 203.0.113.2 2334 2335 2336 862 2337 2338 21 2339 21 2340 20 2341 20 2342 2343 2344 2345 2347 2348 2349 2350 2351 true 2352 2353 203.0.113.3 2354 54000 2355 203.0.113.4 2356 54001 2357 1232 2358 2359 203.0.113.1 2360 2361 2362 16341 2363 2364 2365 203.0.113.2 2366 2367 2368 862 2369 2370 2 2371 2 2372 1 2373 1 2375 2376 2377 203.0.113.1 2378 54001 2379 192.68.0.2 2380 55001 2381 178943 2382 2383 203.0.113.1 2384 2385 2386 16341 2387 2388 2389 203.0.113.2 2390 2391 2392 862 2393 2394 21 2395 21 2396 20 2397 20 2398 2399 2400 2401 2403 7. Security Considerations 2405 The YANG module defined in Section 5 is designed to be accessed, 2406 among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF 2407 use a secure transport layer like SSH that is mandatory to implement. 2408 The NETCONF Access Control Module (NACM) [RFC6536] provides the means 2409 to restrict access for particular users to a pre-configured set of 2410 NETCONF protocol operations and attributes. 2412 There are a number of nodes defined in this YANG module which are 2413 writeable. These data nodes may be considered sensitive and 2414 vulnerable to attacks in some network environments. Ability to write 2415 into these nodes without proper protection can have a negative effect 2416 on the devices that support this feature. 2418 Examples of nodes that are particularly vulnerable include several 2419 timeout values put in the protocol to protect against sessions that 2420 are not active but are consuming resources. 2422 8. IANA Considerations 2424 This document registers a URI in the IETF XML registry [RFC3688]. 2425 Following the format in [RFC3688], the following registration is 2426 requested to be made. 2428 URI: urn:ietf:params:xml:ns:yang:ietf-twamp 2430 Registrant Contact: The IPPM WG of the IETF. 2432 XML: N/A, the requested URI is an XML namespace. 2434 This document registers a YANG module in the YANG Module Names 2435 registry [RFC6020]. 2437 name: ietf-twamp 2439 namespace: urn:ietf:params:xml:ns:yang:ietf-twamp 2441 prefix: twamp 2443 reference: RFC XXXX 2445 9. Acknowledgements 2447 We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell, 2448 Robert Sherman, and Marius Georgescu for their thorough and 2449 constructive reviews, comments and text suggestions. 2451 Haoxing Shen contributed to the definition of the YANG module in 2452 Section 5. 2454 Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG 2455 module and the examples in Appendix A. 2457 Kostas Pentikousis was partially supported by FP7 UNIFY 2458 (http://fp7-unify.eu), a research project partially funded by the 2459 European Community under the Seventh Framework Program (grant 2460 agreement no. 619609). The views expressed here are those of the 2461 authors only. The European Commission is not liable for any use that 2462 may be made of the information in this document. 2464 10. Contributors 2466 Lianshu Zheng, Huawei Technologies, China 2468 Email: vero.zheng@huawei.com 2470 11. References 2472 11.1. Normative References 2474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2475 Requirement Levels", BCP 14, RFC 2119, 2476 DOI 10.17487/RFC2119, March 1997, 2477 . 2479 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2480 performance measurement with periodic streams", RFC 3432, 2481 DOI 10.17487/RFC3432, November 2002, . 2484 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2485 DOI 10.17487/RFC3688, January 2004, . 2488 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2489 Zekauskas, "A One-way Active Measurement Protocol 2490 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 2491 . 2493 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2494 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2495 RFC 5357, DOI 10.17487/RFC5357, October 2008, 2496 . 2498 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2499 the Network Configuration Protocol (NETCONF)", RFC 6020, 2500 DOI 10.17487/RFC6020, October 2010, 2501 . 2503 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 2504 Protocol (TWAMP) Reflect Octets and Symmetrical Size 2505 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 2506 . 2508 [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, 2509 "IKEv2-Derived Shared Secret Key for the One-Way Active 2510 Measurement Protocol (OWAMP) and Two-Way Active 2511 Measurement Protocol (TWAMP)", RFC 7717, 2512 DOI 10.17487/RFC7717, December 2015, . 2515 11.2. Informative References 2517 [I-D.ietf-ippm-metric-registry] 2518 Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. 2519 Akhter, "Registry for Performance Metrics", draft-ietf- 2520 ippm-metric-registry-12 (work in progress), June 2017. 2522 [I-D.ietf-netconf-restconf] 2523 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2524 Protocol", draft-ietf-netconf-restconf-18 (work in 2525 progress), October 2016. 2527 [I-D.unify-nfvrg-challenges] 2528 Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino, 2529 D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud 2530 Networks: Problem Statement and Challenges", draft-unify- 2531 nfvrg-challenges-04 (work in progress), July 2016. 2533 [I-D.unify-nfvrg-devops] 2534 Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G., 2535 Pentikousis, K., Wright, S., Lynch, P., and W. John, 2536 "DevOps for Software-Defined Telecom Infrastructures", 2537 draft-unify-nfvrg-devops-06 (work in progress), July 2016. 2539 [NSC] John, W., Pentikousis, K., et al., "Research directions in 2540 network service chaining", Proc. SDN for Future Networks 2541 and Services (SDN4FNS), Trento, Italy IEEE, November 2013. 2543 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 2544 Specification Version 2.0", RFC 2898, 2545 DOI 10.17487/RFC2898, September 2000, . 2548 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2549 "Randomness Requirements for Security", BCP 106, RFC 4086, 2550 DOI 10.17487/RFC4086, June 2005, . 2553 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 2554 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 2555 DOI 10.17487/RFC5618, August 2009, . 2558 [RFC5938] Morton, A. and M. Chiba, "Individual Session Control 2559 Feature for the Two-Way Active Measurement Protocol 2560 (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, 2561 . 2563 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2564 and A. Bierman, Ed., "Network Configuration Protocol 2565 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2566 . 2568 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2569 Protocol (NETCONF) Access Control Model", RFC 6536, 2570 DOI 10.17487/RFC6536, March 2012, . 2573 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 2574 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 2575 Defined Networking (SDN): Layers and Architecture 2576 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2577 2015, . 2579 Appendix A. Detailed Data Model Examples 2581 This appendix extends the example presented in Section 6 by 2582 configuring more fields such as authentication parameters, DSCP 2583 values and so on. 2585 A.1. Control-Client 2587 2588 2589 2590 2591 true 2592 2593 0 2594 authenticated 2595 2596 2597 1 2598 unauthenticated 2599 2600 2601 KeyClient1ToRouterA 2602 secret1 2603 2604 2605 KeyForRouterB 2606 secret2 2607 2608 2609 RouterA 2610 203.0.113.1 2611 203.0.113.2 2612 32 2613 KeyClient1ToRouterA 2614 2615 Test1 2616 203.0.113.3 2617 54000 2618 203.0.113.4 2619 55000 2620 64 2621 0 2622 ok 2623 1232 2624 2625 2626 Test2 2627 203.0.113.1 2628 54001 2629 203.0.113.2 2630 55001 2631 128 2632 0 2633 ok 2634 178943 2635 2636 2637 2638 2639 2641 2642 2643 2644 2645 true 2646 2647 0 2648 authenticated 2649 2650 2651 1 2652 unauthenticated 2653 2654 2655 KeyClient1ToRouterA 2656 secret1 2657 2658 2659 KeyForRouterB 2660 secret2 2661 2662 2663 RouterA 2664 2001:DB8:203:0:113::1 2665 2001:DB8:203:0:113::2 2666 32 2667 KeyClient1ToRouterA 2668 2669 Test1 2670 2001:DB8:10:1:1::1 2671 54000 2672 2001:DB8:10:1:1::2 2673 55000 2674 64 2675 0 2676 ok 2677 1232 2678 2679 2680 Test2 2681 2001:DB8:203:0:113::1 2682 54001 2683 2001:DB8:203:0:113::2 2684 55001 2685 128 2686 0 2687 ok 2688 178943 2689 2690 2691 2692 2693 2695 A.2. Server 2697 2698 2699 2700 2701 true 2702 1800 2703 32 2704 authenticated unauthenticated 2705 1024 2706 2707 KeyClient1ToRouterA 2708 secret1 2709 2710 2711 KeyClient10ToRouterA 2712 secret10 2713 2714 2715 203.0.113.1 2716 16341 2717 203.0.113.2 2718 862 2719 2720 active 2721 2722 32 2723 unauthenticated 2724 KeyClient1ToRouterA 2725 1024 2726 2727 2728 2729 2731 2732 2733 2734 2735 true 2736 1800 2737 32 2738 authenticated unauthenticated 2739 1024 2740 2741 KeyClient1ToRouterA 2742 secret1 2743 2744 2745 KeyClient10ToRouterA 2746 secret10 2747 2748 2749 2001:DB8:203:0:113::1 2750 16341 2751 2001:DB8:203:0:113::2 2752 862 2753 2754 active 2756 2757 32 2758 unauthenticated 2759 KeyClient1ToRouterA 2760 1024 2761 2762 2763 2764 2766 A.3. Session-Sender 2768 2769 2770 2771 2772 true 2773 2774 Test1 2775 RouterA 2776 zero 2777 900 2778 1 2779 setup 2780 2 2781 2 2782 1 2783 1 2784 2785 2786 Test2 2787 2788 RouterA 2789 2790 random 2791 900 2792 1 2793 2 2794 setup 2795 21 2796 21 2797 20 2798 20 2799 2800 2801 2802 2804 A.4. Session-Reflector 2806 2807 2808 2809 2810 2811 true 2812 2813 2814 203.0.113.3 2815 54000 2816 203.0.113.4 2817 55000 2818 1232 2819 2820 203.0.113.1 2821 2822 2823 16341 2824 2825 2826 203.0.113.2 2827 2828 2829 862 2830 2831 32 2832 2 2833 2 2834 1 2835 1 2836 2837 2838 203.0.113.1 2839 54001 2840 192.68.0.2 2841 55001 2842 178943 2843 2844 203.0.113.1 2845 2846 2847 16341 2848 2849 2850 203.0.113.2 2851 2852 2853 862 2854 2855 32 2856 21 2857 21 2858 20 2859 20 2860 2861 2862 2863 2865 2866 2867 2868 2869 true 2870 2871 2001:DB8:10:1:1::1 2872 54000 2873 2001:DB8:10:1:1::2 2874 55000 2875 1232 2876 2877 2001:DB8:203:0:113::1 2878 2879 2880 16341 2881 2882 2883 2001:DB8:203:0:113::2 2884 2885 2886 862 2887 2888 32 2889 2 2890 2 2891 1 2892 1 2893 2894 2895 2001:DB8:203:0:113::1 2896 54001 2897 2001:DB8:192:68::2 2898 55001 2899 178943 2900 2901 2001:DB8:203:0:113::1 2902 2903 2904 16341 2905 2906 2907 2001:DB8:203:0:113::2 2908 2909 2910 862 2911 2912 32 2913 21 2914 21 2915 20 2916 20 2917 2918 2919 2920 2922 Appendix B. TWAMP Operational Commands 2924 TWAMP operational commands could be performed programmatically or 2925 manually, e.g. using a command-line interface (CLI). 2927 With respect to programmability, YANG can be used to define NETCONF 2928 Remote Procedure Calls (RPC), therefore it would be, in principle, 2929 possible to define TWAMP RPC operations for actions such as starting 2930 or stopping control connections or test sessions or groups of 2931 sessions; retrieving results; clearing stored results, and so on. 2933 However, [RFC5357] does not attempt to describe such operational 2934 actions. Refer also to Section 2 and the unlabeled links in 2935 Figure 1. In actual deployments different TWAMP implementations may 2936 support different sets of operational commands, with different 2937 restrictions. Therefore, this document considers it the 2938 responsibility of the individual implementation to define its 2939 corresponding TWAMP operational commands data model. 2941 Authors' Addresses 2942 Ruth Civil 2943 Ciena Corporation 2944 307 Legget Drive 2945 Kanata, ON K2K 3C8 2946 Canada 2948 Email: gcivil@ciena.com 2949 URI: www.ciena.com 2951 Al Morton 2952 AT&T Labs 2953 200 Laurel Avenue South 2954 Middletown,, NJ 07748 2955 USA 2957 Phone: +1 732 420 1571 2958 Fax: +1 732 368 1192 2959 Email: acmorton@att.com 2961 Reshad Rahman 2962 Cisco Systems 2963 2000 Innovation Drive 2964 Kanata, ON K2K 3E8 2965 Canada 2967 Email: rrahman@cisco.com 2969 Mahesh Jethanandani 2970 Cisco Systems 2971 3700 Cisco Way 2972 San Jose, CA 95134 2973 USA 2975 Email: mjethanandani@gmail.com 2977 Kostas Pentikousis (editor) 2978 Travelping 2979 Siemensdamm 50 2980 Berlin 13629 2981 Germany 2983 Email: k.pentikousis@travelping.com