idnits 2.17.1 draft-liu-supa-policy-based-management-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 2 longer pages, the longest (page 10) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 22, 2016) is 2834 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'TR235' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-supa-generic-policy-info-model-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SUPA W. Liu 2 Internet Draft J. Strassner 3 Intended status: Informational G. Karagiannis 4 Expires: January 2017 Huawei Technologies 5 M. Klyus 6 NetCracker 7 J. Bi 8 Tsinghua University 9 C. Xie 10 China Telecom 11 July 22, 2016 13 SUPA policy-based management framework 14 draft-liu-supa-policy-based-management-framework-02 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at 30 http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 8, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 Simplified Use of Policy Abstractions (SUPA) defines base YANG data 57 models to encode policy, which will point to device-, technology-, 58 and service-specific YANG models developed in other working groups. 59 Policy rules within an operator's environment can be used to express 60 high-level, possibly network-wide policies to a network management 61 function (within a controller, an orchestrator, or a network element). 62 The network management function can then control the configuration 63 and/or monitoring of network elements and services. This document 64 describes the SUPA basic framework, its elements and interfaces. 66 Table of Contents 68 1. Introduction ................................................ 2 69 2. Framework for Generic Policy-based Management ............... 3 70 2.1. Overview ............................................... 3 71 2.2. Operation .............................................. 8 72 2.3. The GPIM and the EPRIM ................................. 9 73 2.4. Creation of Generic YANG Modules ....................... 9 74 3. Security Considerations .................................... 10 75 4. IANA Considerations ........................................ 10 76 5. Contributors ............................................... 10 77 6. Acknowledgments ............................................ 10 78 7. References ................................................. 12 79 7.1. Normative References .................................. 12 80 7.2. Informative References ................................ 12 81 Authors' Addresses ............................................ 14 83 1. Introduction 85 The rapid growth in the variety and importance of traffic flowing 86 over increasingly complex enterprise and service provider network 87 architectures makes the task of network operations and management 88 applications and deploying new services much more difficult. In 89 addition, network operators want to deploy new services quickly and 90 efficiently. Two possible mechanisms for dealing with this growing 91 difficulty are the use of software abstractions to simplify the 92 design and configuration of monitoring and control operations, and 93 the use of programmatic control over the configuration and operation 94 of such networks. Policy-based management can be used to combine 95 these two mechanisms into an extensible framework. 97 Policy rules within an operator's environment can be used to express 98 high-level, possibly network-wide policies to a network management 99 function (within a controller, an orchestrator, or a network element). 100 The network management function can then control the configuration 101 and/or monitoring of network elements and services. 103 Simplified Use of Policy Abstractions (SUPA) will define a generic 104 policy information model (GPIM) [SUPA-info-model] for use in network 105 operations and management applications. The GPIM defines concepts 106 and terminology needed by policy management indepednent of the form 107 and content of the policy rule. The ECA Policy Rule Information 108 Model (EPRIM) [SUPA-info-model] extends the GPIM to define how to 109 build policy rules according to the event-condition-action paradigm. 111 Both the GPIM and the EPRIM are targeted at controlling the 112 configuration and monitoring of network elements throughout the 113 service development and deployment lifecycle. The GPIM and the EPRIM 114 will both be translated into corresponding YANG [RFC6020][RFC6020bis] 115 modules that define policy concepts, terminology, and rules in a 116 generic and interoperable manner; additional YANG modules may also 117 be defined from the GPIM and/or EPRIM to manage specific functions. 119 The key benefit of policy management is that it enables different 120 network elements and services to be instructed to behave the same 121 way, even if they are programmed differently. Management 122 applications will benefit from using policy rules that enable 123 scalable and consistent programmatic control over the 124 configuration and monitoring of network elements and services. 126 2. Framework for Generic Policy-based Management 128 This section briefly describes the design and operation of the SUPA 129 policy-based management framework. 131 2.1. Overview 133 Figure 1 shows a simplified functional architecture of how SUPA is 134 used to define policies for creating network element configuration 135 and monitoring snippets. SUPA uses the GPIM to define a consensual 136 vocabulary that different actors can use to interact with network 137 elements and services. The EPRIM defines a generic structure for 138 imperative policies. The GPIM, as well as the combination of the 139 GPIM and EPRIM, are converted to generic YANG data modules. 141 In one possible approach, SUPA Generic & ECA Policy YANG Data 142 modules together with the Resource and Service YANG data models 143 specified in IETF (which define the specific elements that will be 144 controlled by policies) are used by the Service Interface Logic. 145 This Service Interface Logic creates appropriate input mechanisms 146 for the operator to define policies (e.g., a web form or a script) 147 for creating and managing the network configuration. The operator 148 interacts with the interface, which is then translated to 149 configuration snippets. 151 Note that YANG models may not exist. In this case, the SUPA generic 152 policy YANG data modules serve as an extensible basis to develop new 153 YANG data models for the Service Interface Logic to create 154 appropriate input mechanisms for the operator to define policies. 155 This transfers the work specified by the Resource and Service YANG 156 data models specified in IETF into the Service Interface Logic, 157 which is then translated to configuration snippets. 159 +---------------------+ 160 +----------+ \| SUPA | 161 | IETF |---+----+ Information Models | 162 +----------+ | /| GPIM and EPRIM | 163 | +---------+-----------+ 164 Assignments | | Defines Policy Concepts 165 and Manage | \|/ 166 Content | +---------+-----------+ 167 | \| SUPA Generic | 168 +----+ & ECA Policy | 169 /| YANG Data modules | 170 +---------+-----------+ 171 * Possible Approach 172 +-----------------------------*-----------------------------+ 173 | Management System * | 174 | \*/ | 175 | Fills +---------+---------+ +-------------+ | 176 | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ 177 | |Operator|--------+ Logic +--|Service YANG |----|IETF| 178 | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+ 179 | scripts |forms, scripts,...)| +-------------+ | 180 | +---------+---------+ | 181 | \|/ | 182 | +-------+--------+ | 183 | | Local Devices | | 184 | | and Management | | 185 | | Systems | | 186 | +----------------+ | 187 +-----------------------------------------------------------+ 189 Figure 1 SUPA Framework 191 Figure 1 is exemplary. The Operator actor shown in Figure 1 can 192 interact with SUPA in other ways not shown in Figure 1. In addition, 193 other actors (e.g., an application developer) that can interact with 194 SUPA are not shown for simplicity. 196 The EPRIM defines an Event-Condition-Action (ECA) policy as an 197 example of imperative policies. An ECA policy rule is activated 198 when its event clause is true; the condition clause is then 199 evaluated and, if true, signals the execution of one or more 200 actions in the action clause. Imperative policy rules require 201 additional management functions, which are explained in section 2.2 202 below. 204 Figure 2 shows a SUPA Policy Model creating and communicating policy 205 rules to two different Network Manager and Network Controller 206 elements. 208 The Generic Policy Information Model (GPIM) was used to construct 209 policies. The GPIM defines generic policy concepts, as well as two 210 types of policies: ECA policy rules and declarative policy 211 statements. 213 An ECA policy rule is activated when its event clause is true; the 214 condition clause is then evaluated and, if true, signals the 215 execution of one or more actions in the action clause. This type of 216 policy explicitly defines the current and desired states of the 217 system being managed. 219 A set of Generic Policy Data Models are then created from the GPIM. 220 These YANG data model policies are then used to control the 221 configuration of network elements that model the service(s) to be 222 managed using policy. 224 OSS/BSS/Orchestrator 225 / \ 226 C 227 \ / 228 +------------------------------+----------------------------------+ 229 | SUPA Policy Model | 230 | +----------------------------------+ | 231 | | Generic Policy Information Model | | 232 | +----+------------------------+----+ | 233 | D \D/ | 234 | D +------------+--------------+ | 235 | D | ECAPolicyRule Information | | 236 | D | Model (EPRIM) | | 237 | D +------------+--------------+ | 238 | +----------------D------------------------D----------------+ | 239 | | \D/ SUPA Policy DM D | | 240 | |+---------------+-----------+ D | | 241 | || Generic Policy Data Model | D | | 242 | |+-------------------+-------+ D | | 243 | | \D/ \D/ | | 244 | | +--+--------------------+--------------+ | | 245 | | | ECA PolicyRule Data Model | | | 246 | | +--------------------------------------+ | | 247 | +------------------------------+---------------------------+ | 248 +---------------------------------|-------------------------------+ 249 +-------------+--------+ 250 \C/ \C/ NETCONF/RESTCONF 251 +----------------+-----------+ +-------+--------------------+ 252 | EMS/NMS/Controller | | EMS/NMS/Controller | 253 | +---------------------+ | | +---------------------+ | 254 | | Network Service & | | | | Network Service & | | 255 | | Resource Data Models| | | | Resource Data Models| | 256 | +---------------------+ | | +---------------------+ | 257 +---+---+---+----------------+ +-----+---+---+--------------+ 258 / \ / \ / \ / \ / \ / \ 259 C C C C C C 260 \ / \ / \ / \ / \ / \ / 261 NE1 NE2 NEn NE1 NE2 NEn 263 Figure 2 SUPA Policy Model Framework 265 In Figure 2: 266 A double-headed arrow with Cs means communication; 267 A double-headed arrow with Ds means derived from. 269 The network elements used in this framework are: 271 SUPA Policy Model: represents one or more policy modules that 272 contain the following entities: 274 Generic Policy Information Model: a model for defining policy 275 rules that are independent of data repository, data definition, 276 query, and implementation languages, and protocol. This model is 277 abstract and is used for design; it MUST be turned into a data model 278 for implementation. 280 Generic Policy Data Model: a model of policy rules for that are 281 dependent of data repository, data definition, query, and 282 implementation languages, and protocol. 284 ECA Policy Rule Information Data Model (EPRIM): represents a policy 285 rule as a statement that consists of an event clause, a condition 286 clause, and an action clause. This type of Policy Rule explicitly 287 defines the current and desired states of the system being managed. 288 This model is abstract and is used for design; it MUST be turned 289 into a data model for implementation. 291 ECA Policy Rule Data Model: a model of policy rules derived from 292 EPRIM, consist of an event clause, a condition clause, and an action 293 clause. 295 EMS/NMS/Controller: represents one or more entities that are able 296 to control the operation and management of a network infrastructure 297 (e.g., a network topology that consists of Network Elements). 299 Network Service & Resource Data Models: models of the service as 300 well as physical and virtual network topology including the resource 301 attributes (e.g., data rate or latency of links) and operational 302 parameters needed to support service deployment over the network 303 topology. 305 Network Element (NE), which can interact with local or remote 306 EMS/NMS/Controller in order to exchange information, such as 307 configuration information, policy enforcement capabilities, and 308 network status. 310 Relationship among Policy, Service and Resource models can be illustrated by the 311 figure below. 312 +---------------+ +----------------+ 313 | Policy | (1) | Service | 314 | |*******************| | 315 | ( SUPA ) | | ( L3SM, ... ) | 316 +---------------+ +----------------+ 317 ** ** 318 ** ** 319 ** ** 320 (2) ** ** (3) 321 ** ** 322 ** ** 323 ** ** 324 +-------------------+ 325 | Resource | 326 | | 327 | (Inventory, ... ) | 328 +-------------------+ 329 Figure 3 Relationship among Policy, Service and Resource 331 In Figure 3: 332 (1) policy manages and can adjust service behavior as necessary 333 (2) policy manages and can adjust resource behavior as necessary 334 (3) resource hosts service; changing resources may change service 335 behavior as necessary 337 Policies are used to manage behavior. Policies can be applied to 338 services and resources. More importantly, policies can be used to 339 manage how resources are allocated and assigned to services. This 340 enables a single policy to manage one or multiple services and 341 resources as well as their dependencies. 343 2.2. Operation 345 SUPA can be used to define various types of policies, including 346 policies that affect services and/or the configuration of 347 individual or groups of network elements. SUPA can be used by a 348 centralized and/or distributed set of entities for creating, 349 managing, interacting with, and retiring policy rules. 351 The SUPA scope is limited to policy information and data models. 352 SUPA will not define network resource data models or network 353 service data models; both are out of scope. Instead, SUPA will make 354 use of network resource data models defined by other WGs or SDOs. 356 Declarative policies that specify the goals to achieve but not how 357 to achieve those goals (also called "intent-based" policies) are out 358 of scope for the initial phase of SUPA. 360 2.3. The GPIM and the EPRIM 362 The GPIM provides a common vocabulary for representing concepts 363 that are common to expressing different types of policy, but which 364 are independent of language, protocol, repository, and level of 365 abstraction. 367 This enables different policies at different levels of abstraction 368 to form a continuum, where more abstract policies can be translated 369 into more concrete policies, and vice-versa. For example, the 370 information model can be extended by generalizing concepts from an 371 existing data model into the GPIM; the GPIM extensions can then be 372 used by other data models. 374 The SUPA working group develops models for expressing policy at 375 different levels of abstraction. Specifically, two models are 376 envisioned (both of which are contained in the Generic Policy 377 Information Model block in Figure 1: 379 1. a generic model (the GPIM) that defines concepts and vocabulary 380 needed by policy management systems independent of the form and 381 content of the policy 383 2. a more specific model (the EPRIM) that refines the GPIM to 384 specify policy rules in an event-condition-action form 386 2.4. Creation of Generic YANG Modules 388 An information model is abstract. As such, it cannot be directly 389 instantiated (i.e., objects cannot be created directly from it). 390 Therefore, both the GPIM, as well as the combination of the GPIM 391 and the EPRIM, are translated to generic YANG modules. 393 SUPA will provide guidelines for translating the GPIM (or the 394 combination of the GPIM and the EPRIM) into concrete YANG data 395 models that define how to manage and communicate policies between 396 systems. Multiple imperative policy YANG data models may be 397 instantiated from the GPIM (or the combination of the GPIM and the 398 EPRIM). In particular, SUPA will specify a set of YANG data models 399 that will consist of a base policy model for representing policy 400 management concepts independent of the type or structure of a 401 policy, and as well, an extension for defining policy rules 402 according to the ECA paradigm. 404 The process of developing the GPIM, EPRIM and the derived/translated 405 YANG data models is realized following the sequence shown below. 406 After completing this process and if the implementation of the YANG 407 data models requires it, the GPIM and EPRIM and the 408 derived/translated YANG data models are updated and synchronized. 410 (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') 412 Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)= 413 Implementation; (3')= update of YANG data models; (2')=update of 414 EPRIM; (1') = update of GPIM 416 The YANG module derived from the GPIM contains concepts and 417 terminology for the common operation and administration of policy- 418 based systems, as well as an extensible structure for policy rules 419 of different paradigms. The YANG module derived from the EPRIM 420 extends the generic nature of the GPIM to represent policies using 421 an event-condition-action structure. 423 The above sequence allows for the addition of new, as well as editing 424 of existing model elements in the GPIM and EPRIM. In practice, the 425 implementation sequence may be much simpler. Specifically, it is 426 unlikely that the GPIM will need to be changed. In addition, changes 427 to the EPRIM will likely be focused on fine-tuning the behavior 428 offered by a specific set of model elements. 430 3. Security Considerations 432 TBD 434 4. IANA Considerations 436 This document has no actions for IANA. 438 5. Contributors 440 The following people all contributed to creating this document, 441 listed in alphabetical order: 443 Ying Chen, China Unicom 444 Luis M. Contreras, Telefonica I+D 445 Dan Romascanu, Avaya 446 J. Schoenwaelder, Jacobs University, Germany 447 Qiong Sun, China Telecom 449 6. Acknowledgments 451 This document has benefited from reviews, suggestions, comments and 452 proposed text provided by the following members, listed in 453 alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern, Bert 454 Wijnen, Tianran Zhou. 456 Part of the initial draft of this document was picked up from 457 previous documents, and this section lists the acknowledgements from 458 them. 460 From "SUPA Value Proposition" [Klyus2016] 462 The following people all contributed to creating this document, 463 listed in alphabetical order: 465 Vikram Choudhary, Huawei Technologies 466 Luis M. Contreras, Telefonica I+D 467 Dan Romascanu, Avaya 468 J. Schoenwaelder, Jacobs University, Germany 469 Qiong Sun, China Telecom 470 Parviz Yegani, Juniper Networks 472 This document has benefited from reviews, suggestions, comments and 473 proposed text provided by the following members, listed in 474 alphabetical order: H. Rafiee, J. Saperia and C. Zhou. 476 The authors of "SUPA Value Proposition" [Klyus2016] were: 478 Maxim Klyus, Ed. , NetCracker 479 John Strassner, Ed. , Huawei Technologies 480 Will(Shucheng) Liu, Huawei Technologies 481 Georgios Karagiannis, Huawei Technologies 482 Jun Bi, Tsinghua University 484 The initial draft of this document merged one document, and this 485 section lists the acknowledgements from it. 487 From "Problem Statement for Simplified Use of Policy Abstractions 488 (SUPA)" [Karagiannis2015] 490 The authors of this draft would like to thank the following persons 491 for the provided valuable feedback and contributions: Diego Lopez, 492 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 493 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon 494 Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas 495 Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, 496 Scott O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. 497 Tina Tsou, Will Liu and Jean-Francois Tremblay contributed to an 498 early version of this draft. 500 The authors of "Problem Statement for Simplified Use of Policy 501 Abstractions (SUPA)" [Karagiannis2015] were: 503 Georgios Karagiannis, Huawei Technologies 504 Qiong Sun, China Telecom 505 Luis M. Contreras, Telefonica 506 Parviz Yegani, Juniper 507 John Strassner, Huawei Technologies 508 Jun Bi, Tsinghua University 510 From "The Framework of Simplified Use of Policy Abstractions (SUPA)" 511 [Zhou2015] 513 The authors of this draft would like to thank the following persons 514 for the provided valuable feedback: Diego Lopez, Jose Saldana, 515 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 516 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, 517 Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, 518 Georgios Karagiannis, John Strassner, Raghav Rao, Jing Huang. 520 Early version of this draft can be found here: 521 https://tools.ietf.org/html/draft-zhou-supa-architecture-00 522 At the early stage of SUPA, we think quite some issues are left open, 523 it is not so suitable to call this draft as "architecture". We would 524 like to rename it to "framework". Later there may be a dedicated 525 architecture document. 527 The authors of "The Framework of Simplified Use of Policy 528 Abstractions (SUPA)" [Zhou2015] were: 530 Cathy Zhou, Huawei Technologies 531 Luis M. Contreras, Telefonica 532 Qiong Sun, China Telecom 533 Parviz Yegani, Juniper 535 7. References 537 7.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 7.2. Informative References 544 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 545 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 546 J., Waldbusser, S., "Terminology for Policy-Based Management", RFC 547 3198, November, 2001 549 [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the 550 Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 552 [RFC6020bis] M. Bjorklund, "The YANG 1.1 Data Modeling Language", 553 IETF Internet draft, draft-ietf-netmod-rfc6020bis-14, June 2016. 555 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 556 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 557 Optimization (ALTO) Protocol", September 2014 559 [SUPA-info-model] J. Strassner, J. Halpern, S. van der Meer, "Generic 560 Policy Information Model for Simplified Use of Policy Abstractions 561 (SUPA)", IETF Internet draft, 562 draft-ietf-supa-generic-policy-info-model-01, July 2016 564 [TR235] J. Strassner, ed., "ZOOM Policy Architecture and 565 Information Model Snapshot", TR245, part of the TM Forum ZOOM 566 project, October 26, 2014 568 [Karagiannis2015] G. Karagiannis, ed., "Problem Statement for 569 Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft, 570 draft-karagiannis-supa-problem-statement-07, June 5, 2015 572 [Klyus2016] M. Klyus, ed., "SUPA Value Proposition", IETF Internet 573 draft, draft-klyus-supa-value-proposition-00, Mar 21, 2016 575 [Zhou2015] C. Zhou, ed., "The Framework of Simplified Use of Policy 576 Abstractions (SUPA)", draft-zhou-supa-framework-02, May 08, 2015 578 Authors' Addresses 580 Will(Shucheng) Liu 581 Huawei Technologies 582 Bantian, Longgang District, Shenzhen 518129 583 P.R. China 584 Email: liushucheng@huawei.com 586 John Strassner 587 Huawei Technologies 588 2330 Central Expressway 589 Santa Clara, CA 95138 USA 590 Email: strazpdj@gmail.com 592 Georgios Karagiannis 593 Huawei Technologies 594 Hansaallee 205, 40549 Dusseldorf 595 Germany 596 Email: Georgios.Karagiannis@huawei.com 598 Maxim Klyus 599 NetCracker 600 Kozhevnicheskaya str.,7 Bldg. #1 601 Moscow, Russia 602 E-mail: klyus@netcracker.com 604 Jun Bi 605 Tsinghua University 606 Network Research Center, Tsinghua University 607 Beijing 100084 608 P.R. China 609 Email: junbi@tsinghua.edu.cn 611 Chongfeng Xie 612 China Telecom Beijing Research Institute 613 China Telecom Beijing Information Science&Technology Innovation Park 614 Beiqijia Town Changping District Beijing 102209 China 615 Email: xiechf@ctbri.com.cn