idnits 2.17.1 draft-zhuge-sdnrg-sdn-sdp-06.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 44 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 (December 18, 2017) is 2311 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) -- Looks like a reference, but probably isn't: '37' on line 787 == Unused Reference: 'China-Communications' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'ONF-White-Paper' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'RFC5812' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC6956' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'RFC7426' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'Telecommunications-Science' is defined on line 878, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: June 21, 2018 Simon Fraser University 6 Y. Qi 7 Y. Zhu 8 W. Wang 9 Zhejiang Gongshang University 10 December 18, 2017 12 An Intelligent SDN Framework based on Meta-Model with Software-Defined 13 Pricing (SDP) 14 draft-zhuge-sdnrg-sdn-sdp-06 16 Abstract 18 This document defines a notion called Software-Defined Pricing (SDP) 19 and introduces it into a Software-Defined Networks (SDN) framework. 20 The SDN system with SDP inside is expected to promote the efficiency 21 on SDN resources usage and ease management for service providers.This 22 document also defines a mechanism that can efficiently mannage SDN 23 framework orderly and intelligently. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 21, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Software-Defined Pricing (SDP) . . . . . . . . . . . . . . . 3 61 3. SDN with SDP . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Adopting SDP in SDN . . . . . . . . . . . . . . . . . . . 5 63 3.2. Framework of SDN with SDP . . . . . . . . . . . . . . . . 6 64 3.3. Framework of SDN Bases on Meta-Model . . . . . . . . . . 10 65 3.4. The Relationship between the Layers in the SDN Framework 66 with SDP Bases on Meta-Model . . . . . . . . . . . . . . 13 67 4. The Trading between the Layers . . . . . . . . . . . . . . . 14 68 5. Intelligent Mechanism bases on Meta-Model . . . . . . . . . . 16 69 5.1. Intelligent Component . . . . . . . . . . . . . . . . . . 16 70 5.2. Mechanism Principles . . . . . . . . . . . . . . . . . . 18 71 5.3. MSFC . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 74 8. Informative References . . . . . . . . . . . . . . . . . . . 20 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 77 1. Introduction 79 Software-Defined Networks(SDN) is in the research process. With the 80 idea of SDN, networking resources like switches, routers and types of 81 Network Elements (NEs)are managed as kinds of virtual resources, 82 forming virtual networks so as to provide rather flexible services to 83 network users. In this research process, we noticed that how to 84 price the services and the use of virtual network resources in an SDN 85 is as critical as how the SDN is defined. We consider that it seems 86 a precious idea to treat a service pricing mechanism as part of the 87 SDN framework and to manage it in a software-defined way. 89 Network service prices are traditionally determined by service 90 providers in a rather rigid way, which lacks of flexibility and 91 sometimes even fairness to resources users. By means of the idea of 92 SDP, it is able to treat service pricing as a part of SDN, forming a 93 service pricing model flexible to time, traffic and other network 94 factors and status. In this way, it is expected to promote the 95 efficiency of SDN resources usage and ease the management for service 96 providers. 98 Due to the ever increasing network complexity, the operators of 99 intelligent network are driven toward a virtualization of network 100 functionality that calls for a paradigm shift from a hardware-based 101 approach to a software-based approach. We will correspondingly 102 develop an intelligent management framework based on the concept of 103 SDN, which is featured by the decoupling of control plane from data 104 plane.The intelligent SDN framework aims to provide a viable way to 105 solve the existing challenges in a unified manner. 107 2. Software-Defined Pricing (SDP) 109 Software-Defined Pricing (SDP) is an idea specific to network 110 management, whose core is that the service prices of network 111 resources are determined by means of software-defined algorithms and/ 112 or mechanisms, which figure the prices according to various factors 113 and status of the network resources. In contrast to SDP, service 114 prices may be pre-determined rigidly by service providers. 116 An SDP Protocol is an instance of SDP implementation shown in a way 117 of protocol, which specifically defines algorithms and/or mechanisms 118 to price specific services and use of network resources. An SDP 119 protocol may be a private protocol if it is defined by a service 120 provider personally, or a public protocol if defined publicly by 121 standardization organizations. 123 By use of the software-defined mechanism, SDP essentially supports 124 automatic negotiations of prices in a pricing process. Automatic 125 resource and price negotiation features a Guaranteed Service (GS). 126 As a result, SDN with SDP essentially supports GS services. 128 Network users must accept and abide by the network SDP protocol when 129 they use the network resources and the services. 131 An SDP protocol usually includes trading partners, trading content, 132 obligations and other transaction costs. Service providers can make 133 provisions for users in terms of workload and resource use. 135 As an example, we present a typical process for an SDP protocol. 136 When users expect to use resources from a virtual network by a 137 service provider, users first query prices of various resources and 138 services by means of the SDP protocol. The service provider returns 139 the resource prices to users. Then, users will start up a price 140 negotiation process with the service provider by use of the SDP 141 protocol. Both the user and the service provider will proceed the 142 price negotiation process based on their specific price negotiation 143 algorithms. The negotiation process will be ended only from the user 144 with the SDP protocol. It will end with an agreement is either met 145 or not. The SDP protocol process is shown in Figure 1. Usually, in 146 a negotiation algorithm, the user or the service provider are able to 147 take into consideration of current network status and other network 148 factors, which make the price negotiation process much more efficient 149 and flexible than traditional pricing methods. 151 +------+ + + +-----------+ 152 | | | --------SDP protocol------->| -----------------+ | | 153 | | | | search price | | | 154 | | | <-------SDP protocol--------|<-----------------+ | | 155 | | | --------SDP protocol------->|------------------+ | service | 156 | user | | | price negotiation| | sprovider | 157 | | | <-------SDP protocol--------|<-----------------+ | | 158 | | | --------SDP protocol------->|------------------+ | | 159 | | | | negotiation ends | | | 160 | | | <-------SDP protocol--------|<-----------------+ | | 161 +------+ + + +-----------+ 163 Figure 1: Process of an SDP Protocol 165 To fulfill above process, an SDP protocol header may usually include 166 fields like shown in Figure 2, where: 168 o ID: the unique identifier of the protocol header. 170 o Level: service priorities identified. 172 o Expression: including one or more ITP(ID-Type-Properties) formats, 173 where ID is the unique identifier of a resource, Type is the type 174 of resource, Properties is the attributes of the resource. 176 o TimeSpec: a structure of service time, mainly refers to the 177 selection of the service period. 179 o Price: the price of the transaction. 181 o ContractTime: trading hours. 183 o State: trading status with success or failure. 185 +----------------------------------------------------------------------+ 186 | ID | Level | Expression | TimeSpec | Price | ContractTime | State | 187 +------------|------------|----------|---------------------------------+ 188 | | 189 | +----------------------+ 190 V | 191 +------------------------+ | 192 | ID | Type | Properties | | 193 +-----------|------------+ V 194 | +-------------------------------------+ 195 | | Y/M/D | Mon-Fri/Weekend | 8:00-0:00 | 196 V +-------------------------------------+ 197 +-----------------------------------------+ 198 | rate | delay | shake | etc. | 199 +-----------------------------------------+ 201 Figure 2: An SDP Protocol Header 203 (TBD) 205 3. SDN with SDP 207 3.1. Adopting SDP in SDN 209 SDP can be applied to SDN architecture well because of its natural 210 software-defined feature. 212 In SDN architecture, control plane and data plane are separated to 213 achieve the segregation of the control and forwarding. A typical SDN 214 architecture usually includes: application layer, control layer, and 215 infrastructure (forwarding) layer. To adopt SDP in SDN, an SDP 216 module is applied. An SDP module implements the SDP protocol and 217 corresponding negotiation algorithms/mechanisms. An SDP module can 218 be applied to any layer in the SDN, where resources need to be 219 priced. In this way, theoretically, all kinds of network resources 220 and services can be programmed in terms of use prices as well as 221 resources functions. This makes SDN more complete regarding its 222 software-defining characters. 224 In SDN application market, resource providers and resource consumers 225 actually hardly know each other fully for the value of resources and 226 services. Hence, the trade between them is an information asymmetry 227 game. To take this into consideration, an SDP module with its 228 protocol and associated negotiation mechanisms applied to an SDN 229 system is usually of the following features: 231 o 1) An SDP module can be distributed across parts of SDN system, to 232 get the optimal level of service quality under budget constraints 233 of service consumers. As a result, the SDP module usually further 234 contains a pricing module and a trading module, used for pricing 235 and trading of resources respectively. With an SDP module, users 236 can submit their requirements according to their budgets at the 237 SDN application layer to SDN control layer. Then, the SDN control 238 layer can get results of optimal resource services based on user's 239 budget. 241 o 2) An SDP module usually includes an auto-negotiation mechanism. 242 During the trading process, resource providers first get the price 243 based on the price algorithm and/or mechanism, and present them to 244 resources consumers. If consumers are not satisfied with the 245 prices, process of negotiation with auto-negotiation algorithm or 246 mechanism will be triggered. 248 o 3) With SDP, use of resources and their prices are not unique 249 anymore. Different resources providers may provide different 250 prices even for the same resources. SDP module may query 251 different resources providers for optimal prices. This process 252 usually takes place at the SDP protocol stage of searching prices. 254 o 4) In an SDP transaction, an SDN application usually act as a 255 resource provider to end users. Whereas, at the same time, it can 256 also act as resource consumers to SDN control plane as well as SDN 257 forwarding plane. It sells resources to end users. At the same 258 time, it may buy or hire resources from SDN core systems. All 259 these can be done by use of SDP module. 261 o 5) With a time attribute, SDP can respectively support SDN 262 applications well for temporary term users or long term users 263 regarding optimal use prices. 265 3.2. Framework of SDN with SDP 267 As mentioned, a typical SDN framework usually includes Application 268 Layer, Control Layer, and Infrastructure (forwarding) Layer. In SDN 269 Application Layer, things like virtual servers and other SDN 270 personalized services will be presented as individual SDN 271 Applications. Based on the idea above on adopting SDP to SDN, a 272 typical framework of an SDN system which adopts SDP module is as 273 shown in Figure 3.In this framework, the SDP-App includes an SDP 274 module inside and makes the module support software-defined pricing 275 function. 277 SDP-App may exist in each layer of the SDN framework. Note that, SDN 278 Application communicates with SDN controllers via the AD-SAL and 279 Service Interface.Either should require that the AD-SAL and Service 280 Interface must support SDP protocol to support the SDN with SDP. 282 Also note that, SDN Control Layer includes the network service, SDP- 283 App, and control abstraction Layer(CAL), it is defined to communicate 284 with SDN forwarding layer by means of the resource abstraction 285 layer(RAL) and the uniformly defined SDN southern interface protocols 286 like ForCES ,OpenFlow, etc. To support SDN with SDP, SDP protocol 287 must be designed supportable by these protocols for messaging 288 purpose. This may become a key question for the design of an SDP 289 protocol. The SDN Forwarding Layer includes the network element, and 290 SDP-App. It is exposed via the Resource Abstraction Layer (RAL), 291 which may be expressed by one or more abstraction models. 293 (TBD) 294 o--------------------------------o 295 | | 296 | +-------------+ +----------+ | 297 | | Application | | SDP-App | | 298 | +-------------+ +----------+ | 299 | Application Layer | 300 o---------------Y----------------o 301 | 302 *-----------------------------Y---------------------------------* 303 | Application-Driven Services Abstraction Layer (AD-SAL) | 304 *-----------------------------Y---------------------------------* 305 | 306 |Service 307 |Interface 308 | 309 o-----------------------------Y--------------------------------o 310 | Control | Layer | 311 | +----------Y--------+ +---------+ | 312 | | Network Service | | SDP-App | | 313 | +----------Y--------+ +----Y----+ | 314 | | | | 315 | *------------Y----------------Y------* | 316 | | Control Abstraction Layer (CAL) | | 317 | *------------Y-----------------------* | 318 | | | 319 o-----------------------------|--------------------------------o 320 | 321 | Southbound 322 | Interface 323 | 324 *-----------------------------Y---------------------------------* 325 | Resource Abstraction Layer (RAL) | 326 *-----------------------------Y---------------------------------* 327 | | | 328 | o--------Y-----------o +----------+ | 329 | | Network Element | | SDP-App | | 330 | o--------------------o +----------+ | 331 | Forwarding Layer | 332 +---------------------------------------------------------------+ 334 Figure 3: An SDN Framework with SDP 336 As another example, we try to present an SDN application which uses 337 SDP to access network resources so as to get optimal resources use 338 price. We call the SDN application a 'Chat' App, which is to 339 construct a social App platform to connect, communicate and share 340 among people and things by means of Guaranteed-Service (GS) rather 341 than Best-Efforts (BE) services to users. Hence, the App needs to 342 hire network resources from cloud network service providers to 343 provide virtual server and Guaranteed Service (GS) resources. 345 Fig 4 shown the process for 'Chat' to access the GS Resources by use 346 of SDP. 'Chat' client and 'Chat' Server makes service agreement via 347 SDP module. 'Chat' server may be implemented as a virtual server, 348 whose pricing is also implemented by SDP module. Further more, 349 resources to support the virtual server and the 'chat' message 350 forwarding are used based on SDP negotiations. As shown inFigure 4 , 351 in this case, SDN controller inside the virtual server of 'chat' may 352 send requests to multiple cloud platforms by SDP module(such as Sina 353 cloud, Baidu cloud and Ali cloud in the figure). All the cloud 354 service providers return with resource prices, and SDN controller 355 inside the 'chat' server select or negotiate with the cloud service 356 providers. SDN controller finally may select or get a successful or 357 failed negotiation results and returns to the 'chat' client via SDP 358 protocols. As a result, a transaction for a GS service pricing ends. 360 +---------------------+ 361 | 'Chat' client | 362 | ( With SDP ) | 363 +---------------------+ 364 A 365 | 366 V 367 +---------------------+ 368 | 'Chat' server | 369 | ( With SDP ) | 370 +---------------------+ 371 A 372 | 373 V 374 +---------------------+ 375 | virtual server | 376 | ( With SDP ) | 377 +---------------------+ 378 A 379 | 380 V 381 +---------------------+ 382 | SDN controller | 383 | ( With SDP ) | 384 +---------------------+ 385 A 386 | 387 +----------------------------------------------+ 388 | | | 389 V V V 390 +----------------+ +---------------+ +-------------+ 391 | Sina cloud | | Baidu cloud | | Ali cloud | 392 | (With SDP) | | (With SDP ) | | (With SDP | 393 +----------------+ +---------------+ +-------------+ 395 Figure 4: The Process for 'Chat' Accessing Resources by Use of SDP 397 3.3. Framework of SDN Bases on Meta-Model 399 A Meta-Model is a model architecture in which each defined layer will 400 supply services and functions that built in a meta-model, to be 401 exactly, APP-likely way. Then all of APPs could be refactoried and 402 combined to satisfied sorts of diversified needs from users in upper 403 layer. To be more precisely to defined the meta-model, the following 404 elements will be invoked: 406 o Meta-APP:The minimum logical elements in application layer that be 407 used to combine and register applications with more complexity. 409 Meta-APPs includes all of function feature and needs of 410 application, and they could abstract the fundamental functions of 411 network service needed by business according to feature and 412 requirements of application. 414 o Con-App:Business Abstraction Layer:It is a mechanism that be used 415 to logically mapping the meta-app onto the corresponding meta- 416 service in the application layer. Business Abstraction Layer will 417 recognize and adapte all of meta-service supplied by controller, 418 and then select suitable meta-service to service a meta-app bases 419 on the requirement of relevant business. 421 o SDP-App:The modules proposed here which could support software- 422 defined pricing function in the aspects of resource and service 423 from each layer. 425 o Meta-Ability: The fine-grained elements of switch function in 426 switch layer, which is the atomic elements in divide assignment. 427 It is the fundamental host components. All of the meta-ability 428 can supply diversified host ability for meta-service within the 429 scope of world-wide network. 431 o Resource Abstraction layer: Mapping the physical resources to 432 virtual resource. Resource Abstraction Layer uses virtualization 433 technology to abstract physical resources at the bottom in order 434 to shidding the difference between facilities. In addition, 435 Resource Abstraction Layer can schedule resources to achieve its 436 reasonable alloction, which can avoid the quality reduction of 437 upper layer application due to the resource shortcut and waste in 438 result of its long-term idleness, raising the resource 439 untilization ratio. 441 Based on the idea above on Meta-Model to SDN, a typical framework of 442 an SDN with SDP bases on Meta-Model system is as shown in Figure 5.In 443 this framework, the application layer includes a meta-app part inside 444 and makes the module support dividing and refactoring the meta- 445 service . 447 (TBD) 449 o---------------------------------------------------------------o 450 | | 451 | +-------------+ +----------+ +----------+ +----------+ | 452 | | Meta-App | | SDP-App | | Meta-APP | | Meta-App | | 453 | +-------------+ +----------+ +----------+ +----------+ | 454 | Application Layer | 455 o---------------------------------------------------------------o 456 | 458 *-----------------------------Y---------------------------------* 459 | Business Abstraction Layer | 460 *-----------------------------Y---------------------------------* 461 | 462 |Service 463 |Interface 464 | 465 o-----------------------------Y--------------------------------o 466 | Control | Layer | 467 | +----------Y--------+ +---------+ | 468 | | Meta-Service | | SDP-App | | 469 | +----------Y--------+ +----Y----+ | 470 | | | | 471 | | +-----------+ | 472 | | | | 473 | *------Y----Y-* | 474 | | Con-App | | 475 | *------Y------* | 476 | | | 477 o-----------------------------Y--------------------------------o 478 | 479 | Southbound 480 | Interface 481 | 482 *-----------------------------Y---------------------------------* 483 | Service Abstraction Layer | 484 *----Y-------------Y----------Y-----------Y-------Y---------Y---* 485 | | | | | | 486 *----Y-----* *----Y--* *----Y----* *---Y--* *--Y--* *---Y----* 487 | OpenFlow | | OVSDB | | NETCONF | | LISP | | BGP | | ForCES | 488 *----Y-----* *----Y--* *----Y----* *---Y--* *--Y--* *---Y----* 489 | | | | | | 490 *----Y-------------Y----------Y-----------Y-------Y---------Y---* 491 | Resource Abstraction Layer (RAL) | 492 *---------------------------------------------------------------* 493 | | 494 | o--------------o o----------------o +----------+ | 495 | | Meta-Ability | | Meta-Ability | | SDP-App | | 496 | o--------------o o----------------o +----------+ | 497 | Forwarding Layer | 498 +---------------------------------------------------------------+ 500 Figure 5: An SDN Framework with SDP Bases on Meta-Model 502 3.4. The Relationship between the Layers in the SDN Framework with SDP 503 Bases on Meta-Model 505 As the mentioned definiton of SDN framework with SDP bases on Meta- 506 Model above, the minimum units of application are meta-app, which of 507 control layer are meta-service, and the minimum units in forwarding 508 layer are meta-ability. Meanwhile, Refering to the idea of 509 reconfigurable network architecture, The features of business and the 510 load capacity of network could be abstract as a chained model like 511 "Application -> Meta-App -> Meta-Service -> Meta-Ability" which be 512 showed in Figure 6. A complicated network application can be divided 513 to amounts of meta-app abstractly, and each meta-app contains 514 features and functions of network applications. In this case, The 515 meta-app is also combined by a series of fine-grained meta-service 516 sets that called network fundamental function components. In 517 addition, A set of meta-abilities can combine a series of fundamental 518 load components of network, which can associate meta-service. 520 Conceptually, the meta-ability is a tiny unit defined by fundamental 521 network, which having the abilities to certain capacity and function 522 information. By using meta-abilities, The core of internet can be 523 abstracted to lots of distinct LFBs (Logical Functional Block) which 524 combined by the set of meta-abilities. Meanwhile, This also allows 525 the core of internet to add new meta-ability extensions for promoting 526 network extensibility. 528 Meta-Abilities are described as senary struction including type, 529 mark, attribute set, operation, vendor and price. This "type" 530 element specified the type of meta-abilities for classifying the 531 meta-abilities with similar network function into separate type 532 class. This "mark" element should be defined as natural number. Via 533 type and mark element, the unique identity of meta-abilities can be 534 defined within the scope of world-wide network. This "attribute set" 535 element includes parameters about targets and relevant capacity of 536 those targets. This targets in attribute set can specify the targets 537 that meta-abilities should deal with. And this relevant capacity in 538 attribute set can indicates the parameterized capacity goal of meta- 539 abilities. This "operation" element indicates the operation that 540 meta-ability can implemente to targets. This "vendor" element on 541 behalf of the vendors of this meta-ability (e.g., telecom operators). 542 This "price" element state the cost in the process of using this 543 meta-ability. 545 (TBD) 546 Service Service Application 547 Abstract Map Abstract 548 o---------------o o---------------o o-----------o 549 | | | | | | 550 | +-----------+ | | +-----------+ | | +-------+ | 551 | | M-ability |->------->-| M-service |->-+----->-| M-App |->---+ 552 | +-----------+ | +----->-+-----------+ | | | +-------+ | | 553 | | | | | | | | | | 554 | +-----------+ | | | +-----------+ | +----->-+-------+ | | 555 | | M-ability |->-+----->-| M-service |->---+--->-| M-App |->-+ | 556 | +-----------+ | | +--->-+-----------+ | | +->-+-------+ | | | 557 | | | | | | | | | | | +->o-----o 558 | +-----------+ | | | | +-----------+ | +-|->-+-------+ | +--->| App | 559 | | M-ability |->-|-+--->-| M-service |->-+---|->-| M-App | | +-->o-----o 560 | +-----------+ | | +-->-+-----------+ | | | | +-------+ | | 561 | . | | | | . | | +-+ | | | 562 | . | | | | . | | | | | | 563 | . | | | | . | | | | | | 564 | . | | | | . | | | | | | 565 | +-----------+ | +--|-->-+-----------+ | +-|--->-+-------+ | | 566 | | M-ability |->----+ | | M-service |->---+--->-| M-App |->--+ 567 | +-----------+ | | +-----------+ | | +-------+ | 568 | | | | | | 569 o---------------o o---------------o o-----------o 571 where: 573 M-ability = Meta-ability 574 M-service = Meta-service 575 M-App = Meta-App 577 Figure 6: The Relationship between Meta-Model Layers 579 4. The Trading between the Layers 581 As shown inFigure 7A complete SDN environment is made up of 582 application layer, control layer, data forwarding plane, if regard 583 SDN environment as an economy market ,Then corresponding to the three 584 layers structure of SDN environment, the economy market can be 585 divided into: user layer, trading platform and provider layer. But 586 each layer is embedded with the pricing model and consumption pattern 587 which is apply to this layer , the communication between each other 588 is accomplished by special protocol, each of them is independent but 589 closely linked.In application layer, there are many users, the users 590 were independent of each other, and they belonged to different 591 platforms.In control layer there are multiple platforms, on the two 592 ends of platform respectively connected to different users and 593 providers, the existence of multiple platforms can solve the monopoly 594 of a single platform and the problem that users and providers'choice 595 unicity.In fowarding layer,there are many providers, they can offer 596 different types of resources for each platform. 598 *------------------------------------------------------------------------* 599 |Application +--------------+ +---------------+ +---------------+ | 600 | Layer | Application 1| | Application 2 | ... | Application n | | 601 | +--------------+ +---------------+ +---------------+ | 602 *--------------Y-Y-Y---------------Y-Y--Y--------------------Y--Y--Y-----* 603 | | | +-------------+ | | +---------------+ | | 604 | | | | +-----------|--|----|------------------+ | 605 | | +-|---|-----------|--|----|----------------+ | 606 | +---|---|-------+ | +----|-----------+ | | 607 | | | | | | | | | 608 *--------------V-----V---V-------V---V-------V-----------V----V----V-----* 609 | Control +--------------+ +---------------+ +---------------+ | 610 | Layer |Control Plane1| |Control Plane2 | ... |Control Plane n| | 611 | +--------------+ +---------------+ +---------------+ | 612 *--------------Y-Y-Y---------------Y-Y--Y--------------------Y--Y--Y-----* 613 | | | +-------------+ | | +---------------+ | | 614 | | | | +-----------|--|----|------------------+ | 615 | | +-|---|-----------|--|----|----------------+ | 616 | +---|---|-------+ | +----|-----------+ | | 617 | | | | | | | | | 618 *--------------V-----V---V-------V---V-------V-----------V----V----V---------* 619 |Forwarding +-----------------+ +-----------------+ +------------------+ | 620 | Layer |Forwarding Plane1| |Forwarding Plane2| ... |Forwarding Plane n| | 621 | +-----------------+ +-----------------+ +------------------+ | 622 *----------------------------------------------------------------------------* 624 Figure 7: Multi-Ownership Combinatorial Double Auction Model 626 We summarize the differences of three kinds of trading pattern and 627 the position of SDN architecture which applied them , as shown in 628 Figure 8: 630 ----------------------------------------------------------------------------------- 631 Trading | Product | Trading| Trading Risk | Trading price | Location 632 Pattern | Pattern | market | | | of SDN 633 -----------|------------|--------|---------------|-----------------|--------------- 634 spot | Retail | No |Greater risk | Negotiation | Application 635 trading | Commodity| | |non-standard | layer 636 -----------|------------|--------|---------------|-----------------|--------------- 637 Futures | A kind of | Future | Has margin, |Settlement based | 638 trading | products as| | less risk |on the price |Data forwarding 639 | a unit | | |of the exchange |layer 640 -----------|------------|--------|---------------|-----------------|--------------- 641 Planned |Goods in any| Overall|PlannedSpending| Control price, | Entire 642 trading | combination| market |almost no risk |according to |architecture 643 | | | |supply and demand| 644 -----------|------------|--------|---------------|-----------------|--------------- 646 Figure 8: the Differences among Three Trading Patterns 648 The commodities mode, trading market and other factors of planned 649 trading decides it apply to the entire SDN market; the commodities 650 mode of spot trading determines which is suitable for small number of 651 resources trading, and it has some risks, therefore it works in the 652 application layer of SDN architecture; the commodities mode of 653 futures trading trade in a kind of resource as a unit, and the risk 654 is small, possess the futures market, so it works in data forwarding 655 layer of SDN architecture. 657 5. Intelligent Mechanism bases on Meta-Model 659 5.1. Intelligent Component 661 As shown inFigure 9We defines a advenced mechanism of SDN framework, 662 the primary module sustains the speciality of intelligence and smart, 663 which composed by three main components, including network sense 664 function, SDP module, and policy control. 666 The network sence function, within this intelligence mechanism, in 667 change of preceiving each details , monitoring network state on a 668 domain scale, to be special, bandwidth, quality of service, line 669 loading, besides, node capacities of calculation, storage and speed. 670 While network sence function learns those information from SDN south 671 interface, they could analyze and encapsulate them with an overlay, 672 following, send encapsulated message to SDP module though inner port. 674 The SDP module porvides pre-customized algorithm based upon SDP 675 protocol, which would operated in encapsulated message processing, 676 consists the interaction and the relation between meta-abilities and 677 requirements of applicatoin, and manages preliminary SFC policies, 678 overviewed of RFC 7665 [RFC7665], to construct meta-abilities with 679 knowledge reasoning. 681 Policy, in contrast, interacts with the system in other 682 places.Policies and SDP module may monitor meta-abilities to decide 683 if additional (or fewer) instances of services are needed. When 684 applicable, those decisions may in turn result in interactions that 685 direct the control logic to change the placement of meta-abilities 686 service function chain,in short, MSFC. 688 The policy control module is part of the overall intelligent 689 mechanism, and is responsible for constructing MSFCs, translating 690 MSFCs to forwarding paths, and propagating path information to 691 participating meta-ability nodes to achieve requisite forwarding 692 behavior to construct the service overlay and qualify the 693 requirements of application. For instance, the physical placement of 694 meta-ability nodes may be static; selecting exactly which MSFCs and 695 which meta-abilities from those MSFCs are to be used, or it may be 696 dynamic, allowing the network to perform some or all of the choices 697 of MSFC or meta-abilities to use to deliver the selected service 698 chain within the constraints represented by the service path. While, 699 within this mechanism, physical resource and logicl meta models state 700 are permitted to be registered on the policy control module. 702 Architecturally, within the same policy control module domain, some 703 MSFCs may be fully specified, selecting exactly which MSFC and which 704 meta-abilities are to be visited by packets using that MSFC, while 705 other MSFCs may be quite vague, deferring to the traffic the 706 decisions about the exact sequence of steps to be used to realize the 707 MSFC. 709 o . . . . . . . . . . . . . . . . . . . . . . . 710 . +------------+ 711 . + | SDP Module |+ + ----------------------- 712 South . +---------+ / +------------+ \ | Policy +----+ +----+ 713 Intf . | Network | / +| Control |SFC1|...|SFCn| 714 +--------->| Sence |+ +--------------+ | Module +----+ +----+ 715 Network. | Function| |Kernel Control| +------------V--------V--- 716 State . +---------+ | Module | / / 717 . +--------------+<-------------+--------+ 718 o . . . . . . . . Y . . . . . . . . . . . . . . 719 +-------------+ 720 | | 721 V V 722 Meta-Ability1...Meta-Abilityn 724 Figure 9: Composite Intelligent and Software-Defined-Price Mechanism 725 Model 727 5.2. Mechanism Principles 729 Intelligent mechanism bases on meta-model is predicated on several 730 key architectural principles: 732 1. Universality:IPv6 networks should be supported. And diversified 733 user requirements and endpoint also can transport in this 734 mechanism. 736 2. Sensation:Intelligent mechanism should have the capacity to sence 737 diversified behavior characteristic of network services and 738 users. While, this mechanism should support the intellgent 739 recognition and analysis based on users, context and application, 740 and on this situation to achieve a flexible policy scheduling and 741 routing. 743 3. Efficient: Requires the network to provide on-demand support for 744 users and application requirements, intelligent traffic control 745 capabilities, and the ability to alleviate the unreasonable 746 consumption of uncontrollable traffic to network resources. At 747 the same time,this mechanism can improve network adaptability 748 reasonably, and achieve content distribution efficiently by 749 enhancing the dynamic regulation of resources on demand quality 750 assurance capabilities. 752 4. Openness:The application of security and network awareness, 753 traffic scheduling and other capabilities should be combined in 754 the netwok of intellgent open-architecture. This mechanism could 755 lower the threshold to further innovation of the upper 756 application, and meet the needs of personalized, diverse user, 757 meanwhile, optimize the existing carrier network management 758 model, improve the operational efficiency of the network. 760 5. Evolution: Network development must support future users and 761 applications through overlaying new-built or existing system 762 upgrades based on active network-level architectures. Seldom 763 change to the running underlay network forwarding facility -- 764 implicit, or explicit -- are needed to deploy and invoke 765 intelligent mechanism. And this mechanism should provides 766 standardized communication protocols and interfaces for 767 collaboration processes between different levels, between 768 external systems, between meta-models, with little influence on 769 existing networks and can be gradually upgraded amongst existing 770 networks architecture. 772 6. Autonomy:With the development of network, it is necessary to 773 introduce artificial intelligence technology to achieve self- 774 adjustment, self-optimization, self-recovery of the network 775 through collection of huge data of network state and machine 776 learning. The areas of machine learning which are easier to be 777 used in the network field may include: troubleshooting of network 778 problems, network traffic prediction, traffic optimization 779 adjustment, security defense, security auditing, etc., to 780 implement network perception and cognition. 782 5.3. MSFC 784 1. Meta-model-based service function linking method in this draft 785 encapsulates the logic function blocks in the metamodel network 786 into multiple MetaService Functions (MSFs) in combination with 787 SFC[37]. MSF is a virtual element or is embedded into an 788 industry-standard universal physical network element. It is 789 mainly responsible for receiving various types of traffic and 790 forwarding the data to a designated MSF or network logical 791 service block. We define a Meta Service Function Chain (MSFC) 792 based on a metamodel network architecture to describe an ordered 793 application of services or data to upper layers for processing 794 data packets, network frames and service flows A collection of 795 abstract MSFs that classify and forward the processing results. 797 2. SFC Management orchestration domain refers to the network or 798 network area that enables an SFC and serves the upper layer. An 799 SFC can only be constrained in a single management orchestration 800 domain and is subject to management, coordination and scheduling 801 of the management orchestration domain. Figure 24 shows an MSFC 802 architecture in a metamodel-based SDN network. This system 803 establishes service sublayer and service execution sublayer in 804 each layer of SDN network. The service organization sub-layer 805 includes core control module, SDP module and other functional 806 nodes responsible for MSF scheduling. It receives the upper- 807 layer service request through the northbound interface, and the 808 SDP module is responsible for generating a specific MSF policy 809 and uses the internal control module Interface with the 810 underlying MSF to deliver the policy to the service execution 811 sub-layer. The service execution sublayer includes a series of 812 MSF collections that have business traffic acceptance, 813 processing, and forwarding capabilities. EP represents a 814 terminal node, and the terminal may be a network element device, 815 a user terminal or an MSFC in other management domains. 817 3. The next generation of new networks requires that services can 818 dynamically adapt to the changing needs of services. Network 819 service providers need to combine basic meta-capabilities based 820 on orthogonal decomposition into different composite network 821 services to achieve service-oriented service customization and 822 agile development. When a service layer user sends a request the 823 SDN control layer, the SDN agent reconfigures from the NE node to 824 the service link by issuing a policy and makes a series of 825 internal adjustments to adapt to this type of service. 827 4. Meta-capabilities within a single-cell node can be dynamically 828 combined into a sequence of metaclassic capabilities that we call 829 the meta-capability stack. The meta-capability stack is a basic 830 logical structure for providing data transmission and initial 831 processing of information in a network element node. When a 832 meta-capability stack is created, it is temporarily created for 833 service. When the request is completed, it will continue to 834 survive for some time until it dies naturally or a similar 835 strategy arrives. 837 6. Security 839 TBD 841 7. IANA Considerations 843 This document has no actions for IANA. 845 8. Informative References 847 [China-Communications] 848 Zhuge, B., Deng, L., Dai, G., Wan, L., Wang, W., and J. 849 Lan, "Resource Scheduling Algorithm and Ecnomic Model in 850 ForCES Networks.China Communications", 2014. 852 [ONF-White-Paper] 853 Fundation O N., "Software-defined networking: The new norm 854 for networks", 2012. 856 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 857 Element Separation (ForCES) Forwarding Element Model", 858 RFC 5812, DOI 10.17487/RFC5812, March 2010, 859 . 861 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. 862 Halpern, "Forwarding and Control Element Separation 863 (ForCES) Logical Function Block (LFB) Library", RFC 6956, 864 DOI 10.17487/RFC6956, June 2013, 865 . 867 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 868 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 869 Defined Networking (SDN): Layers and Architecture 870 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 871 2015, . 873 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 874 Chaining (SFC) Architecture", RFC 7665, 875 DOI 10.17487/RFC7665, October 2015, 876 . 878 [Telecommunications-Science] 879 Zhuge, B., Wang, B., and Y. Wang, "Architecture of SDN 880 applications based on Software-Defined price", 2015. 882 [Telecommunications-Science.2] 883 Zhuge, B., Zhu, H., and B. Wang, "Research on the Meta 884 Model Construction Mechanism in SDN Architecture", 2016. 886 Authors' Addresses 888 Bin Zhuge 889 Zhejiang Gongshang University 890 18 Xuezheng Str., Xiasha University Town 891 Hangzhou 310018 892 P.R.China 894 Phone: +86 571 28877723 895 Email: zhugebin@zjsu.edu.cn 896 Yining Wang 897 Simon Fraser University 898 8888 University Drive 899 Burnaby 900 Canada 902 Phone: +1 (778) 885-0009 903 Email: ywa165@sfu.ca 905 Yihang Qi 906 Zhejiang Gongshang University 907 18 Xuezheng Str., Xiasha University Town 908 Hangzhou 310018 909 P.R.China 911 Phone: +86 571 28877723 912 Email: 1107811460@qq.com 914 Yingjie Zhu 915 Zhejiang Gongshang University 916 18 Xuezheng Str., Xiasha University Town 917 Hangzhou 310018 918 P.R.China 920 Phone: +86 571 28877723 921 Email: zhuyj6055@163.com 923 Weiming Wang 924 Zhejiang Gongshang University 925 18 Xuezheng Str., Xiasha University Town 926 Hangzhou 310018 927 P.R.China 929 Phone: +86 571 28877761 930 Email: wmwang@zjsu.edu.cn