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