idnits 2.17.1 draft-zhang-teas-transport-service-model-01.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 31 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2734 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) == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 658, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 == Outdated reference: A later version (-20) exists of draft-ietf-netmod-rfc6087bis-06 == Outdated reference: A later version (-05) exists of draft-liu-netmod-yang-schedule-02 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-04 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-03 == Outdated reference: A later version (-05) exists of draft-zhang-teas-actn-yang-02 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group X. Zhang, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track J. Ryoo 5 Expires: May 4, 2017 ETRI 6 October 31, 2016 8 A Service YANG Model for Connection-oriented Transport Networks 9 draft-zhang-teas-transport-service-model-01 11 Abstract 13 A transport network is a server-layer network designed to provide 14 connectivity services for a client-layer network to carry the client 15 traffic opaquely across the server-layer network resources. A 16 transport network may be constructed from equipments utilizing any of 17 a number of different transport technologies such as the evolving 18 optical transport infrastructure (Synchronous Optical Networking 19 (SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport 20 Network (OTN)) or packet transport as epitomized by the MPLS 21 Transport Profile (MPLS-TP). 23 This draft provides a transport service YANG model that can be used 24 together with the RESTCONF protocol for a northbound client to 25 initiate service requests toward the transport network controllers 26 via the RESTful interface between them so as to enable automated 27 service interations. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 4, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Service Model - YANG Tree . . . . . . . . . . . . . . . . . . 4 71 4. Service Model - YANG Code . . . . . . . . . . . . . . . . . . 6 72 5. General Considerations and Some Open Issues . . . . . . . . . 13 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 7. Manageability Considerations . . . . . . . . . . . . . . . . 13 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 11.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 A transport network is a server-layer network designed to provide 86 connectivity services, or more advanced services like Virtual Private 87 Networks (VPN) for a client-layer network to carry the client traffic 88 opaquely across the server-layer network resources. It acts as a 89 pipe provider for upper-layer networks, such as IP network and mobile 90 networks. 92 Transport networks, such as Synchronous Optical Networking (SONET) / 93 Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), 94 Wavelength Division Multiplexing (WDM), and flexi-grid networks, are 95 often built using equipments from a single vendor and are managed 96 using private interfaces to dedicated Element Management Systems 97 (EMS) / Network Management Systems (NMS). All transport networks 98 have high benchmarks for reliability and operational simplicity. 99 This suggests a common, technology-independent management/control 100 paradigm that is extended to represent and configure specific 101 technology attributes. 103 The YANG language [RFC6020] is currently the data modeling language 104 of choice within the IETF and has been adopted by a number of 105 industry-wide open management and control initiatives. YANG may be 106 used to model both configuration and operational states; it is 107 vendor-neutral and supports extensible APIs for control and 108 management of elements. 110 This document, exploting the YANG language, provides a transport 111 service model that can be used by a northbound client (e.g., an 112 orchestrator, a client network controller etc.) to initiate service 113 requests, as well as retrieving service states, toward the transport 114 network via the RESTful interface provided by the transport network 115 controller(s). The model is currently scoped for connection-oriented 116 transport networks and connection-less transport networks are out of 117 scope. To understand better what interfaces a service model can 118 apply to in the transport SDN architecture (i.e., Abstract Control of 119 Transport Networks (ACTN))and how service model relates to other YANG 120 models defined in IETF in general, please refer to 121 [I-D.zhang-teas-actn-yang] for more detailed information. 123 2. Terminology 125 A simplified graphical representation of the data model is used in 126 this document. The meaning of the symbols in the YANG data tree 127 presented later in this draft is defined in 128 [I-D.ietf-netmod-rfc6087bis]. They are provided below for reference. 130 o Brackets "[" and "]" enclose list keys. 132 o Abbreviations before data node names: "rw" means configuration 133 (read-write) and "ro" state data (read-only). 135 o Symbols after data node names: "?" means an optional node, "!" 136 means a presence container, and "*" denotes a list and leaf-list. 138 o Parentheses enclose choice and case nodes, and case nodes are also 139 marked with a colon (":"). 141 o Ellipsis ("...") stands for contents of subtrees that are not 142 shown. 144 3. Service Model - YANG Tree 146 The service model YANG tree is provided below: 148 module: ietf-transport-service 149 +--rw transport_service 150 +--rw service* [service-name] 151 +--rw service-name -> ../config/service-name 152 +--rw config 153 | +--rw service-name? string 154 | +--rw service-id? uint32 155 | +--rw service-endpoints* [node-id tp-id] 156 | | +--rw type? enumeration 157 | | +--rw node-id union 158 | | +--rw tp-id uint32 159 | | +--rw endpoint-name? string 160 | +--rw service-type identityref 161 | +--rw supporting-tunnel 162 | | +--rw tunnel-name? string 163 | +--rw bandwidth? decimal64 164 | +--rw protection-type? identityref 165 | +--rw constraints 166 | +--rw delay-limit? uint32 167 | +--rw delayvariation-limit? uint32 168 | +--rw packetloss-limit? decimal64 169 | +--rw objective? identityref 170 +--ro state 171 +--ro service-name? string 172 +--ro service-id? uint32 173 +--ro service-endpoints* [node-id tp-id] 174 | +--ro type? enumeration 175 | +--ro node-id union 176 | +--ro tp-id uint32 177 | +--ro endpoint-name? string 178 +--ro service-type identityref 179 +--ro supporting-tunnel 180 | +--ro tunnel-name? string 181 +--ro bandwidth? decimal64 182 +--ro protection-type? identityref 183 +--ro creation-time? ytypes:date-and-time 184 +--ro constraints 185 | +--ro delay-limit? uint32 186 | +--ro delayvariation-limit? uint32 187 | +--ro packetloss-limit? decimal64 188 | +--ro objective? identityref 189 +--ro performance-info 190 | +--ro delay? uint32 191 | +--ro delay-variation? uint32 192 | +--ro packet-loss? decimal64 193 +--ro oper-status tet:te-oper-status 195 4. Service Model - YANG Code 197 file "ietf-transport-service@2016-10-31.yang" 198 module ietf-transport-service { 199 yang-version 1; 200 namespace "urn:ietf:params:xml:ns:yang:ietf-transport-service"; 201 prefix transservice; 203 import ietf-inet-types { 204 prefix inet; 205 } 207 import ietf-yang-types { 208 prefix ytypes; 209 } 211 import ietf-te-types { 212 prefix "tet"; 213 } 215 organization "Internet Engineering Task Force"; 216 contact 217 "Editor: Xian ZHANG (zhang.xian@huawei.com)"; 218 description 219 "this module describes a service module that is an essential 220 API for a client to ask for a provider network for a path 221 without the need to care about underlying technologies. 222 Capability to specify constraints/policies are provided as 223 optional features."; 225 revision 2016-10-31 { 226 description 227 "Initial revision."; 228 reference "to add the draft name"; 229 } 231 grouping endpoints-grouping{ 232 description "end point grouping"; 233 leaf type { 234 type enumeration { 235 enum root { 236 description "root"; 237 } 238 enum leaf { 239 description "leaf"; 240 } 241 enum unknown { 242 description "unknown"; 243 } 244 } 245 default root; 247 description 248 "This attribute indicates whether a endpoint of the 249 service is acting as a root or leaf, and takes on 250 the value either root, leaf or unkown. If the service 251 type is Point-to-Point or Multipoint-to-Multipoint, 252 then the type is equal to root. If the service type 253 is Point-to-Multipoint, then the type can be either 254 root or leaf."; 255 } 257 leaf node-id { 258 type union { 259 type inet:ip-address; //IPv4 or IPv6 260 type uint32; 261 } 262 description 263 "the node address of a service ."; 264 } 266 leaf tp-id { 267 type uint32; 268 description 269 "the termination point of a service."; 270 } 272 leaf endpoint-name { 273 type string; 274 description 275 "the name of this service endpoint"; 276 } 277 } 279 identity service-type { 280 description 281 "base identity from which the specific service 282 type can be derived."; 283 } 285 identity service-P2P { 286 base service-type; 287 description 288 "a point-to-point service type"; 289 } 291 identity service-P2MP { 292 base service-type; 293 description 294 "a point to multi-point type"; 295 } 297 identity service-MP2MP { 298 base service-type; 299 description 300 "a multi-point to multi-point type"; 301 } 303 //note: service type such as EPL, EVPL, EPLAN 304 // EVPLAN, E-Tree can be added when augmenting 305 // this model. 307 identity service-prot-type { 308 description 309 "base identity from which the specific 310 protection type can be derived."; 311 } 313 identity service-prot-unprotected { 314 base service-prot-type; 315 description 316 "service protection type: unprotected"; 317 } 319 identity service-prot-1plusR { 320 base service-prot-type; 321 description 322 "service protection type: dynamic reroute"; 323 reference 324 "draft-ietf-teas-gmpls-resource-sharing-proc-04"; 325 } 327 identity service-prot-1plus1 { 328 base service-prot-type; 329 description 330 "service protection type: static 1+1"; 331 } 333 identity service-prot-1plus1plusR { 334 base service-prot-type; 335 description 336 "service protection type: 1+1+R"; 337 reference 338 "draft-ietf-teas-gmpls-resource-sharing-proc-04"; 339 } 341 identity objective-type{ 342 description 343 "base identity from which the specific obective 344 funciton can be derived."; 345 } 346 identity objective-mindelay{ 347 base objective-type; 348 description 349 "objective: minimized delay"; 350 } 351 identity objective-mincost { 352 base objective-type; 353 description 354 "objective: minimized cost"; 355 } 357 identity objective-mindistance { 358 base objective-type; 359 description 360 "objective: minimized distance"; 361 } 363 grouping service-config-grouping { 364 description "service-config-groupoing"; 366 leaf service-name{ 367 type string; 368 description "the name for a service"; 369 } 371 leaf service-id { 372 type uint32; 373 description 374 "an unique identificaiton of a service."; 375 } 377 list service-endpoints{ 378 key "node-id tp-id"; 379 description 380 "this provides the service endpoints and it can be used 381 to support different types of services (including P2P, 382 MP2MP, P2MP)"; 384 uses endpoints-grouping; 385 } 387 leaf service-type { 388 type identityref { 389 base service-type; 390 } 391 mandatory true; 392 description 393 "the type of a service request"; 394 } 396 container supporting-tunnel { 397 leaf tunnel-name{ 398 type string; 399 description "the name of a tunnel (unique)"; 400 } 402 description 403 "the tunnels that can be used to support the service"; 404 } 406 leaf bandwidth { 407 type decimal64 { 408 fraction-digits 2; 409 } 410 description "the bandwidth requested by a service."; 411 } 413 leaf protection-type{ 414 type identityref { 415 base service-prot-type; 416 } 417 description 418 "the type of protection expected for this 419 service"; 420 } 421 } 423 grouping constraints-grouping { 424 leaf delay-limit { 425 type uint32; 426 description 427 "Delay variation in micro-seconds."; 428 } 429 leaf delayvariation-limit { 430 type uint32; 431 description 432 "Delay variation."; 433 } 435 leaf packetloss-limit { 436 type decimal64 { 437 fraction-digits 6; 438 range "0 .. 50.331642"; 439 } 440 description 441 "Delay variation in %."; 442 } 443 leaf objective { 444 type identityref 445 { 446 base objective-type; 447 } 448 description 449 "objective function imposed for path computation 450 from this service."; 451 } 452 description "constraints gropuing"; 453 } 455 container transport_service { 456 description 457 "serves as a top-level container for a list of services"; 459 list service { 460 key "service-name"; 461 description 462 "an unique identifier of a service"; 464 leaf service-name { 465 type leafref { 466 path "../config/service-name"; 467 } 468 description "a unique service identifier."; 469 } 470 container config{ 471 description "service config container"; 473 uses service-config-grouping; 475 container constraints{ 476 uses constraints-grouping; 477 description 478 "specify the constraints imposed by a 479 service"; 480 } 481 } 483 container state 484 { 485 config false; 486 description "operational state of a service"; 488 uses service-config-grouping; 490 leaf creation-time { 491 type ytypes:date-and-time; 492 description 493 "the time when service is created"; 494 } 496 container constraints{ 497 uses constraints-grouping; 498 description 499 "specify the constraints imposed by a 500 service"; 501 } 503 container performance-info{ 504 description "service state-performance info"; 505 leaf delay{ 506 type uint32; 507 description "the latency of this service"; 508 } 510 leaf delay-variation { 511 type uint32; 512 description "the service delay varation"; 513 } 514 leaf packet-loss { 515 type decimal64 { 516 fraction-digits 6; 517 range "0 .. 50.331642"; 518 } 519 description "packet loss"; 520 } 521 } 522 leaf oper-status { 523 type tet:te-oper-status; 524 mandatory true; 525 description 526 "the operational status of this service"; 527 } 528 }//end of state of a service 529 }//end of service list (including config and state) 530 }//service top container 531 } 533 535 5. General Considerations and Some Open Issues 537 [I-D.liu-netmod-yang-schedule] defines a YANG data model for 538 configuration scheduling. A service model can also be scheduled, 539 therefore the ietf-schedule model can be used to serve this purpose 540 by specifying the appropriate object using xpath. 542 Functions that are under considerations for updating the YANG model: 544 1): Service delivery model augmentation: Information such as PIR/ 545 CIR pertaining to ETH service is needed and it is more appropriate 546 to augment the base model; for OTN-based service model, signal- 547 type information needs to be added; 549 2): To add service-related notification, e.g.: service up; service 550 down, service degraded etc.; Currently, there are two options 551 available, one is using the method provided in [RFC5277], the 552 other one is using the new mechanism proposed in 553 [I-D.ietf-netconf-yang-push]. 555 3): To figure out how to deal with attributes such as bandwidth, 556 schedule where it can be per node for non-P2P, but is per node 557 pair for P2P; 559 4): to add XRO/IRO constraints; 561 6. IANA Considerations 563 TBD. 565 7. Manageability Considerations 567 TBD 569 8. Security Considerations 571 Since the data model defined in this draft is manipulated via, for 572 example, the interface between an orchestrator and a transport 573 network controller. The YANG module defined in this draft is 574 designed to be accessed via the RESTCONF protocol defined in 575 [I-D.ietf-netconf-restconf], or maybe via the NETCONF protocol 576 [RFC6241]. As mentioned in Security Conserations Section of 577 [I-D.ietf-netconf-restconf] that HTTPS defined in [RFC7230] can be 578 used to provide security while accessing data. 580 There are a number of data nodes defined in the YANG module which are 581 writable/creatable/deletable (i.e., config true, which is the 582 default). These data nodes may be considered sensitive or vulnerable 583 in some network environments. Write operations (e.g., POST) to these 584 data nodes without proper protection can have a negative effect on 585 network operations. 587 Editor note: to List specific subtrees and data nodes and their 588 sensitivity/vulnerability. 590 9. Acknowledgements 592 We would like to thank Baoquan Rao and Gang Xie for their initial 593 discussions that trigger the generation of this draft. We would also 594 like to thank Michael Scharf from Nokia for very useful comments to 595 this draft and the model. 597 Aspects of the work in this Internet-Draft is funded by the UK 598 Engineering and Physical Sciences Research Council (EPSRC) under the 599 TOUCAN project (EP/L020009/1). 601 10. Contributors 603 Zhe Liu 604 Huawei Technologies 605 Email: liuzhe123@huawei.com 607 Sergio Belotti 608 Nokia 609 Email:sergio.belotti@nokia.com 611 Daniel King 612 Lancaster University 613 Email:d.kindg@lancaster.ac.uk 615 11. References 617 11.1. Normative References 619 [I-D.ietf-netconf-restconf] 620 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 621 Protocol", draft-ietf-netconf-restconf-13 (work in 622 progress), April 2016. 624 [I-D.ietf-netmod-rfc6087bis] 625 Bierman, A., "Guidelines for Authors and Reviewers of YANG 626 Data Model Documents", draft-ietf-netmod-rfc6087bis-06 627 (work in progress), March 2016. 629 [I-D.liu-netmod-yang-schedule] 630 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 631 O. Dios, "A YANG Data Model for Configuration Scheduling", 632 draft-liu-netmod-yang-schedule-02 (work in progress), 633 October 2016. 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, 637 DOI 10.17487/RFC2119, March 1997, 638 . 640 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 641 the Network Configuration Protocol (NETCONF)", RFC 6020, 642 DOI 10.17487/RFC6020, October 2010, 643 . 645 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 646 Protocol (HTTP/1.1): Message Syntax and Routing", 647 RFC 7230, DOI 10.17487/RFC7230, June 2014, 648 . 650 11.2. Informative References 652 [I-D.ietf-netconf-yang-push] 653 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 654 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 655 YANG datastore push updates", draft-ietf-netconf-yang- 656 push-04 (work in progress), October 2016. 658 [I-D.ietf-teas-yang-te] 659 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen, 660 X., Jones, R., and B. Wen, "A YANG Data Model for Traffic 661 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 662 te-03 (work in progress), March 2016. 664 [I-D.zhang-teas-actn-yang] 665 Lee, Y., Zhang, X., Yoon, B., Dios, O., and J. Shin, 666 "Applicability of YANG models for Abstraction and Control 667 of Traffic Engineered Networks", draft-zhang-teas-actn- 668 yang-02 (work in progress), October 2016. 670 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 671 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 672 . 674 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 675 and A. Bierman, Ed., "Network Configuration Protocol 676 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 677 . 679 Authors' Addresses 681 Xian Zhang (editor) 682 Huawei Technologies 683 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 684 Shenzhen, Guangdong 518129 685 P.R.China 687 Email: zhang.xian@huawei.com 689 Jeong-dong Ryoo 690 ETRI 692 Email: ryoo@etri.re.kr