idnits 2.17.1 draft-zhou-supa-framework-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 3) being 65 lines 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 08, 2015) is 3276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ID.draft-zaalouk-supa-vpn-service-management-model' is mentioned on line 217, but not defined == Missing Reference: 'ID.draft-contreras-supa-yang-network-topo' is mentioned on line 231, but not defined == Unused Reference: 'ID.draft-cheng-supa-ddc-use-cases' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'ID.draft-strassner-supa-generic-policy-info-model' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'ID.draft-bi-supa-policy-model' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'ID.draft-pentikousis-supa-mapping' is defined on line 431, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-04 == Outdated reference: A later version (-07) exists of draft-karagiannis-supa-problem-statement-06 == Outdated reference: A later version (-08) exists of draft-cheng-supa-ddc-use-cases-06 == Outdated reference: A later version (-05) exists of draft-pentikousis-supa-mapping-04 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Zhou 2 Internet-Draft Huawei Technologies 3 L. M. Contreras 4 Intended status: Informational Telefonica 5 Expires: November 08, 2015 Q. Sun 6 China Telecom 7 P. Yegani 8 Juniper Networks 9 May 08, 2015 11 The Framework of Simplified Use of Policy Abstractions (SUPA) 12 draft-zhou-supa-framework-02 14 Abstract 16 Currently, there are network services that impose specific demands 17 on a communication network. This document describes the SUPA basic 18 architecture, its elements and interfaces. The main SUPA 19 architecture entities are the Service Management (SM) and the 20 Network Manager/Controller (NM/NC). The SM is a functional entity 21 that creates and runs network services by using a set of NM/NCs. The 22 NM/NC is a functional entity that provides one or more of the 23 following functions: (1) the generation, maintenance and release of 24 network topologies, (2) the generation, maintenance, and release of 25 network service-specific abstractions, (3) the mapping between 26 network service-specific abstractions and the network topology, and 27 (4) the mapping between network service-specific abstractions and 28 network device configuration. Both the SM and the NM/NC may be made 29 up of multiple distinct entities that collectively perform their 30 functions. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. Internet- 41 Drafts are draft documents valid for a maximum of six months and may 42 be updated, replaced, or obsoleted by other documents at any time. 43 It is inappropriate to use Internet-Drafts as reference material or 44 to cite them other than as "work in progress." This Internet-Draft 45 will expire on April 27, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [RFC2119]. 72 Table of Content 73 1. INTRODUCTION .................................................... 2 74 2. TERMINOLOGY ..................................................... 3 75 3. SUPA FRAMEWORK .................................................. 4 76 4. FRAMEWORK FUNCTIONAL ENTITIES ................................... 6 77 4.1. SERVICE MANAGEMENT ........................................... 6 78 4.2. NETWORK MANAGER/CONTROLLER ................................... 6 79 4.3. NETWORK ELEMENTS ............................................. 7 80 5. SECURITY CONSIDERATIONS ......................................... 8 81 6. IANA CONSIDERATIONS ............................................. 8 82 7. ACKNOWLEDGEMENTS ................................................ 8 83 8. NORMATIVE REFERENCES ............................................ 8 84 9. INFORMATIVE REFERENCES .......................................... 8 85 AUTHORS' ADDRESSES ................................................. 9 87 1. Introduction 89 As the Internet grows, new services are created, new devices are 90 connected, and new users use the Internet. These and other factors 91 contribute to the significant increase in the amount and type of 92 network traffic. This in turn makes network management and 93 configuration more and more complicated. 95 However, the need for dynamic and real-time configuration changes is 96 required. One example is Inter-Data Center (DC) traffic steering and 97 tunneling, based on real-time network status. Dedicated network 98 management applications are required to automate the complicated and 99 dynamic network configuration present in today's systems. Such 100 applications need interoperable data models of network topology, 101 network services, and policy rules to support the design, deployment, 102 and maintenance of network services. Providing these data models to 103 network management applications may provide significant improvements 104 in configuration agility, error detection, and uptime for operators. 106 However, in order to scale and to ensure configuration change 107 consistency, existing network configuration schemes must be 108 simplified through the use of abstraction. This increases the 109 programmatic control over such systems. Simplified models are able 110 to provide a wide range of granularity for various applications and 111 network services needs, from the lower-level physical network to 112 high-level application services. 114 An abstract view of a network infrastructure can be realized using 115 one or more network topology data models. Each such topology model, 116 whether physical or logical, may be used as its own reusable managed 117 object. This enables existing topologies to be reused to create new 118 topologies. This applies to models of different layers, including 119 the application layer (L7), IP/network layer (L3), and lower layers 120 (L0-L2, such as MPLS, SDH, OTN, WDM). The network resources may 121 include physical and/or virtual network nodes and links. 123 A network service data model is service specific, and usually relies 124 on a network topology data model. The network service data model 125 defines the behavior of the network service, which is characterized 126 by one or more metrics that include performance, dependability, and 127 security specifications. 129 One method to automate service configuration is to use a policy data 130 model. Policy, in conjunction with network service and device data 131 models, can be used to tell the Network Manager/Controller (NM/NC) 132 how to generate Network Element (NE) configurations using network 133 service data models in combination with topology data models. For 134 example, this process can be used to choose a path for VPN which 135 will involve a set of NE's. 137 The main goal of this document is to specify the SUPA reference 138 architecture, its elements, and its interfaces. 140 YANG data models (e.g., see [RFC6020], [RFC6991]) can be used for 141 representing service and topology models. 143 2. Terminology 145 The terminology used in the SUPA problem statement draft 146 [ID.karagiannis-supa-problem-statement] also applies to this draft. 148 NE Network Element 149 NC Network Controller 150 NM Network Manager 151 NM/NC Network Manager/Controller 152 SM Service Management 154 3. SUPA Framework 156 +------------------------+ 157 | Service Management | 158 | +--------------------+ | 159 | | Policy Data Model | | 160 | +--------------------+ | 161 | +--------------------+ | 162 | | Service Management | | 163 | | Data Model | | 164 | +--------------------+ | 165 +------------------------+ 166 | 167 | 168 | NETCONF/RESTCONF 169 ----------------------------------------------- 170 | | 171 | | 172 +----------------------------+ +----------------------------+ 173 | Network Manager/Controller | | Network Manager/Controller | 174 | +------------------------+ | | +------------------------+ | 175 | | Network Resource | | | | Network Resource | | 176 | | Data Model | | | | Data Model | | 177 | +------------------------+ | | +------------------------+ | 178 +----------------------------+ +----------------------------+ 179 | | | | | | 180 | | | | | | 181 | | | | | | 182 NE1 NE2 NEn NE1 NE2 NEn 184 Figure 1 SUPA Framework 186 An overview of the SUPA framework is shown in Figure 1. The network 187 entities used in this framework are: 189 SM: Service Management, which represents one or more network 190 entities that are running and controlling network services. 191 Policy Data Model 192 Model of policy rules for managing the network service and 193 mapping services dynamically to the network topology and 194 network resources. Policy data models are used to describe 195 high level service requirements, such as routing requirements. 197 Example of policy data model can be found in [ID.draft- 198 strassner-supa-generic-policy-info-model] and [ID.draft-bi- 199 supa-policy-model]. 201 There can be various types of policies, including service 202 specific policies and network-wide policies. There can be a 203 centralized entity managing the network-wide policies, which 204 may be called as policy manager. The policy manager can be 205 located in the SM or in a separate location. 207 Policy data models now considered by SUPA are generic policy 208 data model, ECA (event, condition, action) as described in 209 SUPA charter. The work may be extended in the future. 211 Service Management Data Model 212 Model of the network service (e.g., VPNs) and the network 213 resources required by the network service to be correctly 214 deployed and executed on the physical and/or virtual topology. 216 Example of service management data model can be found in 217 [ID.draft-zaalouk-supa-vpn-service-management-model]. 219 NM/NC: Network Manager / Controller, which represents one or 220 more entities that are able to control the operation and 221 management of a network infrastructure (e.g., a network topology 222 that consists of Network Elements (NEs)). 224 Network Resource Data Model 225 Model of the physical and virtual network topology including 226 the resource attributes (e.g., data rate or latency of links) 227 and operational parameters needed to support service 228 deployment over the network topology. 230 Example of network resource data model can be found in 231 [ID.draft-contreras-supa-yang-network-topo] 233 SUPA will not define network resource data model, which is 234 out of the scope of SUPA. SUPA will make use of network 235 resource data models defined by other WGs or SDOs. 237 Network Element (NE), which handles packets based on the network 238 management and controlling procedures. NEs can interact with 239 local or remote NM/NC in order to exchange information, such as 240 configuration information, policy enforcement capabilities, and 241 network status. 243 Service Management (SM) communicates with Network Manager/Controller 244 (NM/NC) using an appropriate protocol, such as NETCONF [RFC6241] or 245 RESTCONF [ID.draft-ietf-netconf-restconf]. 247 NM/NC exchanges configuration information with NEs and derives the 248 current network topology that contains the NEs, and also the 249 capabilities and status of NEs, which will be stored in network 250 resource data model. NM/NC may also communication with traditional 251 network management system to retrieve the above information. It can 252 use existing network management and signaling protocols, such as 253 I2RS [I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf- 254 restconf], etc. 256 Service Management (SM) will send policy data model and service 257 management data model, which will in conjunction with network 258 resource data model be mapped to detail NEs' configurations by 259 network manager / controller. 261 4. Framework Functional Entities 263 4.1. Service Management 265 There are a wide variety of communication services offered by 266 service providers. 268 The Service Management (SM) is a functional entity, residing at the 269 Application layer, which enables network services, such as: 270 o) Network services (e.g., L2VPN, L3VPN, etc.) 271 o) application-specific policies 273 SM will push service management data model and policy data model to 274 NM/NC for service deployment. 276 4.2. Network Manager/Controller 278 | 279 | to/from Service Management 280 | 281 +--------------------------+----------------------------------------+ 282 | Network Manager/Controller Functional Block | 283 | +-------------------------------+ +---------------------------+ | 284 | | NM/NC to SM Interface | | mapping: Policy Data | | 285 | +-------------------------------+ | Model + Network Resource | | 286 | | Data Model to Service | | 287 | +-------------------------------+ | Specific Topology | | 288 | | | +---------------------------+ | 289 | | Network Resource Data Model | | 290 | | | +---------------------------+ | 291 | +-------------------------------+ | mapping: Service Data | | 292 | | Model + Service Specific | | 293 | +-------------------------------+ | Topology to Detail NEs' | | 294 | | NM/NC to NE Interface | | Configurations | | 295 | +-------------------------------+ +---------------------------+ | 296 +-------------------------------------------------------------------+ 297 Figure 2 NM/NC Functional Blocks 298 Network Manager/Controller (NM/NC) is a functional entity that is 299 able to generate and maintain desired and current topologies of the 300 network infrastructure. As part of this process, it is also 301 responsible for reserving and releasing network resources that are 302 required to support network services in a given network 303 infrastructure. 305 The NM/NC contains a set of data models, functions and APIs, 306 including: 308 o) Network Resource Data Model 309 Maintain an up to date topology of the network infrastructure, 310 including capabilities and current status of NEs. 312 o) Mapping: service specific topology 313 This mapping procedure will combine the policy data model and 314 service management data model and generate a specific topology. 316 o) Mapping: target NE(s) detail configurations 317 This mapping procedure will use the service specific topology 318 generated in the previous procedure and the service management 319 data model to generate detail NE(s) configurations. 321 o) NM/NC to traditional network management system interface: 322 provides the interface with existing network management system 323 protocols (e.g., I2RS [I2RS], NETCONF, etc.) to request 324 configuration and status information, and push configuration changes 325 to NEs. 327 o) NM/NC to SM interface: used to support the communication between 328 the SM and NM/NC. The candidate protocols used for this purpose 329 could be either NETCONF [RFC6241] or RESTCONF [ID.draft-ietf- 330 netconf-restconf]. 332 An example of the mapping procedures can be that, a service requires 333 that a link from A to B is created; and the policy requires that the 334 hops of this link should not exceed N. Then when NM/NC receives the 335 policy data model and service management data model from SM, it will 336 first apply the policy data model to the network resource data model 337 and get a sub-set topology which can fulfill the hops limit 338 requirements. Then NM/NC will further generate detail configurations 339 for target NE(s). The mapping procedures can be enforced by 340 functional entity called policy agent. 342 After the service is deployed, if there is a network topology change, 343 network configurations for this service may need to be updated 344 accordingly. A possible solution is to repeat the mapping procedures, 345 and generate configurations for NEs (maybe another set of NEs). This 346 requires that NM/NC maintains a copy of the service management data 347 models and policy data models. 349 For more detail about mapping mechanisms, please refer to [ID.draft- 350 pentikousis-supa-mapping]. 352 4.3. Network Elements 354 The Network Element (NE) responds to requests and commands from the 355 NM/NC and makes corresponding configuration changes. An NE may be a 356 physical or a virtual entity, and is locally managed (e.g., via CLI, 357 SNMP, or NETCONF). 359 SUPA will specify mechanisms, in order to enable the NEs to interact 360 with either local or remote network management systems. The 361 interaction may include the exchange of information, such as 362 configuration and status information. The NEs will be able to push 363 this information in an event that the NM/NC can subscribe to, and/or 364 provide this information after receiving a request from the NM/NC. 366 5. Security Considerations 368 Security is a key aspect of any protocol that allows state 369 installation and extracting of detailed configuration states. More 370 investigation remains to fully define the security requirements, 371 such as authorization and authentication levels. 373 6. IANA Considerations 375 No IANA considerations. 377 7. Acknowledgements 379 The authors of this draft would like to thank the following persons 380 for the provided valuable feedback: Diego Lopez, Jose Saldana, 381 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 382 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, 383 Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, 384 Georgios Karagiannis, John Strassner, Raghav Rao, Jing Huang. 386 Early version of this draft can be found here: 387 https://tools.ietf.org/html/draft-zhou-supa-architecture-00 388 At the early stage of SUPA, we think quite some issues are left open, 389 it is not so suitable to call this draft as "architecture". We would 390 like to rename it to "framework". Later there may be a dedicated 391 architecture document. 393 8. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 9. Informative References 400 [I2RS] Interface to the Routing System (i2rs) charter, 401 http://datatracker.ietf.org/wg/i2rs/charter/ 403 [ID.draft-ietf-netconf-restconf] A. Bierman, M. Bjorklund, K. Watsen, 404 R. Fernando, "RESTCONF Protocol", IETF Internet draft (work in 405 progress), draft-ietf-netconf-restconf-04, January 2015 407 [ID.karagiannis-supa-problem-statement] G. Karagiannis, Q. Sun, L. M. 408 Contreras, P. Yegani, JF Tremblay, " Problem Statement for 409 Simplified Use of Policy Abstractions (SUPA)" IETF Internet Draft 410 (work in progress)", draft-karagiannis-supa-problem-statement-06, 411 March 2015. 413 [ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi 414 , L. M. Contreras, "Use Case for Distributed Data Center in SUPA", 415 IETF Internet draft (Work in progress), draft-cheng-supa-ddc-use- 416 cases-06, April 2015 418 [ID. draft-zaalouk-supa-vpn-service-management-model] D. Zhang, A. 419 Zaalouk, K. Pentikousis, Y. Cheng, "VPN Service Management YANG Data 420 Model", IETF Internet draft (Work in progress), draft-zaalouk-supa- 421 vpn-service-management-model-03, April 2015 423 [ID.draft-strassner-supa-generic-policy-info-model] J. Strassner, 424 "Generic Policy Model for Simplified Use of Policy Abstractions 425 (SUPA)", IETF Internet draft (Work in progress), April, 2015 427 [ID.draft-bi-supa-policy-model] J. Bi, R. Tadepalli, M. Hayashi, 428 "DDC Service Policy YANG Data Model", IETF Internet draft (Work in 429 progress), March, 2015 431 [ID.draft-pentikousis-supa-mapping] K. Pentikousis, D. Zhang, 432 "Simplified Use of Policy Abstractions (SUPA): Configuration and 433 Policy Mapping", IETF Internet draft (Work in progress), draft- 434 pentikousis-supa-mapping-04, March 2015 436 [NETCONF] Network Configuration (netconf) charter, 437 http://datatracker.ietf.org/wg/netconf/charter/ 439 [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the 440 Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 442 [RFC6991] J. Schoenwaelder, "Common YANG Data Types", RFC 6991, 443 July 2013. 445 [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, 446 "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. 448 Authors' Addresses 450 Cathy Zhou 451 Huawei Technologies 452 Bantian, Longgang District 453 Shenzhen 518129 454 P.R. China 455 Email: cathy.zhou@huawei.com 457 Luis M. Contreras 458 Telefonica I+D 459 Ronda de la Comunicacion, Sur-3 building, 3rd floor 460 Madrid 28050 461 Spain 462 Email: luismiguel.contrerasmurillo@telefonica.com 463 URI: http://people.tid.es/LuisM.Contreras/ 465 Qiong Sun 466 China Telecom 467 No.118 Xizhimennei street, Xicheng District 468 Beijing 100035 469 P.R. China 471 Email: sunqiong@ctbri.com.cn 473 Parviz Yegani 474 JUNIPER NETWORKS 475 1133 Innovation Way 476 Sunnyvale, CA 94089 477 Email: pyegani@juniper.net