Internet Working Group Ali Sajassi Internet Draft Samer Salam Intended Status: Standards Luyuan Fang Cisco Nabil Bitar Verizon Dinesh Mohan Nortel Raymond Zhang British Telecom Expires: January 2009 July 2008 Customer MAC Address Flushing Mechanisms for Provider Backbone Bridging over VPLS draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge Sajassi, et. al. [Page 1] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 (PBB) functionality in VPLS access. PBB introduces the notion of Backbone MAC (B-MAC) addresses vs. Customer MAC (C-MAC) addresses, thereby leading to the requirement for having MAC address flushing mechanisms for each. This document discusses a C-MAC address flushing notification mechanism to be used in VPLS networks that employ PBB technology. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 Table of Contents 1. Introduction....................................................2 2. Terminology.....................................................3 3. C-MAC vs. B-MAC Address Flushing in PBB Networks................4 4. C-MAC Address Flushing Mechanisms for H-VPLS with PBB Components6 4.1. H-VPLS with PBBN Access.......................................7 4.2. H-VPLS with MPLS Access: PBB U-PE.............................8 4.3. H-VPLS with MPLS Access: PBB N-PE.............................9 5. Message Format..................................................9 6. Advantages of Mechanism........................................11 7. Security Considerations........................................12 8. IANA Considerations............................................12 9. Intellectual Property Considerations...........................12 10. Full Copyright Statement......................................12 11. IPR Notice....................................................12 12. Normative References..........................................13 13. Informative References........................................13 14. Authors' Addresses............................................14 1. Introduction [P802.1ah] introduces a hierarchical network architecture where customer MAC frames are encapsulated in "backbone" MAC frames before being forwarded in the Provider Backbone Bridged Network (PBBN). Customer MAC address (C-MAC) learning is performed only at the edge of the PBBN (by I-Components) whereas all forwarding and learning in the core of the network is performed on Backbone MAC addresses (B- MACs). This gives rise to two independent MAC address spaces: the C- MAC address space and the B-MAC address space. Consequently, MAC Sajassi, et al. [Page 2] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 address flushing mechanisms are required for each address space, independently. [VPLS-PBB] analyzes the interoperability of Provider Backbone Bridge (PBB) technology with VPLS. It also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS with existing MPLS access or IEEE 802.1ad (aka Q-in-Q) Ethernet access and interoperability among them. This document discusses the C-MAC address flushing notification mechanism for VPLS networks that employ PBB technology, for both H- VPLS with native PBBN access and H-VPLS with MPLS access. Section 2 provides a summary of the terminology used throughout the document. Section 3 discusses the difference between C-MAC address and B-MAC address flushing in the context of PBB technology. Section 4 depicts the C-MAC address flushing mechanisms for three representative network use-case scenarios. Then, section 5 captures the message formats. Finally, section 6 summarizes the advantages of the solution. 2. Terminology 802.1ad: IEEE specification for "Q-in-Q" encapsulation and bridging of Ethernet frames. 802.1ah: IEEE specification for "MAC tunneling" encapsulation and bridging of frames across a provider backbone bridged network. B-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains a B-component that supports bridging in the provider backbone based on B-MAC and B-TAG information. B-MAC: The backbone source and destination MAC address fields defined in the 802.1ah provider MAC encapsulation header. BCB: A backbone core bridge running in the core of a provider backbone bridged network. It bridges frames based on B-TAG information just as an 802.1ad provider bridge will bridge frames based on a VLAN identifier (S-VLAN) BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It can contain an I-component, B-component or both I and B components. B-TAG: field defined in the 802.1ah provider MAC encapsulation header that conveys the backbone VLAN identifier information. The format of the B-TAG field is the same as that of an 802.1ad S-TAG field. Sajassi, et al. [Page 3] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 B-VID: The specific VLAN identifier carried inside a B-TAG C-MAC: Customer source or destination address used in a customer MAC frame. I-Component: A bridging component contained in a backbone edge bridge that bridges in the customer space (customer MAC addresses, S-VLAN) IB-BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs) and a B-component for bridging the provider's backbone space (B-MAC, B- TAG). I-BEB: A backbone edge bridged positioned at the edge of a provider backbone bridged network. It contains an I-component for bridging in the customer space (customer MAC addresses, service VLAN IDs). I-SID: The 24-bit service instance field carried inside the I-TAG. The I-SID defines the service instance that the frame should be "mapped to". I-TAG: A field defined in the 802.1ah provider MAC encapsulation header that conveys the service instance information (I-SID) associated with the frame. PBB: Provider Backbone Bridge PBBN: Provider Backbone Bridged Network S-TAG: A field defined in the 802.1ad QinQ encapsulation header that conveys the service VLAN identifier information (S-VLAN). S-VLAN: The specific service VLAN identifier carried inside an S-TAG 3. C-MAC vs. B-MAC Address Flushing in PBB Networks In PBB networks, C-MAC address learning is confined to the edge of the network, and performed on Backbone Edge Bridges that host an I- Component (i.e. I-BEBs and IB-BEBs) only. The I-Component builds a mapping of C-MAC addresses to B-MAC addresses based on traffic received from the PBB core. The core of the network forwards and learns based only on B-MAC addresses; thus, it is completely transparent to C-MAC addresses. Any topology change in the customer's network, or its connection(s) to the PBB network, that results in the reachability of a given C- MAC address moving from one I-Component to another I-Component should trigger a C-MAC address flush notification for the affected Sajassi, et al. [Page 4] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 service (I-SID). This is required to prevent potential traffic black-holing due to a remote I-Component maintaining a stale C-MAC to B-MAC address association. Such notification is only of interest to remote bridges that host an I-Component for the service in question (i.e. I-BEBs or IB-BEBs), but it is not of any value to Backbone Core Bridges (BCBs). Furthermore, as long as the C-MAC address flushing notification signals a topology change for a single I-SID, it can be made completely transparent to B-BEBs as well. This limits the scope of devices that need to transmit and/or handle C- MAC address flushing notifications to the edge of the PBB network, and more precisely only to Backbone Edge Bridges with an I-Component function (I-BEBs and IB-BEBs). This is shown as "Zone C" in Figure 1 below. On the other hand, topology changes within the PBB network, which result in the reach-ability of a given B-MAC address moving from one port to another, should trigger a B-MAC address flushing notification. This is of interest only to devices that learn and forward based on B-MAC addresses. Hence, B-MAC address flushing notifications can be confined to devices that implement BCB or B- Component (IB-BEB or B-BEB) functions in the PBB or the MPLS network. This is depicted as "Zone B" in Figure 1. I-Components are completely transparent to B-MAC address flushing mechanisms. C-MAC Flushing Scope --+ | +-------------------------------------|------------------+ | Zone C V | | +----------------------------------------+ | | | +----------------------------------+ | | | | | | | | | +---+ | | +---+ +---+ +---+ +---+ | | +---+ | | |I- | | | |B- | |BCB| |BCB| |B- | | | |I- | | | |BEB|-------|BEB|---| |----| |---|BEB|-------|BEB| | | +---+ | | +---+ +---+\ /+---+ +---+ | | +---+ | | | | \/ | | | | +---+ | | +---+ +---+ /\ +---+ +---+ | | +---+ | | |I- | | | |B- | |BCB|/ \|BCB| |B- | | | |I- | | | |BEB|-------|BEB|---| |----| |---|BEB|-------|BEB| | | +---+ | | +---+ +---+ +---+ +---+ | | +---+ | | | | | | | | | | +------+ | | +------+ | | | IB- | | | | IB- | | | | BEB |---------+ +----------| BEB | | | +------+ +------+ | | | | Zone B ^ | | | +-------+ +-------------------------|--------+ +-------+ | Sajassi, et al. [Page 5] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 B-MAC Flushing Scope --+ Figure 1: C-MAC and B-MAC Address Flushing Scope in PBB Networks It is worth noting that devices which implement IB-BEB functions will have to participate in both C-MAC as well as B-MAC address flushing mechanisms because the subtended I-Component operates on C- MAC addresses whereas the subtended B-Component operates on B-MAC addresses. This is the reason why IB-BEBs are shown to be part of both Zones B and C in Figure 1 above. For H-VPLS with PBB technology, including MPLS access and PBBN access, both B-MAC address as well as C-MAC address flushing notification mechanisms are required. In this context, B-MAC address flushing notification can be accomplished via the use of LDP Address Withdraw Message, as described in [RFC4762]. This is independent of C-MAC flushing mechanisms, and as such, is considered outside the scope of this document. Having established the differentiation between C-MAC address and B- MAC address flushing in this section, we will now sharpen our focus in the next section on C-MAC address flushing mechanisms for H-VPLS with PBB technology. 4. C-MAC Address Flushing Mechanisms for H-VPLS with PBB Components As discussed in the previous section, C-MAC address flushing notification need only be generated or processed by devices that employ an I-Component function. Given that these devices are confined to the edge of the PBB or the MPLS network, it is possible to tunnel C-MAC address flushing messages transparently through the PBB core bridges or N-PE devices without any loss of functionality. As a matter of fact, this is indeed the preferred behavior for the following reasons: i) Devices operating on B-MAC addresses do not care about C-MAC address flushing notification messages, and need not process them. Actually having these devices process the C-MAC address flush messages as control traffic places unnecessary burden on the processors of these network nodes. i i) Passing C-MAC address flushing notifications as regular data frames (as opposed to control frames) within the PBB core speeds up convergence, primarily because the forwarding can be performed in the hardware that takes care of data traffic switching. Given the above, an in-band MAC address flushing notification mechanism, that is native to the Ethernet layer, proves better suited for C-MAC address flushing than an out-of-band mechanism. The Sajassi, et al. [Page 6] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 C-MAC address flush notification message should be generated by the device which hosts an I-Component that detects the topology change. The message is encapsulated in a PBB frame that is tunneled as regular data through the PBB core. The message must be flooded to all edge devices that host an I-Component for the service experiencing the topology change. These devices should remove the PBB encapsulation from the frame and process the encapsulated C-MAC address flush notification message. The processing involves flushing the C-MAC address table entries for the affected service (I-SID). In the following subsections, we demonstrate how the C-MAC address flushing notification mechanism works in three representative network architectures: section 4.1 focuses on H-VPLS with native Ethernet PBBN access; whereas, sections 4.2 and 4.3 describe H-VPLS with MPLS access and with PBB functions on the U-PE and N-PE, respectively. 4.1. H-VPLS with PBBN Access Consider the network architecture of Figure 2 where native Ethernet PBB aggregation networks are connected over a VPLS core. The CE connected to the aggregation network on the left is dual-homed to two PBB backbone edge bridges (IB-BEB1 and IB-BEB2). Assume that initially the link to IB-BEB1 was the active CE uplink. If this link fails, the CE will failover to the uplink connected to IB-BEB2 and the latter will detect the topology change by virtue of the redundancy mechanism running between the CE and the IB-BEB. The details of this redundancy mechanism are outside the scope of this document. The key point here is that the detection of the topology change on IB-BEB2 will trigger that device to transmit C-MAC address flushing notification messages for the affected services (I-SIDs). A single C-MAC address flushing notification message should be generated per I-SID. The message is encapsulated with the PBB header, and is flooded to all other IB-BEBs that participate in the affected I-SID, by using the multicast "Backbone Service Instance Group Address" for that I-SID, as defined in [P802.1ah] section 26.4. The C-MAC flush notification message will be forwarded transparently, like a regular data frame, by the bridges in the core of the PBBN aggregation networks as well as by the VPLS PEs. When a remote IB-BEB (e.g. IB-BEB3 and IB-BEB4), which participates in the I-SID in question, receives the C-MAC flushing notification message, it would process the frame by flushing the corresponding C-MAC address table for the affected service (I-SID). Sajassi, et al. [Page 7] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 +----------+ +----+ | | +----+ -|IB- |-------+ | IP/MPLS | +-------|IB- | +--+ / |BEB1| | +----+ +----+ | |BEB3|--|CE| +--+ +----+ PBBN | |VPLS| |VPLS| | PBBN +----+ +--+ |CE| | 802.1ah|---| PE | | PE |--| 802.1ah | +--+ +----+ | +----+ +----+ | +----+ +--+ \ |IB- | | | Backbone | | |IB- |--|CE| -|BEB2|-------+ +----------+ +-------|BEB4| +--+ +----+ +----+ Figure 2: H-VPLS with PBBN Access 4.2. H-VPLS with MPLS Access: PBB U-PE In this architecture, MPLS access networks are connected over a VPLS core, and PBB Backbone Edge Bridge functionality is embedded into the U-PEs. Refer to Figure 3 below for an example. The CE in the left access network is dual-homed to two U-PEs (U-PE1 and U-PE2). A redundancy mechanism, the details of which are beyond the scope of this document, determines that the CE uplink to U-PE1 is active initially. A failure, e.g. of this uplink, triggers the redundancy mechanism to activate the CE uplink to U-PE2 and to notify the latter of the topology change. U-PE2 reacts to this notification by transmitting C-MAC address flushing notification messages, similar to what was described in Section 4.1. The C-MAC address flushing notification message is forwarded by U-PE2 towards the N-PE, which transparently floods the message over the full-mesh of pseudowires in the VPLS core (for the VSI in question). Remote N-PEs which receive those messages will again forward them as regular data frames over the spoke pseudowires to the U-PEs. The U-PEs that participate in the affected I-SID would respond to these messages by flushing their local C-MAC address tables. Effectively, the C-MAC address flush notification messages are treated as normal data frames throughout the H-VPLS network, except at the U-PE nodes. PBB BEB PBB | +----------+ BEB V +----------+ | | | +-----+ MPLS | | IP | +-----------+ | /|U-PE1| Access| | MPLS | | MPLS | | / +-----+ +----+ | Core | +----+ Access | V +--+ | |VPLS|-| |-|VPLS| +-----+ +--+ |CE|\ +-----+ |N-PE| | | |N-PE| |U-PE3|--|CE| +--+ \|U-PE2| +----+ | | +----+ +-----+ +--+ +-----+ | | | | | ^ +----------+ +----------+ +-----------+ | PBB BEB Sajassi, et al. [Page 8] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 Figure 3: H-VPLS with MPLS Access Network and PBB U-PE 4.3. H-VPLS with MPLS Access: PBB N-PE Referring to Figure 4 below, in this network architecture the PBB BEB functionality is implemented on the VPLS N-PE. Operation of the C-MAC address flushing mechanism is similar to what was discussed in the previous section, except that the messages are generated and processed by the N-PEs instead of the U-PEs. PBB BEB PBB | BEB V | +-----+ +----------+ | +--------|VPLS | | | | | |N-PE1|-| IP | | +-----------+ | +-----+ | MPLS | V | MPLS | +--+ +-----+ MPLS | | Core | +-----+ Access| |CE|--|U-PE | Access | | |-|VPLS | +-----+ +--+ +--+ +-----+ | | | |N-PE3| |U-PE |--|CE| | +-----+ | | +-----+ +-----+ +--+ | |VPLS |-| | | | +--------|N-PE2| +----------+ +-----------+ +-----+ ^ | PBB BEB Figure 4: H-VPLS with MPLS Access Network and PBB N-PE 5. Message Format The format of the C-MAC address flushing notification message is based on a PBB-encapsulated Multi-VLAN Registration Protocol (MVRP) PDU, as defined in [802.1ak]. This is shown in Figure 5 below. It should be noted that generation or reception handling of this message does NOT require a VPLS PE device (with PBB I-Component functionality) to necessarily run the IEEE 802.1ak protocol stack. This is primarily because all the fields of the encapsulated MVRP PDU are fixed. It is sufficient for the VPLS PE device to encapsulate the PDU with the right PBB header on transmission, and react to the message by flushing the appropriate C-MAC address table for the I-SID on reception. Sajassi, et al. [Page 9] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 +--------------------+ | B-DA | +--------------------+ | B-SA | +--------------------+ | EtherType = 0x88a8 | +--------------------+ | B-VLAN | +--------------------+ | EtherType = 0x88e7 | +--------------------+ | I-SID | +--------------------+ | C-DA | +--------------------+ | C-SA | +--------------------+ | EtherType = 0x88f5 | +--------------------+ | | ~ MVRP PDU ~ | | +--------------------+ Figure 5: C-MAC Address Flushing Notification Message Format B-DA: The Backbone Service Instance Group Address for the I-SID that is experiencing the topology change, as defined in [P802.1ah] section 26.4 B-SA: The B-MAC source address of the I-Component generating the message. B-VLAN: The B-VLAN used for the I-SID for which C-MAC addresses should be flushed. I-SID: The I-SID for which C-MAC addresses should be flushed. C-DA: This should be set to 01-80-C2-00-00-21 if the Customer Instance Ports (CIPs) encountering the topology change for the I-SID in question are 802.1Q interfaces, and set to 01-80-C2-00-00-0D if the CIPs are 802.1ad / Q-in-Q interfaces. Refer to [802.1ak] Table 8-1 and Table 10-1. C-SA: The C-MAC address that uniquely identifies the I-Component. This should not be the same as the B-SA in order to avoid any confusion that may arise from using the same address value in both Sajassi, et al. [Page 10] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 C-MAC and B-MAC address spaces. The value for this field can be set to the port MAC address of any of the CIPs associated with the I- Component generating the C-MAC address flushing notification message. MVRP PDU: This is an MVRP PDU declaring "new" registrations for all VLANs (1 to 4094). The format of this PDU is as shown in Figure 6 below. No. Bits Field Value +--------------------+ 8 | Protocol Version | 0x00 +--------------------+ 8 | AttributeType | 0x01 +--------------------+ 8 | AttributeLength | 0x02 +- +--------------------+ -+ | | LeaveAllEvent | | 16 -+ +--------------------+ +- 0x0ffe | | NumberofValues | | +- +--------------------+ -+ 16 | FirstValue | 0x01 +--------------------+ 10920 | Vector | 0x00 (repeated 1365 times) +--------------------+ 16 | EndMark | 0x0000 +--------------------+ Figure 6: MVRP PDU Format The various fields of this PDU are standardized by IEEE as outlined in [802.1ak]. 6. Advantages of Mechanism The C-MAC address flushing notification mechanism described in this document has the following advantages: i) It is completely transparent to all devices that operate on B- MAC addresses; e.g., is transparent to VPLS PE and N-PE in the case of H-VPLS with PBBN access and the case of H-VPLS with MPLS access (PBB on U-PE), respectively. i i) Treating C-MAC address flushing notifications as regular data frames (as opposed to control frames) within the PBB core and the on the VPLS PEs / N-PEs speeds up convergence, primarily because the forwarding can be performed in hardware, and no software-based control-plane processing is involved. Sajassi, et al. [Page 11] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 i i i) The mechanism applies to Tightly Coupled, Loosely Coupled as well as Different Service Domains [VPLS-PBB]. This is because each message carries a flush indication for a single I-SID, and the value of the I-SID is encoded in the PBB header only. Furthermore, I-SID translation, in the case of Different Service Domains, can be performed in the normal data-path by the hardware that handles regular data traffic. 7. Security Considerations There are no additional security aspects beyond those of VPLS/H-VPLS that need to be discussed here. 8. IANA Considerations None. 9. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 10. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information Sajassi, et al. [Page 12] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 12. Normative References [P802.1ah] IEEE P802.1ah/D4.2, "Draft Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", IEEE 802.1 Interworking Task Group, March, 2008. [RFC4762] "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007 [802.1ak] IEEE Std. 802.1ak-2007, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks - Amendment 7: Multiple Registration Protocol", IEEE Computer Society, June, 2007. [802.1ad] IEEE Std. 802.1ad-2005, "IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", IEEE Computer Society, May, 2006. 13. Informative References [VPLS-PBB] Sajassi et al., "VPLS Interoperability with Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop-02.txt, work in progress, November, 2007. Sajassi, et al. [Page 13] draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008 14. Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1, Canada Email: ssalam@cisco.com Luyuan Fang Cisco 300 Beaver Brook Road Boxborough, MA 01719, US Email: lufang@cisco.com Nabil Bitar Verizon Communications Email : nabil.n.bitar@verizon.com Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON K2H8E9 Email: mohand@nortel.com Raymond Zhang British Telecom 2160 E. Grand Avenue El Segundo, CA 90245 Email: raymond.zhang@bt.com Sajassi, et al. [Page 14]