idnits 2.17.00 (12 Aug 2021) /tmp/idnits9918/draft-xia-sdnrg-nemo-language-01.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 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2014) is 2763 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) == Outdated reference: A later version (-02) exists of draft-xia-sdnrg-service-description-language-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG Y. Xia, Ed. 3 Internet-Draft S. Jiang, Ed. 4 Intended status: Standards Track T. Zhou, Ed. 5 Expires: April 30, 2015 S. Hares 6 Huawei Technologies Co., Ltd 7 October 27, 2014 9 NEMO (NEtwork MOdeling) Language 10 draft-xia-sdnrg-nemo-language-01 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 30, 2015. 40 Copyright Notice 42 Copyright (c) 2014 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. Link 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.sdnrg-service-description-language] describe the requirements 121 for a service description language and the design 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 simply 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. Although it is extensible for more data 195 modeling in addition to NETCONF, YANG is not capable of describing 196 high level network requirements, such as SLA (Service Level 197 Agreement). YANG is designed for north-bound interfaces of the 198 device, which is also the south-bound of the controller. It is not 199 proper to model the north-bound interface of the controller, aka the 200 NBI. Moreover, the YANG is not capable of describing the service 201 processing logic, which typically includes transition of conditions 202 and states. 204 UML (Unified Modeling Language) is a powerful modeling language, 205 which is domain agnostic. It is hard to describe the network demand, 206 and cannot be embedded in network applications. UML is appropriate 207 to describe the model behind the NBI language not the NBI itself. 209 With the emergence of the SDN concept, it is a consensus to simplify 210 the network operation, which leads to many cutting-edge explorations 211 in the academic area. 213 Nick McKeown from Stanford University proposed the SFNet [TSFNet], 214 which translated the high level network demand to the underlying 215 controller interfaces. By concealing the low level network details, 216 the controller simplified the operation of resource, flow, and 217 information for applications. The SFNet is used for the SDN 218 architecture design, and does not go into the NBI design. 220 Jennifer from Princeton University designed the Frenetic [Frenetic] 221 based on the OpenFlow protocol. It is an advanced language for flow 222 programming, and systematically defines the operating model and mode 223 for the flow. However, the network requirement from the service is 224 not only the flow operations, but also includes operations of 225 resource, service conditions, and service logic. 227 In the book [PBNM], John Strassner defined the policy concept and 228 proposed the formal description for network operations by using the 229 policy. The method for querying network information is absent in the 230 book. Virtual tenant network and operations to the tenant network 231 are not considered. 233 All these investigations direct to the future SDN that use simple and 234 intuitive interfaces to describe the network demands without complex 235 programming. 237 5. The NEMO Language Specifications 239 NEMO language is a domain specific language (DSL) based on 240 abstraction of network models and conclusion of operation patterns. 241 It provides NBI fashion in the form of language. Instead of tons of 242 abstruse APIs, with limited number of key words and expressions, NEMO 243 language enables network users/applications to describe their demands 244 for network resources, services and logical operations in an 245 intuitive way. And finally the NEMO language description can be 246 explained and executed by a language engine. 248 5.1. Network Model of the NEMO Language 250 Behind the NEMO language, there is a set of basic network models 251 abstracting the network demands from the top down according to the 252 service requirement. Those demands can be divided into two types: 253 the demand for network resources and the demands for network 254 behaviors. 256 The network resource is composed of three kinds of entities: node, 257 link and flow. Each entity contains property and statistic 258 information. With a globally unique identifier, the network entity 259 is the basic object for operation. 261 o Node model: describes the entity with the capability of packet 262 processing. According to the functionality, there are three types 263 of node 265 * The forwarding node (FN) only deals with L2/3 forwarding. It 266 forwards packets according to the forwarding table and modifies 267 packet heads. 269 * The processing node (PN) provides L4-7 network services, and 270 will modify the body of packets. 272 * The logical node (LN) describes a set of network elements and 273 their links, such as subnet, autonomous system, and internet. 274 It conceals the internal topology and exposes properties as one 275 entity. It also enables iteration, i.e., a network entity may 276 include other network entities. 278 o Link model: describes the connectivity between node entities. 280 o Flow model: describes a sequence of packets with certain common 281 characters, such as source/destination IP address, port, and 282 protocol. From the northbound perspective, flow is the special 283 traffic with user concern, which may be per device or across many 284 devices. So the flow characters also include ingress/egress node, 285 and so on. 287 Network behavior includes the information and control operations. 289 The information operation provides two methods to get the network 290 information for users. 292 o Query: a synchronous mode to get the information, i.e., one can 293 get the response when a request is sent out. 295 o Notification: an asynchronous mode to get the information, i.e., 296 with one request, one or multiple responses will be sent to the 297 subscriber automatically whenever trigger conditions meet. 299 The NEMO language uses policy to describe the control operation. 301 o Policy: control the behavior of specific entities by APP, such as 302 flow policy, node policy. All the policies follow the same 303 pattern "with , to execute ", and can be 304 applied to any entity. 306 5.2. Notation 308 The syntactic notation used in this specification is an extended 309 version of BNF ("Backus Naur Form" or "Backus Normal Form"). In BNF, 310 each syntactic element of the language is defined by means of a 311 production rule. This defines the element in terms of a formula 312 consisting of the characters, character strings, and syntactic 313 elements that can be used to form an instance of it. The version of 314 BNF used in this specification makes use of the following symbols: 316 < > 318 Angle brackets delimit character strings that are the names of 319 syntactic elements. 321 ::= 323 The definition operator. This is used in a production rule to 324 separate the element defined by the rule from its definition. The 325 element being defined appears to the left of the operator and the 326 formula that defines the element appears to the right. 328 [ ] 330 Square brackets indicate optional elements in a formula. The portion 331 of the formula within the brackets may be explicitly specified or may 332 be omitted. 334 { } 336 Braces group elements in a formula. The portion of the formula 337 within the braces shall be explicitly specified. 339 | 341 The alternative operator. The vertical bar indicates that the 342 portion of the formula following the bar is an alternative to the 343 portion preceding the bar. If the vertical bar appears at a position 344 where it is not enclosed in braces or square brackets, it specifies a 345 complete alternative for the element defined by the production rule. 346 If the vertical bar appears in a portion of a formula enclosed in 347 braces or square brackets, it specifies alternatives for the contents 348 of the innermost pair of such braces or brackets. 350 !! 352 Introduces ordinary English text. This is used when the definition 353 of a syntactic element is not expressed in BNF. 355 5.3. NEMO Language Overview 357 NEMO language provides 5 classes of commands: model definition, 358 resource access, behavior, connection management, transaction to 359 facilitate the user intent description. 361 := | | 362 363 := | | 364 | 365 := | | | 366 | | 367 := | | | 368 | 369 := | 370 := | 372 NEMO language provides limited number of key words to enables network 373 users/applications to describe their intent. The key words supported 374 by the language are as follows: 376 := Boolean | Integer | String | Date | UUID | EthAddr | 377 IPPrefix | NodeModel | LinkModel | FlowModel | 378 ActionModel | Description | Porperty | Node | Link| 379 Flow | No | EndNodes | Type | NW | Match | List | 380 Range| Query | From | Notification | Listener | 381 Policy | ApplyTo | Priority | Condition | Action | 382 Connect | Disconnect | Address | Port | Transaction | 383 Commit 385 5.4. Model Definition 387 5.4.1. Data Types 389 NEMO language provides several build-in data types: 391 Boolean This data type is used for simple flags that track true/ 392 false conditions. There are only two possible values: true and 393 false. The Boolean literal is represented by the token . 395 Integer A number with an integer value, within the range from 396 -(2^63) to +(2^63)-1. The Integer literal is represented by the 397 token . 399 String A sequence of characters. The string is always in the 400 quotation marks. The String literal is represented by the token 401 . 403 Date A string in the format yyyy-mm-dd hh:mm:ss, or yyyy-mm-dd, or 404 hh:mm:ss. The Date literal is represented by the token . 406 UUID A string in the form of Universally Unique IDentifier 407 [RFC4122], e.g. "6ba7b814-9dad-11d1-80b4-00c04fd430c8". A 408 typical usage of the UUID is to identify network entities, 409 policies, actions and so on. The UUID literal is represented by 410 the token . 412 EthAddr A string in the form of MAC address, e.g. 413 "00:00:00:00:00:01". The EthAddr literal is represented by the 414 token . 416 IPPrefix A string in the form of IP address, e.g. "10.0.1.1". The 417 mask can be used in the IP address description, e.g. 418 "10.0.1.0/24". The IPPrefix literal is represented by the token 419 . 421 The token can be defined as follows: 423 := Boolean | Integer | String | Date | UUID | 424 EthAddr | IPPrefix 426 And a generic literal is represented by the token 428 := | | | | | 429 | 431 5.4.2. Model Definition and Description Statement 433 In addition to default build-in network models, NEMO language 434 facilitates users to define new model types. 436 The token is a string that must start with a letter and 437 followed by any number of letters and digits. More specific naming 438 can be defined as follows: 440 := !!type name of the node model 441 := !!type name of the link model 442 := !!type name of the flow model 443 := | | 444 := !!type name of the action model 445 := | 446 := !!name of the property in a model 448 The statement is used to create a node model: 450 := NodeModel 451 Property { : }; 453 The NodeModel specifies a new node type. 455 The Property is followed by a list of " : " 456 pairs to specify properties for the new node type. Since belonging 457 network is the intrinsic property for a node model, there is no need 458 to redefine the belonging network in the property list. 460 Example: 462 NodeModel "DPI" Property String : "name", Boolean : "is_enable"; The 463 statement generates a new node model named DPI with two properties, 464 "name" and "is_enable". 466 The statement is used to create a link model: 468 := LinkModel 469 Property { : }; 471 The LinkModel specifies a new link type. 473 The Property is followed by a list of " : " 474 pairs to specify properties for the new link type. Since end nodes 475 are intrinsic properties for a link model, there is no need to 476 redefine the end nodes in the property list. 478 The statement is used to create a flow model: 480 := FlowModel 481 Property { : }; 483 The FlowModel specifies a new flow type. 485 The Property is followed by a list of " : " 486 pairs to specify fields for the new flow type. The 487 statement is used to create an action model: 489 := ActionModel 490 Property { : }; 492 The ActionModel specifies a new action type. 494 The Property is followed by a list of " : " 495 pairs to specify properties for the new action. 497 NEMO language also supports querying the description of a defined 498 model by using the statement: 500 := Description ; 502 The keyword Description is follow by a model type name. The 503 description of the queried model will return from the language 504 engine. 506 5.5. Resource Access Statements 508 In NEMO language, each resource entity instance is identified by a 509 . We use the following token to indicate the identifier given 510 to the resource entity instance. 512 := !! name to identify the node instance 513 := !! name to identify the link instance 514 := !! name to identify the flow instance 515 := || 517 5.5.1. Node Operations 519 The statement is used to create or update a node instance: 521 := Node Type 522 NW 523 [Property {: }]; 525 The Node is followed by a user specified . If the 526 is new in the system, a new node will be created automatically. 527 Otherwise, the corresponding node identified by will be 528 updated with the following information. 530 The Type specifies the type of the node to operate. 532 The NW specifies the dependence where the node is located. 534 The Property is an optional keyword followed by a list of 535 ": " pairs. Multiple ": 536 " pairs are separated by commas. The must be 537 selected from the property definition of the corresponding node 538 definition. 540 Node "switch-1" 541 Type "switch" 542 NW "LN-1" 543 Property "ip_version" : 4; 545 The statement creates a switch type node that is located in the 546 logical network "LN-1". 548 The statement is used to delete a node instance: 550 := No Node ; 552 The No Node is to delete a node in user's network. 554 5.5.2. Link Operations 556 The statement is used to create or update a link: 558 := Link 559 EndNodes , 560 [Property {: }]; 562 The Link is followed by a user specified . If the 563 is new in the system, a new link will be created automatically. 565 Otherwise, the corresponding link identified by the will be 566 updated with the following information. 568 The EndNodes specifies the two end nodes, identified by " 569 : ", of a link. The Property is an optional keyword 570 followed by a list of ": " pairs. Multiple 571 ": " pairs are separated by commas. The 572 must be selected from the property definition of the 573 corresponding link definition. 575 Example: 577 Link "link-1" 578 EndNodes "S1", "S2" 579 Property "bandwidth" : 1000, "delay" : 40; 581 The statement creates a link between two nodes, and sets the link 582 property. 584 The statement is used to delete a node instance: 586 := No Link ; 588 The No Link is to delete a link in user's network. 590 5.5.3. Flow Operations 592 The statement is used to create or update a flow: 594 := Flow Match {: 595 | Range (, ) 596 | List({})} 598 The Flow is followed by a user defined . If the 599 is new in the system, a new flow will be created automatically. 600 Otherwise, the corresponding flow identified by the will be 601 updated with the following information. 603 The Match specifies a flow by indicate match fields. NEMO language 604 also provides two keywords to assist the expression of values: 606 o The List is used to store a collection of data with the same data 607 type. 609 o The Range is used to express a range of values. 611 Example: 613 Flow "flow-1" 614 Match "src_ip" : Range ("192.168.1.1", "192.168.1.243"); 616 The statement describes a flow with the source IP address ranging 617 from 192.168.1.1 to 192.168.1.243. 619 The statement is used to delete a flow instance: 621 := No Flow ; 623 The No Flow is to delete a flow in user's network. 625 5.6. Behavior Statements 627 5.6.1. Query Behavior 629 The query statement is to retrieve selected data from specified model 630 object. 632 The generate a query: 634 := Query {} 635 From {|} 637 The Query is followed by one or more s which are 638 defined properties of the object to be queried. 640 The From is followed by the one or more queried objects. NENO 641 language support query operation to network entities and the policy. 643 5.6.2. Policy Behavior 645 In NEMO language, each policy instance is identified by a 647 := !! name to identify the policy instance 649 Create and update a policy 651 := Policy ApplyTo 652 Priority 653 [Condition {}] 654 Action { : {}}; 656 The Policy is followed by a user defined . If the 657 is new in the system, a new policy will be created 658 automatically. Otherwise, the corresponding notification identified 659 by the will be updated with the following information. 661 The ApplyTo specifies the entity to which the policy will apply. 663 The Priority specifies the globe priority of the policy in the tenant 664 name space. The with lower number has a higher priority, 665 i.e. priority 0 holds the highest priority. 667 The Condition is an optional keyword follow by an expression. It 668 tells your program to execute the following actions only if a 669 particular test described by the expression evaluates to true. A 670 NEMO language expression is a construct made up of variables, 671 operators, and method invocations, which are constructed according to 672 the syntax of the language and evaluates to a single value. NEMO 673 language supports many operators to facilitate the construction of 674 expressions. Assume variable A holds 10 and variable B holds 0, 675 then: 677 +----------+----------------------------------------------+---------+ 678 | Operator | Description | Example | 679 +----------+----------------------------------------------+---------+ 680 | && | Called Logical AND operator. If both the | (A && | 681 | | operands are non-zero, then the condition | B) is | 682 | | becomes true. | false. | 683 | || | Called Logical OR Operator. If any of the | (A || | 684 | | two operands are non-zero, then the | B) is | 685 | | condition becomes true. | true. | 686 | ! | Called Logical NOT Operator. Use to reverses | !(A && | 687 | | the logical state of its operand. If a | B) is | 688 | | condition is true then Logical NOT operator | true. | 689 | | will make false. | | 690 | == | Checks if the values of two operands are | (A == | 691 | | equal or not, if yes then condition becomes | B) is | 692 | | true. | not | 693 | | | true. | 694 | != | Checks if the values of two operands are | (A != | 695 | | equal or not, if values are not equal then | B) is | 696 | | condition becomes true. | true. | 697 | > | Checks if the value of left operand is | (A > B) | 698 | | greater than the value of right operand, if | is not | 699 | | yes then condition becomes true. | true. | 700 | >= | Checks if the value of left operand is | (A >= | 701 | | greater than or equal to the value of right | B) is | 702 | | operand, if yes then condition becomes true. | not | 703 | | | true. | 704 | < | Checks if the value of left operand is less | (A < B) | 705 | | than the value of right operand, if yes then | is | 706 | | condition becomes true. | true. | 707 | <= | Checks if the value of left operand is less | (A <= | 708 | | than or equal to the value of right operand, | B) is | 709 | | if yes then condition becomes true. | true. | 710 +----------+----------------------------------------------+---------+ 712 The Action specifies the execution when conditions meet. 714 Example: 716 Policy "policy-1" 717 ApplyTo "flow-1" 718 Priority 100 719 Condition ("time">"18:00") || ("time"<"21:00") 720 Action "gothrough" : List( "switch-1" , "switch-2"); 722 The statement creates a policy which indicates the flow to go through 723 two specified switches from 18:00 to 21:00. 725 Delete a policy: 727 := No Policy ; 729 The No Policy is to delete a policy in user's network. 731 5.6.3. Notification Behavior 733 In NEMO language, each notification instance is identified by a 734 736 := !! name to identify the notification 737 instance 739 Create and update a notification 741 := Notification 742 [(Query {} 743 From {})] 744 Condition {} 745 Listener ; 747 The Notification is followed by a user defined . If 748 the is new in the system, a new notificaiton will 749 be created automatically. Otherwise, the corresponding notification 750 identified by the will be updated with the 751 following information. 753 The Query clause is nested in the notification statement to indicate 754 the information acquisition. 756 The Condition clause is the same as in policy statement, which 757 triggers the notification. 759 The Listener specifies the callback function that is used to process 760 the notification. 762 Delete a notification: 764 := No Notification ; 766 The No Notification is to delete a notification in user's network. 768 5.7. Connection Management Statements 770 In NEMO language, each connection instance is identified by a 771 772 := !! name to identify the connection instance 774 Setup a connection to the NEMO language engine: 776 := Connect Address 777 Port 779 The Connect is followed by a user defined . If the 780 is new in the system, a new connection will be created 781 automatically. Otherwise, the corresponding connection identified by 782 will be updated with the following information. 784 The Address and Prot specify the IP address and the port of the NEMO 785 language engine to connect separately. 787 Disconnect the connection to the NEMO language engine: 789 := Disconnect 791 The Disconnect is to remove the connection with an ID equals to 792 from the NEMO language engine. 794 5.8. Transaction Statements 796 := Transaction 797 := Commit 799 The keywords Transaction and Commit are used to tag begin and end of 800 a transaction. The code between the two key words will be 801 interpreted as a transaction and executed by the NEMO language 802 engine. 804 6. The NEMO Language Examples 806 An enterprise with geographically distributed headquarter and branch 807 sites has the requirement to dynamically balance the backup traffic. 809 In order to implement this scenario, the virtual WAN tenant creates 810 two routers, and generates two links with different SLA to carry 811 diverse service flows. One link has 100M bandwidth with less than 812 50ms delay, which is used for normal traffic. And the other link has 813 40G bandwidth with less than 400ms delay, which is used for backup 814 traffic after work (from 19:00 to 23:00). With self defined flow 815 policy, the tenant can manage the link load balancing conveniently. 817 Real-time Link 818 +-------------+ 819 10.0.1.0/24 | | 20.0.1.0/24 820 +---------+ +----+ +----+ +-------------+ 821 | Branch |------| R1 | | R2 |------| Headquarter | 822 +---------+ +----+ +----+ +-------------+ 823 | | 824 +-------------+ 825 Broadband Link 827 The detailed operation and code are shown as follows. 829 o Step1: Create two virtual switch nodes in the WAN 831 Node "R1" 832 Type "router" 833 NW "LN-1" 834 Property "ip_version" : 4; 836 Node "R2" 837 Type "router" 838 NW "LN-1" 839 Property "ip_version" : 4; 841 o Step2: Connect the two virtual nodes with two virtual links with 842 different SLA. 844 Link "broadband_link" 845 EndNodes "R1", "R2" 846 Property "bandwidth" : 40000, "delay" : 400; 848 Link "realtime_link" 849 EndNodes "R1", "R2" 850 Property "bandwidth" : 100, "delay" : 50; 852 o Step3: Indicate the flow to be operated. 854 Flow "flow_all" 855 Match "src_ip" : "10.0.1.0/24", "dst_ip": "10.0.1.0/24"; 857 Flow "flow_backup" 858 Match "src_ip" : "10.0.1.0/24", "dst_ip": "20.0.1.0/24", 859 "port": 55555; 861 o Step4: Apply policies to corresponding flows. 863 P1: 864 Policy "policy4all" 865 ApplyTo "flow_all" 866 Priority 200 867 Action "forward_to": "realtime_link"; 868 P2: 869 Policy "policy4backup" 870 ApplyTo "flow_backup" 871 Priority 100 872 Condition ("time">"19:00:00") || ("time"<"23:00:00") 873 Action "forward_to": "broadband_link"; 875 7. Security Considerations 877 Because the network customers are allowed to customize their own 878 services, they may bring potentially big impacts to a running IP 879 network. A strong user authentication mechanism is needed for the 880 northbound interface of the SDN controller. User authorization 881 should be carefully managed by the network administrator to avoid any 882 dangerous operations and prevent any abuse of network resources. 884 8. IANA Considerations 886 This memo includes no request to IANA. 888 9. Acknowledgements 890 The authors would like to thanks the valuable comments made by Wei 891 Cao, Xiaofei Xu, Fuyou Miao and Wenyang Lei. 893 This document was produced using the xml2rfc tool [RFC2629]. 895 10. Informative References 897 [Frenetic] 898 Foster, N., Harrison, R., Freedman, M., Monsanto, C., 899 Rexford, J., Story, A., and D. Walker, "Frenetic: A 900 Network Programming Languages, ICFP' 11", . 902 [I-D.sdnrg-service-description-language] 903 Xia, Y., Jiang, S., and S. Hares, "Requirements for a 904 Service Description Language and Design Considerations, 905 draft-xia-sdnrg-service-description-language-00, Work in 906 progress", July 2014. 908 [PBNM] Strassner, J., "Policy-Based Network Management: Solutions 909 for the Next Generation, Morgan Kaufmann Publishers Inc. 910 San Francisco, CA, USA.", 2003. 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, March 1997. 915 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 916 June 1999. 918 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 919 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 920 2005. 922 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 923 Network Configuration Protocol (NETCONF)", RFC 6020, 924 October 2010. 926 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 927 Bierman, "Network Configuration Protocol (NETCONF)", RFC 928 6241, June 2011. 930 [TSFNet] Yap, K., Huang, T., Dodson, B., Lam, M., and N. McKeown, 931 "Towards Software-Friendly Networks, APSys 2010, pp:49-54, 932 2010, New Delhi, India.", . 934 Authors' Addresses 936 Yinben Xia (editor) 937 Huawei Technologies Co., Ltd 938 Q14, Huawei Campus, No.156 Beiqing Road 939 Hai-Dian District, Beijing, 100095 940 P.R. China 942 Email: xiayinben@huawei.com 944 Sheng Jiang (editor) 945 Huawei Technologies Co., Ltd 946 Q14, Huawei Campus, No.156 Beiqing Road 947 Hai-Dian District, Beijing, 100095 948 P.R. China 950 Email: jiangsheng@huawei.com 951 Tianran Zhou (editor) 952 Huawei Technologies Co., Ltd 953 Q14, Huawei Campus, No.156 Beiqing Road 954 Hai-Dian District, Beijing, 100095 955 P.R. China 957 Email: zhoutianran@huawei.com 959 Susan Hares 960 Huawei Technologies Co., Ltd 961 7453 Hickory Hill 962 Saline, CA 48176 963 USA 965 Email: shares@ndzh.com