Internet DRAFT - draft-xia-customizable-nai-arch

draft-xia-customizable-nai-arch







Internet Engineering Task Force                              Y. Xia, Ed.
Internet-Draft                                             S. Jiang, Ed.
Intended status: Standards Track                                 X. Wang
Expires: July 27, 2014                      Huawei Technologies Co., Ltd
                                                        January 23, 2014


  Customizable Network Abstract Interface (NAI) Architecture based on
                           Model Description
                   draft-xia-customizable-nai-arch-00

Abstract

   The more and more complicated ISP networks are required a new
   interaction mechanism between their customers and their networks.  A
   flexible Network Abstract Interface (NAI) is needed to provide
   abstracted network information and capability to network customers
   and receive customized orders from them.  This document introduces an
   architecture that allows network administrators to create their
   specific Network Abstract Interface.

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 27, 2014.

Copyright Notice

   Copyright (c) 2014 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



Xia, et al.               Expires July 27, 2014                 [Page 1]

Internet-DraftCustomizable Network Abstract Interface Arch  January 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements for Network Abstract Interface . . . . . . . . .   3
     3.1.  Abstracted Network Level Information  . . . . . . . . . .   3
     3.2.  Support Classified User Profile . . . . . . . . . . . . .   4
     3.3.  Support Interface Customizable  . . . . . . . . . . . . .   4
     3.4.  Support Services-Oriented Description . . . . . . . . . .   4
   4.  A Flexible Model Architecture for NAI . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The IP networks of Internet Service Providers (ISPs) are becoming
   more and more big and complicated.  Simultaneously, the services that
   are demanded by their customers, particularly the upper layer
   applications, are also becoming more and more complicated.  The
   rigescent service models are lacking the flexibility to meet the
   various requirements/scenarios.

   A better form would be that the network customers are allowed to
   customize their own services as they need.  It would be based on and
   limited by the open data from ISPs.

   However, the ISP would not open their capability right of network
   devices directly.  It is preferred only abstracted (filtered) network
   information and capability and control right are opened based on user
   authorization.  This is also preferred by the network customers
   because this can hide complexity of networks and release them from
   the burden of selecting useful information and capability from vast
   information and capability of the infrastructure network.

   So, it is an efficient mechanism to create a Network Abstract
   Interface (NAI) between the ISPs and their customers.  A concrete NAI
   is unique to a particular network and in accordance with the demands
   of the network administrator, it enables network customers to get
   abstracted network information, execute network capability and deploy
   service logic to network, based on their authorization.



Xia, et al.               Expires July 27, 2014                 [Page 2]

Internet-DraftCustomizable Network Abstract Interface Arch  January 2014


   This document introduces an architecture that allows network
   administrators to customize their specific Network Abstract
   Interface.  It is flexible enough to support various network
   structures.  The interaction between the NAI and the ISP
   infrastructure network, such as how the information and capability of
   infrastructure network are abstracted, how network capability are
   executed and how the service logic are translated, are out of scope
   of this document.

2.  Terminology

   Network Abstract Interface (NAI)  An interactive interface between
        network and their customers.  It provides network abstracted
        information and capability distinguished by user authorization.
        It receives the customer order in both data form or service
        logic form.

   NAI Model  The concrete description of a specific NAI, which defines
        the results of abstracted network information and capability.  A
        model that is used to generate the open NAI.

   NAI Modeling Language  A modeling language used to describe a
        specific NAI Model by the network administrators.

   NAI User Instance  A set of data collection for a certain user or
        user class.  It contains all abstracted network information and
        capability that would open to this user or user class.

3.  Requirements for Network Abstract Interface

   The purpose of the Network Abstract Interface is to provide enough
   information and capability, while excrescent information and
   capability are filtered for the network customers in order to enable
   them to create their customized network services, which meet their
   unique demands.

3.1.  Abstracted Network Level Information

   The detailed information and capability of network devices are
   enormous.  Most of them are irrelevant to network customers.  It
   would be a huge burden if network customers have to select useful
   information and capability from the vast information and capability
   of the infrastructure network.

   On another side, the ISPs also do not want to open their control all
   their network information and capability.  The direct control right
   of network devices should also be remain on the ISPs in order to
   prevent any abusing of network resources.



Xia, et al.               Expires July 27, 2014                 [Page 3]

Internet-DraftCustomizable Network Abstract Interface Arch  January 2014


   On behalf of both network operators and their customers, it is
   preferred only abstracted (filtered) network level information and
   capability, and only authorized control that network customers can
   perform, are open.

3.2.  Support Classified User Profile

   ISPs have many different customers, which may have different
   authorization.  The NAI should be able to distinguish them.
   Different customers should access to different information and
   capability according to their different authorization.
   Correspondently, the capability rights of different customers or
   customer classes are also distinguished.

3.3.  Support Interface Customizable

   Every ISP networks are different.  Any rigescent interfaces or
   interface models would not be able to meet the various network
   structures and various management requirements of network operators.

   The way that a specific NAI is created should be flexible to be able
   to adapt any ISP network.  It should be able to support the network
   administrators to create and manage easily with the ability to
   support any kind requirements.  The network administrators should
   also be allowed to manage or modify their NAI in running time.

3.4.  Support Services-Oriented Description

   The network administrators are responsible to describe a few services
   or service templates for network customers to select.  These services
   or service templates may allow complex logic.  The NAI should be able
   to understand these service logic and express them within NAI user
   instances.

   On another side, the demanded services from network customers are
   various.  New services or demands may appear in the future.  The NAI
   should be flexible enough to allow all these customer defined
   services.  Therefore, some customer demands may be expressed as logic
   orders rather than any rigescent data forms.  The NAI should be able
   to understand these logic order and resolve them into network
   configuration or network function executing.  Furthermore, the whole
   process should be automatic completed without requesting for human
   intelligence.  Support Customer Defined Services and Logic Order








Xia, et al.               Expires July 27, 2014                 [Page 4]

Internet-DraftCustomizable Network Abstract Interface Arch  January 2014


4.  A Flexible Model Architecture for NAI

   This document introduces an architecture that allows network
   administrators to customize their specific Network Abstract
   Interface.  This architecture are designed to meet the abovementioned
   requirements.  It is flexible enough to support various network
   structures.

     +--------------------------+
     |   APP/Customer Operator  |
     +--------------------------+
          /\           ||
          ||     Logical Order
          ||     or Data Order
          ||           ||
          ||           \/
     +--------------------------+
     |Network Abstract Interface|
     +--------------------------+
     |      The NAI Model       |<------+ NAI
     +--------------------------+       | Modeling
              /\     ||                 | Language
              ||     \/             +-------------+
              /   |   \             |Network Admin|
             /    |    \            +-------------+
            /     |     \
   Network Level Information & Capability
           |      |      |
      +-----------------------+
      |   Network  & Devices  |
      +-----------------------+

   This architecture uses model description to constructe customizable
   Network Abstract Interface (NAI).

   Firstly, the network administrator designs a specific NAI model for
   his specific network based on its open requirements, which stipulates
   the openness of network abstracted network information, capability
   and services based on the user authorizations and their authorized
   operations.  The network administrator describes this model using NAI
   modeling language [I-D.xia-nai-modeling-language], which are
   specifically designed for the NAI generation purpose.

   Secondly, the NAI model is filled with the collected and abstracted
   network information, capability and services to form a specific NAI
   instance, which is available for network customers to interact with.
   This process should be as automatic as possible, though some human
   intervence and intelligence may be needed.



Xia, et al.               Expires July 27, 2014                 [Page 5]

Internet-DraftCustomizable Network Abstract Interface Arch  January 2014


   Then, the network customers can obtain their abstracted network
   information and capability, including their authorized purviews.  The
   network customers can make their service orders, depending on their
   specific authorizations.  The service orders may also be described
   using the NAI modeling language.  The communication/transport between
   NAI and network customers may use HTTP[RFC2616], or its successor.

   Note: the network administrators can incrementally manage or modify
   the NAI model, consequently manage or modify the specific NAI
   instance, in running time by descriptions in the NAI modeling
   language.

   Note: the interaction between the NAI model and the ISP
   infrastructure network, such as how the information and capability of
   infrastructure network are abstracted, how network capability are
   executed and how the service logic are translated, are out of scope
   of this document.  They may be completed by various network elements,
   such as SDN controller, or network management system, etc. which are
   also out of scope.

5.  Security Considerations

   Because the network customers are allowed to customize their own
   services, they may bring potentially big impacts to a running ISP
   network.  A strong user authentication mechanism is needed for the
   Network Abstract Interface.  User authorization should be carefully
   managed by the network administrator to avoid any dangerous
   operations and prevent any abusing of network resources.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Acknowledgements

   The authors would like to thanks the valuable comments made by
   Xiaofei Xu, Fuyou Miao and Wenyang Lei.

   This document was produced using the xml2rfc tool [RFC2629].

8.  Informative References

   [I-D.xia-nai-modeling-language]
              Xia, Y., Jiang, S., Wang, X., and B. Liu, "Network
              Abstract Interface (NAI) Modeling Language, draft-xia-nai-
              modeling-language-00, Working in progress", January 2014.





Xia, et al.               Expires July 27, 2014                 [Page 6]

Internet-DraftCustomizable Network Abstract Interface Arch  January 2014


   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

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

















Xia, et al.               Expires July 27, 2014                 [Page 7]