idnits 2.17.1 draft-vassilev-bmwg-network-interconnect-tester-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 225 has weird spacing: '...-stream uin...' == Line 257 has weird spacing: '...-stream uin...' == Line 301 has weird spacing: '...rw type ide...' == Line 498 has weird spacing: '...The raw frame...' -- The document date (February 16, 2021) is 1163 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6991' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC7224' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'IEEE1588' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'IEEE802.3-2014' is defined on line 1121, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Vassilev 3 Internet-Draft Lightside Instruments AS 4 Intended status: Standards Track February 16, 2021 5 Expires: August 20, 2021 7 A YANG Data Model for Network Interconnect Tester Management 8 draft-vassilev-bmwg-network-interconnect-tester-05 10 Abstract 12 This document introduces new YANG model for use in network 13 interconnect testing containing modules of traffic generator and 14 traffic analyzer. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 20, 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1.1. Definitions and Acronyms . . . . . . . . . . . . . . 2 53 1.1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 55 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.4. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Using the network interconnect tester model . . . . . . . . . 5 58 3. Traffic Generator Module Tree Diagram . . . . . . . . . . . . 5 59 4. Traffic Analyzer Module Tree Diagram . . . . . . . . . . . . 6 60 5. Traffic Generator Module YANG . . . . . . . . . . . . . . . . 7 61 6. Traffic Analyzer Module YANG . . . . . . . . . . . . . . . . 15 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 63 7.1. URI Registration . . . . . . . . . . . . . . . . . . . . 22 64 7.2. YANG Module Name Registration . . . . . . . . . . . . . . 22 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 66 8.1. ietf-traffic-generator.yang . . . . . . . . . . . . . . . 23 67 8.2. ietf-traffic-analyzer.yang . . . . . . . . . . . . . . . 23 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 70 9.2. Informative References . . . . . . . . . . . . . . . . . 24 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 24 72 A.1. Basic Test Program . . . . . . . . . . . . . . . . . . . 25 73 A.2. Generating RFC2544 Testframes . . . . . . . . . . . . . . 26 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 76 1. Introduction 78 There is a need for standard mechanism to allow the specification and 79 implementation of the transactions part of network tests. The 80 mechanism should allow the control and monitoring of the data plane 81 traffic in a transactional way. This document defines two YANG 82 modules for test traffic generator and analyzer. 84 The YANG modules in this document conform to the Network Management 85 Datastore Architecture (NMDA) defined in RFC 8342. 87 1.1. Terminology 89 1.1.1. Definitions and Acronyms 91 DUT: Device Under Test 93 TA: Traffic Analyzer 95 TG: Traffic Generator 97 1.1.2. Tree Diagram 99 For a reference to the annotations used in tree diagrams included in 100 this document, please see YANG Tree Diagrams [RFC8340]. 102 1.2. Problem Statement 104 Network interconnect tests require active network elements part of 105 the tested network that generate test traffic and network elements 106 that analyze the test traffic at one or more points of its path. A 107 network interconnect tester is a device that can either generate test 108 traffic, analyze test traffic or both. Here is a figure borrowed 109 from [RFC2544] representing the horseshoe test setup topology 110 consisting of a single tester and a single DUT connected in a network 111 interconnect loop. 113 +------------+ 114 | | 115 +------------| tester |<-------------+ 116 | | | | 117 | +------------+ | 118 | | 119 | +------------+ | 120 | | | | 121 +----------->| DUT |--------------+ 122 | | 123 +------------+ 125 This document attempts to address the problem of defining YANG model 126 of a network interconnect tester that can be used for development of 127 vendor independent network interconnect tests and utilize the 128 advantages of transactional management using standard protocols like 129 NETCONF. 131 1.3. Objectives 133 This section describes some of the design objectives for the model. 134 It should: 136 o provide means to specify the generated traffic as streams of 137 cyclic sequence of bursts with configurable frame size, frame 138 data, interframe gap and interburst gap. 140 o have a mandatory single stream mode and optional multi stream 141 mode. 143 o provide means for configuration of traffic streams with static 144 frame data where frames with identical frame data are sent during 145 the lifetime of the stream. 147 o provide means for configuration of traffic streams with dynamic 148 frame data where frames contain fields with dynamic data like 149 generation time and sequence number. 151 o allow third parties to augment the base module with alternative 152 dynamic fields of frame data extensions. 154 o provide means for realtime synchronization and orchestration of 155 the generated streams. 157 o provide counters for received test traffic frames and octets. 159 o provide latency statistic in the case of test traffic with dynamic 160 frame data that includes timestamp. 162 o provide sequence number errors in the case of test traffic with 163 dynamic frame data that includes sequence number. 165 1.4. Solution 167 The proposed model splits the design into 2 modules - 1) Traffic 168 Generator module (TG), 2) Traffic Analyzer module (TA). The modules 169 are implemented as augmentations of the ietf-interfaces [RFC8343] 170 module adding configuration and state data that models the 171 functionality of a network interconnect tester. The TA and TG 172 modules concept is illustrated with the following diagram of a tester 173 with two interfaces (named e0 and e1) connected in a loop with single 174 DUT: 176 +----------------+ 177 e0.egress | | e1.ingress 178 +------------| TG tester TA |<-------------+ 179 | | | | 180 | +----------------+ | 181 | | 182 | +------------+ | 183 | | | | 184 +------------->| DUT |----------------+ 185 | | 186 +------------+ 188 2. Using the network interconnect tester model 190 Basic example of how the model can be used in transactional network 191 test program to control the testers part of a network and report 192 counter statistics and timing measurement data is presented in 193 Appendix A. All example cases present the configuration and state 194 data from a single test trial. The search algorithm logic that 195 operates to control the trial configuration is outside the scope of 196 this document. One of the examples demonstrates the use of the 197 [RFC2544] defined testframe packet. 199 3. Traffic Generator Module Tree Diagram 201 module: ietf-traffic-generator 202 augment /if:interfaces/if:interface: 203 +--rw traffic-generator {egress-direction}? 204 | +--rw (type)? 205 | | +--:(single-stream) 206 | | | +--rw testframe-type? identityref 207 | | | +--rw frame-size uint32 208 | | | +--rw frame-data? string 209 | | | +--rw interframe-gap uint32 210 | | | +--rw interburst-gap? uint32 211 | | | +--rw frames-per-burst? uint32 212 | | | +--rw src-mac-address? yang:mac-address {ethernet}? 213 | | | +--rw dst-mac-address? yang:mac-address {ethernet}? 214 | | | +--rw ether-type? uint16 {ethernet}? 215 | | +--:(multi-stream) 216 | | +--rw streams 217 | | +--rw stream* [id] 218 | | +--rw id uint32 219 | | +--rw testframe-type? identityref 220 | | +--rw frame-size uint32 221 | | +--rw frame-data? string 222 | | +--rw interframe-gap uint32 223 | | +--rw interburst-gap? uint32 224 | | +--rw frames-per-burst? uint32 225 | | +--rw frames-per-stream uint32 226 | | +--rw interstream-gap uint32 227 | | +--rw src-mac-address? 228 | | | yang:mac-address {ethernet}? 229 | | +--rw dst-mac-address? 230 | | | yang:mac-address {ethernet}? 231 | | +--rw ether-type? uint16 {ethernet}? 232 | +--rw realtime-epoch? 233 | | yang:date-and-time {realtime-epoch}? 234 | +--rw total-frames? uint64 235 +--rw traffic-generator-ingress {ingress-direction}? 236 +--rw (type)? 237 | +--:(single-stream) 238 | | +--rw testframe-type? identityref 239 | | +--rw frame-size uint32 240 | | +--rw frame-data? string 241 | | +--rw interframe-gap uint32 242 | | +--rw interburst-gap? uint32 243 | | +--rw frames-per-burst? uint32 244 | | +--rw src-mac-address? yang:mac-address {ethernet}? 245 | | +--rw dst-mac-address? yang:mac-address {ethernet}? 246 | | +--rw ether-type? uint16 {ethernet}? 247 | +--:(multi-stream) 248 | +--rw streams 249 | +--rw stream* [id] 250 | +--rw id uint32 251 | +--rw testframe-type? identityref 252 | +--rw frame-size uint32 253 | +--rw frame-data? string 254 | +--rw interframe-gap uint32 255 | +--rw interburst-gap? uint32 256 | +--rw frames-per-burst? uint32 257 | +--rw frames-per-stream uint32 258 | +--rw interstream-gap uint32 259 | +--rw src-mac-address? 260 | | yang:mac-address {ethernet}? 261 | +--rw dst-mac-address? 262 | | yang:mac-address {ethernet}? 263 | +--rw ether-type? 264 | uint16 {ethernet}? 265 +--rw realtime-epoch? 266 | yang:date-and-time {realtime-epoch}? 267 +--rw total-frames? uint64 269 4. Traffic Analyzer Module Tree Diagram 271 module: ietf-traffic-analyzer 272 augment /if:interfaces/if:interface: 273 +--rw traffic-analyzer! {ingress-direction}? 274 | +--rw filter! {filter}? 275 | | +--rw type identityref 276 | | +--rw ether-type? uint16 277 | +--ro state 278 | +--ro pkts? yang:counter64 279 | +--ro octets? yang:counter64 280 | +--ro idle-octets? yang:counter64 {idle-octets-counter}? 281 | +--ro errors? yang:counter64 282 | +--ro testframe-stats 283 | | +--ro testframe-pkts? yang:counter64 284 | | +--ro sequence-errors? yang:counter64 285 | | +--ro payload-errors? yang:counter64 286 | | +--ro latency 287 | | +--ro samples? uint64 288 | | +--ro min? uint64 289 | | +--ro max? uint64 290 | | +--ro average? uint64 291 | | +--ro latest? uint64 292 | +--ro capture {capture}? 293 | +--ro frame* [sequence-number] 294 | +--ro sequence-number uint64 295 | +--ro timestamp? yang:date-and-time 296 | +--ro length? uint32 297 | +--ro preceding-interframe-gap? uint32 298 | +--ro data? string 299 +--rw traffic-analyzer-egress! {egress-direction}? 300 +--rw filter! {filter}? 301 | +--rw type identityref 302 +--ro state 303 +--ro pkts? yang:counter64 304 +--ro octets? yang:counter64 305 +--ro idle-octets? yang:counter64 {idle-octets-counter}? 306 +--ro errors? yang:counter64 307 +--ro testframe-stats 308 | +--ro testframe-pkts? yang:counter64 309 | +--ro sequence-errors? yang:counter64 310 | +--ro payload-errors? yang:counter64 311 | +--ro latency 312 | +--ro samples? uint64 313 | +--ro min? uint64 314 | +--ro max? uint64 315 | +--ro average? uint64 316 | +--ro latest? uint64 317 +--ro capture {capture}? 318 +--ro frame* [sequence-number] 319 +--ro sequence-number uint64 320 +--ro timestamp? yang:date-and-time 321 +--ro length? uint32 322 +--ro preceding-interframe-gap? uint32 323 +--ro data? string 325 5. Traffic Generator Module YANG 327 file "ietf-traffic-generator@2021-02-16.yang" 329 module ietf-traffic-generator { 330 yang-version 1.1; 331 namespace "urn:ietf:params:xml:ns:yang:ietf-traffic-generator"; 332 prefix tg; 334 import ietf-interfaces { 335 prefix if; 336 reference 337 "RFC 8343: A YANG Data Model For Interface Management"; 338 } 339 import ietf-yang-types { 340 prefix yang; 341 reference 342 "RFC 6991: Common YANG Data Types"; 343 } 344 import iana-if-type { 345 prefix ianaift; 346 reference 347 "RFC 7224: IANA Interface Type YANG Module"; 348 } 350 organization 351 "IETF Benchmarking Methodology Working Group"; 352 contact 353 "WG Web: 354 WG List: 356 Editor: Vladimir Vassilev 357 "; 358 description 359 "This module contains a collection of YANG definitions for 360 description and management of network interconnect testers. 362 Copyright (c) 2021 IETF Trust and the persons identified as 363 authors of the code. All rights reserved. 365 Redistribution and use in source and binary forms, with or 366 without modification, is permitted pursuant to, and subject 367 to the license terms contained in, the Simplified BSD License 368 set forth in Section 4.c of the IETF Trust's Legal Provisions 369 Relating to IETF Documents 370 (http://trustee.ietf.org/license-info). 371 This version of this YANG module is part of RFC XXXX; see 372 the RFC itself for full legal notices."; 374 revision 2021-02-16 { 375 description 376 "Initial revision."; 377 reference 378 "RFC XXXX: A YANG Data Model for 379 Network Interconnect Tester Management"; 381 } 383 feature egress-direction { 384 description 385 "The device can generate traffic in the egress direction."; 386 } 388 feature ingress-direction { 389 description 390 "The device can generate traffic in the ingress direction."; 391 } 393 feature multi-stream { 394 description 395 "The device can generate multi-stream traffic."; 396 } 398 feature ethernet { 399 description 400 "The device can generate ethernet traffic."; 401 } 403 feature realtime-epoch { 404 description 405 "The device can generate traffic precisely 406 at configured realtime epoch."; 407 } 409 identity testframe-type { 410 description 411 "Base identity for all testframe types."; 412 } 414 identity static { 415 base testframe-type; 416 description 417 "Identity for static testframe. 418 The frame data and size are constant."; 419 } 421 identity dynamic { 422 base testframe-type; 423 description 424 "Identity to be used as base for dynamic 425 testframe type identities defined 426 in external modules. 428 When used itself it identifies dynamic testframe 429 where the last 18 octets of the payload contain 430 incrementing sequence number field (8 octets) 431 followed by timestamp field in the 432 IEEE 1588-2008 format (10 octets). If frame data is defined 433 for the last 18 octets of the payload it will be ignored 434 and overwritten with dynamic data according to this 435 specification."; 436 } 438 grouping common-data { 439 description 440 "Common configuration data."; 441 leaf realtime-epoch { 442 if-feature "realtime-epoch"; 443 type yang:date-and-time; 444 description 445 "If this leaf is present the stream generation will start 446 at the specified realtime epoch."; 447 } 448 leaf total-frames { 449 type uint64; 450 description 451 "If this leaf is present the traffic generation will stop 452 after the specified number of frames are generated."; 453 } 454 } 456 grouping burst-data { 457 description 458 "Generated traffic burst parameters."; 459 leaf testframe-type { 460 type identityref { 461 base tg:testframe-type; 462 } 463 default "tg:static"; 464 description 465 "In case of dynamic testframes this leaf specifies 466 the dynamic testframe identity."; 467 } 468 leaf frame-size { 469 type uint32; 470 mandatory true; 471 description 472 "Size of the frames generated. For example for 473 ethernet interfaces the following definition 474 applies: 476 Ethernet frame-size in octets includes: 478 * Destination Address (6 octets), 479 * Source Address (6 octets), 480 * Frame Type (2 octets), 481 * Data (min 46 octets or 42 octets + 4 octets 802.1Q tag), 482 * CRC Checksum (4 octets). 484 Ethernet frame-size does not include: 485 * Preamble (dependent on MAC configuration 486 by default 7 octets), 487 * Start of frame delimiter (1 octet) 489 Minimum standard ethernet frame-size is 64 bytes but 490 generators might support smaller sizes for validation."; 491 } 492 leaf frame-data { 493 type string { 494 pattern '([0-9A-F]{2})*'; 495 } 496 must 'string-length(.)<=(../frame-size*2)'; 497 description 498 "The raw frame data specified as hexadecimal string. 499 The specified data can be shorter then the ../frame-size 500 value specifying only the header or the header and the 501 payload with or without the 4 byte CRC Checksum 502 in the case of a Ethernet frame."; 503 } 504 leaf interframe-gap { 505 type uint32; 506 mandatory true; 507 description 508 "Length of the idle period between generated frames. 509 For example for ethernet interfaces the following 510 definition applies: 512 Ethernet interframe-gap between transmission of frames 513 known as the interframe gap (IFG). A brief recovery time 514 between frames allows devices to prepare for 515 reception of the next frame. The minimum 516 interframe gap is 96 bit times (12 octet times) (the time it 517 takes to transmit 96 bits (12 octets) of raw data on the 518 medium). However the preamble (7 octets) and start of 519 frame delimiter (1 octet) are considered a constant gap that 520 should be included in the interframe-gap. Thus the minimum 521 value for standard ethernet transmission should be considered 522 20 octets."; 523 } 524 leaf interburst-gap { 525 type uint32; 526 description 527 "Similar to the interframe-gap but takes place between 528 any two bursts of the stream."; 529 } 530 leaf frames-per-burst { 531 type uint32; 532 description 533 "Number of frames contained in a burst"; 534 } 535 } 537 grouping multi-stream-data { 538 description 539 "Multi stream traffic generation parameters."; 540 container streams { 541 description 542 "Non-presence container holding the configured stream list."; 543 list stream { 544 key "id"; 545 description 546 "Each stream repeats a burst until frames-per-stream 547 count is reached followed by interstream-gap delay."; 548 leaf id { 549 type uint32; 550 description 551 "Number specifying the order of the stream."; 552 } 553 uses burst-data; 554 leaf frames-per-stream { 555 type uint32; 556 mandatory true; 557 description 558 "The count of frames to be generated before 559 generation of the next stream is started."; 560 } 561 leaf interstream-gap { 562 type uint32; 563 mandatory true; 564 description 565 "Idle period after the last frame of the last burst."; 566 } 567 } 568 } 569 } 571 grouping ethernet-data { 572 description 573 "Ethernet frame data specific parameters."; 575 reference 576 "IEEE 802-2014 Clause 9.2"; 577 leaf src-mac-address { 578 type yang:mac-address; 579 description 580 "Source Address field of the generated Ethernet packet."; 581 } 582 leaf dst-mac-address { 583 type yang:mac-address; 584 description 585 "Destination Address field of the generated Ethernet packet."; 586 } 587 leaf ether-type { 588 type uint16; 589 description 590 "Length/Type field of the generated Ethernet packet."; 591 } 592 } 594 augment "/if:interfaces/if:interface" { 595 description 596 "Traffic generator augmentations of ietf-interfaces."; 597 container traffic-generator { 598 if-feature "egress-direction"; 599 description 600 "Traffic generator for egress direction."; 601 choice type { 602 description 603 "Choice of the type of the data model of the generator. 604 Single or multi stream."; 605 case single-stream { 606 uses burst-data; 607 } 608 case multi-stream { 609 uses multi-stream-data; 610 } 611 } 612 uses common-data; 613 } 614 container traffic-generator-ingress { 615 if-feature "ingress-direction"; 616 description 617 "Traffic generator for ingress direction."; 618 choice type { 619 description 620 "Choice of the type of the data model of the generator. 621 Single or multi stream."; 622 case single-stream { 623 uses burst-data; 624 } 625 case multi-stream { 626 uses multi-stream-data; 627 } 628 } 629 uses common-data; 630 } 631 } 633 augment "/if:interfaces/if:interface/tg:traffic-generator/tg:type/" 634 + "tg:single-stream" { 635 when "derived-from-or-self(../if:type, 'ianaift:ethernetCsmacd')" { 636 description 637 "Ethernet interface type."; 638 } 639 if-feature "ethernet"; 640 description 641 "Ethernet specific augmentation for egress 642 single stream generator type."; 643 uses ethernet-data; 644 } 646 augment "/if:interfaces/if:interface/tg:traffic-generator/" 647 + "tg:type/tg:multi-stream/tg:streams/tg:stream" { 648 when "derived-from-or-self(../../../if:type," 649 + "'ianaift:ethernetCsmacd')" { 650 description 651 "Ethernet interface type."; 652 } 653 if-feature "ethernet"; 654 description 655 "Ethernet specific augmentation for egress 656 multi stream generator type."; 657 uses ethernet-data; 658 } 660 augment "/if:interfaces/if:interface/tg:traffic-generator-ingress/" 661 + "tg:type/tg:single-stream" { 662 when "derived-from-or-self(../if:type, 'ianaift:ethernetCsmacd')" { 663 description 664 "Ethernet interface type."; 665 } 666 if-feature "ethernet"; 667 description 668 "Ethernet specific augmentation for ingress 669 single stream generator type."; 670 uses ethernet-data; 672 } 674 augment "/if:interfaces/if:interface/tg:traffic-generator-ingress/" 675 + "tg:type/tg:multi-stream/tg:streams/tg:stream" { 676 when "derived-from-or-self(../../../if:type," 677 + "'ianaift:ethernetCsmacd')" { 678 description 679 "Ethernet interface type."; 680 } 681 if-feature "ethernet"; 682 description 683 "Ethernet specific augmentation for ingress 684 multi stream generator type."; 685 uses ethernet-data; 686 } 687 } 689 691 6. Traffic Analyzer Module YANG 693 file "ietf-traffic-analyzer@2021-02-16.yang" 695 module ietf-traffic-analyzer { 696 yang-version 1.1; 697 namespace "urn:ietf:params:xml:ns:yang:ietf-traffic-analyzer"; 698 prefix ta; 700 import ietf-interfaces { 701 prefix if; 702 reference 703 "RFC 8343: A YANG Data Model For Interface Management"; 704 } 705 import ietf-yang-types { 706 prefix yang; 707 reference 708 "RFC 6991: Common YANG Data Types"; 709 } 711 organization 712 "IETF Benchmarking Methodology Working Group"; 713 contact 714 "WG Web: 715 WG List: 717 Editor: Vladimir Vassilev 718 "; 719 description 720 "This module contains a collection of YANG definitions for 721 description and management of network interconnect testers. 723 Copyright (c) 2021 IETF Trust and the persons identified as 724 authors of the code. All rights reserved. 726 Redistribution and use in source and binary forms, with or 727 without modification, is permitted pursuant to, and subject 728 to the license terms contained in, the Simplified BSD License 729 set forth in Section 4.c of the IETF Trust's Legal Provisions 730 Relating to IETF Documents 731 (http://trustee.ietf.org/license-info). 733 This version of this YANG module is part of RFC XXXX; see 734 the RFC itself for full legal notices."; 736 revision 2021-02-16 { 737 description 738 "Initial revision."; 739 reference 740 "RFC XXXX: A YANG Data Model for 741 Network Interconnect Tester Management"; 742 } 744 feature egress-direction { 745 description 746 "The device can analyze traffic from the egress direction."; 747 } 749 feature ingress-direction { 750 description 751 "The device can generate traffic from the ingress direction."; 752 } 754 feature filter { 755 description 756 "This feature indicates that the device implements 757 filter that can specify a subset of packets to be 758 analyzed when filtering is enabled."; 759 } 761 feature idle-octets-counter { 762 description 763 "This feature indicates that the device implements 764 idle-octets counter that accumulates the time 765 the link is not utilized. The minimum required 766 idle gaps are not counted as idle octets."; 767 } 768 feature capture { 769 description 770 "This feature indicates that the device implements 771 packet capture functionality."; 772 } 774 identity filter { 775 description 776 "Base filter identity."; 777 } 779 identity ethernet { 780 base ta:filter; 781 description 782 "Ethernet packet fields filter."; 783 } 785 grouping statistics-data { 786 description 787 "Analyzer statistics."; 788 leaf pkts { 789 type yang:counter64; 790 description 791 "Total number of packets analyzed."; 792 } 793 leaf octets { 794 type yang:counter64; 795 description 796 "This counter is identical with the in-octets/out-octets 797 counters defined in RFC8343 except that it counts the 798 octets since the analyzer was created."; 799 } 800 leaf idle-octets { 801 if-feature "idle-octets-counter"; 802 type yang:counter64; 803 description 804 "Total accumulated period with no frame transmission 805 taking place measured in octets at the current link 806 speed. Octets not counted in ../octets but not idle are 807 for example layer 1 framing octets - for Ethernet links 808 7+1 preamble octets per packet."; 809 } 810 leaf errors { 811 type yang:counter64; 812 description 813 "Count of packets with errors. 814 Not counted in the pkts or captured. 815 For example packets with CRC error."; 817 } 818 container testframe-stats { 819 description 820 "Statistics for testframe packets containing 821 either sequence number, payload checksum, 822 timestamp or any combination of these features."; 823 leaf testframe-pkts { 824 type yang:counter64; 825 description 826 "Total count of detected testframe packets."; 827 } 828 leaf sequence-errors { 829 type yang:counter64; 830 description 831 "Total count of testframe packets with 832 unexpected sequence number. After each sequence 833 error the expected next sequence number is 834 updated."; 835 } 836 leaf payload-errors { 837 type yang:counter64; 838 description 839 "Total count of testframe packets with 840 payload errors."; 841 } 842 container latency { 843 description 844 "Latency statistics."; 845 leaf samples { 846 type uint64; 847 description 848 "Total count of packets used for estimating 849 the latency statistics. Ideally 850 samples=../testframe-stats."; 851 } 852 leaf min { 853 type uint64; 854 units "nanoseconds"; 855 description 856 "Minimum measured latency."; 857 } 858 leaf max { 859 type uint64; 860 units "nanoseconds"; 861 description 862 "Maximum measured latency."; 863 } 864 leaf average { 865 type uint64; 866 units "nanoseconds"; 867 description 868 "The sum of all sampled latencies divided 869 by the number of samples."; 870 } 871 leaf latest { 872 type uint64; 873 units "nanoseconds"; 874 description 875 "Latency of the latest sample."; 876 } 877 } 878 } 879 } 881 grouping capture-data { 882 description 883 "Grouping with statistics and data 884 of one or more captured frame."; 885 container capture { 886 if-feature "capture"; 887 description 888 "Statistics and data of 889 one or more captured frames."; 890 list frame { 891 key "sequence-number"; 892 description 893 "Statistics and data of a captured frame."; 894 leaf sequence-number { 895 type uint64; 896 description 897 "Incremental counter of frames captured."; 898 } 899 leaf timestamp { 900 type yang:date-and-time; 901 description 902 "Timestamp of the moment the frame was captured."; 903 } 904 leaf length { 905 type uint32; 906 description 907 "Frame length. Ideally the data captured will be 908 of the same length but can be shorter 909 depending on implementation limitations."; 910 } 911 leaf preceding-interframe-gap { 912 type uint32; 913 units "nanoseconds"; 914 description 915 "Measured delay between the reception of the previous 916 frame was completed and the reception of the current 917 frame was started."; 918 } 919 leaf data { 920 type string { 921 pattern '([0-9A-F]{2})*'; 922 } 923 description 924 "Raw data of the captured frame."; 925 } 926 } 927 } 928 } 930 grouping filter-data { 931 description 932 "Grouping with a filter container specifying the filtering 933 rules for processing only a specific subset of the 934 frames."; 935 container filter { 936 if-feature "filter"; 937 presence "When present packets are 938 filtered before analyzed according 939 to the filter type"; 940 description 941 "Contains the filtering rules for processing only 942 a specific subset of the frames."; 943 leaf type { 944 type identityref { 945 base ta:filter; 946 } 947 mandatory true; 948 description 949 "Type of the applied filter. External modules can 950 define alternative filter type identities."; 951 } 952 } 953 } 955 augment "/if:interfaces/if:interface" { 956 description 957 "Traffic analyzer augmentations of ietf-interfaces."; 958 container traffic-analyzer { 959 if-feature "ingress-direction"; 960 presence "Enables the traffic analyzer for ingress traffic."; 961 description 962 "Traffic analyzer for ingress direction."; 963 uses filter-data; 964 container state { 965 config false; 966 description 967 "State data."; 968 uses statistics-data; 969 uses capture-data; 970 } 971 } 972 container traffic-analyzer-egress { 973 if-feature "egress-direction"; 974 presence "Enables the traffic analyzer for egress traffic."; 975 description 976 "Traffic analyzer for egress direction."; 977 uses filter-data; 978 container state { 979 config false; 980 description 981 "State data."; 982 uses statistics-data; 983 uses capture-data; 984 } 985 } 986 } 988 augment "/if:interfaces/if:interface/ta:traffic-analyzer/ta:filter" { 989 when "derived-from-or-self(ta:type, 'ta:ethernet')"; 990 description 991 "Ethernet frame specific filter type."; 992 leaf ether-type { 993 type uint16; 994 description 995 "The Ethernet Type (or Length) value 996 defined by IEEE 802."; 997 reference 998 "IEEE 802-2014 Clause 9.2"; 999 } 1000 } 1001 } 1003 1005 7. IANA Considerations 1007 This document registers two URIs and two YANG modules. 1009 7.1. URI Registration 1011 This document registers two URIs in the IETF XML registry [RFC3688]. 1012 Following the format in RFC 3688, the following registration is 1013 requested to be made: 1015 URI: urn:ietf:params:xml:ns:yang:ietf-traffic-generator 1016 URI: urn:ietf:params:xml:ns:yang:ietf-traffic-analyzer 1018 Registrant Contact: The IESG. 1020 XML: N/A, the requested URI is an XML namespace. 1022 7.2. YANG Module Name Registration 1024 This document registers two YANG module in the YANG Module Names 1025 registry YANG [RFC6020]. 1027 name: ietf-traffic-generator 1028 namespace: urn:ietf:params:xml:ns:yang:ietf-traffic-generator 1029 prefix: tg 1030 reference: RFC XXXX 1032 name: ietf-traffic-analyzer 1033 namespace: urn:ietf:params:xml:ns:yang:ietf-traffic-analyzer 1034 prefix: ta 1035 reference: RFC XXXX 1037 8. Security Considerations 1039 The YANG modules defined in this document are designed to be accessed 1040 via the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF 1041 layer is the secure transport layer and the mandatory to implement 1042 secure transport is SSH RFC 6242 [RFC6242]. The NETCONF access 1043 control model RFC 6536 [RFC6536] provides the means to restrict 1044 access for particular NETCONF users to a pre-configured subset of all 1045 available NETCONF protocol operations and content. 1047 There are a number of data nodes defined in this YANG module which 1048 are writable/creatable/deletable (i.e. config true, which is the 1049 default). These data nodes may be considered sensitive or vulnerable 1050 in some network environments. Write operations (e.g. edit-config) to 1051 these data nodes without proper protection can have a negative effect 1052 on network operations. These are the subtrees and data nodes and 1053 their sensitivity/vulnerability: 1055 8.1. ietf-traffic-generator.yang 1057 The ietf-traffic-generator YANG module controls a stateless traffic 1058 generator which is intended to be used for testing and verification 1059 purposes but can be used for malicious purposes like generating 1060 network traffic part of a Denial-of-Service (DoS) attack. This 1061 should be taken into consideration when granting write access to the 1062 following container and descendant data nodes: 1064 o /if:interfaces/if:interface/tg:traffic-generator 1066 8.2. ietf-traffic-analyzer.yang 1068 The ietf-traffic-analyzer YANG module controls a traffic analyzer 1069 which is designed for use in testing and verification but can be used 1070 for reading information contained in packets sent and received on any 1071 of the interfaces on systems that implement the capture feature. 1072 This should be taken into consideration when granting read access to 1073 the following container and descendant data nodes: 1075 o /if:interfaces/if:interface/ta:traffic-analyzer/ta:capture 1077 9. References 1079 9.1. Normative References 1081 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1082 the Network Configuration Protocol (NETCONF)", RFC 6020, 1083 DOI 10.17487/RFC6020, October 2010, 1084 . 1086 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1087 and A. Bierman, Ed., "Network Configuration Protocol 1088 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1089 . 1091 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1092 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1093 . 1095 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1096 Protocol (NETCONF) Access Control Model", RFC 6536, 1097 DOI 10.17487/RFC6536, March 2012, 1098 . 1100 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1101 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1102 . 1104 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1105 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1106 . 1108 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1109 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1110 . 1112 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1113 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1114 . 1116 9.2. Informative References 1118 [IEEE1588] 1119 IEEE, "IEEE 1588-2008", 2008. 1121 [IEEE802.3-2014] 1122 IEEE WG802.3 - Ethernet Working Group, "IEEE 802.3-2014", 1123 2014. 1125 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1126 Network Interconnect Devices", RFC 2544, 1127 DOI 10.17487/RFC2544, March 1999, 1128 . 1130 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1131 DOI 10.17487/RFC3688, January 2004, 1132 . 1134 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1135 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1136 . 1138 Appendix A. Examples 1140 The following topology will be used for the examples in this section: 1142 +-------------+ +------------+ +------------+ 1143 | | e0 e0 | | e1 e0 | | 1144 | tester0 TG|>-------->| dut0 |>------->|TA tester1 | 1145 | | | | | | 1146 +-------------+ +------------+ +------------+ 1148 A.1. Basic Test Program 1150 This pseudo code program orchestrates a network test and shows how 1151 the model can be used: 1153 #Connect to network 1154 net=connect("topology.xml") 1156 # Configure DUTs and enable traffic-analyzers 1157 net.node("dut0").edit( \ 1158 "create /interfaces/interface[name='e0'] -- type=ethernetCsmacd") 1159 net.node("dut0").edit( 1160 "create /interfaces/interface[name='e1'] -- type=ethernetCsmacd") 1161 net.node("dut0").edit( 1162 "create /flows/flow[id='t0'] -- match/in-port=e0 " 1163 "actions/action[order='0']/output-action/out-port=e1") 1165 net.node("tester1").edit( 1166 "create /interfaces/interface[name='e0']/traffic-analyzer") 1167 net.commit() 1169 #Get network state - before 1170 before=net.get() 1172 # Start traffic 1173 net.node("tester0).edit( 1174 "create /interfaces/interface[name='e0']/traffic-generator -- " 1175 "frame-size=64 interframe-gap=20") 1177 net.commit() 1179 time.sleep(60) 1181 # Stop traffic 1182 net.node("tester1").edit("delete /interfaces/interface[name='e0']/" 1183 "traffic-generator") 1184 net.commit() 1186 #Get network state - after 1187 after=net.get() 1189 #Report 1190 sent_pkts=delta("tester0",before,after, 1191 "/interfaces/interface[name='e0']/statistics/out-unicast-pkts") 1193 received_pkts=delta("tester1",before,after, 1194 "/interfaces/interface[name='e0']/statistics/in-unicast-pkts") 1196 latency_max=absolute(after, 1197 "/interfaces/interface[name='e0']/traffic-analyzer/state/" 1198 "testframe-stats/latency/max") 1200 #Cleanup 1201 net.node("tester1").edit( 1202 "delete /interfaces/interface/traffic-analyzer") 1203 net.node("dut0").edit("delete /flows") 1204 net.node("dut0").edit("delete /interfaces") 1205 net.commit() 1207 A.2. Generating RFC2544 Testframes 1209 In sec. C.2.6.4 Test Frames a detailed format is specified. The 1210 frame-data leaf allows full control over the generated frames 1211 payload. 1213 ... 1214 net.node("tester1").edit( 1215 "merge /interfaces/interface[name='e0']/" 1216 "traffic-generator -- frame-data=" 1217 "6CA96F0000026CA96F00000108004500" 1218 "002ED4A500000A115816C0000201C000" 1219 "0202C0200007001A0000010203040506" 1220 "0708090A0B0C0D0E0F101112") 1221 ... 1223 Author's Address 1225 Vladimir Vassilev 1226 Lightside Instruments AS 1228 Email: vladimir@lightside-instruments.com