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