idnits 2.17.00 (12 Aug 2021) /tmp/idnits10702/draft-xia-sdnrg-nemo-language-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 137 has weird spacing: '...service also ...' == Line 143 has weird spacing: '...rk user also ...' -- The document date (May 4, 2015) is 2574 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG Y. Xia, Ed. 3 Internet-Draft S. Jiang, Ed. 4 Intended status: Standards Track T. Zhou, Ed. 5 Expires: November 5, 2015 S. Hares 6 Huawei Technologies Co., Ltd 7 May 4, 2015 9 NEMO (NEtwork MOdeling) Language 10 draft-xia-sdnrg-nemo-language-02 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 November 5, 2015. 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 . . . . . . . . . . . . . . . 11 69 5.5.1. Node Operations . . . . . . . . . . . . . . . . . . . 12 70 5.5.2. Connection Operations . . . . . . . . . . . . . . . . 12 71 5.5.3. Flow Operations . . . . . . . . . . . . . . . . . . . 13 72 5.6. Behavior Statements . . . . . . . . . . . . . . . . . . . 14 73 5.6.1. Query Behavior . . . . . . . . . . . . . . . . . . . 14 74 5.6.2. Policy Behavior . . . . . . . . . . . . . . . . . . . 14 75 5.6.3. Notification Behavior . . . . . . . . . . . . . . . . 17 76 5.7. Connection Management Statements . . . . . . . . . . . . 17 77 5.8. Transaction Statements . . . . . . . . . . . . . . . . . 18 78 6. The NEMO Language Examples . . . . . . . . . . . . . . . . . 18 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 82 10. Informative References . . . . . . . . . . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 85 1. Introduction 87 While SDN (Software Defined Network) is becoming one of the most 88 important directions of network evolution, the essence of SDN is to 89 make the network more flexible and easy to use. The North-Bound 90 Interface (NBI), located between the control plane and the 91 applications, is essential to enable the application innovations and 92 nourish the eco-system of SDN by abstracting the network 93 capabilities/information and opening the abstract/logic network to 94 applications. 96 The NBI is usually provided in the form of API (Application 97 Programming Interface). Different vendors provide self-defined API 98 sets. Each API set, such as OnePK from Cisco and OPS from Huawei, 99 often contains hundreds of specific APIs. Diverse APIs without 100 consistent style are hard to remember and use, and nearly impossible 101 to be standardized. 103 In addition, most of those APIs are designed by network domain 104 experts, who are used to thinking from the network system 105 perspective. The interface designer does not know how the users will 106 use the device and exposes information details as much as possible. 107 It enables better control of devices, but leaves huge burden of 108 selecting useful information to users without well training. Since 109 the NBI is used by network users, a more appropriate design is to 110 express user intent and abstract the network from the top down. 112 To implement such an NBI design, we can learn from the successful 113 case of SQL (Structured Query Language), which simplified the 114 complicated data operation to a unified and intuitive way in the form 115 of language. Applications do not care about the way of data storage 116 and data operation, but to describe the demand for the data storage 117 and operation and then get the result. As a data domain DSL, SQL is 118 simple and intuitive, and can be embedded in applications. So what 119 we need for the network NBI is a set of "network domain SQL". 120 [I-D.xia-sdnrg-service-description-language] describe the 121 requirements for a service description language and the design 122 considerations. 124 This document will introduce an intent based NBI with novel language 125 fashion. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 [RFC2119] when they appear in ALL CAPS. When these words are not in 133 ALL CAPS (such as "should" or "Should"), they have their usual 134 English meanings, and are not to be interpreted as [RFC2119] key 135 words. 137 Network service also "service" for short, is the service logic that 138 contains network operation requirements; 140 Network APP also "APP" for short, is the application to implement 141 the network service; 143 Network user also "user" for short, is the network administrator or 144 operator. 146 3. Requirements for the Intent Based NBI Language 148 An intent based NBI language design contains following features: 150 o Express user intent 152 To simplify the operation, applications or users can use the NBI 153 directly to describe their requirements for the network without 154 taking care of the implementation. All the parameters without 155 user concern will be concealed by the NBI. 157 o Platform independent 159 With the NBI, the application or user can description of network 160 demand in a generic way, so that any platform or system can get 161 the identical knowledge and consequently execute to the same 162 result. Any low-level and device/vendor specific configurations 163 and dependencies should be avoided. 165 o Intuitive Domain Specific Language (DSL) for network 167 The expression of the DSL should be human-friendly and be easily 168 understood by network operators. DSL should be directly used by 169 the system. 171 o Privilege control 173 Every application or user is authorized within a specific network 174 domain, which can be physical or virtual. While different network 175 domains are isolated without impact, the application or user may 176 have access to all the resource and capabilities within its 177 domain. The user perception of the network does not have to be 178 the same as the network operators. The NBI language works on the 179 user's view so the users can create topologies based on the 180 resources the network-operators allow them to have. 182 o Declarative style 184 As described above, the NBI language is designed to help defining 185 service requirement to network, detailed configurations and 186 instructions performed by network devices are opaque to network 187 operators. So the NBI language should be declarative rather than 188 imperative. 190 4. Related work 192 YANG [RFC6020] is a data modeling language used to model 193 configuration and state data manipulated by the Network Configuration 194 Protocol (NETCONF) [RFC6241], NETCONF remote procedure calls, and 195 NETCONF notifications. 197 UML (Unified Modeling Language) is a powerful modeling language, 198 which is domain agnostic. YANG and UML all focus on syntax 199 specification which formulate grammatical structure of NBI language, 200 however, they do not have the ability to express users' real 201 semantics. NBI language should facilitate users to express their own 202 intent explicitly, instead of general complying with grammar syntax. 203 So YANG and UML is appropriate to describe the model behind the NBI 204 language not the NBI itself. 206 With the emergence of the SDN concept, it is a consensus to simplify 207 the network operation, which leads to many cutting-edge explorations 208 in the academic area. 210 Nick McKeown from Stanford University proposed the SFNet [TSFNet], 211 which translated the high level network demand to the underlying 212 controller interfaces. By concealing the low level network details, 213 the controller simplified the operation of resource, flow, and 214 information for applications. The SFNet is used for the SDN 215 architecture design, and does not go into the NBI design. 217 Jennifer from Princeton University designed the Frenetic [Frenetic] 218 based on the OpenFlow protocol. It is an advanced language for flow 219 programming, and systematically defines the operating model and mode 220 for the flow. However, the network requirement from the service is 221 not only the flow operations, but also includes operations of 222 resource, service conditions, and service 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: node, 254 connection and flow. Each entity contains property and statistic 255 information. With a globally unique identifier, the network entity 256 is the basic object for operation. Users can construct their own 257 topology or network traffic arbitrarily with these basic objects 258 without considering about real physical topology. In addition, NEMO 259 Engine also has the ability of obtaining available resources 260 automatically as operation objects when users don't define them. 262 o Node model: describes the entity with the capability of packet 263 processing. According to the functionality, there are two types 264 of node 266 * The function node (FN) provides network services or forwarding 267 with user concern, such as, firewall, load balance, vrouter, 268 etc. 270 * The business node (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 between node 277 entities. This connection is not limited at the connectivity 278 between single entity and single entity, but it also can express 279 the connectivity between single entity and multiply entities, or 280 multiply entities and multiply entities. 282 o Flow model: describes a sequence of packets with certain common 283 characters, such as source/destination IP address, port, and 284 protocol. From the northbound perspective, flow is the special 285 traffic with user concern, which may be per device or across many 286 devices. So the flow characters also include ingress/egress node, 287 and so on. 289 Network behavior includes the information and control operations. 291 The information operation provides two methods to get the network 292 information for users. 294 o Query: a synchronous mode to get the information, i.e., one can 295 get the response when a request is sent out. 297 o Notification: an asynchronous mode to get the information, i.e., 298 with one request, one or multiple responses will be sent to the 299 subscriber automatically whenever trigger conditions meet. 301 The NEMO language uses policy to describe the control operation. 303 o Policy: control the behavior of specific entities by APP, such as 304 flow policy, node policy. All the policies follow the same 305 pattern "when , to execute , with 306 ", and can be applied to any entity. But some of 307 policy elements can be omitted according to users' requirement. 309 5.2. Notation 311 The syntactic notation used in this specification is an extended 312 version of BNF ("Backus Naur Form" or "Backus Normal Form"). In BNF, 313 each syntactic element of the language is defined by means of a 314 production rule. This defines the element in terms of a formula 315 consisting of the characters, character strings, and syntactic 316 elements that can be used to form an instance of it. The version of 317 BNF used in this specification makes use of the following symbols: 319 < > 321 Angle brackets delimit character strings that are the names of 322 syntactic elements. 324 ::= 326 The definition operator. This is used in a production rule to 327 separate the element defined by the rule from its definition. The 328 element being defined appears to the left of the operator and the 329 formula that defines the element appears to the right. 331 [ ] 333 Square brackets indicate optional elements in a formula. The portion 334 of the formula within the brackets may be explicitly specified or may 335 be omitted. 337 { } 339 Braces group elements in a formula. The portion of the formula 340 within the braces shall be explicitly specified. 342 | 344 The alternative operator. The vertical bar indicates that the 345 portion of the formula following the bar is an alternative to the 346 portion preceding the bar. If the vertical bar appears at a position 347 where it is not enclosed in braces or square brackets, it specifies a 348 complete alternative for the element defined by the production rule. 349 If the vertical bar appears in a portion of a formula enclosed in 350 braces or square brackets, it specifies alternatives for the contents 351 of the innermost pair of such braces or brackets. 353 !! 355 Introduces ordinary English text. This is used when the definition 356 of a syntactic element is not expressed in BNF. 358 5.3. NEMO Language Overview 360 NEMO language provides 5 classes of commands: model definition, 361 resource access, behavior, connection management, transaction to 362 facilitate the user intent description. 364 := | | 365 366 := | | 367 | 368 := | | | 369 | | 370 := | | | 371 | 372 := | 373 := | 375 NEMO language provides limited number of key words to enables network 376 users/applications to describe their intent. The key words supported 377 by the language are as follows: 379 := Boolean | Integer | String | Date | UUID | EthAddr | 380 IPPrefix | NodeModel | ConnectionModel | FlowModel | 381 ActionModel | Description | Porperty | Node | Connection| 382 Flow | No | EndNodes | Type | NW | Match | List | 383 Range| Query | From | Notification | Listener | 384 Policy | ApplyTo | Priority | Condition | Action | 385 Connect | Disconnect | Address | Port | Transaction | 386 Commit 388 5.4. Model Definition 390 5.4.1. Data Types 392 NEMO language provides several build-in data types: 394 Boolean This data type is used for simple flags that track true/ 395 false conditions. There are only two possible values: true and 396 false. The Boolean literal is represented by the token . 398 Integer A number with an integer value, within the range from 399 -(2^63) to +(2^63)-1. The Integer literal is represented by the 400 token . 402 String A sequence of characters. The string is always in the 403 quotation marks. The String literal is represented by the token 404 . 406 Date A string in the format yyyy-mm-dd hh:mm:ss, or yyyy-mm-dd, or 407 hh:mm:ss. The Date literal is represented by the token . 409 UUID A string in the form of Universally Unique IDentifier 410 [RFC4122], e.g. "6ba7b814-9dad-11d1-80b4-00c04fd430c8". A 411 typical usage of the UUID is to identify network entities, 412 policies, actions and so on. The UUID literal is represented by 413 the token . 415 EthAddr A string in the form of MAC address, e.g. 416 "00:00:00:00:00:01". The EthAddr literal is represented by the 417 token . 419 IPPrefix A string in the form of IP address, e.g. "192.0.2.1". The 420 mask can be used in the IP address description, e.g. 421 "192.0.2.0/24". The IPPrefix literal is represented by the token 422 . 424 The token can be defined as follows: 426 := Boolean | Integer | String | Date | UUID | 427 EthAddr | IPPrefix 429 And a generic literal is represented by the token 431 := | | | | | 432 | 434 5.4.2. Model Definition and Description Statement 436 In addition to default build-in network models, NEMO language 437 facilitates users to define new model types. 439 The token is a string that MUST start with a letter and 440 followed by any number of letters and digits. More specific naming 441 can be defined as follows: 443 := !!type name of the node model 444 := !!type name of the connection model 445 := !!type name of the flow model 446 := | | 447 := !!type name of the action model 448 := | 449 := !!name of the property in a model 451 The statement is used to create a node model: 453 := NodeModel 454 Property { : }; 456 The NodeModel specifies a new node type. 458 The Property is followed by a list of " : " 459 pairs to specify properties for the new node type. Since belonging 460 network is the intrinsic property for a node model, there is no need 461 to redefine the belonging network in the property list. 463 Example: 465 NodeModel "DPI" Property String : "name", Boolean : "is_enable"; The 466 statement generates a new node model named DPI with two properties, 467 "name" and "is_enable". 469 The statement is used to create a connection 470 model: 472 := ConnectionModel 473 Property { : }; 475 The ConnectionModel specifies a new connection type. 477 The Property is followed by a list of " : " 478 pairs to specify properties for the new connection type. Since end 479 nodes are intrinsic properties for a connection model, there is no 480 need to redefine the end nodes in the property list. 482 The statement is used to create a flow model: 484 := FlowModel 485 Property { : }; 487 The FlowModel specifies a new flow type. 489 The Property is followed by a list of " : " 490 pairs to specify fields for the new flow type. The 491 statement is used to create an action model: 493 := ActionModel 494 Property { : }; 496 The ActionModel specifies a new action type. 498 The Property is followed by a list of " : " 499 pairs to specify properties for the new action. 501 NEMO language also supports querying the description of a defined 502 model by using the statement: 504 := Description ; 506 The keyword Description is follow by a model type name. The 507 description of the queried model will return from the language 508 engine. 510 5.5. Resource Access Statements 512 In NEMO language, each resource entity instance is identified by a 513 . We use the following token to indicate the identifier given 514 to the resource entity instance. 516 := !! name to identify the node instance 517 := !! name to identify the connection instance 518 := !! name to identify the flow instance 519 := || 521 5.5.1. Node Operations 523 The statement is used to create or update a node instance: 525 := Node Type 526 NW 527 [Property {: }]; 529 The Node is followed by a user specified . If the 530 is new in the system, a new node will be created automatically. 531 Otherwise, the corresponding node identified by will be 532 updated with the following information. 534 The Type specifies the type of the node to operate. 536 The NW specifies the dependence where the node is located. 538 The Property is an optional keyword followed by a list of 539 ": " pairs. Multiple ": 540 " pairs are separated by commas. The MUST be 541 selected from the property definition of the corresponding node 542 definition. 544 Node "Headquater" 545 Type "logicnw" 546 NW "LN-1" 547 Property "location" : "Beijing"; 549 The statement creates a switch type node that is located in the 550 logical network "LN-1". 552 The statement is used to delete a node instance: 554 := No Node ; 556 The No Node is to delete a node in user's network. 558 5.5.2. Connection Operations 560 The statement is used to create or update a 561 connection: 563 := Connection 564 EndNodes , 565 [Property {: }]; 567 The Connection is followed by a user specified . If 568 the is new in the system, a new connection will be 569 created automatically. Otherwise, the corresponding connection 570 identified by the will be updated with the following 571 information. 573 The EndNodes specifies the two end nodes, identified by " 574 : ", of a connection. The Property is an optional keyword 575 followed by a list of ": " pairs. Multiple 576 ": " pairs are separated by commas. The 577 MUST be selected from the property definition of the 578 corresponding connection definition. 580 Example: 582 Connection "connection-1" 583 EndNodes "S1", "S2" 584 Property "bandwidth" : 1000, "delay" : 40; 586 The statement creates a connection between two nodes, and sets the 587 connection property. 589 The statement is used to delete a node instance: 591 := No Connection ; 593 The No Connection is to delete a connection in user's network. 595 5.5.3. Flow Operations 597 The statement is used to create or update a flow: 599 := Flow Match {: 600 | Range (, ) 601 | List({})} 603 The Flow is followed by a user defined . If the 604 is new in the system, a new flow will be created automatically. 605 Otherwise, the corresponding flow identified by the will be 606 updated with the following information. 608 The Match specifies a flow by indicate match fields. NEMO language 609 also provides two keywords to assist the expression of values: 611 o The List is used to store a collection of data with the same data 612 type. 614 o The Range is used to express a range of values. 616 Example: 618 Flow "flow-1" 619 Match "src_ip" : Range ("192.0.2.1", "192.0.2.243"); 621 The statement describes a flow with the source IP address ranging 622 from 192.0.2.1 to 192.0.2.243. 624 The statement is used to delete a flow instance: 626 := No Flow ; 628 The No Flow is to delete a flow in user's network. 630 5.6. Behavior Statements 632 5.6.1. Query Behavior 634 The query statement is to retrieve selected data from specified model 635 object. 637 The generate a query: 639 := Query {} 640 From {|} 642 The Query is followed by one or more s which are 643 defined properties of the object to be queried. 645 The From is followed by the one or more queried objects. NENO 646 language support query operation to network entities and the policy. 648 5.6.2. Policy Behavior 650 In NEMO language, each policy instance is identified by a 652 := !! name to identify the policy instance 654 Create and update a policy 656 := Policy ApplyTo 657 Priority 658 [Condition {}] 659 Action { : {}} 660 [Constraint {}]; 662 The Policy is followed by a user defined . If the 663 is new in the system, a new policy will be created 664 automatically. Otherwise, the corresponding notification identified 665 by the will be updated with the following information. 667 The ApplyTo specifies the entity to which the policy will apply. 669 The Priority specifies the globe priority of the policy in the tenant 670 name space. The with lower number has a higher priority, 671 i.e. priority 0 holds the highest priority. 673 The Condition is an optional keyword follow by an expression. It 674 tells your program to execute the following actions only if a 675 particular test described by the expression evaluates to true. And 676 users also can define which objects won't need to execute these 677 actions with Constraint. 679 A NEMO language expression is a construct made up of variables, 680 operators, and method invocations, which are constructed according to 681 the syntax of the language and evaluates to a single value. NEMO 682 language supports many operators to facilitate the construction of 683 expressions. Assume variable A holds 10 and variable B holds 0, 684 then: 686 +----------+----------------------------------------------+---------+ 687 | Operator | Description | Example | 688 +----------+----------------------------------------------+---------+ 689 | && | Called Logical AND operator. If both the | (A && | 690 | | operands are non-zero, then the condition | B) is | 691 | | becomes true. | false. | 692 | || | Called Logical OR Operator. If any of the | (A || | 693 | | two operands are non-zero, then the | B) is | 694 | | condition becomes true. | true. | 695 | ! | Called Logical NOT Operator. Use to reverses | !(A && | 696 | | the logical state of its operand. If a | B) is | 697 | | condition is true then Logical NOT operator | true. | 698 | | will make false. | | 699 | == | Checks if the values of two operands are | (A == | 700 | | equal or not, if yes then condition becomes | B) is | 701 | | true. | not | 702 | | | true. | 703 | != | Checks if the values of two operands are | (A != | 704 | | equal or not, if values are not equal then | B) is | 705 | | condition becomes true. | true. | 706 | > | Checks if the value of left operand is | (A > B) | 707 | | greater than the value of right operand, if | is not | 708 | | yes then condition becomes true. | true. | 709 | >= | Checks if the value of left operand is | (A >= | 710 | | greater than or equal to the value of right | B) is | 711 | | operand, if yes then condition becomes true. | not | 712 | | | true. | 713 | < | Checks if the value of left operand is less | (A < B) | 714 | | than the value of right operand, if yes then | is | 715 | | condition becomes true. | true. | 716 | <= | Checks if the value of left operand is less | (A <= | 717 | | than or equal to the value of right operand, | B) is | 718 | | if yes then condition becomes true. | true. | 719 +----------+----------------------------------------------+---------+ 721 The Action specifies the execution when conditions meet. 723 Example: 725 Policy "policy-1" 726 ApplyTo "flow-1" 727 Priority 100 728 Condition ("time">"18:00") || ("time"<"21:00") 729 Action "gothrough" : "backup_connection"; 731 The statement creates a policy which indicates the flow to go through 732 backup connection from 18:00 to 21:00. 734 Delete a policy: 736 := No Policy ; 738 The No Policy is to delete a policy in user's network. 740 5.6.3. Notification Behavior 742 In NEMO language, each notification instance is identified by a 743 745 := !! name to identify the notification 746 instance 748 Create and update a notification 750 := Notification 751 [(Query {} 752 From {})] 753 Condition {} 754 Listener ; 756 The Notification is followed by a user defined . If 757 the is new in the system, a new notificaiton will 758 be created automatically. Otherwise, the corresponding notification 759 identified by the will be updated with the 760 following information. 762 The Query clause is nested in the notification statement to indicate 763 the information acquisition. 765 The Condition clause is the same as in policy statement, which 766 triggers the notification. 768 The Listener specifies the callback function that is used to process 769 the notification. 771 Delete a notification: 773 := No Notification ; 775 The No Notification is to delete a notification in user's network. 777 5.7. Connection Management Statements 779 In NEMO language, each connection instance is identified by a 780 781 := !! name to identify the connection instance 783 Setup a connection to the NEMO language engine: 785 := Connect Address 786 Port 788 The Connect is followed by a user defined . If the 789 is new in the system, a new connection will be created 790 automatically. Otherwise, the corresponding connection identified by 791 will be updated with the following information. 793 The Address and Prot specify the IP address and the port of the NEMO 794 language engine to connect separately. 796 Disconnect the connection to the NEMO language engine: 798 := Disconnect 800 The Disconnect is to remove the connection with an ID equals to 801 from the NEMO language engine. 803 5.8. Transaction Statements 805 := Transaction 806 := Commit 808 The keywords Transaction and Commit are used to tag begin and end of 809 a transaction. The code between the two key words will be 810 interpreted as a transaction and executed by the NEMO language 811 engine. 813 6. The NEMO Language Examples 815 An enterprise with geographically distributed headquarter and branch 816 sites has the requirement to dynamically balance the backup traffic. 818 In order to implement this scenario, the virtual WAN tenant creates 819 two logicnw, and generates two connections with different SLA to 820 carry diverse service flows. One connection has 100M bandwidth with 821 less than 50ms delay, which is used for normal traffic. And the 822 other connection has 40G bandwidth with less than 400ms delay, which 823 is used for backup traffic after work (from 19:00 to 23:00). With 824 self defined flow policy, the tenant can manage the connection load 825 balancing conveniently. 827 Real-time Connection 828 +--------------------+ 829 192.0.2.0/24 198.51.100.0/24 830 +---------+ +-------------+ 831 | Branch |------------------| Headquarter | 832 +---------+ +-------------+ 833 | | 834 +--------------------+ 835 Broadband Connection 837 The detailed operation and code are shown as follows. 839 o Step1: Create two virtual logicnw nodes in the WAN 841 Node "Branch" 842 Type "logicnw" 843 NW "LN-1" 844 Property "ipv4Prefix" : 192.0.2.0/24; 846 Node "Headquarter" 847 Type "logicnw" 848 NW "LN-1" 849 Property "ipv4Prefix" : 198.51.100.0/24; 851 o Step2: Connect the two virtual nodes with two virtual connections 852 with different SLA. 854 Connection "broadband_connection" 855 EndNodes "Branch", "Headquater" 856 Property "bandwidth" : 40000, "delay" : 400; 858 Connection "realtime_connection" 859 EndNodes "Branch", "Headquater" 860 Property "bandwidth" : 100, "delay" : 50; 862 o Step3: Indicate the flow to be operated. 864 Flow "flow_all" 865 Match "src_ip" : "192.0.2.0/24", "dst_ip": "198.51.100.0/24"; 867 Flow "flow_backup" 868 Match "src_ip" : "192.0.2.0/24", "dst_ip": "198.51.100.0/24", 869 "port": 55555; 871 o Step4: Apply policies to corresponding flows. 873 P1: 874 Policy "policy4all" 875 ApplyTo "flow_all" 876 Priority 200 877 Action "forward_to": "realtime_connection"; 878 P2: 879 Policy "policy4backup" 880 ApplyTo "flow_backup" 881 Priority 100 882 Condition ("time">"19:00:00") || ("time"<"23:00:00") 883 Action "forward_to": "broadband_connection"; 885 7. Security Considerations 887 Because the network customers are allowed to customize their own 888 services, they may bring potentially big impacts to a running IP 889 network. A strong user authentication mechanism is needed for the 890 northbound interface of the SDN controller. User authorization 891 should be carefully managed by the network administrator to avoid any 892 dangerous operations and prevent any abuse of network resources. 894 8. IANA Considerations 896 This memo includes no request to IANA. 898 9. Acknowledgements 900 The authors would like to thanks the valuable comments made by Wei 901 Cao, Xiaofei Xu, Fuyou Miao, Yali Zhang and Wenyang Lei. 903 This document was produced using the xml2rfc tool [RFC2629]. 905 10. Informative References 907 [Frenetic] 908 Foster, N., Harrison, R., Freedman, M., Monsanto, C., 909 Rexford, J., Story, A., and D. Walker, "Frenetic: A 910 Network Programming Languages, ICFP' 11". 912 [I-D.xia-sdnrg-service-description-language] 913 Xia, Y., Jiang, S., and S. Hares, "Requirements for a 914 Service Description Language and Design Considerations", 915 draft-xia-sdnrg-service-description-language-02 (work in 916 progress), May 2015. 918 [PBNM] Strassner, J., "Policy-Based Network Management: Solutions 919 for the Next Generation, Morgan Kaufmann Publishers Inc. 920 San Francisco, CA, USA.", 2003. 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 926 June 1999. 928 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 929 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 930 2005. 932 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 933 Network Configuration Protocol (NETCONF)", RFC 6020, 934 October 2010. 936 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 937 Bierman, "Network Configuration Protocol (NETCONF)", RFC 938 6241, June 2011. 940 [TSFNet] Yap, K., Huang, T., Dodson, B., Lam, M., and N. McKeown, 941 "Towards Software-Friendly Networks, APSys 2010, pp:49-54, 942 2010, New Delhi, India.". 944 Authors' Addresses 946 Yinben Xia (editor) 947 Huawei Technologies Co., Ltd 948 Q14, Huawei Campus, No.156 Beiqing Road 949 Hai-Dian District, Beijing, 100095 950 P.R. China 952 Email: xiayinben@huawei.com 954 Sheng Jiang (editor) 955 Huawei Technologies Co., Ltd 956 Q14, Huawei Campus, No.156 Beiqing Road 957 Hai-Dian District, Beijing, 100095 958 P.R. China 960 Email: jiangsheng@huawei.com 961 Tianran Zhou (editor) 962 Huawei Technologies Co., Ltd 963 Q14, Huawei Campus, No.156 Beiqing Road 964 Hai-Dian District, Beijing, 100095 965 P.R. China 967 Email: zhoutianran@huawei.com 969 Susan Hares 970 Huawei Technologies Co., Ltd 971 7453 Hickory Hill 972 Saline, CA 48176 973 USA 975 Email: shares@ndzh.com