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]