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