idnits 2.17.1 draft-mansfield-mpls-tp-nm-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2009) is 5481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Hing-Kam Lam 2 Internet Draft Alcatel-Lucent 3 Expires: October, 2009 Scott Mansfield 4 Intended Status: Informational Eric Gray 5 Ericsson 6 April 23, 2009 8 MPLS TP Network Management Framework 9 draft-mansfield-mpls-tp-nm-framework-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance 14 with the provisions of BCP 78 and BCP 79. 16 This memo provides information for the Internet community. It 17 does not specify an Internet standard of any kind. Distribution 18 of this memo is unlimited. 20 By submitting this Internet-Draft, each author represents that 21 any applicable patent or other IPR claims of which he or she is 22 aware have been or will be disclosed, and any of which he or she 23 becomes aware will be disclosed, in accordance with BCP 78 and 24 BCP 79. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF), its areas, and its working 28 groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them other than as "work 35 in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on October 23, 2009. 45 Copyright and License Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 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 in effect on the date of 52 publication of this document (http://trustee.ietf.org/license- 53 info). Please review these documents carefully, as they describe 54 your rights and restrictions with respect to this document. 56 Abstract 58 This document provides the network management framework the 59 Transport Profile for Multi-Protocol Label Switching (MPLS-TP). 61 Table of Contents 63 1. Introduction................................................4 64 1.1. Terminology............................................4 65 2. Management Architecture Consideration.......................5 66 2.1. Network Management Architecture........................6 67 2.2. Element Management Architecture........................7 68 2.3. Standard Management Interfaces........................10 69 2.4. Management and Control specific terminology...........11 70 2.5. Management Channel....................................11 71 3. Fault Management Considerations............................13 72 3.1. Supervision...........................................13 73 3.2. Validation............................................13 74 3.3. Alarm Handling........................................13 75 4. Configuration Management Considerations....................13 76 4.1. LSP ownership handover................................13 77 5. Performance Management Considerations......................14 78 6. Security Considerations....................................15 79 7. IANA Considerations........................................15 80 8. Acknowledgments............................................15 81 9. References.................................................15 82 9.1. Normative References..................................15 83 9.2. Informative References................................16 84 10. Author's Addresses........................................16 86 1. Introduction 88 This document provides a framework for using the MPLS-TP NM 89 requirements [1] for managing the elements and networks that 90 support a Transport Profile for MPLS. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 95 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described 97 in RFC 2119 [3]. 99 Communication Channel (CC): a logical channel between network 100 elements (NEs) that can be used - e.g. - management plane 101 applications or control plane applications. The physical channel 102 supporting the CC is technology specific. An example of physical 103 channels supporting the CC is a DCC channel within SDH. 105 Data Communication Network (DCN): a network that supports Layer 106 1 (physical), Layer 2 (data-link), and Layer 3 (network) 107 functionality for distributed management communications related 108 to the management plane, for distributed signaling 109 communications related to the control plane, and other 110 operations communications (e.g., order-wire/voice 111 communications, software downloads, etc.). 113 Equipment Management Function (EMF): the management functions 114 within an NE. See ITU-T G.7710 [2]. 116 Local Craft Terminal (LCT): An out-of-band device that connects 117 to an NE for management purposes. 119 Management Application Function (MAF): An application process 120 that participates in system management. See ITU-T G.7710 [2]. 122 Management Communication Channel (MCC): a CC dedicated for 123 management plane communications. 125 Message Communication Function (MCF): The communications process 126 that performs functions such as information interchange and 127 relay. See ITU-T M.3013 [10]. 129 Management Communication Network (MCN): A DCN supporting 130 management plane communication is referred to as a Management 131 Communication Network (MCN). 133 MPLS-TP NE: a network element (NE) that supports MPLS-TP 134 functions. 136 MPLS-TP network: a network in which MPLS-TP NEs are deployed. 138 Network Element Function (NEF): The set of functions necessary 139 to manage a network element. 141 Operations System (OS): A system that performs the functions 142 that support processing of information related to operations, 143 administration, maintenance, and provisioning (OAM&P) for the 144 networks, including surveillance and testing functions to 145 support customer access maintenance. 147 Signaling Communication Network (SCN): A DCN supporting control 148 plane communication is referred to as a Signaling Communication 149 Network (SCN). 151 Signaling Communication Channel (SCC): a CC dedicated for 152 control plane communications. The SCC may be used for GMPLS/ASON 153 signaling and/or other control plane messages (e.g., routing 154 messages). 156 2. Management Architecture Consideration 158 The management of the MPLS-TP network could be based on a multi- 159 tiered distributed management systems, for example as described 160 in ITU-T M.3010 [7] and M.3060 [8]. Each tier provides a 161 predefined level of network management capabilities. The lowest 162 tier of this organization model includes the MPLS-TP Network 163 Element that provides the transport service and the Operations 164 System (OS) at the Element Management Level. The management 165 application function within the NEs and OSs provides the 166 management support. The management application function at each 167 entity can include agents only, managers only, or both agents 168 and managers. The management application function that include 169 managers are capable of managing an agent included in other 170 management application functions. 172 The management communication to peer NEs and/or Operations 173 System (OSs) is provided via the message communication function 174 within each entity (e.g. NE and OS). The user can access the 175 management of the MPLS-TP transport network via a Local Craft 176 Terminal (LCT) attached to the NE or via a Work Station (WS) 177 attached to the OS. 179 2.1.Network Management Architecture 181 A transport Management Network (MN) MAY consist of several 182 transport technology specific Management Networks. Figure 1 183 below from G.7710 [2] shows an example of management network 184 partitioning. Notation used in G.7710 for a transport 185 technology specific MN is x.MN, where x is the transport 186 specific technology. In the example "O.MSN" is equivalent to an 187 optical management subnetwork, and "S.MSN" is equivalent to an 188 SDH management subnetwork. A MPLS-TP specific MN might be 189 abbreviated as MPLS-TP.MN. Where there is no ambiguity, we will 190 use "MN" for an MPLS-TP specific MN, and "MPLS-TP.MN" (or "MPLS- 191 TP MN") and "MN" where both are used in a given context. 193 ______________________________ ______________________________ 194 |.-------.-------.----.-------.||.-------.-------.----.-------.| 195 |: : : : :||: : : : :| 196 |:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:S.MSN-1:S.MSN-2: .. :S.MSN-n:| 197 |: : : : :||: : : : :| 198 '-============================-''-============================-' 199 _______________________________ 200 |.-------.-------.-----.-------.| 201 |: : : : :| 202 |:x.MSN-1:x.MSN-2: ... :x.MSN-n:| 203 |: : : : :| 204 '-=============================-' 205 Figure 1 Management Network Partitioning 207 The management of the MPLS-TP network is be separable from the 208 management of the other technology-specific networks, and 209 operate independently of any particular client or server layer 210 management plane. 212 A MPLS-TP Management Network could be partitioned into MPLS-TP 213 Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just 214 "MSN" where usage is unambiguous) for consideration of 215 scalability (e.g. geographic or load balancing) or 216 administrative (e.g. administrative or ownership). 218 The MPLS-TP MSN could be connected to other parts of the MN 219 through one or more LCTs and/or OSs. The message communication 220 function (MCF) of an MPLS-TP NE initiates/terminates, routes, or 221 otherwise processes management messages over CCs or via an 222 external interface. 224 Multiple addressable MPLS-TP NEs could be present at a single 225 physical location (i.e. site or office). The inter-site 226 communications link between the MPLS-TP NEs will normally be 227 provided by the CCs. Within a particular site, the NEs could 228 communicate via an intra-site CC or via a LAN. 230 2.2. Element Management Architecture 232 The Equipment Management Function (EMF) of a MPLS-TP NE provides 233 the means through which a management system manages the NE. 235 The EMF interacts with the NE's transport functions and control 236 functions (i.e., control plane functions that reside in the NE) 237 by exchanging Management Information (MI) across the Management 238 Point (MP) Reference Points. The EMF may contain a number of 239 functions that provide a data reduction mechanism on the 240 information received across the MP Reference Points. 242 The EMF includes functions such as Date & Time and the FCAPS 243 (Fault, Configuration, Accounting, Performance and Security) 244 management functions. The EMF provides event message 245 processing, data storage and logging. The management Agent, a 246 component of the EMF, converts internal management information 247 (MI signals) into Management Application messages and vice 248 versa. The Agent responds to Management Application messages 249 from the message communication function by performing the 250 appropriate operations on (for example) the Managed Objects in a 251 Management Information Base (MIB), as necessary. The message 252 communication function contains communications functions related 253 to the outside world of the NE (i.e. Date & Time source, 254 Management Plane, Control Plane, Local Craft Terminal and Local 255 Alarms). 257 The Date & Time functions keep track of the NE's date/time which 258 is used by the FCAPS management functions to e.g. time stamp 259 event reports. 261 Below are diagrams that illustrate the components of the element 262 management function of a network element. Figure 2 provides the 263 breakdown of the Network Element Function, then Figure 3 264 provides the details of Equipment Management Function, and 265 finally Figure 4 details the Message Communication Function. 267 ___________________________________________________ 268 | Network Element Function (NEF) | 269 | _________________________ _______________________ | 270 || Equipment Control || Transport Plane || 271 || Function || Atomic Function || 272 ||_________________________||_______________________|| 273 | | |___________| | | 274 | | Management Control Management | | 275 | | Information Information Information | | 276 | |__ ____________| | 277 | ____|____________________________|___ | 278 | | (from date/time)<-----------+ | 279 | | Equipment | | | 280 | | Management (to/from management)<--------+ | | 281 | | Function | | | | 282 | | (EMF) (to/from control)<-----+ | | | 283 | | | | | | | 284 | | (to local alarm)---+ | | | | 285 | |_____________________________________| | | | | | 286 | | | | | | 287 | +--------------------------------------+ | | | | 288 | | +---------------------------------------+ | | | 289 | | | +----------------------------------------+ | | 290 | | | | +-----------------------------------------+ | 291 | | | | | Date & Time _________________ |external 292 | | | | | Info | Message | |time 293 | | | | +-------------- Communication <----------------------- 294 | | | | | Function (MCF) | | 295 | | | | Management | | |management 296 | | | +----------------> | |element 297 | | | Plane Info | <----------------------> 298 | | | | | | 299 | | | Control Plane | | | 300 | | +------------------> | | 301 | | Information | | |control 302 | | | | |element 303 | | Local Alarm | <----------------------> 304 | +--------------------> | | 305 | Information | | |to local 306 | | | |alarms 307 | |_________________---------------------> 308 |____________________________________________________| 309 Figure 2 High-level decomposition of NEF 311 _______________________________________ 312 | ________________________ | 313 | Equipment | Management Application || 314 | Management | Function (MAF) || 315 | Function | _____ || 316 | (EMF) || | _______________|| 317 | ___________||___ | | || 318 | | | | | Date & Time || 319 | | Date & Time | | | Interface |<-- 1 320 | | Functions | | |_______________|| 321 | |________________| | _______________|| 322 | ___________||___ | | || 323 | | | | | Management || 324 | |Fault Management| | | Plane |<-> 2 325 | |________________| | | Interface || 326 | ___________||___ | |_______________|| 327 | | | | _______________ | 328 | | Configuration | | | || 329 | | Management | | | Control Plane || 330 | |________________| | | Interface |<-> 3 331 | ___________||___ | |_______________|| 332 | | | | | 333 | | Account | | | 334 | | Management | | | 335 | |________________| | | 336 | ___________||___ | | 337 | | | | | 338 | | Performance | | | 339 | | Management | | | 340 | |________________| | | 341 | ___________||___ | | 342 | | | | | 343 | | Security | | | 344 | | Management | | _______________ | 345 | |________________| | | || 346 | || | | Local Alarm || 347 | +----->|Agent| | Interface |--> 4 348 | v ||_____| |_______________|| 349 | .-===-. |_________________________| 350 | | MIB | | 351 | `-._.-' | 352 |_______________________________________| 353 Figure 3 Equipment Management Function 354 _________________ 355 | | 356 | Message | 357 | Communication | 358 | Function (MCF) | 359 | _______________ | 360 Date & Time || || external 361 1 <--------------| Date & Time <----------------- 362 Information || Communication || time source 363 ||_______________|| 364 | | 365 | _______________ | 366 Management || || management 367 Plane || Management || element 368 2 <---------------> Plane <---------------> 369 Information || Communication || (e.g. - EMS, 370 ||_______________|| peer NE) 371 | | 372 | _______________ | control 373 Control Plane || || element 374 3 <---------------> Control Plane <---------------> 375 Information || Communication || (e.g. - EMS, 376 ||_______________|| peer NE) 377 | : | 378 | : | 379 | : | 380 | _______________ | 381 Local Alarm || || to local 382 4 ----------------> Local Alarm |---------------> 383 Information || Communication || alarms... 384 ||_______________|| 385 |_________________| 386 Figure 4 Message Communication Function 388 2.3.Standard Management Interfaces 390 The MPLS-TP NM requirement document [1] places no restriction 391 on which management interface is to be used for managing an 392 MPLS-TP network. It is possible to provision and manage an 393 end-to-end connection across a network where some segments are 394 created/managed/deleted, for example by netconf/XML or snmp/smi 395 and other segments by CORBA/IDL interfaces. Use of any network 396 management interface for one management related purpose does 397 not preclude use of another network management interface for 398 other management related purposes, or the same purpose at 399 another time. However, an MPLS-TP NE is not expected to 400 actively support more than one management protocol in any given 401 deployment. The protocol to be supported is at the discretion 402 of the operator. 404 2.4. Management and Control specific terminology 406 Data Communication Network (DCN) is the common term for the network 407 used to transport Management and Signaling information between: 408 management systems and network elements, management systems to other 409 management systems, and networks elements to other network elements. 410 The Management Communications Network (MCN) is the part of the DCN 411 which supports the transport of Management information for the 412 Management Plane. The Signaling Communications Network (SCN) is the 413 part of the DCN which supports transport for signaling information 414 for the Control Plane. As shown in Figure 5 each technology has its 415 own terminology that is used for the channels that support management 416 and control plane information transfer. For MPLS-TP, the management 417 plane uses the Management Communication Channel (MCC) and the control 418 plane uses the Signaling Communication Channel (SCC). 420 2.5. Management Channel 422 The Communication Channel (CC) provides a logical channel 423 between NEs for transferring Management and/or Signaling 424 information. Note that some technologies provide separate 425 communication channels for Management (MCC) and Signaling (SCC). 427 . MPLS-TP NEs communicate via the DCN. The DCN connects NEs 428 with management systems, NEs with NEs, and management 429 systems with management systems. 431 Common Terminology |----| 432 /-> | NE |\ 433 |----------| |----------| / |----| \ |----| 434 | | <---> | | |(CC) | NE | 435 |----------| |----------| \ |----| / |----| 436 Management Operations \-> | NE |/ 437 Station System |----| 438 Network Elements use a 439 Communication Channel (CC) 440 for Transport of Management 441 Information 443 Management Terminology |----| 444 /-> | NE |\ 445 |----------| |----------| / |----| \ |----| 446 | | <---> | | |(MCC) | NE | 447 |----------| |----------| \ |----| / |----| 448 Management Operations \-> | NE |/ 449 Station System |----| 450 Network Elements use a 451 Management Communication 452 Channel (MCC) for Transport 453 of Management Information 455 Control Terminology |----| 456 /-> | NE |\ 457 |----------| |----------| / |----| \ |----| 458 | | <---> | | |(SCC) | NE | 459 |----------| |----------| \ |----| / |----| 460 Management Operations \-> | NE |/ 461 Station System |----| 462 Network Elements use a 463 Control/Signaling Communication 464 Channel (SCC) for Transport 465 of Signaling Information 467 Figure 5 Communication Channel Terminology 469 3. Fault Management Considerations 471 A fault is the inability of a function to perform a required action. 472 This does not include an inability due to preventive maintenance, 473 lack of external resources, or planned actions. Fault management 474 provides the mechanisms to detect, verify, isolate, notify, and 475 recover from the fault. 477 3.1. Supervision 479 G.7710 [2] lists five basic categories of supervision that provide 480 the functionality necessary to detect, verify, and notify a fault. 481 The categories are: Transmission Supervision, Quality of Service 482 Supervision, Processing Supervision, Hardware Supervision, and 483 Environment Supervision. Each of the categories provides a set of 484 recommendations to ensure the fault management process is fulfilled. 486 3.2. Validation 488 G.7710 [2] describes a fault cause as a limited interruption of the 489 required function. It is not reasonable for every fault cause to be 490 reported to maintenance personnel. The validation process is used to 491 turn fault causes (events) into failures (alarms). 493 3.3. Alarm Handling 495 Within an element management system, it is important to consider 496 mechanisms to support severity assignment, alarm reporting control, 497 and logging. 499 4. Configuration Management Considerations 501 Configuration management provides the mechanisms to provision the 502 MPLS-TP services, setup security for the MPLS-TP services and MPLS-TP 503 network elements, and provides the destination for fault 504 notifications and performance parameters. Inventory reporting is 505 also considered part of configuration management. 507 Associated with configuration management are hardware and software 508 provisioning and inventory reporting. 510 4.1. LSP ownership handover 512 MPLS-TP networks can be managed not only by Network Management 513 Systems (i.e. management plane), but also by control plane protocols. 515 The utilization of the control plane is not a mandatory requirement 516 (see MPLS-TP Requirements [4]) but it is often used by network 517 operators in order to make network configuration and LSP recovery 518 both faster and simpler. 520 In networks where both CP and MP are provided, an LSP could be 521 created by either (CP or MP). The entity creating an LSP owns the 522 data plane resources comprising that LSP. Only the owner of an LSP 523 is typically able modify/delete it. This results in a need for 524 interaction between the MP and CP to allow either to manage all the 525 resources of a network. 527 Network operators might prefer to have full control of the network 528 resources during the set-up phase and then allow the network to be 529 automatically maintained by the control plane. This can be achieved 530 by creating LSPs via the management plane and subsequently 531 transferring LSP ownership to the control plane. This is referred to 532 as "ownership handover" [9]. MP to CP ownership handover is then 533 considered a requirement [9] where a control plane is in use that 534 supports it. The converse (CP to MP ownership handover) is a feature 535 that is recommended - but not required - for (G)MPLS networks because 536 it has only minor applications (for example moving LSPs from one path 537 to another as a maintenance operation). 539 The LSP handover procedure has already been standardized for GMPLS 540 networks, where the signaling protocol used is RSVP-TE [5]. The 541 utilization of RSVP-TE enhancements are defined in [6]. 543 MP and CP interworking includes also the exchange of information that 544 is either requested by the MP, or a notification by the CP as a 545 consequence of a request from the MP or an automatic action (for 546 example a failure occurs or an operation is performed). The CP is 547 asked to notify the MP in a reliable manner about the status of the 548 operations it performs and to provide a mechanism to monitor the 549 status of control plane objects (e.g. TE Link status, available 550 resources), and to log control plane LSP related operations. Logging 551 is one of the most critical aspects because the MP always needs to 552 have an accurate history and status of each LSP and all data plane 553 resources involved in it. 555 5. Performance Management Considerations 557 Performance statistics can overwhelm a management network, so it is 558 important to provide flexible instrumentation that provides control 559 over the amount of performance data to be collected. A distinction 560 is made between performance data that is collected on-demand and data 561 that is collected proactively. On-demand measurement provides the 562 operator the ability to issue a command to initiate a measurement. 563 Proactive measurement is something that happens continuously over 564 time after being configured with a periodicity and storage 565 requirements. Data collected from proactive measurement are usually 566 used for verifying the performance of the LSP service, while data 567 collected from on-demand measurement are usually used for maintenance 568 purposes such as diagnose or to provide detailed verification of 569 proactive measurement. 571 6. Security Considerations 573 Provisions to any of the network mechanisms designed to satisfy 574 the requirements described herein are required to prevent their 575 unauthorized use. Likewise, these network mechanisms MUST 576 provide a means by which an operator can prevent denial of 577 service attacks if those network mechanisms are used in such an 578 attack. 580 Solutions MUST provide mechanisms to prevent private 581 information from being accessed by unauthorized eavesdropping, 582 or being directly obtained by an unauthenticated network 583 element, system or user. 585 Performance of diagnostic functions and path characterization 586 involves extracting a significant amount of information about 587 network construction that the network operator MAY consider 588 private. 590 7. IANA Considerations 592 There are no IANA actions associated with this document. 594 8. Acknowledgments 596 The authors/editors gratefully acknowledge the thoughtful review, 597 comments and explanations provided by Diego Caviglia and Bernd 598 Zeuner. 600 9. References 602 9.1. Normative References 604 [1] Lam, H.K., et al., "MPLS TP Network Management 605 Requirements", work in progress. 607 [2] ITU-T Recommendation G.7710/Y.1701, "Common equipment 608 management function requirements", July, 2007. 610 [3] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", RFC 2119, March 1997. 613 [4] Niven-Jenkins, B., et al., "MPLS-TP Requirements", work in 614 progress. 616 [5] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP 617 Tunnels", RFC 3209, December 2001. 619 [6] Caviglia, D., et al., "RSVP-TE Signaling Extension For The 620 Conversion Between Permanent Connections And Soft 621 Permanent Connections In A GMPLS Enabled Transport 622 Network", work in progress. 624 9.2.Informative References 626 [7] ITU-T Recommendation M.3010, "Principles for a 627 telecommunication management network", April 2005. 629 [8] ITU-T Recommendation M.3060/Y.2401, "Principles for the 630 Management of Next Generation Networks", March 2006. 632 [9] Caviglia, D., et al., "Requirements for the Conversion 633 between Permanent Connections and Switched Connections in 634 a Generalized Multiprotocol Label Switching (GMPLS) 635 Network", RFC 5493, April 2009. 637 [10] ITU-T Recommendation M.3013, "Considerations for a 638 telecommunications management network", February 2000. 640 10.Author's Addresses 642 Editors: 644 Scott Mansfield 645 Ericsson 646 5000 Ericsson Drive 647 Warrendale, PA, 15086 648 Phone: +1 724 742 6726 649 EMail: scott.mansfield@ericsson.com 651 Hing-Kam (Kam) Lam 652 Alcatel-Lucent 653 600-700 Mountain Ave 654 Murray Hill, NJ, 07974 655 Phone: +1 908 582 0672 656 Email: hklam@alcatel-lucent.com 657 Eric Gray 658 Ericsson 659 900 Chelmsford Street 660 Lowell, MA, 01851 661 Phone: +1 978 275 7470 662 Email: eric.gray@ericsson.com 664 Author(s): 666 Contributor(s):