idnits 2.17.1 draft-zheng-ccamp-otn-client-signal-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 : ---------------------------------------------------------------------------- ** There are 49 instances of too long lines in the document, the longest one being 52 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 182 has weird spacing: '...le-name str...' == Line 304 has weird spacing: '...el-name str...' == Line 697 has weird spacing: '...rouping etht-...' == Line 723 has weird spacing: '...rouping etht-...' == Line 749 has weird spacing: '...rouping etht-...' == (3 more instances...) -- The document date (March 5, 2018) is 2237 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 (-17) exists of draft-ietf-ccamp-otn-topo-yang-02 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-01 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft A. Guo 4 Intended status: Standards Track I. Busi 5 Expires: September 6, 2018 Huawei Technologies 6 Y. Xu 7 CAICT 8 Y. Zhao 9 China Mobile 10 X. Liu 11 Jabil 12 G. Fioccola 13 Telecom Italia 14 March 5, 2018 16 A YANG Data Model for Optical Transport Network Client Signals 17 draft-zheng-ccamp-otn-client-signal-yang-02 19 Abstract 21 A transport network is a server-layer network to provide connectivity 22 services to its client. The topology and tunnel information in the 23 transport layer has already been defined by Traffic-engineered models 24 and OTN models, however, the access to the network has not been 25 described. These information is useful to both client and provider. 27 This draft describe how the client signals are carried over OTN and 28 defined corresponding YANG data model which is required during 29 configuration procedure. More specifically, several client signal 30 (of OTN) models including ETH, STM-n, FC and so on, are defined in 31 this draft. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 6, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 69 3. OTN Client Signal Overview . . . . . . . . . . . . . . . . . 4 70 4. YANG Model for OTN Client Signal . . . . . . . . . . . . . . 4 71 4.1. YANG Tree for Ethernet Service . . . . . . . . . . . . . 4 72 4.2. YANG Tree for other OTN Client Signal Model . . . . . . . 7 73 5. YANG Code for OTN Client Signal . . . . . . . . . . . . . . . 7 74 5.1. The ETH Service YANG Code . . . . . . . . . . . . . . . . 7 75 5.2. YANG Code for ETH transport type . . . . . . . . . . . . 19 76 5.3. Other OTN client signal YANG Code . . . . . . . . . . . . 25 77 6. Considerations and Open Issue . . . . . . . . . . . . . . . . 29 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 79 8. Manageability Considerations . . . . . . . . . . . . . . . . 30 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 82 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 85 12.2. Informative References . . . . . . . . . . . . . . . . . 32 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 88 1. Introduction 90 A transport network is a server-layer network designed to provide 91 connectivity services for a client-layer network to carry the client 92 traffic transparently across the server-layer network resources. 93 Currently there has been topology and tunnel model defined for 94 transport network, such as [I-D.ietf-ccamp-otn-topo-yang] and 95 [I-D.ietf-ccamp-otn-tunnel-model], which has described the network 96 model between PEs. However, there is a missing piece between the PE 97 and CE, which is expected to be solved in this document. 99 This document defines a data model of all OTN network client signals, 100 using YANG language defined in [RFC7950]. The model can be used by 101 applications exposing to a transport controller via a REST interface. 102 Furthermore, it can be used by an application for the following 103 purposes (but not limited to): 105 o To request/update an end-to-end service by driving a new OTN 106 tunnel to be set up to support this service; 108 o To request/update an end-to-end service by using an existing OTN 109 tunnel; 111 o To receive notification with regard to the information change of 112 the given service; 114 The YANG model defined in this document is independent of control 115 plane protocols and captures topology related information pertaining 116 to an Optical Transport Networks (OTN)-electrical layer, as the scope 117 specified by [RFC7062] and [RFC7139]. Furthermore, it is not a 118 stand-alone model, but augmenting from the TE topology YANG model 119 defined in [I-D.ietf-teas-yang-te-topo]. 121 2. Terminology and Notations 123 A simplified graphical representation of the data model is used in 124 this document. The meaning of the symbols in the YANG data tree 125 presented later in this document is defined in 126 [I-D.ietf-netmod-yang-tree-diagrams]. They are provided below for 127 reference. 129 o Brackets "[" and "]" enclose list keys. 131 o Abbreviations before data node names: "rw" means configuration 132 (read-write) and "ro" state data (read-only). 134 o Symbols after data node names: "?" means an optional node, "!" 135 means a presence container, and "*" denotes a list and leaf-list. 137 o Parentheses enclose choice and case nodes, and case nodes are also 138 marked with a colon (":"). 140 o Ellipsis ("...") stands for contents of subtrees that are not 141 shown. 143 3. OTN Client Signal Overview 145 The OTN is usually a server-layer network designed to provide 146 connectivity services for a client-layer network to carry the client 147 traffic opaquely across the server-layer network resources. A 148 transport network may be constructed from equipments utilizing any of 149 a number of different transport technologies such as the evolving 150 optical transport infrastructure (SONET/SDH and OTN) or packet 151 transport as epitomized by the MPLS Transport Profile (MPLS-TP). 153 A full list of G-PID was summarized in [RFC7139], which can be 154 divided into a few categories of OTN client signal. The first 155 category of service type is Ethernet related, including GE, WAN/LAN 156 to support EPL/EVPL service. Another category of service type would 157 be client service which includes SDH/SONET, OTN service, SAN storage 158 (FICON, Fiber Channel) and other applications such as video service 159 (HD-SDI, 3G-SDI, etc.). 161 The G-PID signals can also be categorized into transparent and non- 162 transparent. Examples of transparent signals may include Ethernet, 163 ODU, STM-n and so on. In this approach the OTN devices do not is not 164 aware of the client signal type, and this information is only 165 necessary among the controllers. Once OTN tunnel is set up, there is 166 no switching requested on the client layer, and therefore only signal 167 mapping is needed, without a client tunnel set up. The other 168 category would be non-transparent, such as Carrier Ethernet and MPLS- 169 TP, with a switching request on the client layer. Once the OTN 170 tunnel is set up, a corresponding tunnel in the client layer has to 171 be set up to carry services. The models in this draft are applicable 172 for both of the two above categories. 174 4. YANG Model for OTN Client Signal 176 4.1. YANG Tree for Ethernet Service 178 module: ietf-eth-tran-service 179 +--rw etht-svc 180 +--rw globals 181 | +--rw etht-svc-bandwidth-profiles* [bandwidth-profile-name] 182 | +--rw bandwidth-profile-name string 183 | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 184 | +--rw CIR? uint64 185 | +--rw CBS? uint64 186 | +--rw EIR? uint64 187 | +--rw EBS? uint64 188 | +--rw color-aware? boolean 189 | +--rw coupling-flag? boolean 190 +--rw etht-svc-instances* [etht-svc-name] 191 +--rw etht-svc-name string 192 +--rw etht-svc-descr? string 193 +--rw etht-svc-type? etht-types:service-type 194 +--rw access-provider-id? te-types:te-global-id 195 +--rw access-client-id? te-types:te-global-id 196 +--rw access-topology-id? te-types:te-topology-id 197 +--rw etht-svc-access-ports* [access-port-id] 198 | +--rw access-port-id uint16 199 | +--rw access-node-id? te-types:te-node-id 200 | +--rw access-ltp-id? te-types:te-tp-id 201 | +--rw service-classification-type? identityref 202 | +--rw (service-classification)? 203 | | +--:(port-classification) 204 | | +--:(vlan-classification) 205 | | +--rw outer-tag! 206 | | | +--rw tag-type? etht-types:eth-tag-classify 207 | | | +--rw (individual-bundling-vlan)? 208 | | | +--:(individual-vlan) 209 | | | | +--rw vlan-value? etht-types:vlanid 210 | | | +--:(vlan-bundling) 211 | | | +--rw vlan-range? etht-types:vid-range-type 212 | | +--rw second-tag! 213 | | +--rw tag-type? etht-types:eth-tag-classify 214 | | +--rw (individual-bundling-vlan)? 215 | | +--:(individual-vlan) 216 | | | +--rw vlan-value? etht-types:vlanid 217 | | +--:(vlan-bundling) 218 | | +--rw vlan-range? etht-types:vid-range-type 219 | +--rw split-horizon-group? string 220 | +--rw (direction)? 221 | | +--:(symmetrical) 222 | | | +--rw ingress-egress-bandwidth-profile-name? string 223 | | +--:(asymmetrical) 224 | | +--rw ingress-bandwidth-profile-name? string 225 | | +--rw egress-bandwidth-profile-name? string 226 | +--rw vlan-operations 227 | +--rw (direction)? 228 | +--:(symmetrical) 229 | | +--rw symmetrical-operation 230 | | +--rw pop-tags? uint8 231 | | +--rw push-tags 232 | | +--rw outer-tag! 233 | | | +--rw tag-type? etht-types:eth-tag-type 234 | | | +--rw vlan-value? etht-types:vlanid 235 | | +--rw second-tag! 236 | | +--rw tag-type? etht-types:eth-tag-type 237 | | +--rw vlan-value? etht-types:vlanid 238 | +--:(asymmetrical) 239 | +--rw asymmetrical-operation 240 | +--rw ingress 241 | | +--rw pop-tags? uint8 242 | | +--rw push-tags 243 | | +--rw outer-tag! 244 | | | +--rw tag-type? etht-types:eth-tag-type 245 | | | +--rw vlan-value? etht-types:vlanid 246 | | +--rw second-tag! 247 | | +--rw tag-type? etht-types:eth-tag-type 248 | | +--rw vlan-value? etht-types:vlanid 249 | +--rw egress 250 | +--rw pop-tags? uint8 251 | +--rw push-tags 252 | +--rw outer-tag! 253 | | +--rw tag-type? etht-types:eth-tag-type 254 | | +--rw vlan-value? etht-types:vlanid 255 | +--rw second-tag! 256 | +--rw tag-type? etht-types:eth-tag-type 257 | +--rw vlan-value? etht-types:vlanid 258 +--rw etht-svc-tunnels* [tunnel-name] 259 | +--rw tunnel-name string 260 | +--rw (svc-multiplexing-tag)? 261 | | +--:(other) 262 | | +--:(none) 263 | | +--:(vlan-tag) 264 | | +--:(pw) 265 | +--rw src-split-horizon-group? string 266 | +--rw dst-split-horizon-group? string 267 +--rw pm-config 268 | +--rw pm-enable? boolean 269 | +--rw sending-rate-high? uint64 270 | +--rw sending-rate-low? uint64 271 | +--rw receiving-rate-high? uint64 272 | +--rw receiving-rate-low? uint64 273 +--rw admin-status? identityref 274 +--ro state 275 +--ro operational-state? identityref 276 +--ro provisioning-state? identityref 277 +--ro creation-time? yang:date-and-time 278 +--ro last-updated-time? yang:date-and-time 279 +--ro sending-rate-too-high? uint32 280 +--ro sending-rate-too-low? uint32 281 +--ro receiving-rate-too-high? uint32 282 +--ro receiving-rate-too-low? uint32 284 4.2. YANG Tree for other OTN Client Signal Model 286 module: ietf-trans-client-service 287 +--rw client-svc 288 +--rw client-svc-instances* [client-svc-name] 289 +--rw client-svc-name string 290 +--rw client-svc-descr? string 291 +--rw access-provider-id? te-types:te-global-id 292 +--rw access-client-id? te-types:te-global-id 293 +--rw access-topology-id? te-types:te-topology-id 294 +--rw admin-status? identityref 295 +--rw src-access-ports 296 | +--rw access-node-id? te-types:te-node-id 297 | +--rw access-ltp-id? te-types:te-tp-id 298 | +--rw client-signal? identityref 299 +--rw dst-access-ports 300 | +--rw access-node-id? te-types:te-node-id 301 | +--rw access-ltp-id? te-types:te-tp-id 302 | +--rw client-signal? identityref 303 +--rw svc-tunnels* [tunnel-name] 304 | +--rw tunnel-name string 305 +--ro operational-state? identityref 306 +--ro provisioning-state? identityref 308 5. YANG Code for OTN Client Signal 310 5.1. The ETH Service YANG Code 312 file "ietf-eth-tran-service@2018-03-01.yang" 314 module ietf-eth-tran-service { 316 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 318 prefix "ethtsvc"; 320 import ietf-yang-types { 321 prefix "yang"; 322 } 324 import ietf-te-types { 325 prefix "te-types"; 326 } 327 import ietf-eth-tran-types { 328 prefix "etht-types"; 329 } 331 organization 332 "Internet Engineering Task Force (IETF) CCAMP WG"; 333 contact 334 " 335 WG List: 337 ID-draft editor: 338 Haomian Zheng (zhenghaomian@huawei.com); 339 Italo Busi (italo.busi@huawei.com); 340 Aihua Guo (aihuaguo@huawei.com); 341 Yunbin Xu (xuyunbin@ritt.cn); 342 Yang Zhao (zhaoyangyjy@chinamobile.com); 343 Xufeng Liu (Xufeng_Liu@jabil.com); 344 Giuseppe Fioccola (giuseppe.fioccola@telecomitalia.it); 345 "; 347 description 348 "This module defines a YANG data model for describing 349 the Ethernet transport services."; 351 revision 2018-03-01 { 352 description 353 "Initial revision"; 354 reference 355 "draft-zheng-ccamp-otn-client-signal-yang"; 356 } 358 /* 359 Groupings 360 */ 362 grouping vlan-classification { 363 description 364 "A grouping which represents classification on an 802.1Q VLAN tag."; 366 leaf tag-type { 367 type etht-types:eth-tag-classify; 368 description 369 "The tag type used for VLAN classification."; 370 } 371 choice individual-bundling-vlan { 372 description 373 "VLAN based classification can be individual 374 or bundling."; 376 case individual-vlan { 377 leaf vlan-value { 378 type etht-types:vlanid; 379 description 380 "VLAN ID value."; 381 } 382 } 384 case vlan-bundling { 385 leaf vlan-range { 386 type etht-types:vid-range-type; 387 description 388 "List of VLAN ID values."; 389 } 390 } 391 } 392 } 394 grouping vlan-write { 395 description 396 "A grouping which represents push/pop operations 397 of an 802.1Q VLAN tag."; 399 leaf tag-type { 400 type etht-types:eth-tag-type; 401 description 402 "The VLAN tag type to push/swap."; 403 } 404 leaf vlan-value { 405 type etht-types:vlanid; 406 description 407 "The VLAN ID value to push/swap."; 408 } 409 } 411 grouping vlan-operations { 412 description 413 "A grouping which represents VLAN operations."; 415 leaf pop-tags { 416 type uint8 { 417 range "1..2"; 418 } 419 description 420 "The number of VLAN tags to pop (or swap if used in 421 conjunction with push-tags)"; 422 } 423 container push-tags { 424 description 425 "The VLAN tags to push (or swap if used in 426 conjunction with pop-tags)"; 428 container outer-tag { 429 presence 430 "Indicates existence of the outermost VLAN tag to 431 push/swap"; 433 description 434 "The outermost VLAN tag to push/swap."; 436 uses vlan-write; 437 } 438 container second-tag { 439 must 440 '../outer-tag/tag-type = "s-vlan-tag-type" and ' + 441 'tag-type = "c-vlan-tag-type"' 442 { 444 error-message 445 " 446 When pushing/swapping two tags, the outermost tag must 447 be specified and of S-VLAN type and the second 448 outermost tag must be of C-VLAN tag type. 449 "; 450 description 451 " 452 For IEEE 802.1Q interoperability, when pushing/swapping 453 two tags, it is required that the outermost tag exists 454 and is an S-VLAN, and the second outermost tag is a 455 C-VLAN. 456 "; 457 } 459 presence 460 "Indicates existence of a second outermost VLAN tag to 461 push/swap"; 463 description 464 "The second outermost VLAN tag to push/swap."; 466 uses vlan-write; 467 } 468 } 469 } 471 grouping bandwidth-profiles { 472 description 473 "A grouping which represent bandwidth profile configuration."; 475 choice direction { 476 description 477 "Whether the bandwidth profiles are symmetrical or 478 asymmetrical"; 479 case symmetrical { 480 description 481 "The same bandwidth profile is used to describe the ingress 482 and the egress bandwidth profile."; 484 leaf ingress-egress-bandwidth-profile-name { 485 type "string"; 486 description 487 "Name of the bandwidth profile."; 488 } 489 } 490 case asymmetrical { 491 description 492 "Ingress and egress bandwidth profiles can be specified."; 493 leaf ingress-bandwidth-profile-name { 494 type "string"; 495 description 496 "Name of the bandwidth profile used in 497 the ingress direction."; 498 } 499 leaf egress-bandwidth-profile-name { 500 type "string"; 501 description 502 "Name of the bandwidth profile used in 503 the egress direction."; 504 } 505 } 506 } 507 } 509 grouping etht-svc-access-parameters { 510 description 511 "ETH transport services access parameters"; 513 leaf access-node-id { 514 type te-types:te-node-id; 515 description 516 "The identifier of the access node in 517 the ETH transport topology."; 518 } 519 leaf access-ltp-id { 520 type te-types:te-tp-id; 521 description 522 "The TE link termination point identifier, used 523 together with access-node-id to identify the 524 access LTP."; 525 } 526 leaf service-classification-type { 527 type identityref { 528 base etht-types:service-classification-type; 529 } 530 description 531 "Service classification type."; 532 } 534 choice service-classification { 535 description 536 "Access classification can be port-based or 537 VLAN based."; 539 case port-classification { 540 /* no additional information */ 541 } 543 case vlan-classification { 544 container outer-tag { 545 presence "The outermost VLAN tag exists"; 546 description 547 "Classifies traffic using the outermost VLAN tag."; 549 uses vlan-classification; 550 } 551 container second-tag { 552 must 553 '../outer-tag/tag-type = "classify-s-vlan" and ' + 554 'tag-type = "classify-c-vlan"' 555 { 557 error-message 558 " 559 When matching two tags, the outermost tag must be 560 specified and of S-VLAN type and the second 561 outermost tag must be of C-VLAN tag type. 562 "; 563 description 564 " 565 For IEEE 802.1Q interoperability, when matching two 566 tags, it is required that the outermost tag exists 567 and is an S-VLAN, and the second outermost tag is a 568 C-VLAN. 569 "; 570 } 571 presence "The second outermost VLAN tag exists"; 573 description 574 "Classifies traffic using the second outermost VLAN tag."; 576 uses vlan-classification; 577 } 578 } 579 } 581 /* 582 Open issue: can we constraints it to be used only with mp services? 583 */ 584 leaf split-horizon-group { 585 type string; 586 description "Identify a split horizon group"; 587 } 589 uses bandwidth-profiles; 591 container vlan-operations { 592 description 593 "include parameters for vlan-operation"; 594 choice direction { 595 description 596 "Whether the VLAN operations are symmetrical or 597 asymmetrical"; 598 case symmetrical { 599 container symmetrical-operation { 600 uses vlan-operations; 601 description 602 "Symmetrical operations. 603 Expressed in the ingress direction, but 604 the reverse operation is applied to egress traffic"; 605 } 606 } 607 case asymmetrical { 608 container asymmetrical-operation { 609 description "Asymmetrical operations"; 610 container ingress { 611 uses vlan-operations; 612 description "Ingress operations"; 613 } 614 container egress { 615 uses vlan-operations; 616 description "Egress operations"; 617 } 618 } 619 } 620 } 621 } 622 } 624 grouping etht-svc-tunnel-parameters { 625 description 626 "ETH transport services tunnel parameters"; 628 leaf tunnel-name { 629 type string; 630 description 631 "TE service tunnel instance name."; 632 } 633 choice svc-multiplexing-tag { 634 description 635 "Service multiplexing is optional and flexible."; 637 case other { 638 /* 639 placeholder to support proprietary multiplexing 640 (for further discussion) 641 */ 642 } 644 case none { 645 /* no additional information is needed */ 646 } 648 case vlan-tag { 649 /* 650 No additional information is needed 651 The C-Tag or S-Tag used for service mulitplexing is defined 652 by the VLAN classification and operations configured in the 653 etht-svc-access-parameters grouping 654 */ 655 } 657 case pw { 658 /* to be completed (for further discussion) */ 659 } 660 } 662 /* 663 Open issue: can we constraints it to be used only with mp services? 665 */ 666 leaf src-split-horizon-group { 667 type string; 668 description "Identify a split horizon group at the Tunnel source TTP"; 669 } 670 leaf dst-split-horizon-group { 671 type string; 672 description "Identify a split horizon group at the Tunnel destination TTP"; 673 } 674 } 676 grouping te-topology-identifier { 677 description 678 "An identifier to uniquely identify the TE topology."; 679 leaf access-provider-id { 680 type te-types:te-global-id; 681 description 682 "An identifier to uniquely identify a provider."; 683 } 684 leaf access-client-id { 685 type te-types:te-global-id; 686 description 687 "An identifier to uniquely identify a client."; 688 } 689 leaf access-topology-id { 690 type te-types:te-topology-id; 691 description 692 "Identifies the topology the 693 service access ports belong to."; 694 } 695 } 697 grouping etht-svc-pm-threshold_config { 698 description 699 "Configuraiton parameters for Ethernet service PM thresholds."; 701 leaf sending-rate-high { 702 type uint64; 703 description 704 "High threshold of packet sending rate in kbps."; 705 } 706 leaf sending-rate-low { 707 type uint64; 708 description 709 "Low threshold of packet sending rate in kbps."; 710 } 711 leaf receiving-rate-high { 712 type uint64; 713 description 714 "High threshold of packet receiving rate in kbps."; 715 } 716 leaf receiving-rate-low { 717 type uint64; 718 description 719 "Low threshold of packet receiving rate in kbps."; 720 } 721 } 723 grouping etht-svc-pm-stats { 724 description 725 "Ethernet service PM statistics."; 727 leaf sending-rate-too-high { 728 type uint32; 729 description 730 "Counter that indicates the number of times the sending rate is above the high threshold"; 731 } 732 leaf sending-rate-too-low { 733 type uint32; 734 description 735 "Counter that indicates the number of times the sending rate is below the low threshold"; 736 } 737 leaf receiving-rate-too-high { 738 type uint32; 739 description 740 "Counter that indicates the number of times the receiving rate is above the high threshold"; 741 } 742 leaf receiving-rate-too-low { 743 type uint32; 744 description 745 "Counter that indicates the number of times the receiving rate is below the low threshold"; 746 } 747 } 749 grouping etht-svc-instance_config { 750 description 751 "Configuraiton parameters for Ethernet services."; 753 leaf etht-svc-name { 754 type string; 755 description 756 "Name of the p2p ETH transport service."; 757 } 759 leaf etht-svc-descr { 760 type string; 761 description 762 "Description of the ETH transport service."; 763 } 765 leaf etht-svc-type { 766 type etht-types:service-type; 767 description 768 "Type of Ethernet service (p2p, mp2mp or rmp)."; 769 /* Add default as p2p */ 770 } 772 uses te-topology-identifier; 774 list etht-svc-access-ports { 775 key access-port-id; 776 min-elements "1"; 777 /* 778 Open Issue: 779 Is it possible to limit the max-elements only for p2p services? 781 max-elements "2"; 782 */ 783 description 784 "List of the ETH trasport services access port instances."; 786 leaf access-port-id { 787 type uint16; 788 description 789 "ID of the service access port instance"; 790 } 791 uses etht-svc-access-parameters; 792 } 793 list etht-svc-tunnels { 794 key tunnel-name; 795 description 796 "List of the TE Tunnels supporting the ETH 797 transport service."; 799 uses etht-svc-tunnel-parameters; 800 } 801 container pm-config { 802 description 803 "ETH service performance monitoring"; 805 leaf pm-enable { 806 type boolean; 807 description 808 "Boolean value indicating whether PM is enabled."; 810 } 811 uses etht-svc-pm-threshold_config; 812 } 813 leaf admin-status { 814 type identityref { 815 base te-types:tunnel-state-type; 816 } 817 default te-types:tunnel-state-up; 818 description "ETH service administrative state."; 819 } 820 } 822 grouping etht-svc-instance_state { 823 description 824 "State parameters for Ethernet services."; 826 leaf operational-state { 827 type identityref { 828 base te-types:tunnel-state-type; 829 } 830 default te-types:tunnel-state-up; 831 description "ETH service operational state."; 832 } 833 leaf provisioning-state { 834 type identityref { 835 base te-types:lsp-state-type; 836 } 837 description "ETH service provisioning state."; 838 } 839 leaf creation-time { 840 type yang:date-and-time; 841 description 842 "Time of ETH service creation."; 843 } 844 leaf last-updated-time { 845 type yang:date-and-time; 846 description 847 "Time of ETH service last update."; 848 } 849 uses etht-svc-pm-stats; 850 } 852 /* 853 Data nodes 854 */ 856 container etht-svc { 857 description 858 "ETH transport services."; 860 container globals { 861 description 862 "ETH profile information."; 863 list etht-svc-bandwidth-profiles { 864 key bandwidth-profile-name; 865 description 866 "List of bandwidth profile templates used by 867 Ethernet services."; 869 uses etht-types:etht-bandwidth-profiles; 870 } 871 } 873 list etht-svc-instances { 874 key etht-svc-name; 875 description 876 "The list of p2p ETH transport service instances"; 878 uses etht-svc-instance_config; 880 container state { 881 config false; 882 description 883 "Ethernet Service states."; 885 uses etht-svc-instance_state; 886 } 887 } 888 } 889 } 891 893 5.2. YANG Code for ETH transport type 895 file "ietf-eth-tran-types@2018-03-01.yang" 896 module ietf-eth-tran-types { 898 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 900 prefix "etht-types"; 902 organization 903 "Internet Engineering Task Force (IETF) CCAMP WG"; 905 contact 906 " 907 WG List: 909 ID-draft editor: 910 Haomian Zheng (zhenghaomian@huawei.com); 911 Italo Busi (italo.busi@huawei.com); 912 Aihua Guo (aihuaguo@huawei.com); 913 Yunbin Xu (xuyunbin@ritt.cn); 914 Yang Zhao (zhaoyangyjy@chinamobile.com); 915 Xufeng Liu (Xufeng_Liu@jabil.com); 916 Giuseppe Fioccola (giuseppe.fioccola@telecomitalia.it); 917 "; 919 description 920 "This module defines the ETH transport types."; 922 revision 2018-03-01 { 923 description 924 "Initial revision"; 925 reference 926 "draft-zheng-ccamp-otn-client-signal-yang"; 927 } 929 /* 930 Identities 931 */ 933 identity eth-vlan-tag-type { 934 description 935 "ETH VLAN tag type."; 936 } 938 identity c-vlan-tag-type { 939 base eth-vlan-tag-type; 940 description 941 "802.1Q Customer VLAN"; 942 } 944 identity s-vlan-tag-type { 945 base eth-vlan-tag-type; 946 description 947 "802.1Q Service VLAN (QinQ)"; 948 } 950 identity service-classification-type { 951 description 952 "Service classification."; 954 } 956 identity port-classification { 957 base service-classification-type; 958 description 959 "Port classification."; 960 } 962 identity vlan-classification { 963 base service-classification-type; 964 description 965 "VLAN classification."; 966 } 968 identity eth-vlan-tag-classify { 969 description 970 "VLAN tag classification."; 971 } 973 identity classify-c-vlan { 974 base eth-vlan-tag-classify; 975 description 976 "Classify 802.1Q Customer VLAN tag. 977 Only C-tag type is accepted"; 978 } 980 identity classify-s-vlan { 981 base eth-vlan-tag-classify; 982 description 983 "Classify 802.1Q Service VLAN (QinQ) tag. 984 Only S-tag type is accepted"; 985 } 987 identity classify-s-or-c-vlan { 988 base eth-vlan-tag-classify; 989 description 990 "Classify S-VLAN or C-VLAN tag-classify. 991 Either tag is accepted"; 992 } 994 identity bandwidth-profile-type { 995 description 996 "Bandwidth Profile Types"; 997 } 999 identity mef-10-bwp { 1000 base bandwidth-profile-type; 1001 description 1002 "MEF 10 Bandwidth Profile"; 1003 } 1005 identity rfc-2697-bwp { 1006 base bandwidth-profile-type; 1007 description 1008 "RFC 2697 Bandwidth Profile"; 1009 } 1011 identity rfc-2698-bwp { 1012 base bandwidth-profile-type; 1013 description 1014 "RFC 2698 Bandwidth Profile"; 1015 } 1017 identity rfc-4115-bwp { 1018 base bandwidth-profile-type; 1019 description 1020 "RFC 4115 Bandwidth Profile"; 1021 } 1023 identity service-type { 1024 description 1025 "Type of Ethernet service."; 1026 } 1028 identity p2p-svc { 1029 base service-type; 1030 description 1031 "Ethernet point-to-point service (EPL, EVPL)."; 1032 } 1034 identity rmp-svc { 1035 base service-type; 1036 description 1037 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1038 } 1040 identity mp2mp-svc { 1041 base service-type; 1042 description 1043 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1044 } 1046 /* 1047 Type Definitions 1048 */ 1049 typedef eth-tag-type { 1050 type identityref { 1051 base eth-vlan-tag-type; 1052 } 1053 description 1054 "Identifies a specific ETH VLAN tag type."; 1055 } 1057 typedef eth-tag-classify { 1058 type identityref { 1059 base eth-vlan-tag-classify; 1060 } 1061 description 1062 "Identifies a specific VLAN tag classification."; 1063 } 1065 typedef vlanid { 1066 type uint16 { 1067 range "1..4094"; 1068 } 1069 description 1070 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1071 } 1073 typedef vid-range-type { 1074 type string { 1075 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1076 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1077 } 1078 description 1079 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1080 ascending order, between 1 and 4094. 1082 This type is used to match an ordered list of VLAN Ids, or 1083 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1084 range 1 to 4094, and included in the list in non overlapping 1085 ascending order. 1087 For example: 1,10-100,50,500-1000"; 1088 } 1090 typedef bandwidth-profile-type { 1091 type identityref { 1092 base bandwidth-profile-type; 1093 } 1094 description 1095 "Identifies a specific Bandwidth Profile type."; 1096 } 1097 typedef service-type { 1098 type identityref { 1099 base service-type; 1100 } 1101 description 1102 "Identifies the type of Ethernet service."; 1103 } 1105 /* 1106 Grouping Definitions 1107 */ 1108 grouping etht-bandwidth-profiles { 1109 description 1110 "Bandwidth profile configuration paramters."; 1112 leaf bandwidth-profile-name { 1113 type string; 1114 description 1115 "Name of the bandwidth profile."; 1116 } 1117 leaf bandwidth-profile-type { 1118 type etht-types:bandwidth-profile-type; 1119 description 1120 "The type of bandwidth profile."; 1121 } 1122 leaf CIR { 1123 type uint64; 1124 description 1125 "Committed Information Rate in Kbps"; 1126 } 1127 leaf CBS { 1128 type uint64; 1129 description 1130 "Committed Burst Size in in KBytes"; 1131 } 1132 leaf EIR { 1133 type uint64; 1134 /* 1135 Need to indicate that EIR is not supported by RFC 2697 1137 must 1138 '../bw-profile-type = "mef-10-bwp" or ' + 1139 '../bw-profile-type = "rfc-2698-bwp" or ' + 1140 '../bw-profile-type = "rfc-4115-bwp"' 1142 must 1143 '../bw-profile-type != "rfc-2697-bwp"' 1144 */ 1145 description 1146 "Excess Information Rate in Kbps 1147 In case of RFC 2698, PIR = CIR + EIR"; 1148 } 1149 leaf EBS { 1150 type uint64; 1151 description 1152 "Excess Burst Size in KBytes. 1153 In case of RFC 2698, PBS = CBS + EBS"; 1154 } 1155 leaf color-aware { 1156 type boolean; 1157 description 1158 "Indicates weather the color-mode is color-aware or color-blind."; 1159 } 1160 leaf coupling-flag { 1161 type boolean; 1162 /* 1163 Need to indicate that Coupling Flag is defined only for MEF 10 1165 must 1166 '../bw-profile-type = "mef-10-bwp"' 1167 */ 1168 description 1169 "Coupling Flag."; 1170 } 1171 } 1172 } 1174 1176 5.3. Other OTN client signal YANG Code 1178 file "ietf-trans-client-service@2018-02-09.yang" 1179 module ietf-trans-client-service { 1180 /* TODO: FIXME */ 1181 //yang-version 1.1; 1183 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 1184 prefix "clntsvc"; 1186 import ietf-te-types { 1187 prefix "te-types"; 1188 } 1189 import ietf-otn-types { 1190 prefix "otn-types"; 1191 } 1193 organization 1194 "Internet Engineering Task Force (IETF) CCAMP WG"; 1195 contact 1196 " 1198 ID-draft editor: 1199 Aihua Guo (aihuaguo@huawei.com); 1200 Haomian Zheng (zhenghaomian@huawei.com); 1201 Italo Busi (italo.busi@huawei.com); 1202 Yunbin Xu (xuyunbin@ritt.cn); 1203 Yang Zhao (zhaoyangyjy@chinamobile.com); 1204 Xufeng Liu (Xufeng_Liu@jabil.com); 1205 Giuseppe Fioccola (giuseppe.fioccola@telecomitalia.it); 1206 "; 1208 description 1209 "This module defines a YANG data model for describing 1210 simple transport client services."; 1212 revision 2018-02-09 { 1213 description 1214 "Initial version"; 1215 reference 1216 "ADD REFERENCE HERE"; 1217 } 1219 /* 1220 * Groupings 1221 */ 1222 grouping client-svc-access-parameters { 1223 description 1224 "Transport client services access parameters"; 1226 leaf access-node-id { 1227 type te-types:te-node-id; 1228 description 1229 "The identifier of the access node in the underlying 1230 transport topology."; 1231 } 1233 leaf access-ltp-id { 1234 type te-types:te-tp-id; 1235 description 1236 "The TE link termination point identifier, used together with 1237 access-node-id to identify the access LTP."; 1238 } 1240 leaf client-signal { 1241 type identityref { 1242 base otn-types:client-signal; 1243 } 1244 description 1245 "Identifiies the client signal type associated with this port"; 1246 } 1247 } 1249 grouping client-svc-tunnel-parameters { 1250 description 1251 "Transport client services tunnel parameters"; 1253 leaf tunnel-name { 1254 type string; 1255 description 1256 "TE service tunnel instance name."; 1257 } 1258 } 1260 grouping te-topology-identifier { 1261 description 1262 "description"; 1263 leaf access-provider-id { 1264 type te-types:te-global-id; 1265 description 1266 "An identifier to uniquely identify a provider."; 1267 } 1269 leaf access-client-id { 1270 type te-types:te-global-id; 1271 description 1272 "An identifier to uniquely identify a client."; 1273 } 1275 leaf access-topology-id { 1276 type te-types:te-topology-id; 1277 description 1278 "Identifies the topology the service access ports belong to."; 1279 } 1280 } 1282 grouping client-svc-instance_config { 1283 description 1284 "Configuraiton parameters for client services."; 1286 leaf client-svc-name { 1287 type string; 1288 description 1289 "Name of the p2p transport client service."; 1290 } 1292 leaf client-svc-descr { 1293 type string; 1294 description 1295 "Description of the transport client service."; 1296 } 1298 uses te-topology-identifier; 1300 leaf admin-status { 1301 type identityref { 1302 base te-types:tunnel-state-type; 1303 } 1304 default te-types:tunnel-state-up; 1305 description "Client service administrative state."; 1306 } 1308 container src-access-ports { 1309 description 1310 "Source access port of a client service."; 1311 uses client-svc-access-parameters; 1312 } 1314 container dst-access-ports { 1315 description 1316 "Destination access port of a client service."; 1317 uses client-svc-access-parameters; 1318 } 1320 list svc-tunnels { 1321 key tunnel-name; 1322 description 1323 "List of the TE Tunnels supporting the client service."; 1324 uses client-svc-tunnel-parameters; 1325 } 1326 } 1328 grouping client-svc-instance_state { 1329 description 1330 "State parameters for client services."; 1331 leaf operational-state { 1332 type identityref { 1333 base te-types:tunnel-state-type; 1335 } 1336 config false; 1337 description "Client service operational state."; 1338 } 1339 leaf provisioning-state { 1340 type identityref { 1341 base te-types:lsp-state-type; 1342 } 1343 config false; 1344 description "Client service provisioning state."; 1345 } 1346 } 1348 /* 1349 * Data nodes 1350 */ 1352 container client-svc { 1353 description 1354 "Transport client services."; 1356 list client-svc-instances { 1357 key client-svc-name; 1358 description 1359 "The list of p2p transport client service instances"; 1361 uses client-svc-instance_config; 1362 uses client-svc-instance_state; 1363 } 1364 } 1365 } 1367 1369 6. Considerations and Open Issue 1371 Editor Notes: This section is used to note temporary discussion/ 1372 conclusion that to be fixed in the future version, and will be 1373 removed before publication. We currently assume that there won't be 1374 much common part between Ethernet service model and other client 1375 signals service model, therefore the two groups of models are defined 1376 independently. 1378 It is possible that there can be something in common for Ethernet 1379 service and other client signal service. If there is any need to 1380 construct a base model, we will also work it out in this draft. It 1381 is worth noting that a previous ID draft 1383 [I-D.zhang-teas-transport-service-model] is also addressing the same 1384 problem by defining a base model. But unfortunately we have not 1385 found any chance to augment to that model. Need to determine how we 1386 should go depending on the discussion in WG. 1388 7. IANA Considerations 1390 TBD. 1392 8. Manageability Considerations 1394 TBD. 1396 9. Security Considerations 1398 The data following the model defined in this document is exchanged 1399 via, for example, the interface between an orchestrator and a 1400 transport network controller. The security concerns mentioned in 1401 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 1402 also applies to this document. 1404 The YANG module defined in this document can be accessed via the 1405 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 1406 protocol [RFC6241]. 1408 There are a number of data nodes defined in the YANG module which are 1409 writable/creatable/deletable (i.e., config true, which is the 1410 default). These data nodes may be considered sensitive or vulnerable 1411 in some network environments. Write operations (e.g., POST) to these 1412 data nodes without proper protection can have a negative effect on 1413 network operations. 1415 10. Acknowledgements 1417 We would like to thank Igor Bryskin and Daniel King for their 1418 comments and discussions. 1420 11. Contributors 1422 Yanlei Zheng 1423 China Unicom 1424 Email: zhengyl@dimpt.com 1426 Zhe Liu 1427 Huawei Technologies, 1428 Email: liuzhe123@huawei.com 1430 Zheyu Fan 1431 Huawei Technologies, 1432 Email: fanzheyu2@huawei.com 1434 Sergio Belotti 1435 Nokia, 1436 Email: sergio.belotti@nokia.com 1438 Yingxi Yao 1439 Shanghai Bell, 1440 yingxi.yao@nokia-sbell.com 1442 12. References 1444 12.1. Normative References 1446 [I-D.ietf-ccamp-otn-topo-yang] 1447 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X., 1448 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 1449 Model for Optical Transport Network Topology", draft-ietf- 1450 ccamp-otn-topo-yang-02 (work in progress), October 2017. 1452 [I-D.ietf-ccamp-otn-tunnel-model] 1453 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Rao, R., 1454 Belotti, S., Lopezalvarez, V., Li, Y., and Y. Xu, "OTN 1455 Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-01 1456 (work in progress), October 2017. 1458 [I-D.ietf-teas-yang-te-topo] 1459 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1460 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1461 Topologies", draft-ietf-teas-yang-te-topo-15 (work in 1462 progress), February 2018. 1464 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1465 and A. Bierman, Ed., "Network Configuration Protocol 1466 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1467 . 1469 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1470 and K. Pithewan, "GMPLS Signaling Extensions for Control 1471 of Evolving G.709 Optical Transport Networks", RFC 7139, 1472 DOI 10.17487/RFC7139, March 2014, 1473 . 1475 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1476 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1477 . 1479 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1480 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1481 . 1483 12.2. Informative References 1485 [I-D.ietf-netmod-yang-tree-diagrams] 1486 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1487 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1488 February 2018. 1490 [I-D.zhang-teas-transport-service-model] 1491 Zhang, X. and J. Ryoo, "A Service YANG Model for 1492 Connection-oriented Transport Networks", draft-zhang-teas- 1493 transport-service-model-01 (work in progress), October 1494 2016. 1496 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 1497 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 1498 Optical Transport Networks", RFC 7062, 1499 DOI 10.17487/RFC7062, November 2013, 1500 . 1502 Authors' Addresses 1504 Haomian Zheng 1505 Huawei Technologies 1506 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 1507 Shenzhen, Guangdong 518129 1508 P.R.China 1510 Email: zhenghaomian@huawei.com 1512 Aihua Guo 1513 Huawei Technologies 1515 Email: aihuaguo@huawei.com 1517 Italo Busi 1518 Huawei Technologies 1520 Email: Italo.Busi@huawei.com 1521 Yunbin Xu 1522 CAICT 1524 Email: xuyunbin@ritt.cn 1526 Yang Zhao 1527 China Mobile 1529 Email: zhaoyangyjy@chinamobile.com 1531 Xufeng Liu 1532 Jabil 1534 Email: Xufeng_Liu@jabil.com 1536 Giuseppe Fioccola 1537 Telecom Italia 1539 Email: giuseppe.fioccola@telecomitalia.it