idnits 2.17.00 (12 Aug 2021) /tmp/idnits52820/draft-xia-sdnrg-nemo-language-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 23) being 63 lines 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 14 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 136 has weird spacing: '...service also ...' == Line 142 has weird spacing: '...rk user also ...' == Line 586 has weird spacing: '... Type l3gr...' == Line 588 has weird spacing: '...roperty locat...' == Line 645 has weird spacing: '...roperty band...' == (5 more instances...) -- The document date (April 14, 2016) is 2221 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) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SDNRG Y. Xia, Ed. 2 Internet-Draft S. Jiang, Ed. 3 Intended status: Standards Track T. Zhou, Ed. 4 Expires: October 16, 2016 S. Hares 5 Y.Zhang, Ed. 6 Huawei Technologies Co., Ltd 7 April 14, 2016 9 NEMO (NEtwork MOdeling) Language 10 draft-xia-sdnrg-nemo-language-04 12 Abstract 14 The North-Bound Interface (NBI), located between the control plane 15 and the applications, is essential to enable the application 16 innovations and nourish the eco-system of SDN. 18 While most of the NBIs are provided in the form of API, this document 19 proposes the NEtwork MOdeling (NEMO) language which is intent based 20 interface with novel language fashion. Concept, model and syntax are 21 introduced in the document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 16, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements for the Intent Based NBI Language . . . . . . . 4 60 4. Related work . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. The NEMO Language Specifications . . . . . . . . . . . . . . 6 62 5.1. Network Model of the NEMO Language . . . . . . . . . . . 6 63 5.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. NEMO Language Overview . . . . . . . . . . . . . . . . . 8 65 5.4. Model Definition . . . . . . . . . . . . . . . . . . . . 9 66 5.4.1. Data Types . . . . . . . . . . . . . . . . . . . . . 9 67 5.4.2. Model Definition and Description Statement . . . . . 10 68 5.5. Resource Access Statements . . . . . . . . . . . . . . . 12 69 5.5.1. CustomerFacingNode Operations . . . . . . . . . . . . 12 70 5.5.2. Connection Operations . . . . . . . . . . . . . . . . 13 71 5.5.3. ServiceFlowFlow Operations . . . . . . . . . . . . . 14 72 5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 15 73 5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 16 74 5.6.2. Operation Behavior . . . . . . . . . . . . . . . . . 16 75 5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 19 76 5.7. Transaction Statements . . . . . . . . . . . . . . . . . 20 77 6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 20 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 81 10. Informative References . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 While SDN (Software Defined Network) is becoming one of the most 87 important directions of network evolution, the essence of SDN is to 88 make the network more flexible and easy to use. The North-Bound 89 Interface (NBI), located between the control plane and the 90 applications, is essential to enable the application innovations and 91 nourish the eco-system of SDN by abstracting the network 92 capabilities/information and opening the abstract/logic network to 93 applications. 95 The NBI is usually provided in the form of API (Application 96 Programming Interface). Different vendors provide self-defined API 97 sets. Each API set, such as OnePK from Cisco and OPS from Huawei, 98 often contains hundreds of specific APIs. Diverse APIs without 99 consistent style are hard to remember and use, and nearly impossible 100 to be standardized. 102 In addition, most of those APIs are designed by network domain 103 experts, who are used to thinking from the network system 104 perspective. The interface designer does not know how the users will 105 use the device and exposes information details as much as possible. 106 It enables better control of devices, but leaves huge burden of 107 selecting useful information to users without well training. Since 108 the NBI is used by network users, a more appropriate design is to 109 express user intent and abstract the network from the top down. 111 To implement such an NBI design, we can learn from the successful 112 case of SQL (Structured Query Language), which simplified the 113 complicated data operation to a unified and intuitive way in the form 114 of language. Applications do not care about the way of data storage 115 and data operation, but to describe the demand for the data storage 116 and operation and then get the result. As a data domain DSL, SQL is 117 simple and intuitive, and can be embedded in applications. So what 118 we need for the network NBI is a set of "network domain SQL". 119 [I-D.xia-sdnrg-service-description-language] describe the 120 requirements for a service description language and the design 121 considerations. 123 This document will introduce an intent based NBI with novel language 124 fashion. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 [RFC2119] when they appear in ALL CAPS. When these words are not in 132 ALL CAPS (such as "should" or "Should"), they have their usual 133 English meanings, and are not to be interpreted as [RFC2119] key 134 words. 136 Network service also "service" for short, is the service logic that 137 contains network operation requirements; 139 Network APP also "APP" for short, is the application to implement 140 the network service; 142 Network user also "user" for short, is the network administrator or 143 operator. 145 3. Requirements for the Intent Based NBI Language 147 An intent based NBI language design contains following features: 149 o Express user intent 151 To simplify the operation, applications or users can use the NBI 152 directly to describe their requirements for the network without 153 taking care of the implementation. All the parameters without 154 user concern will be concealed by the NBI. 156 o Platform independent 158 With the NBI, the application or user can description of network 159 demand in a generic way, so that any platform or system can get 160 the identical knowledge and consequently execute to the same 161 result. Any low-level and device/vendor specific configurations 162 and dependencies should be avoided. 164 o Intuitive Domain Specific Language (DSL) for network 166 The expression of the DSL should be human-friendly and be easily 167 understood by network operators. DSL should be directly used by 168 the system. 170 o Privilege control 172 Every application or user is authorized within a specific network 173 domain, which can be physical or virtual. While different network 174 domains are isolated without impact, the application or user may 175 have access to all the resource and capabilities within its 176 domain. The user perception of the network does not have to be 177 the same as the network operators. The NBI language works on the 178 user's view so the users can create topologies based on the 179 resources the network-operators allow them to have. 181 o Declarative style 183 As described above, the NBI language is designed to help defining 184 service requirement to network, detailed configurations and 185 instructions performed by network devices are opaque to network 186 operators. So the NBI language should be declarative rather than 187 imperative. 189 4. Related work 191 YANG [RFC6020] is a data modeling language used to model 192 configuration and state data manipulated by the Network Configuration 193 Protocol (NETCONF) [RFC6241], NETCONF remote procedure calls, and 194 NETCONF notifications. 196 UML (Unified Modeling Language) is a powerful modeling language, 197 which is domain agnostic. YANG and UML all focus on syntax 198 specification which formulate grammatical structure of NBI language, 199 however, they do not have the ability to express users' real 200 semantics. NBI language should facilitate users to express their own 201 intent explicitly, instead of general complying with grammar syntax. 202 So YANG and UML is appropriate to describe the model behind the NBI 203 language not the NBI itself. 205 With the emergence of the SDN concept, it is a consensus to simplify 206 the network operation, which leads to many cutting-edge explorations 207 in the academic area. 209 Nick McKeown from Stanford University proposed the SFNet [TSFNet], 210 which translated the high level network demand to the underlying 211 controller interfaces. By concealing the low level network details, 212 the controller simplified the operation of resource, flow, and 213 information for applications. The SFNet is used for the SDN 214 architecture design, and does not go into the NBI design. 216 Jennifer Rexford from Princeton University designed the Frenetic 217 [Frenetic] based on the OpenFlow protocol. It is an advanced 218 language for flow programming, and systematically defines the 219 operating model and mode for the flow. However, the network 220 requirement from the service is not only the flow operations, but 221 also includes operations of resource, service conditions, and service 222 logic. 224 In the book [PBNM], John Strassner defined the policy concept and 225 proposed the formal description for network operations by using the 226 policy. The method for querying network information is absent in the 227 book. Virtual tenant network and operations to the tenant network 228 are not considered. 230 All these investigations direct to the future SDN that use simple and 231 intuitive interfaces to describe the network demands without complex 232 programming. 234 5. The NEMO Language Specifications 236 NEMO language is a domain specific language (DSL) based on 237 abstraction of network models and conclusion of operation patterns. 238 It provides NBI fashion in the form of language. Instead of tons of 239 abstruse APIs, with limited number of key words and expressions, NEMO 240 language enables network users/applications to describe their demands 241 for network resources, services and logical operations in an 242 intuitive way. And finally the NEMO language description can be 243 explained and executed by a language engine. 245 5.1. Network Model of the NEMO Language 247 Behind the NEMO language, there is a set of basic network models 248 abstracting the network demands from the top down according to the 249 service requirement. Those demands can be divided into two types: 250 the demand for network resources and the demands for network 251 behaviors. 253 The network resource is composed of three kinds of entities: 254 CustomerFacingNode(CFN),Connection and ServiceFlow. Each entity contains 255 property and statistic information. With a globally unique identifier, 256 the network entity is the basic object for operation. Users can 257 construct their own topology or network traffic arbitrarily with these 258 basic objects without considering about real physical topology. 259 In addition, NEMO Engine also has the ability of obtaining available 260 resources automatically as operation objects when users don't define them. 262 o CustomerFacingNode model: describes the entity with the capability of packet 263 processing. According to the functionality, there are two types 264 of CustomerFacingNode. 266 * The function CFN (FN) provides network services or forwarding 267 with user concern, such as, firewall, load balance, vrouter, 268 etc. 270 * The business CFN (BN) describes a set of network elements and 271 their connections, such as subnet, autonomous system, and 272 internet. It conceals the internal topology and exposes 273 properties as one entity. It also enables iteration, i.e., a 274 network entity may include other network entities. 276 o Connection model: describes the connectivity network resource 277 between CustomerFacingNode entities. With Connection model, user 278 could apply for link resources between CustomerFacingNodes and user 279 can assign specific bandwidth for them. Connection constructs 280 the foundation of communication, namely, the necessary condition for 281 communications between CustomerFacingNodes is there are available 282 resources between them. By default, the communication is allowed if there 283 are direct connections between them. The Connection is not limited 284 to the connectivity between single entity and single entity, but it 285 can also express the connectivity between single entity and multiply 286 entities, or multiply entities and multiply entities. 288 o ServiceFlow model: describes a sequence of packets with certain common 289 characters, such as source/destination IP address, port, and 290 protocol. From the northbound perspective, service flow is the special 291 traffic with user concern, which may be per device or across many 292 devices. So the service flow characters also include ingress/egress CFN, 293 and so on. The ServiceFlow model together with the associated operations 294 describe reachability of specific traffic between CustomerFacingNodes in 295 the virtual network, which is different from the connection resource 296 between CustomerFacingNodes. 298 Network behavior includes the information aquisition and the control 299 operations. 301 The NEMO language provides two methods to get the network information 302 for users. 304 o Query: a synchronous mode to get the information, i.e., one can 305 get the response when a request is sent out. 307 o Notification: an asynchronous mode to get the information, i.e., 308 with one request, one or multiple responses will be sent to the 309 subscriber automatically whenever trigger conditions meet. 311 The NEMO language uses operations to control the network. 313 o Operation: control the behavior of specific entities by APP, such 314 as ServiceFlow operation, CustomerFacingNode operation. All the 315 operations follow the same pattern "when , do , 316 with ", and can be applied to any entity. And some of 317 operation elements can be omitted according to users' requirement. 318 Operation has the similar meaning with policy in some sense which 319 also emphasizes the dynamic adjustment of objects. 321 5.2. Notation 323 The syntactic notation used in this specification is an extended 324 version of BNF ("Backus Naur Form" or "Backus Normal Form"). In BNF, 325 each syntactic element of the language is defined by means of a 326 production rule. This defines the element in terms of a formula 327 consisting of the characters, character strings, and syntactic 328 elements that can be used to form an instance of it. The version of 329 BNF used in this specification makes use of the following symbols: 331 < > 333 Angle brackets delimit character strings that are the names of 334 syntactic elements. 336 ::= 338 The definition operator. This is used in a production rule to 339 separate the element defined by the rule from its definition. The 340 element being defined appears to the left of the operator and the 341 formula that defines the element appears to the right. 343 [ ] 345 Square brackets indicate optional elements in a formula. The portion 346 of the formula within the brackets may be explicitly specified or may 347 be omitted. 349 { } 351 Braces group elements in a formula. The portion of the formula 352 within the braces shall be explicitly specified. 354 | 356 The alternative operator. The vertical bar indicates that the 357 portion of the formula following the bar is an alternative to the 358 portion preceding the bar. If the vertical bar appears at a position 359 where it is not enclosed in braces or square brackets, it specifies a 360 complete alternative for the element defined by the production rule. 361 If the vertical bar appears in a portion of a formula enclosed in 362 braces or square brackets, it specifies alternatives for the contents 363 of the innermost pair of such braces or brackets. 365 !! 367 Introduces ordinary English text. This is used when the definition 368 of a syntactic element is not expressed in BNF. 370 5.3. NEMO Language Overview 372 NEMO language provides 5 classes of commands: model definition, 373 resource access, behavior, connection management, transaction to 374 facilitate the user intent description. 376 := | | 377 378 := | | 379 | 380 := | | | 381 | | 382 | | 383 | | 384 385 := | | 386 | | | 387 | 388 := | 390 NEMO language provides limited number of key words to enables network 391 users/applications to describe their intent. The key words supported 392 by the language are as follows: 394 := Boolean | Integer | String | Date | UUID | EthAddr | 395 IPPrefix | CFNModel | ConnectionModel | ServiceFlowModel | 396 ActionModel | Description | Porperty | CFN | Connection| 397 ServiceFlow | EndNodes | Type | Contain | Match | List | 398 Range| Query | From | Notification | Listener | 399 Operation | Target | Priority | Condition | Action | 400 Transaction | Commit | CREATE | IMPORT | UPDATE | DELETE 402 5.4. Model Definition 404 5.4.1. Data Types 406 NEMO language provides several build-in data types: 408 Boolean This data type is used for simple flags that track true/ 409 false conditions. There are only two possible values: true and 410 false. The Boolean literal is represented by the token . 412 Integer A number with an integer value, within the range from 413 -(2^63) to +(2^63)-1. The Integer literal is represented by the 414 token . 416 String A sequence of characters. The string is always in the 417 quotation marks. The String literal is represented by the token 418 . 420 Date A string in the format yyyy-mm-dd hh:mm:ss, or yyyy-mm-dd, or 421 hh:mm:ss. The Date literal is represented by the token . 423 UUID A string in the form of Universally Unique IDentifier 424 [RFC4122], e.g. "6ba7b814-9dad-11d1-80b4-00c04fd430c8". A 425 typical usage of the UUID is to identify network entities, 426 policies, actions and so on. The UUID literal is represented by 427 the token . 429 EthAddr A string in the form of MAC address, e.g. 430 "00:00:00:00:00:01". The EthAddr literal is represented by the 431 token . 433 IPPrefix A string in the form of IP address, e.g. "192.0.2.1". The 434 mask can be used in the IP address description, e.g. 435 "192.0.2.0/24". The IPPrefix literal is represented by the token 436 . 438 The token can be defined as follows: 440 := Boolean | Integer | String | Date | UUID | 441 EthAddr | IPPrefix 443 And a generic literal is represented by the token 445 := | | | | | 446 | 448 5.4.2. Model Definition and Description Statement 450 In addition to default build-in network models, NEMO language 451 facilitates users to define new model types. 453 The token is a string that MUST start with a letter and 454 followed by any number of letters and digits. More specific naming 455 can be defined as follows: 457 := !!type name of the CustomerFacingNode model 458 := !!type name of the connection model 459 := !!type name of the ServiceFlow model 460 := | | 461 := !!type name of the action model 462 := | 463 := !!name of the property in a model 465 The statement is used to create a CustomerFacingNode 466 model: 468 := CFNModel 469 Property { : }; 471 The CFNModel specifies a new CustomerFacingNode type. 473 The Property is followed by a list of " : " 474 pairs to specify properties for the new CustomerFacingNode type. Since 475 belonging network is the intrinsic property for a CustomerFacingNode 476 model, there is no need to redefine the belonging network in the property 477 list. 479 Example: 481 CFNModel "DPI" Property String : "name", Boolean : "is_enable"; The 482 statement generates a new CustomerFacingNode model named DPI with two 483 properties, "name" and "is_enable". 485 The statement is used to create a connection 486 model: 488 := ConnectionModel 489 Property { : }; 491 The ConnectionModel specifies a new connection type. 493 The Property is followed by a list of " : " 494 pairs to specify properties for the new connection type. Since end 495 CFNs are intrinsic properties for a connection model, there is no 496 need to redefine the end CustomerFacingNode in the property list. 498 The statement is used to create a ServiceFlow model: 500 := ServiceFlowModel 501 Property { : }; 503 The ServiceFlowModel specifies a new ServiceFlow type. 505 The Property is followed by a list of " : " 506 pairs to specify fields for the new ServiceFlow type. 508 The statement is used to create an action model: 510 := ActionModel 511 Property { : }; 513 The ActionModel specifies a new action type. 515 The Property is followed by a list of " : " 516 pairs to specify properties for the new action. 518 NEMO language also supports querying the description of a defined 519 model by using the statement: 521 := Description ; 522 The keyword Description is followed by a model type name. The 523 description of the queried model will return from the language 524 engine. 526 5.5. Resource Access Statements 528 In NEMO language, each resource entity instance is identified by a 529 which MUST be unique. We use the following token to 530 indicate the identifier given to the resource entity instance. 532 := !! name to identify the CustomerFacingNode instance 533 := !! name to identify the connection instance 534 := !! name to identify the ServiceFlow instance 535 := || 537 5.5.1. CustomerFacingNode Operations 539 NEMO model defines basic method for the CustomerFacingNode instances, 540 and uses intuitive keyword to indicate the specific method. User could 541 create, import, update and delete a CustomerFacingNode instance. 543 The statement is used to create or update a CustomerFacingNode 544 instance: 546 := CREATE CFN Type 547 [Contain {}] 548 [Property {: }]; 550 The statement is used to import an existing external 551 CustomerFacingNode instance: 553 := IMPORT CFN Type 554 [Contain {}] 555 [Property {: }]; 557 The statement is used to update an existing CustomerFacingNode 558 instance: 560 := UPDATE CFN 561 [Contain {}] 562 [Property {: }]; 564 In all the above three statements, the CFN is followed by a user 565 specified . According to the method, system will take 566 corresponding action for the CustomerFacingNode instance. If the method 567 is CREATE or IMPORT and the is new in the system, a new CustomerFacingNode 568 will be created automatically. If the method is UPDATE and the 569 exists in the system, the corresponding CustomerFacingNode identified by 570 will be updated with the following information. 572 The Type specifies the type of the CustomerFacingNode to operate. 574 The Contain is an optional keyword specifying the internal CustomerFacingNodes 575 which are included in this CustomerFacingNode instance. 577 The Property is an optional keyword followed by a list of 578 ": " pairs. Multiple ": 579 " pairs are separated by commas. The MUST be 580 selected from the property definition of the corresponding CustomerFacingNode 581 definition. 583 An example of creating a CustomerFacingNode instance is as follows: 585 CREATE CFN Headquarter 586 Type l3group 587 Contain LN-1 588 Property location : "Beijing"; 590 The statement creates a layer 3 virtual network which contains a 591 predefined CustomerFacingNode "LN-1". The l3 virtual network is located in 592 Beijing. 594 The statement is used to delete a CustomerFacingNode instance: 596 := DELETE CFN ; 598 The DELETE CFN is to delete a CustomerFacingNode in user's network. 600 5.5.2. Connection Operations 602 NEMO model defines basic method for the connection instances, and use 603 intuitive keyword to indicate the specific method. User could 604 create, update and delete a connection instance. 606 The statement is used to create a connection: 608 := CREATE Connection 609 Type 610 EndNodes , 611 [Property {: }]; 613 The statement is used to update a connection: 615 := UPDATE Connection 616 [EndNodes {}, {}] 617 [Property {: }]; 619 The Connection is followed by a user specified . If 620 the method is CREATE and the is new in the system, a 621 new connection will be created automatically. If the method is 622 UPDATE and the exists in the system, the 623 corresponding connection identified by the will be 624 updated with the following information. 626 The Type specifies the type of the connection to use. For example 627 there will be point to point connection, or point to multiple points 628 connection. 630 The EndNodes specifies the end CustomerFacingNodes of a connection. For each 631 connection there will be left CustomerFacingNodes and right CustomerFacingNodes 632 stand for the two ends. 634 The Property is an optional keyword followed by a list of 635 ": " pairs. Multiple ": 636 " pairs are separated by commas. The MUST be 637 selected from the property definition of the corresponding connection 638 definition. 640 An example of creating a connection instance is as follows: 642 CREATE Connection connection-1 643 Type p2p 644 EndNodes S1, S2 645 Property bandwidth : 1000, delay : 40; 647 The statement creates a connection between two CustomerFacingNodes, and sets the 648 connection property. 650 The statement is used to delete a connection 651 instance: 653 := DELETE Connection ; 655 The DELETE Connection is to delete a connection in user's network. 657 5.5.3. ServiceFlow Operations 659 NEMO model defines basic method for the ServiceFlow instances, and use 660 intuitive keyword to indicate the specific method. User could 661 create, update and delete a ServiceFlow instance. 663 The statement is used to create a ServiceFlow: 665 := CREATE ServiceFlow 666 Match {: 667 | Range (, ) 668 | List({})} 670 The statement is used to update a ServiceFlow: 672 := UPDATE ServiceFlow 673 Match {: 674 | Range (, ) 675 | List({})} 677 The ServiceFlow is followed by a user defined . If the method is 678 CREATE and the is new in the system, a new ServiceFlow identifier 679 will be created automatically. If the method is UPDATE and the 680 exists in the system, the corresponding ServiceFlow identified by 681 the will be updated with the following information. 683 The Match specifies a ServiceFlow by indicate match fields. NEMO language 684 also provides two keywords to assist the expression of values: 686 o The List is used to store a collection of data with the same data 687 type. 689 o The Range is used to express a range of values. 691 An example of creating a ServiceFlow instance is as follows: 693 CREATE ServiceFlow flow-1 694 Match src_ip : Range ("192.0.2.1", "192.0.2.243"); 696 The statement describes a ServiceFlow with the source IP address ranging 697 from 192.0.2.1 to 192.0.2.243. 699 The statement is used to delete a ServiceFlow instance: 701 := DELETE ServiceFlow ; 703 The DELETE ServiceFlow is to delete a ServiceFlow in user's network. 705 5.6. Behavior Statements 706 5.6.1. Query Behavior 708 The query statement is to retrieve selected data from specified model 709 object. 711 The generate a query: 713 := Query {} 714 From {|} 716 The Query is followed by one or more s which are 717 defined properties of the object to be queried. 719 The From is followed by the one or more queried objects. NENO 720 language support query operation to network entities and the policy. 722 5.6.2. Operation Behavior 724 NEMO model defines basic method for the operation instances, and use 725 intuitive keyword to indicate the specific method. User could 726 create, update and delete a operation instance. 728 In NEMO language, each operation instance is identified by a 729 which MUST be unique. 731 := !! name to identify the operation instance 733 Create and update a policy 735 := CREATE Operation 736 Target 737 Priority 738 [Condition ] 739 Action { : {}}; 741 := UPDATE Operation 742 [Target ] 743 [Priority ] 744 [Condition ] 745 [Action { : {}}]; 747 The Operation is followed by a user defined . If the 748 method is CREATE and the is new in the system, a new 749 operation will be created automatically. If the method is UPDATE and 750 the exists in the system, the corresponding operation 751 identified by the will be updated with the following 752 information. 754 The Target specifies the entity to which the operation will apply. 756 The Priority specifies the globe priority of the operation in the 757 tenant name space. The with lower number has a higher 758 priority, i.e. priority 0 holds the highest priority. 760 The Condition is an optional keyword follow by an expression. It 761 tells your program to execute the following actions only if a 762 particular test described by the expression evaluates to true. And 763 users also can define which objects won't need to execute these 764 actions with Constraint. 766 A NEMO language expression is a construct made up of variables, 767 operators, and method invocations, which are constructed according to 768 the syntax of the language and evaluates to a single value. NEMO 769 language supports many operators to facilitate the construction of 770 expressions. Assume variable A holds 10 and variable B holds 0, 771 then: 773 +----------+----------------------------------------------+---------+ 774 | Operator | Description | Example | 775 +----------+----------------------------------------------+---------+ 776 | && | Called Logical AND operator. If both the | (A && | 777 | | operands are non-zero, then the condition | B) is | 778 | | becomes true. | false. | 779 | || | Called Logical OR Operator. If any of the | (A || | 780 | | two operands are non-zero, then the | B) is | 781 | | condition becomes true. | true. | 782 | ! | Called Logical NOT Operator. Use to reverses | !(A && | 783 | | the logical state of its operand. If a | B) is | 784 | | condition is true then Logical NOT operator | true. | 785 | | will make false. | | 786 | == | Checks if the values of two operands are | (A == | 787 | | equal or not, if yes then condition becomes | B) is | 788 | | true. | not | 789 | | | true. | 790 | != | Checks if the values of two operands are | (A != | 791 | | equal or not, if values are not equal then | B) is | 792 | | condition becomes true. | true. | 793 | > | Checks if the value of left operand is | (A > B) | 794 | | greater than the value of right operand, if | is not | 795 | | yes then condition becomes true. | true. | 796 | >= | Checks if the value of left operand is | (A >= | 797 | | greater than or equal to the value of right | B) is | 798 | | operand, if yes then condition becomes true. | not | 799 | | | true. | 800 | < | Checks if the value of left operand is less | (A < B) | 801 | | than the value of right operand, if yes then | is | 802 | | condition becomes true. | true. | 803 | <= | Checks if the value of left operand is less | (A <= | 804 | | than or equal to the value of right operand, | B) is | 805 | | if yes then condition becomes true. | true. | 806 +----------+----------------------------------------------+---------+ 808 The Action specifies the execution when conditions meet. 810 An example of creating anoperation is as follows: 812 CREATE Operation operation-1 813 Target flow-1 814 Priority 100 815 Condition (time>"18:00") || (time<"21:00") 816 Action redirect : "backup_connection"; 818 The statement creates an operation which indicates the service flow to go 819 through backup connection from 18:00 to 21:00. 821 Delete an operation: 823 := DELETE Operation ; 825 The DELETE Operation is to delete a policy in user's network. 827 5.6.3. Notification Behavior 829 In NEMO language, each notification instance is identified by a 830 832 := !! name to identify the notification 833 instance 835 Create and update a notification 837 := CREATE Notification 838 [(Query {} 839 From {})] 840 Condition {} 841 Listener ; 843 := UPDATE Notification 844 [(Query {} 845 From {})] 846 Condition {} 847 Listener ; 849 The Notification is followed by a user defined . If 850 the method is CREATE and the is new in the system, 851 a new notification will be created automatically. If the method is 852 UPDATE and the exists in the system, the 853 corresponding notification identified by the will be 854 updated with the following information. 856 The Query clause is nested in the notification statement to indicate 857 the information acquisition. 859 The Condition clause is the same as in operation statement, which 860 triggers the notification. 862 The Listener specifies the callback function that is used to process 863 the notification. 865 Delete a notification: 867 := DELETE Notification ; 868 The DELETE Notification is to delete a notification in user's 869 network. 871 5.7. Transaction Statements 873 := Transaction 874 := Commit 876 The keywords Transaction and Commit are used to tag begin and end of 877 a transaction. The code between the two key words will be 878 interpreted as a transaction and executed by the NEMO language 879 engine. 881 6. The NEMO Language Examples 883 An enterprise with geographically distributed headquarter and branch 884 sites has the requirement to dynamically balance the backup traffic. 886 In order to implement this scenario, the virtual WAN tenant creates 887 two logicnw, and generates two connections with different SLA to 888 carry diverse service flows. One connection has 100M bandwidth with 889 less than 50ms delay, which is used for normal traffic. And the 890 other connection has 40G bandwidth with less than 400ms delay, which 891 is used for backup traffic after work (from 19:00 to 23:00). With 892 self defined service flow operations, the tenant can manage the connection 893 load balancing conveniently. 895 Real-time Connection 896 +--------------------+ 897 192.0.2.0/24 198.51.100.0/24 898 +---------+ +-------------+ 899 | Branch |------------------| Headquarter | 900 +---------+ +-------------+ 901 | | 902 +--------------------+ 903 Broadband Connection 905 The detailed operation and code are shown as follows. 907 o Step1: Create two virtual logicnw CustomerFacingNodes in the WAN 909 CREATE CFN Branch 910 Type l2group 911 Property ipv4Prefix : 192.0.2.0/24; 913 CREATE CFN Headquarter 914 Type l2group 915 Property ipv4Prefix : 198.51.100.0/24; 917 o Step2: Connect the two virtual CustomerFacingNodes with two virtual connections 918 with different SLA. 920 CREATE Connection broadband_connection 921 EndNodes Branch, Headquater 922 Property bandwidth : 40000, delay : 400; 924 CREATE Connection realtime_connection 925 EndNodes Branch, Headquater 926 Property bandwidth : 100, delay : 50; 928 o Step3: Indicate the service flow to be operated. 930 CREATE ServiceFlow flow_all 931 Match src_ip : "192.0.2.0/24", dst_ip: "198.51.100.0/24"; 933 CREATE ServiceFlow flow_backup 934 Match src_ip : "192.0.2.0/24", dst_ip: "198.51.100.0/24", 935 port: 55555; 937 o Step4: Apply policies to corresponding service flows. 939 P1: 940 CREATE Operation operation4all 941 Target flow_all 942 Priority 200 943 Action redirect: "realtime_connection"; 944 P2: 945 CREATE Operation operation4backup 946 Target flow_backup 947 Priority 100 948 Condition (time>"19:00:00") || (time<"23:00:00") 949 Action redirect: "broadband_connection"; 951 7. Security Considerations 953 Because the network customers are allowed to customize their own 954 services, they may bring potentially big impacts to a running IP 955 network. A strong user authentication mechanism is needed for the 956 northbound interface of the SDN controller. User authorization 957 should be carefully managed by the network administrator to avoid any 958 dangerous operations and prevent any abuse of network resources. 960 8. IANA Considerations 962 This memo includes no request to IANA. 964 9. Acknowledgements 966 The authors would like to thanks the valuable comments made by Wei 967 Cao, Xiaofei Xu, Fuyou Miao, Yali Zhang and Wenyang Lei. 969 This document was produced using the xml2rfc tool [RFC2629]. 971 10. Informative References 973 [Frenetic] 974 Foster, N., Harrison, R., Freedman, M., Monsanto, C., 975 Rexford, J., Story, A., and D. Walker, "Frenetic: A 976 Network Programming Languages, ICFP' 11". 978 [I-D.xia-sdnrg-service-description-language] 979 Xia, Y., Jiang, S., and S. Hares, "Requirements for a 980 Service Description Language and Design Considerations", 981 draft-xia-sdnrg-service-description-language-02 (work in 982 progress), May 2015. 984 [PBNM] Strassner, J., "Policy-Based Network Management: Solutions 985 for the Next Generation, Morgan Kaufmann Publishers Inc. 986 San Francisco, CA, USA.", 2003. 988 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 989 Requirement Levels", BCP 14, RFC 2119, 990 DOI 10.17487/RFC2119, March 1997, 991 . 993 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 994 DOI 10.17487/RFC2629, June 1999, 995 . 997 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 998 Unique IDentifier (UUID) URN Namespace", RFC 4122, 999 DOI 10.17487/RFC4122, July 2005, 1000 . 1002 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1003 the Network Configuration Protocol (NETCONF)", RFC 6020, 1004 DOI 10.17487/RFC6020, October 2010, 1005 . 1007 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1008 and A. Bierman, Ed., "Network Configuration Protocol 1009 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1010 . 1012 [TSFNet] Yap, K., Huang, T., Dodson, B., Lam, M., and N. McKeown, 1013 "Towards Software-Friendly Networks, APSys 2010, pp:49-54, 1014 2010, New Delhi, India.". 1016 Authors' Addresses 1018 Yinben Xia (editor) 1019 Huawei Technologies Co., Ltd 1020 Q14, Huawei Campus, No.156 Beiqing Road 1021 Hai-Dian District, Beijing, 100095 1022 P.R. China 1024 Email: xiayinben@huawei.com 1026 Sheng Jiang (editor) 1027 Huawei Technologies Co., Ltd 1028 Q14, Huawei Campus, No.156 Beiqing Road 1029 Hai-Dian District, Beijing, 100095 1030 P.R. China 1032 Email: jiangsheng@huawei.com 1034 Tianran Zhou (editor) 1035 Huawei Technologies Co., Ltd 1036 Q14, Huawei Campus, No.156 Beiqing Road 1037 Hai-Dian District, Beijing, 100095 1038 P.R. China 1040 Email: zhoutianran@huawei.com 1042 Susan Hares 1043 Huawei Technologies Co., Ltd 1044 7453 Hickory Hill 1045 Saline, CA 48176 1046 USA 1048 Email: shares@ndzh.com 1050 Yali Zhang (editor) 1051 Huawei Technologies Co., Ltd 1052 Q14, Huawei Campus, No.156 Beiqing Road 1053 Hai-Dian District, Beijing, 100095 1054 P.R. China 1056 Email: zhangyali369@huawei.com