idnits 2.17.00 (12 Aug 2021) /tmp/idnits14535/draft-xia-sdnrg-service-description-language-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 : ---------------------------------------------------------------------------- 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 (October 27, 2014) is 2763 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG Y. Xia, Ed. 3 Internet-Draft S. Jiang, Ed. 4 Intended status: Informational S. Hares 5 Expires: April 30, 2015 Huawei Technologies Co., Ltd 6 October 27, 2014 8 Requirements for a Service Description Language and Design 9 Considerations 10 draft-xia-sdnrg-service-description-language-01 12 Abstract 14 The more and more complicated IP networks require a new interaction 15 mechanism between their customers and their networks. A service 16 description language is needed to enable customers to easily describe 17 their diverse intent. SDN controller would compile the user intent 18 into device configurations. This document analyzes requirements for 19 such service description language and gives considerations for 20 designing such service description language. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Analysis of Network Customer's Intent . . . . . . . . . . . . 4 59 3.1. An Example of User Intent . . . . . . . . . . . . . . . . 4 60 4. Design Consideration . . . . . . . . . . . . . . . . . . . . 4 61 4.1. A Description Example of Service Requirements . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The IP networks of the Internet Service Providers (ISPs) and data 71 centers are becoming more and more big and complicated. 72 Simultaneously, the services that are demanded by their customers, 73 particularly the upper layer applications, are also becoming more and 74 more complicated. The rigid service models are lacking the 75 flexibility to meet the various requirements/scenarios. A better 76 form would be that the network customers are allowed to customize 77 their own services as they need. 79 Recently, there are many efforts have been made on opening the IP 80 devices and networks. Today, there are many open APIs from different 81 vendors, such as OnePK from Cisco, OPS from Huawei, and etc. They 82 are mainly device-oriented interfaces. Interface to the Routing 83 System (I2RS) WG is working to allow information, policies, and 84 operational parameters to be injected into and retrieved from the 85 routing system. It makes possible for user application to directly 86 intervene in the running routes, or deploy specific demands. 88 However, such open interfaces are bottom-up designed according to the 89 devices. One has to be very familiar with devices in order to 90 correctly "programming" his intent. Such interfaces are far from 91 user-friendly. Particularly, for many upper layer applications, 92 their demands may involve hundreds and thousands devices. It is very 93 difficult for a network customer to direct program network devices. 95 Software-Defined Networking (SDN) controller has taken such 96 responsibility: hide the complexity of networks from customers, 97 receive abstracted intent from customers, and compile/translate the 98 intent into detailed control operations that can directly execute on 99 network devices. This would allow network customers to be released 100 them the burden of selecting useful information and capability from 101 vast information and capability of the infrastructure network. 103 The interactions between SDN controller and network customers should 104 be as simple as possible. The network customers should be allowed to 105 describe their demands in their own way, which is as close as 106 possible to their intent. Consequently, the northbound interface of 107 SDN controller must be different from the northbound interface of 108 network devices, which actually matches the southbound interface of 109 SDN controller. This northbound interface of SDN controller should 110 be designed using top-domain methodology, so that network customers 111 can use it as easy as possible. 113 This document starts from analyzing the intent from network 114 customers, tries to epurate technical requirements for a service 115 description language and the design consideration for a such 116 language. A few typical examples of network customers' demands and 117 their description examples are also given. 119 The interaction between the SDN controller and the IP infrastructure 120 network, such as how the information and capability of infrastructure 121 networks are abstracted, how network capabilities are executed and 122 how the service logic is translated, are out of scope of this 123 document. 125 2. Terminology 127 SDN Controller An application in Software-Defined Networking (SDN) 128 that manages flow control. It controls manages a number of 129 network devices in the infrastructure network, regarding how to 130 forwarding IP packets. 132 Northbound Interface of SDN Controller An interactive interface 133 between SDN controller and network customers. It receives the 134 customer orders in both data form or service logic form. 136 Northbound Interface of Network Device An interactive interface that 137 allows SDN controller, or network management system to directly 138 operate the network devices. 140 Service Description Language A language used to describe specific 141 service demands by the network customers. 143 3. Analysis of Network Customer's Intent 145 The network customers do not care the detailed configurations of each 146 device, or flow entries in each device, even when their service flows 147 go through these devices. They do not want to be bored the detailed 148 device-oriented operations, such as tunnel management, isolation with 149 other services, PBR configurations of different devices. What the 150 network customers care about is the service demand they require and 151 the service quality they receive. 153 3.1. An Example of User Intent 155 A typical network customer's intent would firstly start from 156 connectivities: connect the two datacenters that locate in two 157 cities. For security reasons, the customer normally want to organize 158 all their connectivities as a virtual network. For example, a tenant 159 needs two connections to carry different service flows between two 160 datacenters. 162 Then, the customer normally need to appoint the quality of service or 163 choose from certain Service Level Agreement (SLA) for this 164 connectivity. For example, one connection of the tenant is 40G 165 bandwidth with less than 400ms delay, another connection is 100M 166 bandwidth with less than 50ms delay. 168 Typically, traffics of customers could be categorized into several 169 classes, which match with different SLAs. For example, the tenant 170 has two types of traffic, CDN sync traffic and online game traffic. 171 CDN Sync traffic uses high bandwidth connection and online game 172 traffic uses low latency connection. 174 Furthermore, the customer may demand some flows go through a certain 175 intermedia server, such as firewall or WOC. 177 The customer may want to organize his few demands together with 178 certain choosing circumstances, for example the tenant wants the 179 online game traffic to go through WOC in nighttime before it is 180 carried by low latency connection. 182 In some scenarios, the customer flows may be needed to be presented 183 by various form. For example, client/server flows normally come from 184 different and distributed sources. 186 4. Design Consideration 188 The purpose of a service description language is to describe the 189 network customer's intent. The SDN controller or network 190 administration system then compile them into the operations of 191 network devices. 193 The language should have the below ability: 195 o be able to describe customer traffics which can be identified as 196 flows; 198 o be able to describe access node, virtual network, servers, and 199 other network entities that the network customers apperceive; 201 o be able to describe QoS, SLAs and other relevant properties; 203 o be able to describe logic that combine a few demands together with 204 certain choosing circumstances; 206 o be able to describe the necessary information from the network 207 (e.g. SDN controller), so that the network customer can describe 208 their intent accordingly; 210 o easy to extend in order to support various new services or demands 211 that may appear in the future. 213 4.1. A Description Example of Service Requirements 215 A tenant needs two connections to carry different service flows 216 between two datacenters. one connection of the tenant is 40G 217 bandwidth with less than 400ms delay, another connection is 100M 218 bandwidth with less than 50ms delay. 220 { 221 Link Link1_id 222 Endnodes (DC1_node_id, DC2_node_id) 223 Property "NAME","DC1_DC2_link_one","Bandwith",40G, "Delay",400ms 225 Link Link2_id 226 Endnodes (DC1_node_id, DC2_node_id) 227 Property "NAME","DC1_DC2_link_two","Bandwith",100M, "Delay",50ms 228 } 230 The tenant has two types of traffic, CDN sync traffic uses high 231 bandwidth connection and online game traffic uses low latency 232 connection. 234 { 235 Flow flow1_id 236 Match "srcip","10.0.1.1/24","dstip",?20.0.1.1/24","Port","55555" 237 Property "NAME", "CDN sync flow", "Bidirection","true? 239 Flow flow2_id 240 Match "srcip","10.0.1.1/24","dstip",?20.0.1.1/24","Port","56663" 241 Property "NAME", "online Game", "Bidirection","true? 243 Policy policy1_id 244 Appliesto flow1_id 245 Action "forwardto", link1_id 247 Policy policy2_id 248 Appliesto flow2_id 249 Action "gothrough", link2_id 250 } 252 the tenant wants the online game traffic to go through WOC in 253 nighttime before it is carried by low latency connection. 255 { 256 Policy policy3_id 257 Appliesto flow2_id 258 Condition {Time>18:00 or Time< 2:00} 259 Action "gothrough", {woc_node_id ,link2_id} 260 } 262 5. Security Considerations 264 Because the network customers are allowed to customize their own 265 services, they may bring potentially big impacts to a running IP 266 network. A strong user authentication mechanism is needed for the 267 northbound interface of the SDN controller. User authorization 268 should be carefully managed by the network administrator to avoid any 269 dangerous operations and prevent any abuse of network resources. 271 6. IANA Considerations 273 This memo includes no request to IANA. 275 7. Acknowledgements 277 The authors would like to thanks the valuable comments made by Wei 278 Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei. 280 This document was produced using the xml2rfc tool [RFC2629]. 282 8. Informative References 284 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 285 June 1999. 287 Authors' Addresses 289 Yinben Xia (editor) 290 Huawei Technologies Co., Ltd 291 Q14, Huawei Campus, No.156 Beiqing Road 292 Hai-Dian District, Beijing, 100095 293 P.R. China 295 Email: xiayinben@huawei.com 297 Sheng Jiang (editor) 298 Huawei Technologies Co., Ltd 299 Q14, Huawei Campus, No.156 Beiqing Road 300 Hai-Dian District, Beijing, 100095 301 P.R. China 303 Email: jiangsheng@huawei.com 305 Susan Hares 306 Huawei Technologies Co., Ltd 307 7453 Hickory Hill 308 Saline, CA 48176 309 USA 311 Email: shares@ndzh.com