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