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]
