idnits 2.17.1 draft-zhang-ccamp-transport-ctrlnorth-yang-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 461 has weird spacing: '...rw name str...' == Line 484 has weird spacing: '...ro name str...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 07, 2016) is 2971 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) == Missing Reference: 'TE-topo' is mentioned on line 395, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-02 == Outdated reference: A later version (-04) exists of draft-lee-ccamp-wson-yang-02 == Outdated reference: A later version (-07) exists of draft-zhang-ccamp-l1-topo-yang-02 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-02 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Xian Zhang 2 Internet-Draft Huawei 3 Intended status: Standards Track R. Jing 4 China Telecom 5 W. Jian 6 China Unicom 7 Jeong-dong Ryoo 8 ETRI 9 Y. Xu 10 CAICT 11 Daniel King 12 Lancaster University 14 Expires: September 05, 2016 March 07, 2016 16 YANG Models for the Northbound Interface of a Transport Network 17 Controller: Requirements, Functions, and a List of YANG Models 19 draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt 21 Abstract 23 A transport network is a server-layer network designed to provide 24 connectivity services for a client-layer network to carry the client 25 traffic opaquely across the server-layer network resources. A 26 transport network may be constructed from equipment utilizing any of 27 a number of different transport technologies such as the evolving 28 optical transport infrastructure (Synchronous Optical Networking 29 (SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport 30 Network (OTN)) or packet transport as epitomized by the MPLS 31 Transport Profile (MPLS-TP). 33 All transport networks have high benchmarks for reliability and 34 operational simplicity. This suggests a common, technology- 35 independent management/control paradigm that can be extended to 36 represent and configure specific technology attributes. 38 This document describes the requirements facing transport networks 39 in order to provide open interfaces for resource programmability and 40 control/management automation. A list of existing and additional 41 YANG models is provided to fulfill the functional requirements. 43 Status of this Memo 45 This Internet-Draft is submitted to IETF in full conformance with 46 the provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet- 51 Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six 54 months and may be updated, replaced, or obsoleted by other documents 55 at any time. It is inappropriate to use Internet-Drafts as 56 reference material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt. 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html. 64 This Internet-Draft will expire on September 05, 2016. 66 Copyright Notice 68 Copyright (c) 2016 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with 76 respect to this document. Code Components extracted from this 77 document must include Simplified BSD License text as described in 78 Section 4.e of the Trust Legal Provisions and are provided without 79 warranty as described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction ................................................ 3 84 2. Conventions used in this document............................ 4 85 3. Terminology and Notations.................................... 4 86 4. Functional Requirements...................................... 5 87 4.1. Scenarios ............................................. 5 88 4.2. Function Requirement Summary ........................... 8 89 5. Function Analysis ........................................... 9 90 5.1. Toplogy Related Functions .............................. 9 91 5.1.1 Obtaining Access Point Info ...................... 9 92 5.1.2 Obtaining Topology ............................... 9 93 5.1.3 Virtual Network Operations ...................... 10 94 5.2. Tunnel Operations ..................................... 10 95 5.3. Service Requests ...................................... 10 96 6. Security Considerations..................................... 17 97 7. Manageability Considerations................................ 17 98 8. IANA Considerations ........................................ 18 99 9. Acknowledgements ........................................... 18 100 10. References ................................................ 18 101 10.1. Normative References............................... 18 102 10.2. Informative References............................. 18 103 11. Contributors' Address...................................... 19 104 Authors' Addresses ............................................. 19 106 1. Introduction 108 A transport network is a server-layer network designed to provide 109 connectivity services, or more advanced services like Virtual 110 Private Networks (VPN) for a client-layer network to carry the 111 client traffic opaquely across the server-layer network resources. 112 It acts as a pipe provider for upper-layer networks, such as IP 113 network and mobile networks. 115 Transport networks, such as Synchronous Optical Networking (SONET) / 116 Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), 117 Wavelength Division Multiplexing (WDM), and flexi-grid networks, are 118 often built using equipment from a single vendor and are managed 119 using private interfaces to dedicated Element Management Systems 120 (EMS) / Network Management Systems (NMS). All transport networks 121 have high benchmarks for reliability and operational simplicity. 122 This suggests a common, technology-independent management/control 123 paradigm that is extended to represent and configure specific 124 technology attributes. 126 The need of network providers to manage multi-vendor and multi- 127 domain transport networks (where each domain is an island of 128 equipment from a single supplier) has been further stressed by the 129 expansion in network size. At the same time, applications such as 130 data center interconnection require larger and more dynamic 131 connectivity matrices. Therefore, transport networks face new 132 challenges going beyond automatic provisioning of tunnel setup 133 enabled by GMPLS (Generalized Multi-Protocol Label Switching) 134 protocols to achieve automatic service provisioning, as well as 135 address opportunities enabled by partitioning the network through 136 the process of resource slicing. With lower operational expenditure 137 (OPEX) and capital expenditure (CAPEX) as the usual objectives, open 138 interfaces to transport networks are considered by network providers 139 as a way to meet these requirements. The concept of Software 140 Defined Networking (SDN) leverages these ideas. 142 The YANG language [RFC6020] is currently the data modeling language 143 of choice within the IETF and has been adopted by a number of 144 industry-wide open management and control initiatives. YANG may be 145 used to model both configuration and operational states; it is 146 vendor-neutral and supports extensible APIs for control and 147 management of elements. 149 This document analyzes typical scenarios that need transport network 150 control/management openness, and lists functions desired to enable 151 deployment. Moreover, a list of YANG models and their relationships 152 have been identified that can help facilitate the deployment and 153 operation of transport network open interfaces. Note that some of 154 the models discussed meet the requirements described, and are 155 already being developed in the IETF. Thus, this document provides a 156 reference of existing models, and provides information of the 157 missing ones which need further work. 159 2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC-2119 [RFC2119]. 165 3. Terminology and Notations 167 A simplified graphical representation of the data model is used in 168 this document. The meaning of the symbols in the YANG data tree 169 presented later in this draft is defined in [ietf-netmod-rfc6087bis]. 170 They are provided below for reference. 172 o Brackets "[" and "]" enclose list keys. 174 o Abbreviations before data node names: "rw" means configuration 175 (read-write) and "ro" state data (read-only). 177 o Symbols after data node names: "?" means an optional node, "!" 178 means a presence container, and "*" denotes a list and leaf-list. 180 o Parentheses enclose choice and case nodes, and case nodes are 181 also marked with a colon (":"). 183 o Ellipsis ("...") stands for contents of subtrees that are not 184 shown. 186 4. Functional Requirements 188 4.1. Scenarios 190 There are several scenarios where an open interface to access 191 server-layer (transport) network resources would be useful. Here two 192 typical scenarios are provided. 194 The first one is depicted as below (Figure 1): 196 /--\ +------+ +------+ /--\ 197 | 1 ~~~| A +------------------| B |~~~~~ 3 | 198 \--/ +-----++ +--+---+ \--/ 199 | | 200 | | 201 | | 202 ++-----+ +---+--+ 203 | F +------------+ C | 204 ++-----+ +--+---+ 205 | | 206 | | 207 | | 208 | | 209 | | 210 +---+-+ +---+-+ /---\ 211 | E +---------------+ D |~~~~ 4 | 212 /--\~~~~~+-----+ +-----+ \---/ 213 | 2 | 214 \--/ 216 +----+ /--\ 217 | | Transport NE | | DC 218 +----+ \--/ 220 ----- Transport Link ~~~ Transport-DC link 222 (a) Data Centers interconnected via a transport network 224 +---------------------+ 225 | Data Center Network | 226 | Controller | 227 +---------+-----------+ 228 | 229 | 230 | 231 | Open Interface 232 | 233 | 234 +---------+-----------+ 235 | Transport Network | 236 | Controller | 237 +---------------------+ 238 (b) The controller architecture for data center interconnection 240 Figure 1: Scenario 1: Data centers interconnected via a transport 241 network and the controller architecture 243 For the data center operator, assuming the objective is to trigger 244 the transport network to provide connectivity on demand, the 245 following capabilities, at a minimum, would be required on the open 246 itnerface between the two contollers illustrated in Figure 1: 248 A: The ability to obtain information about a set of access points of 249 the transport network facing the client side, including information 250 such as access point identifiers, capabilities, etc.; for instance, 251 transport-network-side end point identifiers related to the access 252 link between DC1 and Transport NE A. 254 B: The capability to send a request for a service using the 255 aforementioned access point information, as well as the ability to 256 retrieve a list of service requests and their statuses. In this 257 request, it should at least be possible to include source node, 258 destination node, and requested bandwidth to request the transport 259 network to set up tunnels/paths so as to provide the requested 260 connectivitiy for the service request. 262 C: Note that in this case acquistion of the topology, be it physical 263 or logical, of the transport network is not a compulsory requirement, 264 but it may indeed be able to give data center providers more control 265 over the transport resource usage. Furtheremore, the client 266 controller can impose a virtual network of its own choice by 267 requesting a slice of network resource with its choice of network 268 parameters (such as network topology type, bandwidth etc.). 270 The second scenario, more complicated than the first, is depicted as 271 below (Figure 2). In this example, we focus on the management and 272 control via open interfaces for multi-domain networks with 273 homogeneous technologies (such as OTN), but it can be extended 274 further to multi-domain networks with heterogeneous technologies 275 with higher complexity. 277 +-------------------------------------------------+ 278 | Orchestrator/Coordinator | 279 +---------+--------------+-------------------+----+ 280 | | | 281 | | | 282 +------------+--+ | +----------+----------+ 283 | Controller 1 | | | Controller 2 | 284 +---------+-----+ | +-------+-------------+ 285 # +----------------+ # 286 #Qx | Controller 3 | # 287 # +----------------+ #TL1 288 # # # 289 ----+----- # ----+----- 290 ____/ \____ # ____/ \____ 291 | | # | | 292 | | # | | 293 | Network Domain +***********+ Network Domain | 294 | 1 | # | 2 | 295 |____ ___| # |____ ___| 296 \ / #PCEP \ / 297 ----------- # *---------- 298 * * # * * 299 * * # * * 300 * * # * * 301 * * # * * 302 * * # * * 303 * * # * * 304 * *----+-----* * 305 * ____/ \____ * 306 *| |* 307 | | 308 | Network Domain | 309 | 3 | 310 |____ ___| 311 \ / 312 ---------- 314 ***** inter-domain links 315 ----- Open Interfaces 316 ##### Controller-device interfaces 318 Figure 2: Scenario 2: Multi-domain network control and management 320 For the second scenario, the orchestrator/coordinator controls and 321 manages three distinct network domains, each controlled/managed by 322 their domain controller. In order to orchestrate across 323 domains/layers, the orchestrator needs its interface between domain 324 controllers to be equipped with the following functions: 326 A: Access to the topologies reported by each domain controller, 327 including cross-domain links for the purpose of planning and 328 requesting the paths of end-to-end tunnels. Multiple technologies 329 within a domain (i.e., a multi-layer network), this might be 330 reflected in the reported topology. Depending on the abstraction 331 level of the reported topology, the orchestrator has different 332 control granularities. 334 B: The ability to set up, delete and modify tunnels, be it within 335 one domain or across multiple domains. Furthermore, it should have 336 the abilty to view the tunnels created within each domain as well as 337 thouse that cross domains as reported by each domain controller. 339 4.2. Function Requirement Summary 341 For the open interface of a transport controller towards a 342 northbound client, five functions are derived from the scenarios 343 explained in the last section. They are summarized in the table 344 below and we also match these functions with YANG models that are 345 being developed in existing drafts. 346 Analysis and descriptions of whether and how these functions are 347 supported by the YANG models are provided in more detail in Section 348 5. 350 +-------------+-----------------------+-----------------------+ 351 | Functions | Description | Related Existing | 352 | | | YANG Models | 353 |-------------+-----------------------+-----------------------+ 354 | Obtaining |Getting the necessary | | 355 | Access |access points info | [TE-Topo] | 356 | Point Info | | | 357 +-------------+-----------------------+-----------------------+ 358 | Obtaining |Getting the topology |[TE-Topo], [WDM-Topo] | 359 | Topology |info |[ODU-Topo] | 360 +-------------+-----------------------+-----------------------+ 361 | Tunnel |Tunnel Setup, Deletion | | 362 | Operations |Modification and Info | [TE-Tunnel] | 363 | |Retrieval | | 364 +-------------+-----------------------+-----------------------+ 365 | Service |Requesting connectivity| | 366 | Request |service and retrieval | [this I.D.] | 367 | |the list of service | | 368 | |request | | 369 +-------------+-----------------------+-----------------------+ 370 | Virtual |Requesting a virtual | | 371 | Network |network and related |[TE-Topo], [WDM topo] | 372 | Operations |control operations, |[ODU-Topo] | 373 | |(e.g.,update, deletion)| | 374 +-------------+-----------------------+-----------------------+ 376 5. Function Analysis 378 5.1. Toplogy Related Functions 380 As shown in Section 4, the functions of obtaining access point 381 information, obtaining topology, and imposing virtual network 382 operations can take advantages of the same set of topology YANG 383 models. These functions are briefly explained further in the 384 following sub-sections. 386 5.1.1 Obtaining Access Point Info 388 For cases such as scenario 1, a client may have no interest in 389 directly controlling network resources, but might want an automated 390 open control interface for initiating service requests. In this 391 case, a transport controller may provide the access point 392 information. This information can then be used in service request 393 sent over the open interface. 395 The TE Topology YANG model provided in [TE-topo] can be used to 396 provide a list of links. If the remote node and termination point 397 information is unknown, it is omitted from the reported information. 398 If the client-side node and termination point information is 399 obtained via configuration or a distributed discovery mechanism, 400 then it can also be added into the reported information. 401 Technology-specific details might also be needed to further express 402 the constraints/attributes associated with the access points. Note 403 that all of this information is usually read only. 405 5.1.2 Obtaining Topology 407 Refer to [TE-Topo] for explanations and examples on how to obtain 408 the topology. For technology specific topology information, other 409 models such as those provided in [WDM-Topo] and [ODU-Topo] maybe 410 used. 412 5.1.3 Virtual Network Operations 414 There are two ways to request the creation of a virtual network. 415 One is to define the topology explicitly using the model provided in 416 the topology YANG drafts listed in Section 5.1.2.. The other way is 417 to provide an estimated traffic information (a traffic matrix) and 418 ask for a network controller of the provider network to provide a 419 virtual network that can fulfill the demand. This second approach 420 does not have a supporting model and need further work. 422 5.2. Tunnel Operations 424 Thecurrent [TE-Tunnel] provides a technology agnostic Traffic- 425 Engieering (TE) device tunnel. The model included in that draft is 426 currently being developed to make it generic for both controller and 427 device usage. It is expected that the next version of this draft 428 will provide such a generic TE tunnel model that can cater to the 429 base requirementss for tunnel operations but it may need to be 430 augmented to support controller-specific operations. 432 Futhermore, technology-specific augmentations of the base generic TE 433 tunnel models are needed. For example, for Optical Channel (OCh) 434 tunnels in WDM networks, information such as the lambda resource 435 usage is needed. Similarly, for ODU tunnels, information such as 436 the usage of tributary slots is needed. 438 5.3. Service Requests 440 The service model is an important model that enables automated 441 operations between a client controller and a provider controller. 442 The transport connectivity service model is different from the model 443 of a tunnel since the transport connectivity service model hides 444 technical details from a client. 446 A transport connectivity service model is provided below: 448 module: ietf-transport-service 449 +--rw transport_service 450 | +--rw service* [service-id] 451 | +--rw service-id uint32 452 | +--rw service-name? string 453 | +--rw source 454 | | +--rw node-id? node-id 455 | | +--rw tp-id? tp-id 456 | +--rw destination 457 | | +--rw node-id? node-id 458 | | +--rw tp-id? tp-id 459 | +--rw service-type? service-types 460 | +--rw supporting-tunnel* [name] 461 | | +--rw name string 462 | +--rw bandwidth decimal64 463 | +--rw SLA? SLAtypes 464 | +--rw intended-policies 465 | +--rw schedule 466 | +--rw schedules 467 | +--rw schedule* [schedule-id] 468 | +--rw schedule-id uint32 469 | +--rw start? yang:date-and-time 470 | +--rw schedule-duration? string 471 | +--rw repeat-interval? string 472 +--rw service-state 473 +--ro service* [service-id] 474 +--ro service-id uint32 475 +--ro service-name? string 476 +--ro source 477 | +--ro node-id? node-id 478 | +--ro tp-id? tp-id 479 +--ro destination 480 | +--ro node-id? node-id 481 | +--ro tp-id? tp-id 482 +--ro service-type? service-types 483 +--ro supporting-tunnel* [name] 484 | +--ro name string 485 +--ro bandwidth decimal64 486 +--ro SLA? SLAtypes 487 +--ro applied-policies 488 | +--ro schedule 489 | +--ro schedules 490 | +--ro schedule* [schedule-id] 491 | +--ro schedule-id uint32 492 | +--ro start? yang:date-and-time 493 | +--ro schedule-duration? string 494 | +--ro repeat-interval? string 495 +--ro status? state-types 497 The corresponding YANG code is provided below: 499 file " ietf-transport-service@2016-3-7.yang" 501 module ietf-transport-service { 502 yang-version 1; 503 namespace "urn:ietf:params:xml:ns:yang:ietf_transport_service"; 504 prefix tser; 505 import ietf-inet-types { 506 prefix inet; 507 } 509 import ietf-schedule { 510 prefix "sch"; 511 } 513 organization "TBD"; 514 contact 515 "WILL-BE-DEFINED-LATER"; 516 description 517 "this module describes a service module that is essential 518 API for a client to ask for a provider network for a path 519 without the need to care about underlying technologies. 520 Capability to specify constraints/policies are provided as 521 optional features."; 523 revision 2016-03-07 { 524 description 525 "Initial revision."; 526 reference "to add the draft name"; 527 } 529 typedef tp-id { //client termination port 530 type union { 531 type uint32; 532 type inet:ip-address; // IPv4 or IPv6 address 533 } 534 description 535 "the client termination port of a transport device"; 536 } 538 typedef node-id { //client termination port 539 type union { 540 type uint32; 541 type inet:ip-address; // IPv4 or IPv6 address 542 } 543 description 544 "the node id of a transport device"; 545 } 547 typedef service-types { 548 type enumeration { 549 enum "EPL" { 550 value 0; 551 description 552 "EPL service"; 553 } 554 enum "EVPL" { 555 value 1; 556 description 557 "EVPL"; 558 } 559 enum "EPLAN" { 560 value 2; 561 description 562 "EPLAN"; 563 } 564 enum "EVPLAN" { 565 value 3; 566 description 567 "EVPLAN"; 568 } 569 } 570 description "the type of a service request"; 571 } 573 typedef state-types{ 574 type enumeration { 575 enum "NORMAL" { 576 value 0; 577 description 578 "service is normal/up and running"; 579 } 580 enum "DOWN" { 581 value 1; 582 description 583 "service is down."; 584 } 585 enum "DEGRADED"{ 586 value 2; 587 description 588 "service is in degraded state."; 589 } 590 } 591 description "the state of a service."; 592 } 594 typedef SLAtypes{ 595 type enumeration{ 596 enum "1+1+R"{ 597 value 0; 598 description 599 "A reroute will be provided after both the working and 600 protection path fails."; 601 } 602 enum "1+1"{ 603 value 1; 604 description 605 "a protection path is provided."; 606 } 607 enum "Rerouting"{ 608 value 2; 609 description 610 "rerouting after the working path fails"; 611 } 612 enum "unprotected"{ 613 value 3; 614 description 615 "no protection provided"; 616 } 617 } 618 } 620 grouping service-basics { 621 //later put all service under so that it can reused 622 // in states. 623 leaf service-id { 624 type uint32; 625 description "an unique identificaiton of a service."; 626 } 628 leaf service-name{ 629 type string; 630 description "name for a service"; 631 } 633 container source{ 634 leaf node-id { 635 type node-id; 636 description "node id"; 637 } 638 leaf tp-id { 639 type tp-id; 640 description "TBD"; 641 } 642 description "Service source information"; 643 } 644 container destination{ 645 leaf node-id { 646 type node-id; 647 description "node id"; 648 } 649 leaf tp-id { 650 type tp-id; 651 description "TBD"; 652 } 653 description "Service destination information"; 654 } 656 leaf service-type { 657 type service-types; 658 description "the type of a service request"; 659 } 661 list supporting-tunnel{ 662 key "name"; 663 leaf name{ 664 type string; 665 description "the name of a tunnel"; 666 } 668 description "the list of tunnesl to support the list"; 669 } 671 leaf bandwidth { 672 type decimal64 { 673 fraction-digits 2; 674 } 675 mandatory true; 676 description "the bandwidth requested by a service."; 677 } 679 leaf SLA{ 680 type SLAtypes; 681 description "the type of protection expected for this 682 service"; 683 } 684 } 686 container transport_service { 687 description 688 "serves as a top-level container for a list of services"; 690 list service { 691 key "service-id"; 692 description 693 "an unique identifier of a service"; 695 uses service-basics; 697 container intended-policies { 698 container schedule { 699 uses sch:schedules; 700 description "to specify bandwidth scheduling 701 information of this service."; 702 } 703 description "specify the policy associated with a 704 service"; 705 }//end of policy 706 }//end of service list 707 }//service top container 709 container service-state 710 { 711 list service { 712 config false; 713 key "service-id"; 714 description "operational state of a service"; 716 uses service-basics; 718 container applied-policies{ 719 container schedule { 720 uses sch:schedules; 721 description "to specify bandwidth scheduling 722 information of this service."; 723 } 724 } 726 leaf status { 727 type state-types; 728 description "TBD"; 729 } 730 }//end of a service state 731 }//end of state 732 } 734 736 6. Security Considerations 738 Clearly modifying server-layer resources will have a significant 739 impact on network infrastructure. More specifically they will 740 provide the services and applications running across client-layers, 741 which the server-layer is supporting. Therefore, security must be an 742 important consideration when implementing the architecture, models 743 and protocol mechanisms discussed in this document. 745 Communicating service and network information (including access 746 point identifiers, capabilities, topologies, etc.) across external 747 interfaces represents a security risk. Thus, mechanisms to encrypt 748 or preserve the domain topology confidentiality should be used. 750 A key consideration are the external protocols (those shown as 751 entering or leaving the orchestrator and controllers shown in Figure 752 2 (Scenario 2: Multi-domain network control and management)) which 753 must be appropriately secured. This security should include 754 authentication and authorization to control access to different 755 functions that the orchestrator may perform to modify or create 756 state in the server-layer, and the establishment and management of 757 the orchestrator to controller relationship. 759 The orchestrator will contain significant data about the network 760 domains, the services carried by each domain, and customer type 761 information. Therefore, access to information held in the 762 orchestrator must be secured. Since such access will be largely 763 through external mechanisms, it may be pertinent to apply policy- 764 based controls to restrict access and functions. 766 7. Manageability Considerations 768 The core objectives of this document are to assist in the deployment 769 and operation of transport services across server-layer network 770 infrastructure. The model-driven management/control principles, 771 which are vendor-neutral and supported by extensible APIs, should be 772 utilized. 774 The open models described in this document are based on YANG 775 [RFC6020] and the RESTCONF [RESTCONF] messaging protocol, a REST- 776 like protocol running over HTTP for accessing data defined in YANG, 777 may also be used. 779 8. IANA Considerations 781 TBD. 783 9. Acknowledgements 785 Thank Igor Bryskin for useful discussions on relevant YANG models. 787 10. References 789 10.1. Normative References 791 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 792 requirements levels", RFC 2119, March 1997. 794 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 795 Network Configuration Protocol (NETCONF)", RFC 6020, 796 October 2010. 798 [ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and 799 Reviewers of YANG Data Model Documents", draft-ietf- 800 netmod-rfc6087bis-01, work in progress, October 2014. 802 10.2. Informative References 804 [TE-Topo] Liu X., Bryskin I., et al, "YANG Data Model for TE 805 Topologies", draft-ietf-teas-yang-te-topo-02, October 2015. 807 [WDM-Topo] Lee Y., et al, "A Yang Data Model for WSON Optical 808 Networks", draft-lee-ccamp-wson-yang-02, work in progress, 809 July 2015. 811 [ODU-Topo] Zhang X., Rao B., Liu X., "A YANG Data Model for Layer 1 812 Network Topology", draft-zhang-ccamp-l1-topo-yang-02, 813 December 2015. 815 [TE-Tunnel] Saad T., Gandhi R., Liu X., et al, "A YANG Data Model 816 for Traffic Engineering Tunnels and Interfaces", draft- 817 ietf-teas-yang-te-02, October, 2015. 819 [RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 820 Protocol", Work in Progress, draft-ietf-netconf-restconf- 821 09, December 2015. 823 11. Contributors' Address 825 Sergio Belotti 826 Nokia 827 Sergio.belotti@nokia.com 829 Young Lee 830 Futurewei Technologies 831 leeyoung@huawei.com 833 Aihua Guo 834 Huawei Technologies Canada 835 aihuaguo@huawei.com 837 Authors' Addresses 838 Xian Zhang 839 Huawei Technologies 840 Email: zhang.xian@huawei.com 842 Ruiquan Jing 843 China Telecom 844 jingrq@ctbri.com.cn 846 Wei Jian 847 China Unicom 848 jianwei@chinaunicom.cn 850 Jeong-dong Ryoo 851 ETRI 852 ryoo@etri.re.kr 854 Yunbin Xu 855 China Academy of Information and Communication Technology (CAICT) 856 xuyunbin@ritt.cn 858 Daniel King 859 Lancaster University 860 d.king@lancaster.ac.uk