[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/