idnits 2.17.1 draft-ietf-teas-actn-info-model-08.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 -- The document date (May 3, 2018) is 2185 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Teas Working Group Young Lee 3 Internet Draft Huawei 5 Intended status: Informational Sergio Belotti 6 Nokia 7 Expires: November 3, 2018 8 Dhruv Dhody 9 Huawei 11 Daniele Ceccarelli 12 Ericsson 14 Bin Yeong Yoon 15 ETRI 17 May 3, 2018 19 Information Model for Abstraction and Control of TE Networks (ACTN) 21 draft-ietf-teas-actn-info-model-08.txt 23 Abstract 25 This draft provides an information model for Abstraction and Control 26 of Traffic Engineered Networks (ACTN). 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on November 3, 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 (http://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 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction...................................................3 68 1.1. Terminology...............................................4 69 2. ACTN Common Interfaces Information Model.......................4 70 3. Virtual Network primitives.....................................5 71 3.1. VN Instantiate............................................6 72 3.2. VN Modify.................................................7 73 3.3. VN Delete.................................................7 74 3.4. VN Update.................................................7 75 3.5. VN Compute................................................7 76 3.6. VN Query..................................................8 77 4. Traffic Engineering (TE) primitives............................8 78 4.1. TE Instantiate............................................9 79 4.2. TE Modify.................................................9 80 4.3. TE Delete.................................................9 81 4.4. TE Topology Update (for TE resources).....................9 82 4.5. Path Compute.............................................10 83 5. VN Objects....................................................10 84 5.1. VN Identifier............................................10 85 5.2. VN Service Characteristics...............................11 86 5.3. VN End-Point.............................................13 87 5.4. VN Objective Function....................................14 88 5.5. VN Action Status.........................................15 89 5.6. VN Topology..............................................15 90 5.7. VN Member................................................15 91 5.7.1. VN Computed Path....................................16 92 5.7.2. VN Service Preference...............................16 93 6. TE Objects....................................................17 94 6.1. TE Tunnel Characteristic.................................17 95 7. Mapping of VN primitives with VN Objects......................19 96 8. Mapping of TE primitives with TE Objects......................20 97 9. Security Considerations.......................................21 98 10. IANA Considerations..........................................22 99 11. References...................................................22 100 11.1. Normative References....................................22 101 11.2. Informative References..................................22 102 12. Contributors.................................................23 103 Contributors' Addresses..........................................23 104 Authors' Addresses...............................................23 106 1. Introduction 108 This draft provides an information model for Abstraction and Control 109 of Traffic Engineered Networks (ACTN). The information model 110 described in this document covers the requirements identified in the 111 ACTN requirements document [ACTN-REQ] and the interfaces identified 112 in the ACTN architecture and framework document [ACTN-Frame]. 114 The ACTN reference architecture [ACTN-Frame] identifies a three-tier 115 control hierarchy comprising the following as depicted in Figure 1: 117 - Customer Network Controllers (CNCs) 118 - Multi-Domain Service Coordinator (MDSC) 119 - Provisioning Network Controllers (PNCs). 121 +-------+ +-------+ +-------+ 122 | CNC-A | | CNC-B | | CNC-C | 123 +-------+ +-------+ +-------+ 124 \ | / 125 ------------ | CMI ------------- 126 \ | / 127 +-----------------------+ 128 | MDSC | 129 +-----------------------+ 130 / | \ 131 ------------ | MPI ------------- 132 / | \ 133 +-------+ +-------+ +-------+ 134 | PNC | | PNC | | PNC | 135 +-------+ +-------+ +-------+ 137 Figure 1: A Three-tier ACTN control hierarchy 139 The two interfaces with respect to the MDSC, one north of the MDSC 140 and the other south of the MDSC are referred to as CMI (CNC-MDSC 141 Interface) and MPI (MDSC-PNC Interface), respectively. This document 142 models these two interfaces and derivative interfaces thereof 143 (e.g., MDSC to MDSC in a hierarchy of MDSCs) as a single common 144 interface. 146 1.1. Terminology 148 The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" 149 are defined in [ACTN-Frame] and the terms "abstraction" and 150 "abstract topology" are defined in [RFC7926]. 152 2. ACTN Common Interfaces Information Model 154 This section provides an ACTN common interface information model to 155 describe in terms of primitives, objects, their properties 156 (represented as attributes), their relationships, and the resources 157 for the service applications needed in the ACTN context. 159 The standard interface is described between a client controller and 160 a server controller. A client-server relationship is recursive 161 between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, 162 the client is a CNC while the server is an MDSC. In the MPI, the 163 client is an MDSC and the server is a PNC. There may also be MDSC- 164 MDSC interface(s) that need to be supported. This may arise in a 165 hierarchy of MDSCs in which workloads may need to be partitioned to 166 multiple MDSCs. 168 Basic primitives (messages) are required between the CNC-MDSC and 169 MDSC-PNC controllers. These primitives can then be used to support 170 different ACTN network control functions like network topology 171 request/query, VN service request, path computation and connection 172 control, VN service policy negotiation, enforcement, routing 173 options, etc. 175 There are two different types of primitives depending on the type of 176 interface: 178 - Virtual Network primitives at CMI 179 - Traffic Engineering primitives at MPI 181 As well described in [ACTN-Frame], at the CMI level, there is no 182 need for detailed TE information since the basic functionality is to 183 translate customer service information into virtual network service 184 operation. 186 At the MPI level, MDSC has the main scope for multi-domain 187 coordination and creation of a single e2e abstracted network view 188 which is strictly related to TE information. 190 As for topology, this document employs two types of topology: 192 - The first type is referred to as virtual network topology which 193 is associated with a VN. Virtual network topology is a 194 customized topology for view and control by the customer. See 195 Section 3.1 for details. 197 - The second type is referred to as TE topology which is 198 associated with provider network operation on which we can 199 apply policy to obtain the required level of abstraction to 200 represent the underlying physical network topology. 202 3. Virtual Network primitives 204 This section provides a list of main VN primitives related to 205 virtual network which are necessary to satisfy ACTN requirements 206 specified in [ACTN-REQ] 208 The following VN Action primitives are supported: 210 - VN Instantiate 212 - VN Modify 214 - VN Delete 216 - VN Update 218 - VN Path Compute 220 - VN Query 222 VN Action is an object describing the main VN primitives. 224 VN Action can assume one of the mentioned above primitives values. 226 ::= | 228 | 230 | 232 | 234 | 236 238 All these actions will solely happen at CMI level between Customer 239 Network Controller (CNC) and Multi Domain Service Coordinator 240 (MDSC). 242 3.1. VN Instantiate 244 VN Instantiate refers to an action from customers/applications to 245 request the creation of VNs. Depending on the agreement between 246 client and provider, VN instantiate can imply different VN 247 operations. There are two types of VN instantiation: 249 VN type 1: VN is viewed as a set of edge-to-edge links (VN members). 251 VN type 2: VN is viewed as a VN-topology comprising virtual nodes 252 and virtual links. 254 Please see [ACTN-Frame] for full details regarding the types of VN. 256 3.2. VN Modify 258 VN Modify refers to an action issued from customers/applications to 259 modify an existing VN (i.e., an instantiated VN). 261 VN Modify, depending of the type of VN instantiated, can be a 262 modification of the characteristics of VN members (edge-to-edge 263 links) in case of VN type 1, or a modification of an existing 264 virtual topology (e.g., adding/deleting virtual nodes/links) in case 265 of VN type 2. 267 3.3. VN Delete 269 VN Delete refers to an action issued from customers/applications to 270 delete an existing VN. 272 3.4. VN Update 274 VN Update refers to any update to the VN that needs to be updated to 275 the customers. VN Update fulfills a push model at CMI level, to make 276 customers aware of any specific changes in the topology details 277 related to the instantiated VN. 279 VN Update, depending of the type of VN instantiated, can be an 280 update of VN members (edge-to-edge links) in case of VN type 1, or 281 an update of virtual topology in case of VN type 2. 283 The connection-related information (e.g., LSPs) update association 284 with VNs will be part of the "translation" function that happens in 285 MDSC to map/translate VN request into TE semantics. This information 286 will be provided in case customer optionally wants to have more 287 detailed TE information associated with the instantiated VN. 289 3.5. VN Compute 291 VN Compute consists of Request and Reply. Request refers to an 292 action from customers/applications to request a VN computation. 294 VN Compute Reply refers to the reply in response to VN Compute 295 Request. 297 VN Compute Request/Reply is to be differentiated from a VN 298 Instantiate. The purpose of VN Compute is a priori exploration to 299 compute network resources availability and getting a possible VN 300 view in which path details can be specified matching 301 customer/applications constraints. This a priori exploration may not 302 guarantee the availability of the computed network resources at the 303 time of instantiation. 305 3.6. VN Query 307 VN Query refers to an inquiry pertaining to a VN that has already 308 been instantiated. VN Query fulfills a pull model that permits 309 getting a topology view. 311 VN Query Reply refers to the reply in response to VN Query. The 312 topology view returned by VN Query Reply would be consistent with 313 the topology type instantiated for any specific VN. 315 4. Traffic Engineering (TE) primitives 317 This section provides a list of the main TE primitives necessary to 318 satisfy ACTN requirements specified in [ACTN-REQ] related to typical 319 TE operations supported at the MPI level. 321 The TE action primitives defined in this section should be supported 322 at the MPI consistently with the type of topology defined at the 323 CMI. 325 The following TE action primitives are supported: 327 - TE Instantiate/Modify/Delete 329 - TE Topology Update (See Section 4.4. for the description) 331 - Path Compute 333 TE Action is an object describing the main TE primitives. 335 TE Action can assume one of the mentioned above primitives values. 337 ::= | 339 | 341 | 343 | 345 | 347 All these actions will solely happen at MPI level between Multi 348 Domain Service Coordinator (MDSC) and Provisioning Network 349 Controller (PNC). 351 4.1. TE Instantiate 353 TE Instantiate refers to an action issued from MDSC to PNC to 354 instantiate new TE tunnels. 356 4.2. TE Modify 358 TE Modify refers to an action issued from MDSC to PNC to modify 359 existing TE tunnels. 361 4.3. TE Delete 363 TE Delete refers to an action issued from MDSC to PNC to delete 364 existing TE tunnels. 366 4.4. TE Topology Update (for TE resources) 368 TE Topology Update is a primitive specifically related to MPI to 369 provide TE resource update between any domain controller towards 370 MDSC regarding the entire content of any "domain controller" actual 371 TE topology or an abstracted filtered view of TE topology depending 372 on negotiated policy. 374 See [TE-TOPO] for detailed YANG implementation of TE topology 375 update. 377 ::= 379 ::= [] 381 ::= [] 384 ::= [] 385 ::= 387 ::= [] 390 ::= [] 392 Where 394 Abstraction provides information on level of abstraction (as 395 determined a priori). 397 TE-topology-identifier is an identifier that identifies a specific 398 te-topology, e.g., te-types:te-topology-id [TE-TOPO]. 400 Node-list is detailed information related to a specific node 401 belonging to a te-topology, e.g., te-node-attributes [TE-TOPO]. 403 Link-list is information related to the specific link related 404 belonging to a te-topology, e.g., te-link-attributes [TE-TOPO]. 406 TE Termination Point-list is detailed information associated with 407 the termination points of te-link related to a specific node, e.g., 408 interface-switching-capability [TE-TOPO]. 410 4.5. Path Compute 412 Path Compute consists of Request and Reply. Request refers to an 413 action from MDSC to PNC to request a path computation. 415 Path Compute Reply refers to the reply in response to Path Compute 416 Request. 418 The context of Path Compute is described in [Path-Compute]. 420 5. VN Objects 422 This section provides a list of objects associated to VN action 423 primitives. 425 5.1. VN Identifier 427 VN Identifier is a unique identifier of the VN. 429 5.2. VN Service Characteristics 431 VN Service Characteristics describes the customer/application 432 requirements against the VNs to be instantiated. 434 ::= 436 438 (...) 440 442 Where 444 ::= |||| 447 The Connectivity Type identifies the type of required VN Service. In 448 addition to the classical type of services (e.g. P2P/P2MP etc.), 449 ACTN defines the "multi-destination" service that is a new P2P 450 service where the end points are not fixed. They can be chosen among 451 a list of pre-configured end points or dynamically provided by the 452 CNC. 454 VN Directionality indicates if a VN is unidirectional or 455 bidirectional. This implies that each VN member that belongs to the 456 VN has the same directionality as the VN. 458 ::= 460 [] 462 The VN Traffic Matrix represents the traffic matrix parameters for 463 the required service connectivity. Bandwidth is a mandatory 464 parameter and a number of optional constraints can be specified in 465 the VN Constraints (e.g. diversity, cost). They can include 466 objective functions and TE metrics bounds as specified in [RFC5541]. 468 Further details on the VN constraints are specified below: 470 ::= [] 472 [] 474 ( | ) 476 Where: 478 Layer Protocol identifies the layer topology at which the VN 479 service is requested. It could be for example MPLS, ODU, and OCh. 481 Diversity allows asking for diversity constraints for a VN 482 Instantiate/Modify or a VN Path Compute. For example, a new VN or 483 a path is requested in total diversity from an existing one (e.g. 484 diversity exclusion). 486 ::= ( (...)) | 488 ( (...)) 490 Metric can include all the Metrics (cost, delay, delay variation, 491 latency), bandwidth utilization parameters defined and referenced 492 by [RFC3630] and [RFC7471]. 494 As for VN Objective Function See Section 5.4. 496 VN Survivability describes all attributes related to the VN recovery 497 level and its survivability policy enforced by the 498 customers/applications. 500 ::= 502 [] 504 [] 506 Where: 508 VN Recovery Level is a value representing the requested level 509 of resiliency required against the VN. The following values 510 are defined: 512 . Unprotected VN 513 . VN with per tunnel recovery: The recovery level is defined 514 against the tunnels composing the VN and it is specified in 515 the VN Tunnel Recovery Level. 517 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 519 521 The VN Tunnel Recovery Level indicates the type of protection 522 or restoration mechanism applied to the VN. It augments the 523 recovery types defined in [RFC4427]. 525 ::= [] 527 [] 529 [] 531 [] 533 Where: 535 Local Reroute Allowed is a delegation policy to the Server to 536 allow or not a local reroute fix upon a failure of the 537 primary LSP. 539 Domain Preference is only applied on the MPI where the MDSC 540 (client) provides a domain preference to each PNC (server), 541 e.g., when an inter-domain link fails, then PNC can choose 542 the alternative peering with this info. 544 Push Allowed is a policy that allows a server to trigger an 545 updated VN topology upon failure without an explicit request 546 from the client. Push action can be set as default unless 547 otherwise specified. 549 Incremental Update is another policy that triggers an 550 incremental update from the server since the last period of 551 update. Incremental update can be set as default unless 552 otherwise specified. 554 5.3. VN End-Point 556 VN End-Point Object describes the VN's customer end-point 557 characteristics. 559 ::= ( 561 [] 563 [])... 565 Where: 567 Access Point Identifier represents a unique identifier of the 568 client end-point. They are used by the customer to ask for the 569 setup of a virtual network instantiation. A VN End-Point is 570 defined against each AP in the network and is shared between 571 customer and provider. Both the customer and the provider will map 572 it against their own physical resources. 574 Access Link Capability identifies the capabilities of the access 575 link related to the given access point. (e.g., max-bandwidth, 576 bandwidth availability, etc.) 578 Source Indicator indicates if an end-point is source or not. 580 5.4. VN Objective Function 582 The VN Objective Function applies to each VN member (i.e., each E2E 583 tunnel) of a VN. 585 The VN Objective Function can reuse objective functions defined in 586 [RFC5541] section 4. 588 For a single path computation, the following objective functions are 589 defined: 591 o MCP is the Minimum Cost Path with respect to a specific 592 metric (e.g. shortest path). 593 o MLP is the Minimum Load Path, that means find a path 594 composted by te-link least loaded. 595 o MBP is the Maximum residual Bandwidth Path. 597 For a concurrent path computation, the following objective functions 598 are defined: 600 o MBC is to Minimize aggregate Bandwidth Consumption. 601 o MLL is to Minimize the Load of the most loaded Link. 602 o MCC is to Minimize the Cumulative Cost of a set of paths. 604 5.5. VN Action Status 606 VN Action Status is the status indicator whether the VN has been 607 successfully instantiated, modified, or deleted in the server 608 network or not in response to a particular VN action. 610 Note that this action status object can be implicitly indicated and 611 thus not included in any of the VN primitives discussed in Section 612 3. 614 5.6. VN Topology 616 When a VN is seen by the customer as a topology, it is referred to 617 as VN topology. This is associated with VN Type 2, which is composed 618 of virtual nodes and virtual links. 620 ::= 622 ::= [] 624 :: = [] 626 5.7. VN Member 628 VN Member describes details of a VN Member which is a list of a set 629 of VN Members represented as VN_Member_List. 631 ::= [] 633 Where ::= 635 [] 637 639 Ingress VN End-Point is the VN End-Point information for the ingress 640 portion of the AP. See Section 5.3 for VN End-Point details. 642 Egress VN End-Point is the VN End-Point information for the egress 643 portion of the AP. See Section 5.3 for VN End-Point details. 645 VN Associated LSP describes the instantiated LSPs in the Provider's 646 network for the VN Type 1. It describes the instantiated LSPs over 647 the VN topology for VN Type 2. 649 5.7.1. VN Computed Path 651 The VN Computed Path is the list of paths obtained after the VN path 652 computation request from a higher controller. Note that the computed 653 path is to be distinguished from the LSP. When the computed path is 654 signaled in the network (and thus the resource is reserved for that 655 path), it becomes an LSP. 657 ::= (...) 659 5.7.2. VN Service Preference 661 This section provides VN Service preference. VN Service is defined 662 in Section 2. 664 ::= [] 666 [] 668 [] 670 Where 672 Location Service Preference describes the End-Point Location's 673 (e.g. Data Centers) support for certain Virtual Network Functions 674 (VNFs) (e.g., security function, firewall capability, etc.) and 675 is used to find the path that satisfies the VNF constraint. 677 Client-specific Preference describes any preference related to 678 Virtual Network Service (VNS) that application/client can enforce 679 via CNC towards lower level controllers. For example, permission 680 the correct selection from the network of the destination related 681 to the indicated VNF It is e.g. the case of VM migration among 682 data center and CNC can enforce specific policy that can permit 683 MDSC/PNC to calculate the correct path for the connectivity 684 supporting the data center interconnection required by 685 application. 687 End-Point Dynamic Selection Preference describes if the End-Point 688 (e.g. Data Center) can support load balancing, disaster recovery 689 or VM migration and so can be part of the selection by MDSC 690 following service Preference enforcement by CNC. 692 6. TE Objects 694 6.1. TE Tunnel Characteristics 696 Tunnel Characteristics describes the parameters needed to configure 697 TE tunnel. 699 ::= [] 701 703 [] 705 [] 707 [] 709 711 [] 713 Where 715 ::= ||| 717 The Tunnel Type identifies the type of required tunnel. In this 718 draft, only P2P model is provided. 720 Tunnel Id is the TE tunnel identifier. 722 Tunnel Layer represents the layer technology of the LSPs 723 supporting the tunnel. 725 ::= 727 ::= ||||prot | 729 Tunnel Constraints are the base tunnel configuration constraints 730 parameters. 732 Where ::= [] 734 [] 736 [] 738 [] 740 [] 742 [] 744 [] 746 [] 748 Topology Id references the topology used to compute the tunnel path. 750 Bandwidth is the bandwidth used as parameter in path computation 752 ::= | | 754 Disjointness provides the type of resources from which the tunnel 755 has to be disjointed 757 SRLG is a group of physical resources impacted by the same risk from 758 which an E2E tunnel is required to be disjointed. 760 ::= 762 where 764 Setup Priority indicates the level of priority for taking resources 765 from another tunnel [RFC3209] 767 Holding Priority indicates the level of priority to hold resources 768 avoiding preemption from another tunnel [RFC3209] 770 Affinities represent structure to validate link belonging to path 771 of the tunnel [RFC3209] 773 ::= | 774 Metric can include all the Metrics (cost, delay, delay variation, 775 latency), bandwidth utilization parameters defined and referenced by 776 [RFC3630] and [RFC7471]. 778 ::= 780 ::= | | | | 781 | 783 See chapter 5.4 for objective function type description. 785 7. Mapping of VN primitives with VN Objects 787 This section describes the mapping of VN primitives with VN Objects 788 based on Section 5. 790 ::= 792 794 [] 796 [] 798 ::= 800 802 804 [] 806 [] 808 ::= 810 :: = 812 [] 814 [] 816 ::= 818 820 [] 822 ::= 824 ::= 826 ::= 828 830 [] 832 8. Mapping of TE primitives with TE Objects 834 This section describes the mapping of TE primitives with TE Objects 835 based on Section 6. 837 ::= 839 ::= 841 ::= 842 ::= 844 ::= 846 ::= 848 850 9. Security Considerations 852 The ACTN information model described in this document defines key 853 interfaces for managed traffic engineered networks. Securing the 854 request and control of resources, confidentiality of the 855 information, and availability of function, should all be critical 856 security considerations when deploying and operating ACTN platforms. 858 Several distributed ACTN functional components are required, and 859 implementations should consider encrypting data that flows between 860 components, especially when they are implemented at remote nodes, 861 regardless of these data flows are on external or internal network 862 interfaces. 864 The ACTN security discussion is further split into two specific 865 categories described in the following sub-sections: 867 - Interface between the Customer Network Controller and Multi Domain 868 Service Coordinator (MDSC), CNC-MDSC Interface (CMI) 870 - Interface between the Multi Domain Service Coordinator and 871 Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) 873 From a security and reliability perspective, ACTN may encounter many 874 risks such as malicious attack and rogue elements attempting to 875 connect to various ACTN components. Furthermore, some ACTN 876 components represent a single point of failure and threat vector, 877 and must also manage policy conflicts, and eavesdropping of 878 communication between different ACTN components. 880 The conclusion is that all data models and protocols used to realize 881 the ACTN info model should have rich security features, and 882 customer, application and network data should be stored in encrypted 883 data stores. Additional security risks may still exist. Therefore, 884 discussion and applicability of specific security functions and 885 protocols will be better described in documents that are use case 886 and environment specific. 888 10. IANA Considerations 890 This document has no actions for IANA. 892 11. References 894 11.1. Normative References 896 [ACTN-REQ] Y. Lee, et al., "Requirements for Abstraction and Control 897 of Transport Networks", draft-ietf-teas-actn-requirements, 898 work in progress. 900 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 901 Control of Transport Networks", draft-ietf-teas-actn- 902 framework, work in progress. 904 11.2. Informative References 906 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 907 draft-ietf-teas-yang-te-topo, work in progress. 909 [RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 910 Tunnels", RFC 3209, December 2001. 912 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 913 Extensions to OSPF Version 2", RFC 3630, September 2003. 915 [RFC4427] E. Mannie, D. Papadimitriou (Editors), "Recovery 916 (Protection and Restoration) Terminology for Generalized 917 Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 918 2006. 920 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of 921 Objective Functions in the Path Computation Element 922 Communication Protocol (PCEP)", RFC 5541, June 2009. 924 [RFC7471] S. Giacalone, et al, "OSPF Traffic Engineering (TE) Metric 925 Extensions", RFC 7471, March 2015. 927 [RFC7926] A. Farrel, et al., "Problem Statement and Architecture for 928 Information Exchange between Interconnected Traffic- 929 Engineered Networks", RFC 7926, July 2016. 931 [Path-Compute] I. Busi, S. Belotti, et al., "Yang model for 932 requesting Path Computation", draft-ietf-teas-yang-path- 933 computation", work in progress. 935 12. Contributors 937 Contributors' Addresses 939 Haomian Zheng 940 Huawei Technologies 941 Email: zhenghaomian@huawei.com 943 Xian Zhang 944 Huawei Technologies 945 Email: zhang.xian@huawei.com 947 Authors' Addresses 949 Young Lee (Editor) 950 Huawei Technologies 951 5340 Legacy Drive 952 Plano, TX 75023, USA 953 Phone: (469)277-5838 954 Email: leeyoung@huawei.com 956 Sergio Belotti (Editor) 957 Alcatel Lucent 958 Via Trento, 30 959 Vimercate, Italy 960 Email: sergio.belotti@alcatel-lucent.com 962 Dhruv Dhody 963 Huawei Technologies, 964 Divyashree Technopark, Whitefield 965 Bangalore, India 966 Email: dhruv.ietf@gmail.com 968 Daniele Ceccarelli 969 Ericsson 970 Torshamnsgatan,48 971 Stockholm, Sweden 972 Email: daniele.ceccarelli@ericsson.com 974 Bin Yeong Yoon 975 ETRI 976 Email: byyun@etri.re.kr