idnits 2.17.1 draft-zhou-aponf-architecture-03.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 == Line 123 has weird spacing: '...een the netwo...' == Line 134 has weird spacing: '...ociated netwo...' -- The document date (July 21, 2014) is 3565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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 T. Tsou 3 Intended status: Informational Huawei Technologies 4 Expires: January 21, 2015 D. Lopez 5 Telefonica 6 G. Karagiannis 7 University of Twente 8 Q. Sun 9 China Telecom 10 July 21, 2014 12 The Architecture for Application-based Policy On Network Functions 13 draft-zhou-aponf-architecture-03 15 Abstract 17 Currently, there are network management applications that present 18 specific demands on a communication network. This document describes 19 the APONF basic architecture, its elements and interfaces. The main 20 APONF architecture entities are the Network Management Application 21 Agent (NMAA), which is a network entity that creates and runs network 22 services, and Application-based Policy Decision (ABPD), which 23 supports classified application models. Each of these models support 24 application demands that are similar in nature and therefore can be 25 grouped/classified together. Moreover, the ABPD maps the classified 26 application models into network capabilities, e.g., network 27 management and controlling policies. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 21, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Overview of the APONF Architecture . . . . . . . . . . . . . 3 76 4. Network Management Applications . . . . . . . . . . . . . . . 5 77 4.1. Network Management Application Agent (NMAA) . . . . . . . 5 78 5. Application Based Policy Decision . . . . . . . . . . . . . . 7 79 6. Network Elements . . . . . . . . . . . . . . . . . . . . . . 10 80 7. The APONF Interface . . . . . . . . . . . . . . . . . . . . . 10 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 84 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 85 12. Informative References . . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 As the Internet grows, more and more new services keep on arising, 91 and network traffic is rapidly increased, which may result in slow 92 performance of network devices (e.g., BRAS) and poor end-user 93 experience. In addition, especially for cloud applications, the 94 cloud tenants and developers usually need to use the communication 95 network capabilities, such as dynamic network management and dynamic 96 traffic steering, easily, accurately and efficiently. In this way, 97 the deployment of new applications and services may be accelerated 98 and the user experience can be improved. 100 In particular, today network operators are challenged to create an 101 abstract view of their network infrastructure and help service 102 developers on using and programming this abstraction rather than 103 manipulating individual devices. In this context, network management 104 applications can be used to provide the required configuration and 105 application programming interfaces to such service developers. 106 Subsequently, a network management application can use the 107 application based demands and possibly update its associated network 108 service graph A network service graph provides an abstraction view of 109 a network infrastructure, which also includes network service 110 attributes. The network service attributes are network management 111 application dependent which may include the network service 112 dependencies and network configuration and topology used by a network 113 management application, the used flow steering policy, the IPv6 114 transition policy, the Distributed Data Center application policy. 115 Network management applications are Operational Support System (OSS) 116 like applications that help a communication service provider to 117 monitor, control, analyze and manage a communication network. 119 For each network service instance a network service graph needs to be 120 generated and maintained. 122 The up to date network service graph needs to (1) be communicated 123 between the network management application systems and the network 124 management and controlling systems, (2) map the attributes of the 125 network service graph into specific network management policies, 126 i.e., device level configuration models. 128 The main goal of this document is to specify the APONF basic 129 architecture, its elements and interfaces. The main APONF 130 architecture entities are the Network Management Application Agent 131 (NMAA) and the Application-based Policy Decision (ABPD). NMAA is a 132 network entity that creates and runs network services and is able to 133 use the application based demands and possibly update their 134 associated network service graph. The ABPD is able to map the 135 network service graphs into specific network management policies, 136 i.e., device level configuration models. The definition of these 137 network management policies is out of the APONF scope. 139 2. Terminology 141 The terminology used in the APONF problem statement draft 142 [ID.karagiannis-aponf-problem-statement] applies also to this draft. 144 3. Overview of the APONF Architecture 146 This section depicts an overview of the architecture of application- 147 based policy on network functions. Figure 1 shows APONF 148 architecture. The basic components of the APONF architecture are: 150 Network Management Application: Operational Support System (OSS) like 151 applications that help a communication service provider to monitor, 152 control, analyze and manage a communication network. Several network 153 management applications MAY communicate with the Application Based 154 Policy Decision block via the Network Management Application Agent. 156 +---------------------------------+ +------------------------- ----+ 157 | Network Management Application | |Network Management Application| 158 | | | | 159 | | | | 160 | +---------------------+ | | +---------------------+ | 161 | | Network Management | | | | Network Management | | 162 | | Application Agent | |... | | Application Agent | | 163 | | | | | | | | 164 | | (NMAA) | | | | (NMAA) | | 165 | +------------+--------+ | | +---------+-----------+ | 166 | | | | | | 167 | | | | | | 168 +----------------|----------------+ +-------------|----------------+ 169 | | 170 | | 171 +---------------|------------------------------------|----------------+ 172 |+--------------v-------------+ +---+ +--------v-------------------+| 173 ||Classified Application Model| |...| |Classified Application Model|| 174 |+----------------------------+ +---+ +----------------------------+| 175 | | 176 | Application Based Policy Decision (ABPD) | 177 +-----------------------------------^--------------------------------+ 178 | 179 | 180 | 181 +--------------------+---------------------+ 182 | | 183 | | 184 | | 185 +-------------v---------------+ +------------v-------------+ 186 | | | | 187 | | ... | | 188 | Network Element | | Network Element | 189 +-----------------------------+ +--------------------------+ 191 Figure 1: Architecture of application-based policy on network 192 functions 194 The Network Management Application Agent (NMAA): a network entity 195 that creates and runs network services. These network services 196 should be developed by an operator, which in the context of APONF are 197 assumed to be already available. 198 The NMAA is able to generate, for each of these network service 199 Instances, and using application based demands a network service 200 graph. 202 Application Based Policy Decision(ABPD): A network entity which 203 provides an interface to NMAA(s) and is able to map the classified 204 application based models, which are including the classified 205 application based demands and the network service graph, into 206 specific network management policies, i.e., device level 207 configuration models, which are used by the communication network. 208 ABPD can communicate with multiple NMAAs simultaneously. 210 Network Element (NE):handles incoming packets based on the ABDP 211 network management policies and the corresponding network management 212 and controlling procedures. 214 Figure 1 shows the basic architecture of application-based policy on 215 network functions. 217 4. Network Management Applications 219 This architecture is expected to be used for several categories of 220 network management applications. Such network management 221 applications are representing the realizations of the APONF use 222 cases, which are: "Distributed Data Center " 223 [ID.draft-cheng-aponf-ddc-use-cases], "IPv6 transition " 224 [ID.draft-sun-aponf-openv6-use-cases], 225 "Virtualized Enterprise Applications " 226 [ID.draft-huang-aponf-use-cases] , "Source Address Validation and 227 Traceback (SAVI)" [ID.draft-bi-aponf-sdsavi], and "Using the abstract 228 view of network by service developers" 229 [ID.draft-liu-aponf-using-abstract-view-use-case]. 231 These network management applications are represented by a set of 232 network services. Each network service can be represented by a 233 classified application based policy model, since it can model the 234 group of demands coming from a bundle of end user applications that 235 impose similar requirements on the communication network. Such 236 network services can be "Distributed Data Center ", " IPv6 237 transition", "Virtualized Enterprise Applications " and "Source 238 Address Validation and Traceback (SAVI) " and "Using the abstract 239 view of network by service developers". For each network service 240 instance a network service graph needs to be generated and 241 maintained. 243 4.1. Network Management Application Agent (NMAA) 245 The NMAA is part of the network management application and is a 246 network entity that creates and runs network services. These network 247 services should be developed by an operator, which in the context of 248 APONF are assumed to be already available. 250 The assumption here is that the network management application has a 251 complete view of the available network and network capabilities that 252 it can use. Moreover, it is assumed that the network management 253 application is able to have the abstract view of the network and on 254 how the network service is mapped into this abstract view. This 255 network abstract view is defined using the network service graph . It 256 is assumed that the NMAA can create and maintain the network service 257 graph. 259 An NMAA is a typical OSS gateway or Network Management Station 260 entity, that needs to support the following new functional blocks as 261 shown in Figure 2: 263 +----------------------------------------------+ 264 |NMAA | 265 | | 266 | +--------------+ +----------------+ | 267 | | | | Create/Update | | 268 | | Typical OSS | |network service | | 269 | | | | graph | | 270 | +--------------+ +----------------+ | 271 | | 272 | | 273 | | 274 | +--------------+ +-----------------+ | 275 | | End User | |NMAA - ABDP | | 276 | | Application | | | | 277 | | Interaction | | Interface | | 278 | +--------------+ +-----------------+ | 279 +----------------------------------------------+ 281 Figure 2: NMAA Functionality Block Diagram 283 o Typical OSS (Operations Support System) features. 285 o Create/Update network service graphs: this is a NMAA functional 286 block and is used by the NMAA to use the network service 287 description and create or update a network service graph. 288 The assumption used here is that the description of the network 289 services is provided to end user applications in such a way that 290 the end user application developer can use and program certain 291 network capabilities such that the end user QoE can significantly 292 be increased. The modified versions of the network service 293 description are made known to the network management application 294 and NMAA. This event initiates the update of the network service 295 graph. 297 o End User Application Interaction: this functional block is used to 298 provide and receive information to/from the end user application 299 engine. This functional block is in charge to provide the 300 description of the network services to end user applications in 301 such a way that the end user application developer can use and 302 program certain network capabilities such that the end user QoE 303 can significantly be increased. This functional block is also used 304 to receive the modified versions of the network service from the 305 end user application and to inform the "Create/Update network 306 service graph" functional block about this change. This event 307 initiates the update of the network service graph. Note that it is 308 assumed that the realization of this functional block and the 309 interface with the end user are out of the APONF's scope. 311 o "NMAA - ABDP interface": this functional block is used to support 312 a signaling protocol used between NMAA and the ABDP. Note that 313 one candidate IETF protocol that can be used for this purpose 314 is an enhanced version of the IETF Network Configuration Protocol 315 (NETCONF) [RFC6241]. 317 The Network Management Application Agent (NMAA) will use the APONF 318 interface to communicate with the Application Based Policy Decision 319 (ABPD) entity. 321 5. Application Based Policy Decision 323 The Application-Based Policy Decision (ABPD) block, is a an entity 324 used between the Network Management Applications and the network 325 elements to provide and maintain the application based policies. It 326 supports the APONF interface/protocol and is a software repository, 327 which stores the information associated with each NE, and maps the 328 classified application models, i.e., application based demands and 329 the network service graph, into existing network management policies, 330 i.e., device configuration models. In particular, by creating 331 application based policies that mirror application semantics, a 332 better mapping to existing network management policies can be 333 realized. This provides a simple, self-documenting mechanism for 334 capturing application-based policy requirements and mapping them to 335 existing network management policies. This will allow applications 336 to use the network capabilities in a more accurate and efficient way. 338 Figure 3 illustrates the ABPD functionality block diagram, which is 339 based on [ID.farrkingel-pce-abno-architecture] and enhanced to 340 satisfy the demands of the APONF use cases. Note that the realization 341 of the functional blocks defined in 342 [ID.farrkingel-pce-abno-architecture] is out of the scope of APONF. 343 However, the capabilities provided by the "Provisioning manager" 344 functional block can be combined with capabilities provided by the 345 APONF defined "ABPD Network Management Interface" functional block. 346 The Application Based Policy Decision (ABPD) block includes all the 347 functional blocks provided in Figure 1 of 348 [ID.farrkingel-pce-abno-architecture], together with the following 349 new defined functional blocks: 351 o Fresh network service graphs Maintenance: maintains a fresh 352 abstract view of the network. Note that this is realized using 353 the network service graph that is created by the NMAA. Important 354 to note that for each network service / classified application 355 model that is managed by a network management application a 356 different network service graph is needed. So in order to support 357 this capability, the APONF architecture needs to support a 358 functional block that stores all these abstract views of the 359 network in different network service graphs that are identified by 360 an unique ID. 362 o Application to Network Mapping: the following features are 363 supported by this functional block: 365 1. Translates the actions and the changed network service graph 366 received from the network management application, see 367 explanation below, to a new network service graph. This is 368 accomplished by using application based demands generated by 369 network management applications systems to map the network 370 service graph into specific network management policies, 371 i.e., into device level configuration models. Such 372 application based demands are: 374 +----------------------------------------------------------------+ 375 |ABPD Block | 376 | +--------------------------+ | 377 | | ABPD Management Interface| | 378 | +------------+-------------+ | 379 | +--------------+ | +---------------++--------------+ | 380 | | ABPD-NMAA | | | Fresh network ||Application to| | 381 | | | | | || Network | | 382 | | | | | || Mapping | | 383 | | | | | || | | 384 | | | | | || | | 385 | | Interface | | | Maintenance || | | 386 | +-----------+--+ | +------+--------++-+------------+ | 387 | | | | | | 388 | | | | | | 389 | +-+----+------+------------+-+ | 390 | +------+ | | +-------+ | 391 | |Policy+--+ ABPD Controller +-----+ | | 392 | |Agent | | +--+ | OAM | | 393 | +-+--+-+ +-+------------+----------+--+ | |Handler| | 394 | | | | | | | | | | 395 | +-----++ | +----+-+ +-------+-------+ | | +-------+ | 396 | |ALTO | +-+ VNTM |--+ | | | | 397 | |Server| +--+-+-+ | | | +---+--------+ | 398 | +--+---+ | | | PCE | | |I2RS client | | 399 | | +-------+ | | | | | | | 400 | | | | | | | +------------+ | 401 | +------+--+-+ | | | | | 402 | | Databases +-------:----+ | | | 403 | | TED | | +-+---+----+----+ | | 404 | | LSP-DB + | | | | | | 405 | +-----+--+--+ +-+---------------+-------+-+ | 406 | | Provisioning Manager | | 407 | +---------------------------+ | 408 +----------------------------------------------------------------+ 410 Figure 3: ABPD Functionality Block Diagram, based on 411 [ID.farrkingel-pce-abno-architecture]. 413 Encapsulating, de-encapsulating packets associated with a 414 flow into a tunnel (for example, VPN service, IPv6 415 transition service demands on the network). 417 Blocking, or dropping packets associated with a flow in 418 (the edge of) the network element when the network security 419 service is aware of the attack (for example, SAVI service, 420 Anti-DoS service demands on the network). 422 Configure and dynamically reconfigure data centers to the 423 steer and reroute traffic associated with a specific flow. 425 Configure and dynamically reconfigure data centers to 426 change priorities of different types of traffic associated 427 with a specific flow. 429 Logging the traffic associated with a flow for network 430 security service, 432 Optimization of the traffic based on the IETF ALTO 433 [ID.draft-ietf-alto-protocol], 435 Other actions defined by the administrator. 437 2. if required updates all databases, see Section 2.3.1.8 of 438 [ID.farrkingel-pce-abno-architecture]. 440 3. Uses existing network management and signaling protocols, i2rs 441 [I2RS], SFC [SFC], NETCONF [NETCONF], etc., to request 442 the implementation of the changes into the network. 444 o ABPD Network Management Interface: this functional block provides 445 the interface with existing network management, i2rs, 446 NETCONF, etc. protocols to request and negotiate the 447 implementation of the changes into the network configuration. 449 o ABPD -NMAA interface: this functional block is used to support the 450 communication between NMAA and the ABDP. Note that a candidate 451 IETF protocol that can be used for the support of this 452 interface is an enhanced For example, a possible protocol that 453 can be enhanced and used is the Network Configuration Protocol 454 (NETCONF) [RFC6241]. 456 The definition of the network management policies is out of the APONF 457 scope. 459 These application-based policy models can meet the application's 460 demands on the communication network and map these demands to network 461 management policies that can be understood by the communication 462 network. 464 6. Network Elements 466 The Network Element (NE) handles incoming packets based on the policy 467 information communicated with the ABPD block and makes corresponding 468 policy enforcement, which is based on existing network management 469 policies, see Section 5. 471 A NE may be a physical entity or a virtual entity and is locally 472 managed, whether via CLI, SNMP, or NeTConf. Examples of NEs can 473 include: 475 o A router that has an extended function module. The extended 476 module handles incoming packets based on the flow table of the 477 module. 479 o A server that runs vRouter or vSwitch. 481 o A CGN that runs NAT, Tunnel En/De-capsulation functions. 483 o A virtual network function entity. 485 7. The APONF Interface 487 This APONF Interface/Protocol, needs to be specified by the APONF 488 effort and is used to support the communication between the NMAA 489 entity and the ABPD entity. Several IETF protocols can be used 490 for this purpose. 491 A gap analysis is being performed in order to identify and select the 492 IETF protocol that, after extension, can enable the streaming 493 transfer of bulk-variable/data of the up to date network service 494 graphs between network management application systems and the network 495 management and controlling systems. 496 For example, a possible protocol that can be enhanced and used is the 497 Network Configuration Protocol (NETCONF) [RFC6241]. 499 8. Security Considerations 501 Security is a key aspect of any protocol that allows state 502 installation and extracting of detailed configuration states. More 503 investigation remains to fully define the security requirements, such 504 as authorization and authentication levels. 506 9. IANA Considerations 508 No IANA considerations. 510 10. Acknowledgements 512 The authors of this draft would like to thank the following persons 513 for the provided valuable feedback: Jose Saldana, Spencer Dawkins, 514 Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc 515 Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed Boucadair, 516 Jean Francois Tremblay, Tom Taylor. 518 Special thanks are expressed to the authors of the ID 519 [ID.farrkingel-pce-abno-architecture], since a significant part of 520 the ABPD functional blocks are based on the architecture described in 521 [ID.farrkingel-pce-abno-architecture]. 523 11. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 12. Informative References 530 [I2RS] Interface to the Routing System (i2rs) charter, 531 http://datatracker.ietf.org/wg/i2rs/charter/ 533 [ID.draft-ietf-alto-protocol] R. Alimi, R. Penno, Y. Yang, "ALTO 534 Protocol", IETF Internet draft (work in progress), draft-ietf-alto- 535 protocol-27, March 2014 537 [ID.farrkingel-pce-abno-architecture] King, D. and A. Farrel, 538 "A PCE-based Architecture for Application-based Network Operations", 539 Feb 2014. 541 [ID.karagiannis-aponf-problem-statement] G. Karagiannis, W. Liu, 542 T. Tsou, Q. Sun, and D. Lopez,"Problem Statement for Application 543 Policy on Network Functions (APONF)(work in progress)", June 2014. 545 [ID.draft-sun-aponf-openv6-use-cases] C. Xie, Q. Sun, JF. Tremblay, 546 "Use case of IPv6 transition in APONF", IETF Internet draft 547 Work in progress), draft-sun-aponf-openv6-use-cases-00, July 2014 549 [ID.draft-cheng-aponf-ddc-use-cases] Y. Cheng, C. Zhou, 550 G. Karagiannis, JF. Tremblay, "Use Cases for Distributed Data Center 551 Applicatinos in APONF", IETF Internet draft (Work in progress), 552 draft-cheng-aponf-ddc-use-cases-00, July 4, 2014 554 [ID.draft-huang-aponf-use-cases] C. Huang, Jiafeng Zhu, Peng He, 555 Shucheng (Will) Liu, G. Karagiannis, "Use Cases on Application- 556 centric Network Management and Service Provision" IETF Internet draft 557 (Work in progress), draft-huang-aponf-use-cases-01, Juy 2014 559 [ID.draft-liu-aponf-using-abstract-view-use-case] W. Liu, T. Tsou, 560 G. Karagiannis, J. Saldana, "APONF Use Case: Using Abstract View of 561 Network by Application Developers", IETF Internet draft (Work in 562 progress), draft-liu-aponf-using-abstract-view-use-case-00, 563 July 4, 2014 565 [ID.draft-bi-aponf-sdsavi] J. Bi, G. Yao, "Software Defined SAVI", 566 IETF Internet draft (Work in progress), 567 draft-bi-aponf-sdsavi-00, July 4, 2014 569 [NETCONF] Network Configuration (netconf) charter, 570 http://datatracker.ietf.org/wg/netconf/charter/ 572 [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, 573 "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. 575 [SFC] IETF SFC (Service Function Chaining) WG charter, 576 http://datatracker.ietf.org/wg/sfc/charter/ 578 Authors' Addresses 580 Cathy Zhou 581 Huawei Technologies 582 Bantian, Longgang District 583 Shenzhen 518129 584 P.R. China 586 Email: cathy.zhou@huawei.com 588 Tina Tsou 589 Huawei Technologies 590 Bantian, Longgang District 591 Shenzhen 518129 592 P.R. China 594 Email: Tina.Tsou.Zouting@huawei.com 596 Diego Lopez 597 Telefonica 599 Email: diego@tid.es 601 Georgios Karagiannis 602 University of Twente 604 Email: g.karagiannis@utwente.nl 606 Qiong Sun 607 China Telecom 608 No.118 Xizhimennei street, Xicheng District 609 Beijing 100035 610 P.R. China 612 Email: sunqiong@ctbri.com.cn