idnits 2.17.1 draft-zhang-teas-transport-service-model-00.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 33 instances of too long lines in the document, the longest one being 27 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 (July 08, 2016) is 2848 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 650, 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 (-36) exists of draft-ietf-teas-yang-te-03 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 6 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: January 9, 2017 ETRI 6 July 08, 2016 8 A Service YANG Model for Connection-oriented Transport Networks 9 draft-zhang-teas-transport-service-model-00 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 January 9, 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 . . . . . . . . . . . . . . . . . . 3 71 4. Service Model - YANG Code . . . . . . . . . . . . . . . . . . 5 72 5. Open Issues/Future Items . . . . . . . . . . . . . . . . . . 12 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 7. Manageability Considerations . . . . . . . . . . . . . . . . 13 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 11.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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. 119 2. Terminology 121 A simplified graphical representation of the data model is used in 122 this document. The meaning of the symbols in the YANG data tree 123 presented later in this draft is defined in 124 [I-D.ietf-netmod-rfc6087bis]. They are provided below for reference. 126 o Brackets "[" and "]" enclose list keys. 128 o Abbreviations before data node names: "rw" means configuration 129 (read-write) and "ro" state data (read-only). 131 o Symbols after data node names: "?" means an optional node, "!" 132 means a presence container, and "*" denotes a list and leaf-list. 134 o Parentheses enclose choice and case nodes, and case nodes are also 135 marked with a colon (":"). 137 o Ellipsis ("...") stands for contents of subtrees that are not 138 shown. 140 3. Service Model - YANG Tree 142 The service model YANG tree is provided below: 144 module: ietf-transport-service 145 +--rw transport_service 146 +--rw service* [service-id] 147 +--rw service-id -> ../config/service-id 148 +--rw config 149 | +--rw service-id? uint32 150 | +--rw service-name? string 151 | +--rw service-endpoints* [node-id tp-id] 152 | | +--rw type? enumeration 153 | | +--rw node-id union 154 | | +--rw tp-id uint32 155 | | +--rw endpoint-name? string 156 | +--rw service-type identityref 157 | +--rw supporting-tunnel 158 | | +--rw tunnel-name? string 159 | +--rw bandwidth? decimal64 160 | +--rw protection-type? identityref 161 | +--rw schedule 162 | | +--rw schedules 163 | | +--rw schedule* [schedule-id] 164 | | +--rw schedule-id uint32 165 | | +--rw start? yang:date-and-time 166 | | +--rw schedule-duration? string 167 | | +--rw repeat-interval? string 168 | +--rw constraints 169 | +--rw delay-limit? uint32 170 | +--rw delayvariation-limit? uint32 171 | +--rw packetloss-limit? decimal64 172 | +--rw objective? identityref 173 +--ro state 174 +--ro service-id? uint32 175 +--ro service-name? string 176 +--ro service-endpoints* [node-id tp-id] 177 | +--ro type? enumeration 178 | +--ro node-id union 179 | +--ro tp-id uint32 180 | +--ro endpoint-name? string 181 +--ro service-type identityref 182 +--ro supporting-tunnel 183 | +--ro tunnel-name? string 184 +--ro bandwidth? decimal64 185 +--ro protection-type? identityref 186 +--ro schedule 187 | +--ro schedules 188 | +--ro schedule* [schedule-id] 189 | +--ro schedule-id uint32 190 | +--ro start? yang:date-and-time 191 | +--ro schedule-duration? string 192 | +--ro repeat-interval? string 193 +--ro creation-time? ytypes:date-and-time 194 +--ro constraints 195 | +--ro delay-limit? uint32 196 | +--ro delayvariation-limit? uint32 197 | +--ro packetloss-limit? decimal64 198 | +--ro objective? identityref 199 +--ro performance-info 200 | +--ro delay? uint32 201 | +--ro delay-variation? uint32 202 | +--ro packet-loss? decimal64 203 +--ro oper-status tet:te-oper-status 205 4. Service Model - YANG Code 207 file "ietf-transport-service@2016-07-07.yang" 209 module ietf-transport-service { 210 yang-version 1; 211 namespace "urn:ietf:params:xml:ns:yang:ietf-transport-service"; 212 prefix transservice; 214 import ietf-inet-types { 215 prefix inet; 216 } 218 import ietf-yang-types { 219 prefix ytypes; 220 } 222 import ietf-schedule { 223 prefix "sch"; 224 } 226 import ietf-te-topology { 227 prefix "tet"; 228 } 230 organization "Internet Engineering Task Force"; 231 contact 232 "Editor: Xian ZHANG (zhang.xian@huawei.com)"; 233 description 234 "this module describes a service module that is an essential 235 API for a client to ask for a provider network for a path 236 without the need to care about underlying technologies. 237 Capability to specify constraints/policies are provided as 238 optional features."; 240 revision 2016-07-07 { 241 description 242 "Initial revision."; 243 reference "to add the draft name"; 244 } 246 grouping endpoints-grouping{ 247 description "end point grouping"; 248 leaf type { 249 type enumeration { 250 enum root { 251 description "root"; 252 } 253 enum leaf { 254 description "leaf"; 255 } 256 enum unknown { 257 description "unknown"; 258 } 259 } 260 default root; 262 description 263 "This attribute indicates whether a endpoint of the service is acting 264 as a root or leaf, and takes on the value either root, leaf or 265 unkown. If the service type is Point-to-Point or Multipoint-to-Multipoint, 266 then the type is equal to root. If the service type is Point-to-Multipoint, 267 then the type can be either root or leaf."; 268 } 270 leaf node-id { 271 type union { 272 type inet:ip-address; //IPv4 or IPv6 273 type uint32; 274 } 275 description 276 "the node address of a service ."; 277 } 279 leaf tp-id { 280 type uint32; 281 description 282 "the termination point of a service."; 284 } 286 leaf endpoint-name { 287 type string; 288 description 289 "the name of this service endpoint"; 290 } 291 } 293 identity service-type { 294 description 295 "base identity from which the specific service 296 type can be derived."; 297 } 299 identity service-P2P { 300 base service-type; 301 description 302 "a point-to-point service type"; 303 } 305 identity service-P2MP { 306 base service-type; 307 description 308 "a point to multi-point type"; 309 } 311 identity service-MP2MP { 312 base service-type; 313 description 314 "a multi-point to multi-point type"; 315 } 317 //note: service type such as EPL, EVPL, EPLAN 318 // EVPLAN, E-Tree can be added when augmenting 319 // this model. 321 identity service-prot-type { 322 description 323 "base identity from which the specific 324 protection type can be derived."; 325 } 327 identity service-prot-unprotected { 328 base service-prot-type; 329 description 330 "service protection type: unprotected"; 331 } 332 identity service-prot-1plusR { 333 base service-prot-type; 334 description 335 "service protection type: dynamic reroute"; 336 reference 337 "draft-ietf-teas-gmpls-resource-sharing-proc-04"; 338 } 340 identity service-prot-1plus1 { 341 base service-prot-type; 342 description 343 "service protection type: static 1+1"; 344 } 346 identity service-prot-1plus1plusR { 347 base service-prot-type; 348 description 349 "service protection type: 1+1+R"; 350 reference 351 "draft-ietf-teas-gmpls-resource-sharing-proc-04"; 352 } 354 identity objective-type{ 355 description 356 "base identity from which the specific obective 357 funciton can be derived."; 358 } 359 identity objective-mindelay{ 360 base objective-type; 361 description 362 "objective: minimized delay"; 363 } 364 identity objective-mincost { 365 base objective-type; 366 description 367 "objective: minimized cost"; 368 } 370 identity objective-mindistance { 371 base objective-type; 372 description 373 "objective: minimized distance"; 374 } 376 grouping service-config-grouping { 377 description "service-config-groupoing"; 379 leaf service-id { 380 type uint32; 381 description 382 "an unique identificaiton of a service."; 383 } 385 leaf service-name{ 386 type string; 387 description "the name for a service"; 388 } 390 list service-endpoints{ 391 key "node-id tp-id"; 392 description 393 "this provides the service endpoints and it can be used 394 to support different types of services (including P2P, 395 MP2MP, P2MP)"; 397 uses endpoints-grouping; 398 } 400 leaf service-type { 401 type identityref { 402 base service-type; 403 } 404 mandatory true; 405 description 406 "the type of a service request"; 407 } 409 container supporting-tunnel { 410 leaf tunnel-name{ 411 type string; 412 description "the name of a tunnel (unique)"; 413 } 415 description 416 "the tunnels that can be used to support the service"; 417 } 419 leaf bandwidth { 420 type decimal64 { 421 fraction-digits 2; 422 } 423 description "the bandwidth requested by a service."; 424 } 426 leaf protection-type{ 427 type identityref { 428 base service-prot-type; 429 } 430 description 431 "the type of protection expected for this 432 service"; 433 } 434 } 436 grouping constraints-grouping { 437 leaf delay-limit { 438 type uint32; 439 description 440 "Delay variation in micro-seconds."; 441 } 443 leaf delayvariation-limit { 444 type uint32; 445 description 446 "Delay variation."; 447 } 449 leaf packetloss-limit { 450 type decimal64 { 451 fraction-digits 6; 452 range "0 .. 50.331642"; 453 } 454 description 455 "Delay variation in %."; 456 } 457 leaf objective { 458 type identityref 459 { 460 base objective-type; 461 } 462 description 463 "objective function imposed for path computation 464 from this service."; 465 } 466 description "constraints gropuing"; 467 } 469 container transport_service { 470 description 471 "serves as a top-level container for a list of services"; 473 list service { 474 key "service-id"; 475 description 476 "an unique identifier of a service"; 478 leaf service-id { 479 type leafref { 480 path "../config/service-id"; 481 } 482 description "a unique service identifier."; 483 } 484 container config{ 485 description "service config container"; 487 uses service-config-grouping; 489 container schedule { 490 uses sch:schedules; 491 description 492 "to specify bandwidth scheduling 493 information of this service."; 494 } 496 container constraints{ 497 uses constraints-grouping; 498 description 499 "specify the constraints imposed by a 500 service"; 501 } 502 } 504 container state 505 { 506 config false; 507 description "operational state of a service"; 509 uses service-config-grouping; 511 container schedule { 512 uses sch:schedules; 513 description "to specify bandwidth scheduling 514 state information of this service."; 515 } 517 leaf creation-time { 518 type ytypes:date-and-time; 519 description 520 "the time when service is created"; 521 } 523 container constraints{ 524 uses constraints-grouping; 525 description 526 "specify the constraints imposed by a 527 service"; 528 } 530 container performance-info{ 531 description "service state-performance info"; 532 leaf delay{ 533 type uint32; 534 description "the latency of this service"; 535 } 537 leaf delay-variation { 538 type uint32; 539 description "the service delay varation"; 540 } 541 leaf packet-loss { 542 type decimal64 { 543 fraction-digits 6; 544 range "0 .. 50.331642"; 545 } 546 description "packet loss"; 547 } 548 } 549 leaf oper-status { 550 type tet:te-oper-status; 551 mandatory true; 552 description 553 "the operational status of this service"; 554 } 555 }//end of state of a service 556 }//end of service list (including config and state) 557 }//service top container 558 } 560 562 5. Open Issues/Future Items 564 Attributes/functions that are under considerations for updating the 565 YANG model: 567 1): to add information such as PIR/CIR pertaining to ETH service 568 when augmenting this model; to add signal-type information for otn 569 service when augmenting this model; 570 2): to add service-related notification, e.g.: service up; service 571 down, service degraded etc.; 573 3): to figure out how to deal with attributes such as bandwidth, 574 schedule where it can be per node for non-P2P, but is per node 575 pair for P2P; 577 4): to add a RPC for service query, instead of actual setup; 579 5): to add XRO/IRO constraints; If service query RPC is supported, 580 then loose or strict IRO/ERO should be specified; 582 6. IANA Considerations 584 TBD. 586 7. Manageability Considerations 588 TBD 590 8. Security Considerations 592 Since the data model defined in this draft is manipulated via, for 593 example, the interface between an orchestrator and a transport 594 network controller. The YANG module defined in this draft is 595 designed to be accessed via the RESTCONF protocol defined in 596 [I-D.ietf-netconf-restconf], or maybe via the NETCONF protocol 597 [RFC6241]. As mentioned in Security Conserations Section of 598 [I-D.ietf-netconf-restconf] that HTTPS defined in [RFC7230] can be 599 used to provide security while accessing data. 601 There are a number of data nodes defined in the YANG module which are 602 writable/creatable/deletable (i.e., config true, which is the 603 default). These data nodes may be considered sensitive or vulnerable 604 in some network environments. Write operations (e.g., POST) to these 605 data nodes without proper protection can have a negative effect on 606 network operations. 608 Editor note: to List specific subtrees and data nodes and their 609 sensitivity/vulnerability. 611 9. Acknowledgements 613 We would like to thank Baoquan Rao and Gang Xie for their initial 614 discussions that trigger the generation of this draft. We would also 615 like to thank Michael Scharf from Nokia for very useful comments to 616 this draft and the model. 618 Aspects of the work in this Internet-Draft is funded by the UK 619 Engineering and Physical Sciences Research Council (EPSRC) under the 620 TOUCAN project (EP/L020009/1). 622 10. Contributors 624 Zhe Liu 625 Huawei Technologies 626 Email: liuzhe123@huawei.com 628 Sergio Belotti 629 Nokia 630 Email:sergio.belotti@nokia.com 632 Daniel King 633 Lancaster University 634 Email:d.kindg@lancaster.ac.uk 636 11. References 638 11.1. Normative References 640 [I-D.ietf-netconf-restconf] 641 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 642 Protocol", draft-ietf-netconf-restconf-13 (work in 643 progress), April 2016. 645 [I-D.ietf-netmod-rfc6087bis] 646 Bierman, A., "Guidelines for Authors and Reviewers of YANG 647 Data Model Documents", draft-ietf-netmod-rfc6087bis-06 648 (work in progress), March 2016. 650 [I-D.ietf-teas-yang-te] 651 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen, 652 X., Jones, R., and B. Wen, "A YANG Data Model for Traffic 653 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 654 te-03 (work in progress), March 2016. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, 659 . 661 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 662 the Network Configuration Protocol (NETCONF)", RFC 6020, 663 DOI 10.17487/RFC6020, October 2010, 664 . 666 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 667 Protocol (HTTP/1.1): Message Syntax and Routing", 668 RFC 7230, DOI 10.17487/RFC7230, June 2014, 669 . 671 11.2. Informative References 673 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 674 and A. Bierman, Ed., "Network Configuration Protocol 675 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 676 . 678 Authors' Addresses 680 Xian Zhang (editor) 681 Huawei Technologies 682 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 683 Shenzhen, Guangdong 518129 684 P.R.China 686 Email: zhang.xian@huawei.com 688 Jeong-dong Ryoo 689 ETRI 691 Email: ryoo@etri.re.kr