Network Working Group Y. Xia Internet Draft S. Jiang Intended status: Standards Track X. Wang Expires: July 28, 2014 B. Liu Huawei Technologies January 24, 2014 Network Abstract Interface (NAI) Modeling Language draft-xia-nai-modeling-language-00.txt Abstract This document introduces a modeling language used to model network services by network operators and customers to create specific network service instances through the standardized Network Abstract Interface (NAI) and processed automatically by the network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 28, 2014. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Liu, et al. Expires July 28 2014 [Page 1] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 2. Requirements Language and Terminology ........................ 3 3. Requirements for a NAI Modeling Language ..................... 3 4. NAI Modeling Language Overview ............................... 3 5. NAI Modeling Language Syntax and Statements .................. 5 5.1. Lexical Rules ........................................... 5 5.1.1. Comments ........................................... 5 5.1.2. Tokenization ....................................... 5 5.2. Identifiers ............................................. 6 5.3. NML Statements .......................................... 6 5.4. Typedef Statements ...................................... 7 6. NAI Modeling Language Blocks Definition ...................... 7 6.1. Entity Block ............................................ 7 6.2. Capability Block ....................................... 10 6.3. User Block ............................................. 12 6.4. Service Logic Block .................................... 14 6.5. Open Profiles Block .................................... 15 7. Security Considerations ..................................... 15 8. IANA Considerations ......................................... 15 9. References .................................................. 15 9.1. Normative References ................................... 15 9.2. Informative References ................................. 15 10. Acknowledgments ............................................ 15 Authors' Addresses ............................................. 17 Liu, et al. Expires July 28, 2014 [Page 2] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 1. Introduction In [NAI-ARCH], a model-driven Network Abstract Interface architecture is described. The models are customizable through a model framework and described by network administrators using a NAI modeling language (NML), which is introduced in this document. The modeling language used to model network services by network operators or customers to create specific network service instances through the standardized Network Abstract Interface (NAI) and processed automatically by the network. 2. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words. 3. Requirements for a NAI Modeling Language For the characteristics of the NAI architecture in [NAI-ARCH], there are some requirements for the modeling language: o The language should provide different capabilities and visibility of the network for different users. o The language should be simple and easy to use for network administrators. o The syntax and keywords should be network related and intuitive. o The language should support service logic description as well as service content description. 4. NAI Modeling Language Overview NML is used to design specific model for the specific network based on the requirement of opening the network. And the specific model automatically generates specific NAI for the network. The application developer also uses NML to design service logic to access network information and functions. Liu, et al. Expires July 28, 2014 [Page 3] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 Different users can have different models to implement their customized service requirement and innovative service application. The common interface styles can be used, such as RESTFul style [RESTFUL]. An NAI model is constructed by five blocks: entity block, capability block, user block, service logic block and open profile block. The following figure depicts the relation between the blocks. +-------+ +----------------+ +-------+ | |<--->| User Block |<--->| | | | +----------------+ | | |Service| | Open | | | +----------------+ | | | Logic |<--->|Capability Block|<--->|Profile| | | +----------------+ | | | Block | || | Block | | | +----------------+ | | | |<--->| Entity Block |<--->| | +-------+ +----------------+ +-------+ Figure 1 NAI Modeling Language Blocks Entity Block: describes the network entity that is opened to the user, e.g. network device, device group, port, virtual network device and so on. The property of entity describes the static information of entity, and the statistics of entity describes the statistics and runtime information of entity. NML provides an inheritance mechanism to define the reusable information about each entity. An inherited entity can be defined in another entity to include its definition information so as to avoid repetition. Capability Block: describes the capability that is opened to the user. Capability is a set of network functions and operations that encapsulated together and provided to the users e.g. VPN. User Block: describes the information about the user group, including the basic user group information, authentication and account information. It distinguishes the user group classified profiles. Service Logic Block: describes a set of network management functions based on the user's requirement. A service logic block provides the ability to specify automatic, logic control, monitoring, configuration and maintenance for the administrator and NAI application designer. For example, a NAI application can modify the Liu, et al. Expires July 28, 2014 [Page 4] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 VPN routing automatically in response to the network load of specified network link, or configure different links for one important enterprise customer between two sites in day or night to meet the SLA requirement. A service logic block designed by one designer can be opened to others to reuse its features, improve NAI ecosystem, support and accelerate growing and innovative network applications. Open Profile Block: describes the different authorization and visibility of entity and capability opened for different user. The following section will introduce syntax and keywords for the five blocks. 5. NAI Modeling Language Syntax and Statements The NML syntax is similar to the programming languages like C because of the support of service logic. 5.1. Lexical Rules 5.1.1. Comments A comment is text that the compiler ignores but that is useful for programmers. Comments are normally used to annotate code for future reference. The compiler treats them as white space. The comment is written in one of the following ways: - The /* (slash, asterisk) characters, followed by any sequence of characters (including new lines), followed by the */ characters. This syntax is the same as ANSI C. Therefore, it is commonly called a "block comment." - The // (two slashes) characters, followed by any sequence of characters. A new line not immediately preceded by a backslash terminates this form of comment. Therefore, it is commonly called a "single-line comment." 5.1.2. Tokenization A token is the smallest element of a NML that is meaningful to the compiler. The NML parser recognizes these kinds of tokens: identifiers, keywords, literals, operators, punctuators, and other separators. A stream of these tokens makes up a translation unit. Tokens are usually separated by "white space." White space can be one or more: Blanks, Horizontal or vertical tabs, New lines, Form feeds. Liu, et al. Expires July 28, 2014 [Page 5] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 5.2. Identifiers An identifier is a sequence of characters used to denote different kinds of NML items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. Each identifier has its namespace. Each identifier is valid in a namespace that depends on the type of the NML item being defined. All identifiers defined in a namespace MUST be unique. - All entity names share the same global entity identifier namespace. - All capability names share the same global capability identifier namespace. - All user names share the same global user identifier namespace. - All service-logic-names share the same global service logic identifier namespace. - All property-names share the same identifier namespace defined in the entity's property statement. - All statistics-names share the same identifier namespace defined in the entity's statistics statement. - All para-names share the same identifier namespace defined in the capability parameters statement. - All output-names share the same identifier namespace defined in the capability outputs statement. 5.3. NML Statements A NML model file contains a sequence of statements. Each statement starts with a keyword, followed by zero or one argument, followed either by a semicolon (";") or a block of substatements enclosed within braces ("{ }"): statement = keyword [argument] (";" / "{" *statement "}") Expression statements, Selection Statements, Compound Statements, Iteration Statements are used in NML-script-logic statement body. Liu, et al. Expires July 28, 2014 [Page 6] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 5.4. Typedef Statements The typedef Statement defines a new derived type from base data type. It is followed by the derived type name immediately. - The description statement The "description" statement provides the human-readable descriptive string by the modeler for the NBI application designer to understand the new derived type. - The basetype statement The basetype statement defines the base type name from which the new type is derived. The base type can be primitive type or derived type. - The default statement The default statement defines the default value for the new derived type. There may be default value conflict between the base type and derived type. Only the default value with conforming to the type definition is valid. The valid derived type default has higher priority than that of base type. If base type is provided with default value and derived type is not, the default value of base type is used for derived type when it is valid for derived type. 6. NAI Modeling Language Blocks Definition 6.1. Entity Block Entity block contains the following statements: o Class: defines entity's classification. It is enumeration type. o Description: takes a string that contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer. o Version: defines the version number of current entity. o Import: provides a reference mechanism to refer the property and statistics information of imported entity to the importing entity. The data part of the imported data structure is stored in the imported entity. Liu, et al. Expires July 28, 2014 [Page 7] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 o Inherit: provides a include mechanism to combine the property and statistics information of inherited entity into the inheriting entity. o Property: defines a data structure of property of the entity. Its sub-statements include property-name, type, description, default. The statements (property name, type, description, default) are combined into one property data structure body. One "property" can have one or more than one property data structure body. - Property-Name: defines the name of the property item. The property name must be unique in one "property" statement. This document does not define its naming rule, but it recommends that the name should be simple, human-readable and human- understandable. - Type: defines the data type of the property in property data structure body. The built-In types and derived types can both be used. - Description: provides the human-readable descriptive information by the modeler for the NAI application designer to understand the property item in the property data structure body. - Default: defines the default value for the property item in the property data structure body. If no value for this property is provided when the entity is instantiated or data record is inserted into the entity, the default value will be used. One property data structure body can have zero or one default statement. If no default statement exists, no default value is provided. o Statistics: defines a data structure of statistics information of the entity. Its sub-statements include statistics-name, type, description, default. The statements (statistics-name, type, description, default) are combined into one statistics data structure body. One "statistics" can have one or more than one statistics data structure body. - Statistics-Name: defines the name of the statistics item. The statistics-name must be unique in one "statistics" statement. This document does not define its naming rule, but it recommends that the name should be simple, human-readable and human- understandable. - Type: defines the data type of the statistics item in the statistics data structure body. The built-In types and derived types can be used in this statement. - Description: provides the human-readable descriptive information by the modeler for the NBI application designer to understand the statistics item in the statistics data structure Liu, et al. Expires July 28, 2014 [Page 8] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 body. - Default: defines the default value for the statistics item in the statistics data structure body. If no value for this statistics item is provided when the entity is instantiated or data record is inserted into the entity, the default value will be used. One statistics data structure body can have zero or one default statement. If no default statement exists, no default value is provided. o Description: takes a string that contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer. Following is an example of entity block definition. enum class /*define some classes of entity*/ { ip_device; optical_device; ...; } entity DCI_PE // entity name { class ip_device; // class is enum type description "this is a model for DCI PE device"; version 1.0; inherit device; property { property_name loc;//the name of the property { type uchar; description "the location of the entity"; } property_name ipaddr;//the name of the property { type ulong; description "the ip address of the entity"; } ... ; } statistics { statistics_name inpacket_num;//the name of the property { type ulong; Liu, et al. Expires July 28, 2014 [Page 9] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 description "the number of the inpacket"; } ... ; } } 6.2. Capability Block Capability block contains the following statements: o Class: defines capability's classification. It is enumeration type. o Description: provides the human-readable descriptive string by the modeler for the NAI application designer to understand the capability. o Version: defines the version number of current capability. o Parameters: defines the input parameters for network to execute the capability. It provides a mean for NAI application designer to implement his special service requirement through customized network parameters in his service case. Its sub-statements include para-name, type, description, default. The statements (para-name, type, description, default) are combined into one parameters structure body. One "parameters" statement can have zero, one or more parameters structure body. - Para-Name: defines the name of the parameter. The parameters must be unique in one parameters structure body. This document does not define its naming rule, but it recommends that the name should be simple, human-readable and human-understandable. - Type: defines the data type of the parameter in the parameters structure body. The built-In types and derived types can be used in this statement. - Description: provides the human-readable descriptive information by the capability provider for the NAI application designer to understand the parameter in the parameters structure body. - Default: defines the default value for the parameter in the parameters structure body. If no value for this parameter is provided when the capability is executed, the default value will be used. One parameters structure body can have zero or one default statement. If no default statement exists, no default value is provided. o Outputs: defines the output results from network after executing the capability. It provides a mean for NAI application designer to Liu, et al. Expires July 28, 2014 [Page 10] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 get the network entity property, statistics, or other response in his service application case. Its sub-statements include output-name, type, and description. The statements (output-name, type, description) are combined into one outputs structure body. One "outputs" statement can have zero, one or more outputs structure body. - Output-Name: defines the name of the output. The output-name must be unique in one outputs structure body. This document does not define its naming rule, but it recommends that the name should be simple, human-readable and human-understandable. - Type: defines the data type of the output parameter in the outputs structure body. The built-In types and derived types can be used in this statement. - Description: provides the human-readable descriptive information by the capability provider for the NAI application designer to understand the output parameter in the outputs structure body. o Execution-Link: takes one argument of string as the name of the execution link and two other statement to define its type and description. - Type: defines the type of the execution link in the capability. It is enumeration type. - Description: provides the human-readable descriptive information by the capability provider for the NAI application designer to understand the execution link. Following is an example of capability block definition. enum class /*define some classes of capability*/ { network cap; Service cap; ...; } capability vpn // capability name { class network cap; // class is enum type description "this is a model for creating vpn capability"; version 1.0; parameter { para name pe;//the name of the property Liu, et al. Expires July 28, 2014 [Page 11] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 { type ulong; description "the IP address of the PE"; } para name connection;//the name of the property { para name src; { type ulong; description "the source ip address of the connection"; } para name dst; { type ulong; description "the destination ip address of the connection"; } ... } ... ; } output { output name http link; { type string; description "the output is a http link"; } ... } execution link { exec name exec link; { type string; description "the name of execution body"; } parameter pe; parameter connection; ... } } 6.3. User Block User block contains the following statements: Liu, et al. Expires July 28, 2014 [Page 12] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 o Usergrp: defines user group classification to which administrator wants to open entities and capabilities. The "usrgrp" statement takes one argument of string as the name of the entity and one usrgrp structure body to describe the details of the usrgrp. o Description: takes a string that contains a human-readable textual description of this definition. The text is provided in a human language (or languages) chosen by the module developer. o Information: defines a data structure of information of the usrgrp. Its sub-statements include info_name, type, description, default. The statements (info_name, type, description, default) are combined into one information data structure body. One "information" statement can have one or more than one information data structure body. - info_name: defines the name of the information item. The info_name must be unique in one "information" statement. This document does not define its naming rule, but it recommends that the name should be simple, human-readable and human- understandable. - type: defines the data type of the information in information data structure body. The built-In types and derived types can be used in this statement. - default: defines the default value for the information item in the information data structure body. If no value for this information is provided when the usrgrp is instantiated or data record is inserted into the usrgrp, the default value will be used. One information data structure body contains zero or one default statement. If no default statement exists, no default value is provided. o Authentication: defines the authentication mode of the usrgrp, which is followed by an "enum" variable. So administrator needs to define all the allowed authentication mode with an "enum" variable ahead. o Charge: defines the charge mode of the usrgrp, which is followed by an "enum" variable. So administrator needs to define all the allowed charge mode with an "enum" variable ahead. Following is an example of user block definition. enum authes { Liu, et al. Expires July 28, 2014 [Page 13] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 non; ipsec; ...; } enum charges { buflow; plan1; ...; } usergrp OTT user // usergrp { description "this is a model for OTT user"; information { info name name;//the name of the property { type uchar; description "the name of the entity"; } ... ; } authentication authes; charge charges; } 6.4. Service Logic Block Service logic block contains the following statements: o Selection: mainly includes "if-else" and "switch". o Expression: causes expressions to be evaluated. No transfer of control or iteration takes place as a result of an expression statement. o Compound statement consists of zero or more statements. A compound statement can be used anywhere a statement is expected. o Iteration: causes statements (or compound statements) to be executed zero or more times, subject to some loop-termination criteria. When these statements are compound statements, they are executed in order. NML provides three iteration statements -"while", "do" and "for". Liu, et al. Expires July 28, 2014 [Page 14] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 o Break: causes the innermost enclosing loop or a switch statement to exit immediately. o Continue: is similar to the "break" statement. Instead of exiting a loop, however, "continue" restarts a loop in a new iteration. o Operators: NML support binary arithmetic operators, assignment operators, comparison operators, bitwise operators and string operators. (An example needs to be filled in the future.) 6.5. Open Profiles Block The open model is a bit map which the manager pictures based on open requirements, which is fixed and needn't to be modeled. 7. Security Considerations Since customers can order services directly through the NAI interface, authentication and authorization is strongly needed. 8. IANA Considerations None. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [NAI-ARCH]Xia Y., Jiang S., and X. Wang, "Customizable Network Abstract Interface (NAI) Architecture based on Model Description", Work in Progress, January 2014 [RESTFUL] Roy Thomas Fielding, "Architectural Styles and the Design of Network-based Software Architectures", http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_ar ch_style.htm, 2000 10. Acknowledgments Valuable comment was received from Brian E Carpenter. Liu, et al. Expires July 28, 2014 [Page 15] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 This document was prepared using 2-Word-v2.0.template.dot. Liu, et al. Expires July 28, 2014 [Page 16] Internet-Draft draft-xia-nai-modeling-language-00 January 2014 Authors' Addresses Yinben Xia (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: xiayinben@huawei.com Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Xuewei Wang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: wangxuewei@huawei.com Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: leo.liubing@huawei.com