idnits 2.17.1 draft-zhuge-sdnrg-sdn-sdp-04.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 42 instances of too long lines in the document, the longest one being 11 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 date (November 16, 2016) is 2717 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: 'China-Communications' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'ONF-White-Paper' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC5812' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC6956' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC7426' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'Telecommunications-Science' is defined on line 677, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Zhuge 3 Internet-Draft Zhejiang Gongshang University 4 Intended status: Standards Track Y. Wang 5 Expires: May 20, 2017 Simon Fraser University 6 Y. Zhu 7 H. Zhu 8 W. Wang 9 Zhejiang Gongshang University 10 November 16, 2016 12 An SDN Framework bases on Meta-Model with Software-Defined Pricing (SDP) 13 draft-zhuge-sdnrg-sdn-sdp-04 15 Abstract 17 This document defines a notion called Software-Defined Pricing (SDP) 18 and introduces it into a Software-Defined Networks (SDN) framework. 19 The SDN system with SDP inside is expected to promote the efficiency 20 on SDN resources usage and ease management for service providers. 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 May 20, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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. Software-Defined Pricing (SDP) . . . . . . . . . . . . . . . 2 58 3. SDN with SDP . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Adopting SDP in SDN . . . . . . . . . . . . . . . . . . . 5 60 3.2. Framework of SDN with SDP . . . . . . . . . . . . . . . . 6 61 3.3. Framework of SDN Bases on Meta-Model . . . . . . . . . . 10 62 3.4. The Relationship between the Layers in the SDN Framework 63 with SDP Bases on Meta-Model . . . . . . . . . . . . . . 13 64 4. The Trading between the Layers . . . . . . . . . . . . . . . 14 65 5. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 7. Informative References . . . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 70 1. Introduction 72 Software-Defined Networks(SDN) is in the research process. With the 73 idea of SDN, networking resources like switches, routers and types of 74 Network Elements (NEs)are managed as kinds of virtual resources, 75 forming virtual networks so as to provide rather flexible services to 76 network users. In this research process, we noticed that how to 77 price the services and the use of virtual network resources in an SDN 78 is as critical as how the SDN is defined. We consider that it seems 79 a precious idea to treat a service pricing mechanism as part of the 80 SDN framework and to manage it in a software-defined way. 82 Network service prices are traditionally determined by service 83 providers in a rather rigid way, which lacks of flexibility and 84 sometimes even fairness to resources users. By means of the idea of 85 SDP, it is able to treat service pricing as a part of SDN, forming a 86 service pricing model flexible to time, traffic and other network 87 factors and status. In this way, it is expected to promote the 88 efficiency of SDN resources usage and ease the management for service 89 providers. 91 2. Software-Defined Pricing (SDP) 93 Software-Defined Pricing (SDP) is an idea specific to network 94 management, whose core is that the service prices of network 95 resources are determined by means of software-defined algorithms and/ 96 or mechanisms, which figure the prices according to various factors 97 and status of the network resources. In contrast to SDP, service 98 prices may be pre-determined rigidly by service providers. 100 An SDP Protocol is an instance of SDP implementation shown in a way 101 of protocol, which specifically defines algorithms and/or mechanisms 102 to price specific services and use of network resources. An SDP 103 protocol may be a private protocol if it is defined by a service 104 provider personally, or a public protocol if defined publicly by 105 standardization organizations. 107 By use of the software-defined mechanism, SDP essentially supports 108 automatic negotiations of prices in a pricing process. Automatic 109 resource and price negotiation features a Guaranteed Service (GS). 110 As a result, SDN with SDP essentially supports GS services. 112 Network users must accept and abide by the network SDP protocol when 113 they use the network resources and the services. 115 An SDP protocol usually includes trading partners, trading content, 116 obligations and other transaction costs. Service providers can make 117 provisions for users in terms of workload and resource use. 119 As an example, we present a typical process for an SDP protocol. 120 When users expect to use resources from a virtual network by a 121 service provider, users first query prices of various resources and 122 services by means of the SDP protocol. The service provider returns 123 the resource prices to users. Then, users will start up a price 124 negotiation process with the service provider by use of the SDP 125 protocol. Both the user and the service provider will proceed the 126 price negotiation process based on their specific price negotiation 127 algorithms. The negotiation process will be ended only from the user 128 with the SDP protocol. It will end with an agreement is either met 129 or not. The SDP protocol process is shown in Figure 1. Usually, in 130 a negotiation algorithm, the user or the service provider are able to 131 take into consideration of current network status and other network 132 factors, which make the price negotiation process much more efficient 133 and flexible than traditional pricing methods. 135 +------+ + + +-----------+ 136 | | | --------SDP protocol------->| -----------------+ | | 137 | | | | search price | | | 138 | | | <-------SDP protocol--------|<-----------------+ | | 139 | | | --------SDP protocol------->|------------------+ | service | 140 | user | | | price negotiation| | sprovider | 141 | | | <-------SDP protocol--------|<-----------------+ | | 142 | | | --------SDP protocol------->|------------------+ | | 143 | | | | negotiation ends | | | 144 | | | <-------SDP protocol--------|<-----------------+ | | 145 +------+ + + +-----------+ 147 Figure 1: Process of an SDP Protocol 149 To fulfill above process, an SDP protocol header may usually include 150 fields like shown in Figure 2, where: 152 o ID: the unique identifier of the protocol header. 154 o Level: service priorities identified. 156 o Expression: including one or more ITP(ID-Type-Properties) formats, 157 where ID is the unique identifier of a resource, Type is the type 158 of resource, Properties is the attributes of the resource. 160 o TimeSpec: a structure of service time, mainly refers to the 161 selection of the service period. 163 o Price: the price of the transaction. 165 o ContractTime: trading hours. 167 o State: trading status with success or failure. 169 +----------------------------------------------------------------------+ 170 | ID | Level | Expression | TimeSpec | Price | ContractTime | State | 171 +------------|------------|----------|---------------------------------+ 172 | | 173 | +----------------------+ 174 V | 175 +------------------------+ | 176 | ID | Type | Properties | | 177 +-----------|------------+ V 178 | +-------------------------------------+ 179 | | Y/M/D | Mon-Fri/Weekend | 8:00-0:00 | 180 V +-------------------------------------+ 181 +-----------------------------------------+ 182 | rate | delay | shake | etc. | 183 +-----------------------------------------+ 185 Figure 2: An SDP Protocol Header 187 (TBD) 189 3. SDN with SDP 191 3.1. Adopting SDP in SDN 193 SDP can be applied to SDN architecture well because of its natural 194 software-defined feature. 196 In SDN architecture, control plane and data plane are separated to 197 achieve the segregation of the control and forwarding. A typical SDN 198 architecture usually includes: application layer, control layer, and 199 infrastructure (forwarding) layer. To adopt SDP in SDN, an SDP 200 module is applied. An SDP module implements the SDP protocol and 201 corresponding negotiation algorithms/mechanisms. An SDP module can 202 be applied to any layer in the SDN, where resources need to be 203 priced. In this way, theoretically, all kinds of network resources 204 and services can be programmed in terms of use prices as well as 205 resources functions. This makes SDN more complete regarding its 206 software-defining characters. 208 In SDN application market, resource providers and resource consumers 209 actually hardly know each other fully for the value of resources and 210 services. Hence, the trade between them is an information asymmetry 211 game. To take this into consideration, an SDP module with its 212 protocol and associated negotiation mechanisms applied to an SDN 213 system is usually of the following features: 215 o 1) An SDP module can be distributed across parts of SDN system, to 216 get the optimal level of service quality under budget constraints 217 of service consumers. As a result, the SDP module usually further 218 contains a pricing module and a trading module, used for pricing 219 and trading of resources respectively. With an SDP module, users 220 can submit their requirements according to their budgets at the 221 SDN application layer to SDN control layer. Then, the SDN control 222 layer can get results of optimal resource services based on user's 223 budget. 225 o 2) An SDP module usually includes an auto-negotiation mechanism. 226 During the trading process, resource providers first get the price 227 based on the price algorithm and/or mechanism, and present them to 228 resources consumers. If consumers are not satisfied with the 229 prices, process of negotiation with auto-negotiation algorithm or 230 mechanism will be triggered. 232 o 3) With SDP, use of resources and their prices are not unique 233 anymore. Different resources providers may provide different 234 prices even for the same resources. SDP module may query 235 different resources providers for optimal prices. This process 236 usually takes place at the SDP protocol stage of searching prices. 238 o 4) In an SDP transaction, an SDN application usually act as a 239 resource provider to end users. Whereas, at the same time, it can 240 also act as resource consumers to SDN control plane as well as SDN 241 forwarding plane. It sells resources to end users. At the same 242 time, it may buy or hire resources from SDN core systems. All 243 these can be done by use of SDP module. 245 o 5) With a time attribute, SDP can respectively support SDN 246 applications well for temporary term users or long term users 247 regarding optimal use prices. 249 3.2. Framework of SDN with SDP 251 As mentioned, a typical SDN framework usually includes Application 252 Layer, Control Layer, and Infrastructure (forwarding) Layer. In SDN 253 Application Layer, things like virtual servers and other SDN 254 personalized services will be presented as individual SDN 255 Applications. Based on the idea above on adopting SDP to SDN, a 256 typical framework of an SDN system which adopts SDP module is as 257 shown in Figure 3.In this framework, the SDP-App includes an SDP 258 module inside and makes the module support software-defined pricing 259 function. 261 SDP-App may exist in each layer of the SDN framework. Note that, SDN 262 Application communicates with SDN controllers via the AD-SAL and 263 Service Interface.Either should require that the AD-SAL and Service 264 Interface must support SDP protocol to support the SDN with SDP. 266 Also note that, SDN Control Layer includes the network service, SDP- 267 App, and control abstraction Layer(CAL), it is defined to communicate 268 with SDN forwarding layer by means of the resource abstraction 269 layer(RAL) and the uniformly defined SDN southern interface protocols 270 like ForCES ,OpenFlow, etc. To support SDN with SDP, SDP protocol 271 must be designed supportable by these protocols for messaging 272 purpose. This may become a key question for the design of an SDP 273 protocol. The SDN Forwarding Layer includes the network element, and 274 SDP-App. It is exposed via the Resource Abstraction Layer (RAL), 275 which may be expressed by one or more abstraction models. 277 (TBD) 278 o--------------------------------o 279 | | 280 | +-------------+ +----------+ | 281 | | Application | | SDP-App | | 282 | +-------------+ +----------+ | 283 | Application Layer | 284 o---------------Y----------------o 285 | 286 *-----------------------------Y---------------------------------* 287 | Application-Driven Services Abstraction Layer (AD-SAL) | 288 *-----------------------------Y---------------------------------* 289 | 290 |Service 291 |Interface 292 | 293 o-----------------------------Y--------------------------------o 294 | Control | Layer | 295 | +----------Y--------+ +---------+ | 296 | | Network Service | | SDP-App | | 297 | +----------Y--------+ +----Y----+ | 298 | | | | 299 | *------------Y----------------Y------* | 300 | | Control Abstraction Layer (CAL) | | 301 | *------------Y-----------------------* | 302 | | | 303 o-----------------------------|--------------------------------o 304 | 305 | Southbound 306 | Interface 307 | 308 *-----------------------------Y---------------------------------* 309 | Resource Abstraction Layer (RAL) | 310 *-----------------------------Y---------------------------------* 311 | | | 312 | o--------Y-----------o +----------+ | 313 | | Network Element | | SDP-App | | 314 | o--------------------o +----------+ | 315 | Forwarding Layer | 316 +---------------------------------------------------------------+ 318 Figure 3: An SDN Framework with SDP 320 As another example, we try to present an SDN application which uses 321 SDP to access network resources so as to get optimal resources use 322 price. We call the SDN application a 'Chat' App, which is to 323 construct a social App platform to connect, communicate and share 324 among people and things by means of Guaranteed-Service (GS) rather 325 than Best-Efforts (BE) services to users. Hence, the App needs to 326 hire network resources from cloud network service providers to 327 provide virtual server and Guaranteed Service (GS) resources. 329 Fig 4 shown the process for 'Chat' to access the GS Resources by use 330 of SDP. 'Chat' client and 'Chat' Server makes service agreement via 331 SDP module. 'Chat' server may be implemented as a virtual server, 332 whose pricing is also implemented by SDP module. Further more, 333 resources to support the virtual server and the 'chat' message 334 forwarding are used based on SDP negotiations. As shown inFigure 4 , 335 in this case, SDN controller inside the virtual server of 'chat' may 336 send requests to multiple cloud platforms by SDP module(such as Sina 337 cloud, Baidu cloud and Ali cloud in the figure). All the cloud 338 service providers return with resource prices, and SDN controller 339 inside the 'chat' server select or negotiate with the cloud service 340 providers. SDN controller finally may select or get a successful or 341 failed negotiation results and returns to the 'chat' client via SDP 342 protocols. As a result, a transaction for a GS service pricing ends. 344 +---------------------+ 345 | 'Chat' client | 346 | ( With SDP ) | 347 +---------------------+ 348 A 349 | 350 V 351 +---------------------+ 352 | 'Chat' server | 353 | ( With SDP ) | 354 +---------------------+ 355 A 356 | 357 V 358 +---------------------+ 359 | virtual server | 360 | ( With SDP ) | 361 +---------------------+ 362 A 363 | 364 V 365 +---------------------+ 366 | SDN controller | 367 | ( With SDP ) | 368 +---------------------+ 369 A 370 | 371 +----------------------------------------------+ 372 | | | 373 V V V 374 +----------------+ +---------------+ +-------------+ 375 | Sina cloud | | Baidu cloud | | Ali cloud | 376 | (With SDP) | | (With SDP ) | | (With SDP | 377 +----------------+ +---------------+ +-------------+ 379 Figure 4: The Process for 'Chat' Accessing Resources by Use of SDP 381 3.3. Framework of SDN Bases on Meta-Model 383 A Meta-Model is a model architecture in which each defined layer will 384 supply services and functions that built in a meta-model, to be 385 exactly, APP-likely way. Then all of APPs could be refactoried and 386 combined to satisfied sorts of diversified needs from users in upper 387 layer. To be more precisely to defined the meta-model, the following 388 elements will be invoked: 390 o Meta-APP:The minimum logical elements in application layer that be 391 used to combine and register applications with more complexity. 393 Meta-APPs includes all of function feature and needs of 394 application, and they could abstract the fundamental functions of 395 network service needed by business according to feature and 396 requirements of application. 398 o Con-App:Business Abstraction Layer:It is a mechanism that be used 399 to logically mapping the meta-app onto the corresponding meta- 400 service in the application layer. Business Abstraction Layer will 401 recognize and adapte all of meta-service supplied by controller, 402 and then select suitable meta-service to service a meta-app bases 403 on the requirement of relevant business. 405 o SDP-App:The modules proposed here which could support software- 406 defined pricing function in the aspects of resource and service 407 from each layer. 409 o Meta-Ability: The fine-grained elements of switch function in 410 switch layer, which is the atomic elements in divide assignment. 411 It is the fundamental host components. All of the meta-ability 412 can supply diversified host ability for meta-service within the 413 scope of world-wide network. 415 o Resource Abstraction layer: Mapping the physical resources to 416 virtual resource. Resource Abstraction Layer uses virtualization 417 technology to abstract physical resources at the bottom in order 418 to shidding the difference between facilities. In addition, 419 Resource Abstraction Layer can schedule resources to achieve its 420 reasonable alloction, which can avoid the quality reduction of 421 upper layer application due to the resource shortcut and waste in 422 result of its long-term idleness, raising the resource 423 untilization ratio. 425 Based on the idea above on Meta-Model to SDN, a typical framework of 426 an SDN with SDP bases on Meta-Model system is as shown in Figure 5.In 427 this framework, the application layer includes a meta-app part inside 428 and makes the module support dividing and refactoring the meta- 429 service . 431 (TBD) 433 o---------------------------------------------------------------o 434 | | 435 | +-------------+ +----------+ +----------+ +----------+ | 436 | | Meta-App | | SDP-App | | Meta-APP | | Meta-App | | 437 | +-------------+ +----------+ +----------+ +----------+ | 438 | Application Layer | 439 o---------------------------------------------------------------o 440 | 442 *-----------------------------Y---------------------------------* 443 | Business Abstraction Layer | 444 *-----------------------------Y---------------------------------* 445 | 446 |Service 447 |Interface 448 | 449 o-----------------------------Y--------------------------------o 450 | Control | Layer | 451 | +----------Y--------+ +---------+ | 452 | | Meta-Service | | SDP-App | | 453 | +----------Y--------+ +----Y----+ | 454 | | | | 455 | | +-----------+ | 456 | | | | 457 | *------Y----Y-* | 458 | | Con-App | | 459 | *------Y------* | 460 | | | 461 o-----------------------------Y--------------------------------o 462 | 463 | Southbound 464 | Interface 465 | 466 *-----------------------------Y---------------------------------* 467 | Service Abstraction Layer | 468 *----Y-------------Y----------Y-----------Y-------Y---------Y---* 469 | | | | | | 470 *----Y-----* *----Y--* *----Y----* *---Y--* *--Y--* *---Y----* 471 | OpenFlow | | OVSDB | | NETCONF | | LISP | | BGP | | ForCES | 472 *----Y-----* *----Y--* *----Y----* *---Y--* *--Y--* *---Y----* 473 | | | | | | 474 *----Y-------------Y----------Y-----------Y-------Y---------Y---* 475 | Resource Abstraction Layer (RAL) | 476 *---------------------------------------------------------------* 477 | | 478 | o--------------o o----------------o +----------+ | 479 | | Meta-Ability | | Meta-Ability | | SDP-App | | 480 | o--------------o o----------------o +----------+ | 481 | Forwarding Layer | 482 +---------------------------------------------------------------+ 484 Figure 5: An SDN Framework with SDP Bases on Meta-Model 486 3.4. The Relationship between the Layers in the SDN Framework with SDP 487 Bases on Meta-Model 489 As the mentioned definiton of SDN framework with SDP bases on Meta- 490 Model above, the minimum units of application are meta-app, which of 491 control layer are meta-service, and the minimum units in forwarding 492 layer are meta-ability. Meanwhile, Refering to the idea of 493 reconfigurable network architecture, The features of business and the 494 load capacity of network could be abstract as a chained model like 495 "Application -> Meta-App -> Meta-Service -> Meta-Ability" which be 496 showed in Figure 6. A complicated network application can be divided 497 to amounts of meta-app abstractly, and each meta-app contains 498 features and functions of network applications. In this case, The 499 meta-app is also combined by a series of fine-grained meta-service 500 sets that called network fundamental function components. In 501 addition, A set of meta-abilities can combine a series of fundamental 502 load components of network, which can associate meta-service. 504 Conceptually, the meta-ability is a tiny unit defined by fundamental 505 network, which having the abilities to certain capacity and function 506 information. By using meta-abilities, The core of internet can be 507 abstracted to lots of distinct LFBs (Logical Functional Block) which 508 combined by the set of meta-abilities. Meanwhile, This also allows 509 the core of internet to add new meta-ability extensions for promoting 510 network extensibility. 512 Meta-Abilities are described as senary struction including type, 513 mark, attribute set, operation, vendor and price. This "type" 514 element specified the type of meta-abilities for classifying the 515 meta-abilities with similar network function into separate type 516 class. This "mark" element should be defined as natural number. Via 517 type and mark element, the unique identity of meta-abilities can be 518 defined within the scope of world-wide network. This "attribute set" 519 element includes parameters about targets and relevant capacity of 520 those targets. This targets in attribute set can specify the targets 521 that meta-abilities should deal with. And this relevant capacity in 522 attribute set can indicates the parameterized capacity goal of meta- 523 abilities. This "operation" element indicates the operation that 524 meta-ability can implemente to targets. This "vendor" element on 525 behalf of the vendors of this meta-ability (e.g., telecom operators). 526 This "price" element state the cost in the process of using this 527 meta-ability. 529 (TBD) 530 Service Service Application 531 Abstract Map Abstract 532 o---------------o o---------------o o-----------o 533 | | | | | | 534 | +-----------+ | | +-----------+ | | +-------+ | 535 | | M-ability |->------->-| M-service |->-+----->-| M-App |->---+ 536 | +-----------+ | +----->-+-----------+ | | | +-------+ | | 537 | | | | | | | | | | 538 | +-----------+ | | | +-----------+ | +----->-+-------+ | | 539 | | M-ability |->-+----->-| M-service |->---+--->-| M-App |->-+ | 540 | +-----------+ | | +--->-+-----------+ | | +->-+-------+ | | | 541 | | | | | | | | | | | +->o-----o 542 | +-----------+ | | | | +-----------+ | +-|->-+-------+ | +--->| App | 543 | | M-ability |->-|-+--->-| M-service |->-+---|->-| M-App | | +-->o-----o 544 | +-----------+ | | +-->-+-----------+ | | | | +-------+ | | 545 | . | | | | . | | +-+ | | | 546 | . | | | | . | | | | | | 547 | . | | | | . | | | | | | 548 | . | | | | . | | | | | | 549 | +-----------+ | +--|-->-+-----------+ | +-|--->-+-------+ | | 550 | | M-ability |->----+ | | M-service |->---+--->-| M-App |->--+ 551 | +-----------+ | | +-----------+ | | +-------+ | 552 | | | | | | 553 o---------------o o---------------o o-----------o 555 where: 557 M-ability = Meta-ability 558 M-service = Meta-service 559 M-App = Meta-App 561 Figure 6: The Relationship between Meta-Model Layers 563 4. The Trading between the Layers 565 As shown inFigure 7A complete SDN environment is made up of 566 application layer, control layer, data forwarding plane, if regard 567 SDN environment as an economy market ,Then corresponding to the three 568 layers structure of SDN environment, the economy market can be 569 divided into: user layer, trading platform and provider layer. But 570 each layer is embedded with the pricing model and consumption pattern 571 which is apply to this layer , the communication between each other 572 is accomplished by special protocol, each of them is independent but 573 closely linked.In application layer, there are many users, the users 574 were independent of each other, and they belonged to different 575 platforms.In control layer there are multiple platforms, on the two 576 ends of platform respectively connected to different users and 577 providers, the existence of multiple platforms can solve the monopoly 578 of a single platform and the problem that users and providers'choice 579 unicity.In fowarding layer,there are many providers, they can offer 580 different types of resources for each platform. 582 *------------------------------------------------------------------------* 583 |Application +--------------+ +---------------+ +---------------+ | 584 | Layer | Application 1| | Application 2 | ... | Application n | | 585 | +--------------+ +---------------+ +---------------+ | 586 *--------------Y-Y-Y---------------Y-Y--Y--------------------Y--Y--Y-----* 587 | | | +-------------+ | | +---------------+ | | 588 | | | | +-----------|--|----|------------------+ | 589 | | +-|---|-----------|--|----|----------------+ | 590 | +---|---|-------+ | +----|-----------+ | | 591 | | | | | | | | | 592 *--------------V-----V---V-------V---V-------V-----------V----V----V-----* 593 | Control +--------------+ +---------------+ +---------------+ | 594 | Layer |Control Plane1| |Control Plane2 | ... |Control Plane n| | 595 | +--------------+ +---------------+ +---------------+ | 596 *--------------Y-Y-Y---------------Y-Y--Y--------------------Y--Y--Y-----* 597 | | | +-------------+ | | +---------------+ | | 598 | | | | +-----------|--|----|------------------+ | 599 | | +-|---|-----------|--|----|----------------+ | 600 | +---|---|-------+ | +----|-----------+ | | 601 | | | | | | | | | 602 *--------------V-----V---V-------V---V-------V-----------V----V----V---------* 603 |Forwarding +-----------------+ +-----------------+ +------------------+ | 604 | Layer |Forwarding Plane1| |Forwarding Plane2| ... |Forwarding Plane n| | 605 | +-----------------+ +-----------------+ +------------------+ | 606 *----------------------------------------------------------------------------* 608 Figure 7: Multi-Ownership Combinatorial Double Auction Model 610 We summarize the differences of three kinds of trading pattern and 611 the position of SDN architecture which applied them , as shown in 612 Figure 8: 614 ----------------------------------------------------------------------------------- 615 Trading | Product | Trading| Trading Risk | Trading price | Location 616 Pattern | Pattern | market | | | of SDN 617 -----------|------------|--------|---------------|-----------------|--------------- 618 spot | Retail | No |Greater risk | Negotiation | Application 619 trading | Commodity| | |non-standard | layer 620 -----------|------------|--------|---------------|-----------------|--------------- 621 Futures | A kind of | Future | Has margin, |Settlement based | 622 trading | products as| | less risk |on the price |Data forwarding 623 | a unit | | |of the exchange |layer 624 -----------|------------|--------|---------------|-----------------|--------------- 625 Planned |Goods in any| Overall|PlannedSpending| Control price, | Entire 626 trading | combination| market |almost no risk |according to |architecture 627 | | | |supply and demand| 628 -----------|------------|--------|---------------|-----------------|--------------- 630 Figure 8: the Differences among Three Trading Patterns 632 The commodities mode, trading market and other factors of planned 633 trading decides it apply to the entire SDN market; the commodities 634 mode of spot trading determines which is suitable for small number of 635 resources trading, and it has some risks, therefore it works in the 636 application layer of SDN architecture; the commodities mode of 637 futures trading trade in a kind of resource as a unit, and the risk 638 is small, possess the futures market, so it works in data forwarding 639 layer of SDN architecture. 641 5. Security 643 TBD 645 6. IANA Considerations 647 This document has no actions for IANA. 649 7. Informative References 651 [China-Communications] 652 Zhuge, B., Deng, L., Dai, G., Wan, L., Wang, W., and J. 653 Lan, "Resource Scheduling Algorithm and Ecnomic Model in 654 ForCES Networks.China Communications", 2014. 656 [ONF-White-Paper] 657 Fundation O N., "Software-defined networking: The new norm 658 for networks", 2012. 660 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 661 Element Separation (ForCES) Forwarding Element Model", 662 RFC 5812, DOI 10.17487/RFC5812, March 2010, 663 . 665 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. 666 Halpern, "Forwarding and Control Element Separation 667 (ForCES) Logical Function Block (LFB) Library", RFC 6956, 668 DOI 10.17487/RFC6956, June 2013, 669 . 671 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 672 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 673 Defined Networking (SDN): Layers and Architecture 674 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 675 2015, . 677 [Telecommunications-Science] 678 Zhuge, B., Wang, B., and Y. Wang, "Architecture of SDN 679 applications based on Software-Defined price", 2015. 681 Authors' Addresses 683 Bin Zhuge 684 Zhejiang Gongshang University 685 18 Xuezheng Str., Xiasha University Town 686 Hangzhou 310018 687 P.R.China 689 Phone: +86 571 28877723 690 Email: zhugebin@zjsu.edu.cn 692 Yining Wang 693 Simon Fraser University 694 8888 University Drive 695 Burnaby 696 Canada 698 Phone: +1 (778) 885-0009 699 Email: ywa165@sfu.ca 700 Yingjie Zhu 701 Zhejiang Gongshang University 702 18 Xuezheng Str., Xiasha University Town 703 Hangzhou 310018 704 P.R.China 706 Phone: +86 571 28877723 707 Email: zhuyj6055@163.com 709 Hua Zhu 710 Zhejiang Gongshang University 711 18 Xuezheng Str., Xiasha University Town 712 Hangzhou 310018 713 P.R.China 715 Phone: +86 571 28877723 716 Email: zhuhua9114@163.com 718 Weiming Wang 719 Zhejiang Gongshang University 720 18 Xuezheng Str., Xiasha University Town 721 Hangzhou 310018 722 P.R.China 724 Phone: +86 571 28877761 725 Email: wmwang@zjsu.edu.cn