idnits 2.17.1 draft-xia-customizable-nai-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2014) is 3743 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Xia, Ed. 3 Internet-Draft S. Jiang, Ed. 4 Intended status: Standards Track X. Wang 5 Expires: July 27, 2014 Huawei Technologies Co., Ltd 6 January 23, 2014 8 Customizable Network Abstract Interface (NAI) Architecture based on 9 Model Description 10 draft-xia-customizable-nai-arch-00 12 Abstract 14 The more and more complicated ISP networks are required a new 15 interaction mechanism between their customers and their networks. A 16 flexible Network Abstract Interface (NAI) is needed to provide 17 abstracted network information and capability to network customers 18 and receive customized orders from them. This document introduces an 19 architecture that allows network administrators to create their 20 specific Network Abstract Interface. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 27, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Requirements for Network Abstract Interface . . . . . . . . . 3 59 3.1. Abstracted Network Level Information . . . . . . . . . . 3 60 3.2. Support Classified User Profile . . . . . . . . . . . . . 4 61 3.3. Support Interface Customizable . . . . . . . . . . . . . 4 62 3.4. Support Services-Oriented Description . . . . . . . . . . 4 63 4. A Flexible Model Architecture for NAI . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Informative References . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The IP networks of Internet Service Providers (ISPs) are becoming 73 more and more big and complicated. Simultaneously, the services that 74 are demanded by their customers, particularly the upper layer 75 applications, are also becoming more and more complicated. The 76 rigescent service models are lacking the flexibility to meet the 77 various requirements/scenarios. 79 A better form would be that the network customers are allowed to 80 customize their own services as they need. It would be based on and 81 limited by the open data from ISPs. 83 However, the ISP would not open their capability right of network 84 devices directly. It is preferred only abstracted (filtered) network 85 information and capability and control right are opened based on user 86 authorization. This is also preferred by the network customers 87 because this can hide complexity of networks and release them from 88 the burden of selecting useful information and capability from vast 89 information and capability of the infrastructure network. 91 So, it is an efficient mechanism to create a Network Abstract 92 Interface (NAI) between the ISPs and their customers. A concrete NAI 93 is unique to a particular network and in accordance with the demands 94 of the network administrator, it enables network customers to get 95 abstracted network information, execute network capability and deploy 96 service logic to network, based on their authorization. 98 This document introduces an architecture that allows network 99 administrators to customize their specific Network Abstract 100 Interface. It is flexible enough to support various network 101 structures. The interaction between the NAI and the ISP 102 infrastructure network, such as how the information and capability of 103 infrastructure network are abstracted, how network capability are 104 executed and how the service logic are translated, are out of scope 105 of this document. 107 2. Terminology 109 Network Abstract Interface (NAI) An interactive interface between 110 network and their customers. It provides network abstracted 111 information and capability distinguished by user authorization. 112 It receives the customer order in both data form or service 113 logic form. 115 NAI Model The concrete description of a specific NAI, which defines 116 the results of abstracted network information and capability. A 117 model that is used to generate the open NAI. 119 NAI Modeling Language A modeling language used to describe a 120 specific NAI Model by the network administrators. 122 NAI User Instance A set of data collection for a certain user or 123 user class. It contains all abstracted network information and 124 capability that would open to this user or user class. 126 3. Requirements for Network Abstract Interface 128 The purpose of the Network Abstract Interface is to provide enough 129 information and capability, while excrescent information and 130 capability are filtered for the network customers in order to enable 131 them to create their customized network services, which meet their 132 unique demands. 134 3.1. Abstracted Network Level Information 136 The detailed information and capability of network devices are 137 enormous. Most of them are irrelevant to network customers. It 138 would be a huge burden if network customers have to select useful 139 information and capability from the vast information and capability 140 of the infrastructure network. 142 On another side, the ISPs also do not want to open their control all 143 their network information and capability. The direct control right 144 of network devices should also be remain on the ISPs in order to 145 prevent any abusing of network resources. 147 On behalf of both network operators and their customers, it is 148 preferred only abstracted (filtered) network level information and 149 capability, and only authorized control that network customers can 150 perform, are open. 152 3.2. Support Classified User Profile 154 ISPs have many different customers, which may have different 155 authorization. The NAI should be able to distinguish them. 156 Different customers should access to different information and 157 capability according to their different authorization. 158 Correspondently, the capability rights of different customers or 159 customer classes are also distinguished. 161 3.3. Support Interface Customizable 163 Every ISP networks are different. Any rigescent interfaces or 164 interface models would not be able to meet the various network 165 structures and various management requirements of network operators. 167 The way that a specific NAI is created should be flexible to be able 168 to adapt any ISP network. It should be able to support the network 169 administrators to create and manage easily with the ability to 170 support any kind requirements. The network administrators should 171 also be allowed to manage or modify their NAI in running time. 173 3.4. Support Services-Oriented Description 175 The network administrators are responsible to describe a few services 176 or service templates for network customers to select. These services 177 or service templates may allow complex logic. The NAI should be able 178 to understand these service logic and express them within NAI user 179 instances. 181 On another side, the demanded services from network customers are 182 various. New services or demands may appear in the future. The NAI 183 should be flexible enough to allow all these customer defined 184 services. Therefore, some customer demands may be expressed as logic 185 orders rather than any rigescent data forms. The NAI should be able 186 to understand these logic order and resolve them into network 187 configuration or network function executing. Furthermore, the whole 188 process should be automatic completed without requesting for human 189 intelligence. Support Customer Defined Services and Logic Order 191 4. A Flexible Model Architecture for NAI 193 This document introduces an architecture that allows network 194 administrators to customize their specific Network Abstract 195 Interface. This architecture are designed to meet the abovementioned 196 requirements. It is flexible enough to support various network 197 structures. 199 +--------------------------+ 200 | APP/Customer Operator | 201 +--------------------------+ 202 /\ || 203 || Logical Order 204 || or Data Order 205 || || 206 || \/ 207 +--------------------------+ 208 |Network Abstract Interface| 209 +--------------------------+ 210 | The NAI Model |<------+ NAI 211 +--------------------------+ | Modeling 212 /\ || | Language 213 || \/ +-------------+ 214 / | \ |Network Admin| 215 / | \ +-------------+ 216 / | \ 217 Network Level Information & Capability 218 | | | 219 +-----------------------+ 220 | Network & Devices | 221 +-----------------------+ 223 This architecture uses model description to constructe customizable 224 Network Abstract Interface (NAI). 226 Firstly, the network administrator designs a specific NAI model for 227 his specific network based on its open requirements, which stipulates 228 the openness of network abstracted network information, capability 229 and services based on the user authorizations and their authorized 230 operations. The network administrator describes this model using NAI 231 modeling language [I-D.xia-nai-modeling-language], which are 232 specifically designed for the NAI generation purpose. 234 Secondly, the NAI model is filled with the collected and abstracted 235 network information, capability and services to form a specific NAI 236 instance, which is available for network customers to interact with. 237 This process should be as automatic as possible, though some human 238 intervence and intelligence may be needed. 240 Then, the network customers can obtain their abstracted network 241 information and capability, including their authorized purviews. The 242 network customers can make their service orders, depending on their 243 specific authorizations. The service orders may also be described 244 using the NAI modeling language. The communication/transport between 245 NAI and network customers may use HTTP[RFC2616], or its successor. 247 Note: the network administrators can incrementally manage or modify 248 the NAI model, consequently manage or modify the specific NAI 249 instance, in running time by descriptions in the NAI modeling 250 language. 252 Note: the interaction between the NAI model and the ISP 253 infrastructure network, such as how the information and capability of 254 infrastructure network are abstracted, how network capability are 255 executed and how the service logic are translated, are out of scope 256 of this document. They may be completed by various network elements, 257 such as SDN controller, or network management system, etc. which are 258 also out of scope. 260 5. Security Considerations 262 Because the network customers are allowed to customize their own 263 services, they may bring potentially big impacts to a running ISP 264 network. A strong user authentication mechanism is needed for the 265 Network Abstract Interface. User authorization should be carefully 266 managed by the network administrator to avoid any dangerous 267 operations and prevent any abusing of network resources. 269 6. IANA Considerations 271 This memo includes no request to IANA. 273 7. Acknowledgements 275 The authors would like to thanks the valuable comments made by 276 Xiaofei Xu, Fuyou Miao and Wenyang Lei. 278 This document was produced using the xml2rfc tool [RFC2629]. 280 8. Informative References 282 [I-D.xia-nai-modeling-language] 283 Xia, Y., Jiang, S., Wang, X., and B. Liu, "Network 284 Abstract Interface (NAI) Modeling Language, draft-xia-nai- 285 modeling-language-00, Working in progress", January 2014. 287 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 288 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 289 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 291 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 292 June 1999. 294 Authors' Addresses 296 Yinben Xia (editor) 297 Huawei Technologies Co., Ltd 298 Q14, Huawei Campus, No.156 Beiqing Road 299 Hai-Dian District, Beijing, 100095 300 P.R. China 302 Email: xiayinben@huawei.com 304 Sheng Jiang (editor) 305 Huawei Technologies Co., Ltd 306 Q14, Huawei Campus, No.156 Beiqing Road 307 Hai-Dian District, Beijing, 100095 308 P.R. China 310 Email: jiangsheng@huawei.com 312 Xuewei Wang 313 Huawei Technologies Co., Ltd 314 Q14, Huawei Campus, No.156 Beiqing Road 315 Hai-Dian District, Beijing, 100095 316 P.R. China 318 Email: wangxuewei@huawei.com