idnits 2.17.1 draft-balus-sajassi-l2vpn-pbb-vpls-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4762], [IEEE802.1ah]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2009) is 5528 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1ad' is defined on line 531, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Working Group F. Balus (editor) 2 Internet Draft M. Bocci 3 Intended Status: Proposed Standard M. Aissaoui 4 Expires: September 2009 Alcatel-Lucent 6 John Hoffmans Ali Sajassi (editor) 7 KPN Cisco 9 Geraldine Calvignac Nabil Bitar (editor) 10 France Telecom Verizon 12 Olen Stokes Raymond Zhang 13 Extreme Networks British Telecom 15 March 9, 2009 17 Extensions to VPLS PE model for Provider Backbone Bridging 18 draft-balus-sajassi-l2vpn-pbb-vpls-01.txt 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on September 9, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone 57 Bridges (PBB) defines an architecture and bridge protocols for 58 interconnection of multiple Provider Bridge Networks (PBNs). PBB was 59 defined in IEEE as a connectionless technology based on multipoint 60 VLAN tunnels. MSTP is used as the core control plane for loop 61 avoidance and load balancing. As a result, the coverage of the 62 solution is limited by STP scale in the core of large service 63 provider networks. PBB on the other hand can be used to attain better 64 scalability in terms of number of customer MAC addresses and number 65 of service instances that can be supported. 67 Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for 68 extending Ethernet LAN services, using MPLS tunneling capabilities, 69 through a routed MPLS backbone without running (M)STP across the 70 backbone. As a result, VPLS has been deployed on a large scale in 71 service provider networks. 73 This draft discusses extensions to the VPLS PE model required to 74 incorporate desirable PBB components while maintaining the Service 75 Provider fit of the initial model. 77 Table of Contents 79 1. Introduction...................................................3 80 2. General terminology............................................4 81 2.1. Conventions used in this document.........................5 82 3. PE Reference Model.............................................5 83 4. Packet Walkthrough.............................................8 84 5. Control Plane.................................................10 85 6. Efficient Packet replication in PBB VPLS......................11 86 7. PBB VPLS OAM..................................................11 87 8. Security Considerations.......................................11 88 9. IANA Considerations...........................................11 89 10. References...................................................11 90 10.1. Normative References....................................11 91 10.2. Informative References..................................12 92 11. Acknowledgments..............................................12 94 1. Introduction 96 IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone 97 Bridges (PBB) defines an architecture and bridge protocols for 98 interconnection of multiple Provider Bridge Networks (PBNs). PBB 99 provides data plane hierarchy and new addressing designed to improve 100 the scalability of MAC addresses and service instances in Provider 101 Backbone Networks. MSTP is still used as the core control plane for 102 loop avoidance and load balancing. As a result, the coverage of the 103 solution is limited by STP scale in the core of large service 104 provider networks. 106 Virtual Private LAN Service (VPLS) provides a solution for extending 107 Ethernet LAN services, using MPLS tunneling capabilities, through a 108 routed MPLS backbone without requiring the use of (M)STP across the 109 backbone. VPLS use of the structured FEC 129 [RFC4762] also allows 110 for inter-domain, inter-provider connectivity and enables auto- 111 discovery options across the network improving the service delivery 112 options. 114 A hierarchical solution for VPLS was introduced in [RFC4762] for the 115 purpose of improved scalability and to provide efficient handling of 116 packet replication. These improvements are achieved by reducing the 117 number of PE devices connected in a full-mesh topology through the 118 creation of two-tier PEs. A U-PE aggregates all the CE devices in a 119 lower-tier access network and then connects to the N-PE device(s) 120 deployed around the core domain. In VPLS, MAC address learning and 121 forwarding are done based on customer MAC addresses (C-MACs), which 122 poses scalability issues on the N-PE devices as the number of VPLS 123 instances (and thus customer MAC addresses) increases. Furthermore, 124 since a set of PWs is maintained on a per customer service instance 125 basis, the number of PWs required at N-PE devices is proportional to 126 the number of customer service instances multiplied by the number of 127 N-PE devices in the full-mesh set. This can result in scalability 128 issues (in terms of PW manageability and troubleshooting) as the 129 number of customer service instances grows. 131 This document describes how PBB can be integrated with VPLS to allow 132 for useful PBB capabilities while continuing to avoid the use of MSTP 133 in the backbone. The combined solution referred in this document as 134 PBB-VPLS results in better scalability in terms of number of service 135 instances, PWs and C-MACs that need to be handled in the VPLS PEs. 137 Section 2 gives a quick terminology reference. Section 3 covers the 138 reference model for PBB VPLS PE. Section 4 describes the packet 139 walkthrough. Section 5 to 7 discusses the PBB-VPLS usage of existing 140 VPLS mechanisms - control plane, efficient packet replication, OAM). 142 2. General terminology 144 Some general terminology is defined here; most of the terminology 145 used is from [IEEE802.1ah], [RFC4762] and [RFC4026]. Terminology 146 specific to this memo is introduced as needed in later sections. 148 802.1ad: IEEE specification for "QinQ" encapsulation and bridging of 149 Ethernet frames 151 802.1ah: IEEE specification for "MAC tunneling" encapsulation and 152 bridging of frames across a provider backbone bridged network. 154 B-BEB: A backbone edge bridge positioned at the edge of a provider 155 backbone bridged network. It contains a B-component that supports 156 bridging in the provider backbone based on B-MAC and B-TAG 157 information 159 B-MAC: The backbone source or destination MAC address fields defined 160 in the 802.1ah provider MAC encapsulation header. 162 BEB: A backbone edge bridge positioned at the edge of a provider 163 backbone bridged network. It can contain an I-component, B-component 164 or both I and B components. 166 B-TAG: field defined in the 802.1ah provider MAC encapsulation 167 header that conveys the backbone VLAN identifier information. The 168 format of the B-TAG field is the same as that of an 802.1ad S-TAG 169 field. 171 B-Tagged Service Interface: This is the interface between a BEB and 172 BCB in a provider backbone bridged network. Frames passed through 173 this interface contain a B-TAG field. 175 B-VID: The specific VLAN identifier carried inside a B-TAG 177 I-component: A bridging component contained in a backbone edge bridge 178 that bridges in the customer space (customer MAC addresses, S-VLAN) 180 IB-BEB: A backbone edge bridge positioned at the edge of a provider 181 backbone bridged network. It contains an I-component for bridging in 182 the customer space (customer MAC addresses, service VLAN IDs) and a 183 B-component for bridging the provider's backbone space (B-MAC, B- 184 TAG). 186 I-BEB: A backbone edge bridged positioned at the edge of a provider 187 backbone bridged network. It contains an I-component for bridging in 188 the customer space (customer MAC addresses, service VLAN IDs). 190 I-SID: The 24-bit service instance field carried inside the I-TAG. I- 191 SID defines the service instance that the frame should be "mapped 192 to". 194 I-TAG: A field defined in the 802.1ah provider MAC encapsulation 195 header that conveys the service instance information (I-SID) 196 associated with the frame. 198 I-Tagged Service Interface: This the interface defined between the I 199 and B components inside an IB-BEB or between two B-BEB. Frames passed 200 through this interface contain an I-TAG field 202 PBB: Provider Backbone Bridge 204 PBBN: Provider Backbone Bridged Network 206 PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ) 207 technology. 209 S-TAG: A field defined in the 802.1ad QinQ encapsulation header that 210 conveys the service VLAN identifier information (S-VLAN). 212 S-Tagged Service Interface: This the interface defined between the 213 customer (CE) and the I-BEB or IB-BEB components. Frames passed 214 through this interface contain an S-TAG field. 216 S-VLAN: The specific service VLAN identifier carried inside an S-TAG 218 2.1. Conventions used in this document 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC-2119. 224 3. PE Reference Model 226 The following gives a short primer on PBB before describing the PE 227 reference model for PBB-VPLS. The internal components of a PBB bridge 228 module are depicted in Figure 1. 230 +-------------------------------+ 231 | 802.1ah Bridge Model | 232 | | 233 +---+ | +------+ +-----------+ | 234 |CE |---------|I-Comp|------| | | 235 +---+ | | | | |-------- 236 | +------+ | | | 237 | o | B-Comp | | 238 | o | |-------- 239 | o | | | 240 +---+ | +------+ | | | 241 |CE |---------|I-Comp|------| |-------- 242 +---+ ^ | | | ^ | | | ^ 243 | | +------+ | +-----------+ | | 244 | +------------|------------------+ | 245 | | | 246 | | | 247 S-tagged I-tagged B-tagged 248 Service I/F Service I/F Service I/F 250 Figure 1: PBB Bridge Model 252 Provider Backbone Bridges (PBBs) [IEEE 802.1ah] offers a scalable 253 solution for service providers to build large bridged networks. The 254 focus of PBB is primarily on improving two main areas with provider 255 Ethernet bridged networks: 257 - MAC-address table scalability 258 - Service instance scalability 260 To obviate the above two limitations, PBB introduces a hierarchical 261 network architecture with associated new frame formats which extend 262 the work completed by Provider Bridges (IEEE 802.1ad). In the PBBN 263 architecture, customer networks (using IEEE 802.1Q or 802.1ad 264 bridging) are aggregated into Provider Backbone Bridge Networks 265 (PBBNs) which utilize the IEEE 802.1ah frame format. The frame 266 format employs a MAC tunneling encapsulation scheme for tunneling 267 customer Ethernet frames within provider Ethernet frames across the 268 PBBN. A VLAN identifier (B-VID) is used to segregate the backbone 269 into broadcast domains and a new 24-bit service identifier (I-SID) 270 is defined and used to associate a given customer MAC frame with a 271 provider service instance (also called the service delimiter). It 272 should be noted that in [802.1ah] there is a clear segregation 273 between provider service instances (represented by I-SIDs) and 274 provider VLANs (represented by B-VIDs) which was not the case for 275 802.1ad. 277 As shown in the figure 1, a PBB bridge may consist of a single B- 278 component and one or more I-components. In simple terms, the B- 279 component provides bridging in provider space (B-MAC, B-VLAN) and the 280 I-component provides bridging in customer space (C-MAC, S-VLAN). The 281 customer frame is first encapsulated with the provider backbone 282 header (B-MAC, B-tag, I-tag); then, the bridging is performed in the 283 provider backbone space (B-MAC, B-VLAN) through the network till the 284 frame arrives at the destination BEB where it gets de-encapsulated 285 and passed to the CE. If a PBB bridge consists of both I & B 286 components, then it is called IB-BEB and if it only consists of 287 either B-component or I-component, then it is called B-BEB or I-BEB 288 respectively. The interface between an I-BEB or IB-BEB and a CE is 289 called S-tagged service interface and the interface between an I-BEB 290 and a B-BEB (or between two B-BEBs) is called I-tagged service 291 interface. The interface between a B-BEB or IB-BEB and a Backbone 292 Core Bridge (BCB) is called B-Tagged service interface. 294 To accommodate the PBB components the VPLS model defined in [RFC4664] 295 is extended as depicted in figure 1. 297 +----------------------------------------+ 298 | PBB-VPLS-capable PE model | 299 | +---------------+ +------+ | 300 | | | |VPLS-1|------------ 301 | | |==========|Fwdr |------------ PWs 302 +--+ | | Bridge ------------ |------------ 303 |CE|-|-- | | +------+ | 304 +--+ | | Module | o | 305 | | | o | 306 | | (802.1ah | o | 307 | | bridge) | o | 308 | | | o | 309 +--+ | | | +------+ | 310 |CE|-|-- | ------------VPLS-n|------------- 311 +--+ | | |==========| Fwdr |------------- PWs 312 | | | ^ | |------------- 313 | +---------------+ | +------+ | 314 | | | 315 +-------------------------|--------------+ 316 LAN emulation Interface 318 Figure 2: PBB-VPLS capable PE Model 320 The PBB Module as defined in [IEEE802.1ah] specification is expanded 321 to interact with VPLS Forwarders. The VPLS Forwarders are used in 322 [RFC4762] to build a PW mesh or a set of spoke-PWs (HVPLS 323 topologies). The VPLS instances are represented externally in the 324 MPLS context by a L2FEC which binds related VPLS instances together. 325 VPLS Signaling advertises the mapping between the L2FEC and the PW 326 labels and implicitly associates the VPLS bridging instance to the 327 VPLS Forwarders [RFC4762]. 329 In the PBB-VPLS case the backbone service instance in the B-component 330 space(B-VID) is represented in the backbone MPLS network using a VPLS 331 instance. Same as for the regular VPLS case, existing signaling 332 procedures are used to generate through PW labels the linkage between 333 VPLS Forwarders and the backbone service instance. 335 Similarly with the regular HVPLS, another L2FEC may be used to 336 identify the customer service instance in the I-component space. This 337 will be useful for example to address the PBB-VPLS N-PE case where 338 HVPLS spokes are connecting the PBB-VPLS N-PE to a VPLS U-PE [PBB- 339 Interop]. 341 It is important to note that the PBB-VPLS solution inherits the PBB 342 service aggregation capability where multiple customer service 343 instances may be mapped to a backbone service instance. In the PBB- 344 VPLS case this means multiple customer VPNs can be transported using 345 a single VPLS instance corresponding to the backbone service 346 instance, thus reducing substantially resource consumption in the 347 VPLS core. 349 4. Packet Walkthrough 351 Since PBB bridge module inherently performs forwarding, the PE 352 reference model of Figure 2 can be expanded as the one shown in 353 Figure 3. 355 Furthermore, the B-component is connected via several virtual 356 interfaces to the PW Forwarder module. The function of PW Forwarder 357 is defined in [RFC3985]. In this context, the PW Forwarder simply 358 performs the mapping of the PWs to the Virtual Interface on the B- 359 component without the need for any MAC lookup. 361 This simplified model takes full advantage of PBB bridge module where 362 all the [IEEE 802.1ah] procedures including the C-MAC/B-MAC 363 forwarding and PBB encapsulation/decapsulation takes place and thus 364 avoids specifying any of these functions in here. 366 Because of text-based graphics, the Figure 3 only shows PWs on the 367 core-facing side; however, in case of MPLS access with spoke PWs, the 368 PE reference model is simply extended to include the same PW 369 Forwarder function on the access-facing side. To avoid cluttering the 370 figure, the access-side PW Forwarder is not depicted without loss of 371 any generality. 373 +------------------------------------------------+ 374 | PBB-VPLS-capable PE model | 375 | +---------------+ +------+ | 376 | | | | | | 377 | +------+ | ======== --------- 378 +--+ | | | | | | --------- PWs 379 |CE|-|-- | I- ==== ======== PW --------- 380 +--+ | | comp | | | | Fwdr | 381 | +------+ | | | --------- PWs 382 | | B-Comp ======== --------- 383 | | | ^ | | | 384 | +------+ | | | +------+ | 385 +--+ | | I- | | OOOOOOOOOOOOOOOOOOOOOOOO B-tag 386 |CE|-|-- | comp ==== | | | I/Fs 387 +--+ | | |^ | OOOOOOOOOOOOOOOOOOOOOOOO 388 | +------+| | | | | 389 | | +---------------+ | | 390 | | | | 391 +-----------|--------------------|---------------+ 392 | | 393 Internal I-tag I/Fs Virtual I/Fs 395 +----------+ +------------+ 396 |CMAC DA,SA| | PSN header | 397 |----------| |------------| 398 |SVID, CVID| | PW Label | 399 |----------| |------------| 400 | Payload | | BMAC DA,SA | 401 +----------+ |------------| 402 | PBB I-tag | 403 |------------| 404 | CMAC DA,SA | 405 |------------| 406 | SVID, CVID | 407 |------------| 408 | Payload | 409 +------------+ 411 Figure 3: Packet Walkthrough for PBB VPLS PE 413 In order to better understand the data plane walkthrough let us 414 consider the example of a PBB packet arriving over a B-PW. The PSN 415 header is used to carry the PBB encapsulated frame over the backbone 416 while the PW Label will point to the related Backbone Service 417 Instance (B-SI), same as for regular VPLS. The PW Label has in this 418 case an equivalent role with the Backbone VLAN id on the PBB B-tagged 419 interface. 421 An example of the PBB packet for regular Ethernet PW is depicted in 422 Figure 3 on the right hand side. The MPLS packet from MPLS core 423 network is received by the PBB-VPLS PE. The PW Forwarder function of 424 the PE uses PW label to derive the virtual interface-id on the B- 425 component and then after removing the PSN and PW encapsulation, it 426 passes the packet to the B-component. From there on, the processing 427 and forwarding is performed according to the [IEEE 802.1ah] where 428 bridging based on B-MAC DA is performed which result in one of the 429 three outcomes: 431 1. The packet is forwarded to a physical interface on the B- 432 component. In this case, the 802.1ah Ethernet frame is forwarded 433 as is. 435 2. The packet is forwarded to a virtual interface on the B- 436 component. This is not typically the case because of a single 437 split-horizon group within a VPLS instance; however, if there is 438 more than one split-horizon group, then such forwarding takes 439 place. In this case, the PW Forwarder module adds the PSN and PW 440 labels before sending the packet out. 442 3. The packet is forwarded toward the access side via one of the I- 443 tagged-service interfaces connected to the corresponding I- 444 components. In this scenario, the I-component removes the B-MAC 445 header according to [IEEE 802.1ah] and bridges the packet using 446 C-MAC DA. 448 4. If the destination B-MAC is an unknown or the Group MAC address 449 (Multicast or Broadcast), then the B-components floods the 450 packet to one or more of the three destinations described above. 452 5. Control Plane 454 The existing control plane procedures described in [L2VPN-Sig] and 455 [RFC4762] can be re-used in a PBB-VPLS to setup the PW infrastructure 456 in the service provider and/or customer bridging space. This allows 457 porting the existing control plane procedures (e.g. BGP-AD, PW setup, 458 VPLS MAC Flush, PW OAM) for each domain. 460 6. Efficient Packet replication in PBB VPLS 462 The PBB VPLS architecture takes advantage of the existing VPLS 463 features addressing packet replication efficiency. HVPLS hierarchy 464 may be used in both customer and backbone service instances to reduce 465 the redundant distribution of packets over the core. IGMP and PIM 466 snooping may be applied on a per customer service instance to control 467 the distribution of the Multicast traffic to non-member sites. 469 [IEEE802.1ah] specifies also the use of MMRP protocol [IEEE802.1ak] 470 for flood containment in the backbone instances. The same solution 471 can be ported in the PBB-VPLS solution. 473 Further optimizations of the packet replication in PBB-VPLS are out 474 of the scope of this draft. 476 7. PBB VPLS OAM 478 The existing VPLS, PW and MPLS OAM procedures may be used in each 479 customer or backbone service instance to verify the status of the 480 related connectivity components. 482 PBB OAM procedures make use of the IEEE 802.1ag and Y.1731 tools. 483 [IEEE 802.1ah] specifies their usage in both I-component and B- 484 component. 486 Both set of tools (PBB and VPLS) may be used for the combined PBB- 487 VPLS solution. 489 8. Security Considerations 491 No new security issues are introduced beyond those that are described 492 in [RFC4762]. 494 9. IANA Considerations 496 IANA does not need to take any action for this draft. 498 10. References 500 10.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private 506 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 507 Signaling", RFC 4762, January 2007. 509 [L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and 510 Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt, 511 May 2006 ( work in progress ) 513 10.2. Informative References 515 [RFC3985] Bryant, S. and Pate, P. (Editors)," Pseudo Wire Emulation 516 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 518 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 519 2 Virtual Private 521 [IEEE802.1ah] IEEE 802.1ah "Virtual Bridged Local Area Networks, 522 Amendment 6: Provider Backbone Bridges", Approved Standard 523 June 12th, 2008 525 Networks (L2VPNs)", RFC 4664, September 2006. 527 [IEEE802.1ak] IEEE Draft P802.1ak/D8.0 "Virtual Bridged Local Area 528 Networks, Amendment 7: Multiple Registration Protocol", 529 Work in Progress, November 29, 2006 531 [IEEE802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area 532 Networks, Amendment 4: Provider Bridges", December 7, 2005 534 [RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private 535 Network (VPN) Terminology", RFC 4026, March 2005. 537 11. Acknowledgments 539 The authors would like to thank Wim Henderickx, Dimitri 540 Papadimitriou, Dutta Pranjal, Jorge Rabadan and Maarten Vissers for 541 their insightful comments and probing questions. 543 Authors' Addresses 545 Ali Sajassi 546 Cisco 547 170 West Tasman Drive 548 San Jose, CA 95134, U.S. 549 Email: sajassi@cisco.com 551 Nabil Bitar 552 Verizon 553 40 Sylvan Road 554 Waltham, MA 02145 555 Email: nabil.bitar@verizon.com 557 Florin Balus 558 Alcatel-Lucent 559 701 E. Middlefield Road 560 Mountain View, CA, USA 94043 561 Email: florin.balus@alcatel-lucent.com 563 Mustapha Aissaoui 564 Alcatel-Lucent 565 600 March Road 566 Kanata, ON 567 Canada 568 e-mail: mustapha.aissaoui@alcatel-lucent.com 570 Matthew Bocci 571 Alcatel-Lucent, 572 Voyager Place 573 Shoppenhangers Road 574 Maidenhead 575 Berks, UK 576 e-mail: matthew.bocci@alcatel-lucent.co.uk 578 Raymond Zhang 579 BT 580 2160 E. Grand Ave. 581 El Segundo, CA 900245 USA 582 EMail: raymond.zhang@bt.com 584 Geraldine Calvignac 585 France Telecom 586 2, avenue Pierre-Marzin 587 22307 Lannion Cedex 588 France 589 Email: geraldine.calvignac@orange-ftgroup.com 590 John Hoffmans 591 KPN 592 Regulusweg 1 593 2516 AC Den Haag 594 Nederland 595 Email: john.hoffmans@kpn.com 597 Olen Stokes 598 Extreme Networks 599 PO Box 14129 600 RTP, NC 27709 601 USA 602 Email: ostokes@extremenetworks.com