idnits 2.17.1 draft-xia-sdnrg-service-description-language-02.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 4, 2015) is 3279 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: November 5, 2015 Huawei Technologies Co., Ltd 6 May 4, 2015 8 Requirements for a Service Description Language and Design 9 Considerations 10 draft-xia-sdnrg-service-description-language-02 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 November 5, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 wants to 158 organize all their connectivities as a virtual network. For example, 159 a tenant needs two connections to carry different service flows 160 between two 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 intermediate 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 business group, and function group, that the 199 network customers apperceive, such as, virtual network, firewall, 200 load balance, etc.; 202 o be able to describe QoS, SLAs and other relevant properties; 204 o be able to describe logic that combine a few demands together with 205 certain choosing circumstances; 207 o be able to describe the necessary information from the network 208 (e.g. SDN controller), so that the network customer can describe 209 their intent accordingly; 211 o easy to extend in order to support various new services or demands 212 that may appear in the future. 214 4.1. A Description Example of Service Requirements 216 A tenant needs two connections to carry different service flows 217 between two datacenters. one connection of the tenant is 40G 218 bandwidth with less than 400ms delay, another connection is 100M 219 bandwidth with less than 50ms delay. 221 { 222 Connection connection1_id 223 Endnodes (DC1_node_id, DC2_node_id) 224 Property "NAME","DC1_DC2_connection_one","Bandwith",40G, "Delay", 225 400ms 227 Connection connection2_id 228 Endnodes (DC1_node_id, DC2_node_id) 229 Property "NAME","DC1_DC2_connection_two","Bandwith",100M, "Delay", 230 50ms 231 } 233 The tenant has two types of traffic, CDN sync traffic uses high 234 bandwidth connection and online game traffic uses low latency 235 connection. 237 { 238 Flow flow1_id 239 Match "srcip","192.0.2.0/24","dstip","198.51.100.0/24","Port", 240 "55555" 241 Property "NAME", "CDN sync flow", "Bidirection","true" 243 Flow flow2_id 244 Match "srcip","192.0.2.0/24","dstip","198.51.100.0/24","Port", 245 "56663" 246 Property "NAME", "online Game", "Bidirection","true" 248 Policy policy1_id 249 Appliesto flow1_id 250 Action "forwardto", connection1_id 252 Policy policy2_id 253 Appliesto flow2_id 254 Action "gothrough", connection2_id 255 } 257 the tenant wants the online game traffic to go through WOC in 258 nighttime before it is carried by low latency connection. 260 { 261 Policy policy3_id 262 Appliesto flow2_id 263 Condition {Time>18:00 or Time< 2:00} 264 Action "gothrough", {woc_node_id ,connection2_id} 265 } 267 5. Security Considerations 269 Because the network customers are allowed to customize their own 270 services, they may bring potentially big impacts to a running IP 271 network. A strong user authentication mechanism is needed for the 272 northbound interface of the SDN controller. User authorization 273 should be carefully managed by the network administrator to avoid any 274 dangerous operations and prevent any abuse of network resources. 276 6. IANA Considerations 278 This memo includes no request to IANA. 280 7. Acknowledgements 282 The authors would like to thanks the valuable comments made by Wei 283 Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei. 285 This document was produced using the xml2rfc tool [RFC2629]. 287 8. Informative References 289 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 290 June 1999. 292 Authors' Addresses 294 Yinben Xia (editor) 295 Huawei Technologies Co., Ltd 296 Q14, Huawei Campus, No.156 Beiqing Road 297 Hai-Dian District, Beijing, 100095 298 P.R. China 300 Email: xiayinben@huawei.com 302 Sheng Jiang (editor) 303 Huawei Technologies Co., Ltd 304 Q14, Huawei Campus, No.156 Beiqing Road 305 Hai-Dian District, Beijing, 100095 306 P.R. China 308 Email: jiangsheng@huawei.com 310 Susan Hares 311 Huawei Technologies Co., Ltd 312 7453 Hickory Hill 313 Saline, CA 48176 314 USA 316 Email: shares@ndzh.com