--- 1/draft-ietf-ccamp-gmpls-ethernet-arch-06.txt 2009-12-04 17:12:14.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-ethernet-arch-07.txt 2009-12-04 17:12:14.000000000 +0100 @@ -1,48 +1,43 @@ Internet Draft Don Fedyk, Alcatel-Lucent Category: Informational Lou Berger, LabN -Expiration Date: April 14, 2010 Loa Andersson, Ericsson AB +Expiration Date: June 2, 2010 Loa Andersson, Ericsson AB - October 14, 2009 + December 2, 2009 Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework - draft-ietf-ccamp-gmpls-ethernet-arch-06.txt + draft-ietf-ccamp-gmpls-ethernet-arch-07.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. - 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 BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on April 14, 2010. + This Internet-Draft will expire on June 2, 2010. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -50,25 +45,25 @@ Abstract There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an - architecture and framework for a Generalized GMPLS based control - plane for Ethernet in this "transport network" capacity. GMPLS has - already been specified for similar technologies. Some additional - extensions to the GMPLS control plane are needed and this document - provides a framework for these extensions. + architecture and framework for a Generalized MPLS based control plane + for Ethernet in this "transport network" capacity. GMPLS has already + been specified for similar technologies. Some additional extensions + to the GMPLS control plane are needed and this document provides a + framework for these extensions. Table of Contents 1 Introduction ........................................... 4 1.1 Terminology ............................................ 6 1.1.1 Concepts ............................................... 6 1.1.2 Abbreviations and Acronyms ............................. 7 2 Background ............................................. 8 2.1 Ethernet Switching ..................................... 8 2.2 Operations, Administration, and Maintenance (OAM) ...... 11 @@ -80,100 +75,100 @@ 5 GMPLS Signaling ........................................ 15 6 Link Management ........................................ 16 7 Path Computation and Selection ......................... 17 8 Multiple VLANs ......................................... 18 9 Security Considerations ................................ 18 10 IANA Considerations .................................... 18 11 References ............................................. 18 11.1 Normative References ................................... 18 11.2 Informative References ................................. 19 12 Acknowledgments ........................................ 20 - 13 Author's Addresses ..................................... 20 + 13 Author's Addresses ..................................... 21 1. Introduction There has been significant recent work in increasing the capabilities of Ethernet switches. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as SONET/SDH TDM and ATM. The evolution and development of Ethernet capabilities in these areas is a very active and ongoing process. Multiple organizations have been active in extending Ethernet - Technology support transport networks. This activity has taken place - in the Institute of Electrical and Electronics Engineers (IEEE) 802.1 - Working Group, the International Telecommunication Union (ITU) and - the Metro Ethernet Forum (MEF). These groups have been focusing on - Ethernet forwarding, Ethernet management plane extensions and the - Ethernet Spanning Tree Control Plane, but not on an explicitly - routed, constraint based control plane. + Technology to support transport networks. This activity has taken + place in the Institute of Electrical and Electronics Engineers (IEEE) + 802.1 Working Group, the International Telecommunication Union - + Telecommunication Standardization Sector (ITU-T) and the Metro + Ethernet Forum (MEF). These groups have been focusing on Ethernet + forwarding, Ethernet management plane extensions and the Ethernet + Spanning Tree Control Plane, but not on an explicitly routed, + constraint-based control plane. In the forwarding plane context, extensions have been, or are being, defined to support different transport Ethernet forwarding models, protection modes, and service interfaces. Examples of such extensions include [802.1ah], [802.1Qay], [G.8011] and [MEF.6]. These extensions allow for greater flexibility in the Ethernet forwarding plane and, in some cases, the extensions allow for a departure from forwarding based on Ethernet spanning tree. For example, in the [802.1Qah] case, greater flexibility in forwarding is achieved through the addition of a "provider" address space. [802.1Qay] supports the use of provisioning systems and network control protocols that explicitly select traffic engineered paths. - This document provides a framework for GMPLS Ethernet Label switching + This document provides a framework for GMPLS Ethernet Label Switching (GELS). GELS will likely require more than one switching type to support the different models, and as the GMPLS procedures that will need to be extended are dependent on switching type, these will be covered in the technology specific documents. In the provider bridge model developed in the IEEE 802.1ad project and amended to the IEEE 802.1Q standard [802.1Q], an extra Virtual Local Area Network (VLAN) identifier (VID) is added. This VLAN is - referred to as the Service VID, (S-VID and is carried in a Service - TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah] a backbone - VID (B-VID) and B-MAC header with a Service Instance (I-TAG) + referred to as the Service VID, (S-VID) and is carried in a Service + TAG (S-TAG). In provider backbone bridges (PBB) [802.1ah], a backbone + VID (B-VID) and B-MAC header with a service instance (I-TAG) encapsulates a customer Ethernet frame or a service Ethernet frame. In the IEEE 802.1Q standard the terms Provider Backbone Bridges (PBB) and Provider Backbone Bridged Network (PBBN) are used in the context of these extensions. An example of Ethernet protection extensions can be found in [G.8031]. Ethernet operations, administration, and maintenance (OAM) is another important area that is being extended to enable provider Ethernet services. Related extensions can be found in [802.1ag] and [Y.1731]. An Ethernet based service model is being defined within the context - of the Metro Ethernet Forum (MEF) and International Telecommunication - Union (ITU). [MEF.6] and [G.8011] provide parallel frameworks for - defining network-oriented characteristics of Ethernet services in - transport networks. These framework documents discusses general - Ethernet connection characteristics, Ethernet User-Network Interfaces - (UNIs) and Ethernet Network-Network Interfaces (NNIs). [G.8011.1] - defines the Ethernet Private Line (EPL) service and [G.8011.2] - defines the Ethernet Virtual Private Line (EVPL) service. [MEF.6] - covers both service types. These activities are consistent with the - types of Ethernet switching defined in [802.1ah]. + of the MEF and ITU-T. [MEF.6] and [G.8011] provide parallel + frameworks for defining network-oriented characteristics of Ethernet + services in transport networks. These framework documents discuss + general Ethernet connection characteristics, Ethernet User-Network + Interfaces (UNIs) and Ethernet Network-Network Interfaces (NNIs). + [G.8011.1] defines the Ethernet Private Line (EPL) service and + [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. + [MEF.6] covers both service types. These activities are consistent + with the types of Ethernet switching defined in [802.1ah]. The Ethernet forwarding and management plane extensions allow for the disabling of standard Ethernet spanning tree but do not define an - explicitly routed, constraint based control plane. For example + explicitly routed, constraint-based control plane. For example [802.1Qay] is an amendment to IEEE 802.1Q that explicitly allows for traffic engineering of Ethernet forwarding paths. The IETF's GMPLS work provides a common control plane for different data plane technologies for Internet and telecommunication service providers. The GMPLS architecture is specified in RFC3945 [RFC3945]. The protocols specified for GMPLS can be used to control "Transport Network" technologies, e.g. Optical and TDM networks. GMPLS can also - be used for packet and Layer 2 Switching (frame/cell based networks. + be used for packet and Layer 2 Switching (frame/cell based networks). This document provides a framework for use of GMPLS to control "transport" Ethernet Label Switched Paths (Eth-LSP). Transport Ethernet adds new constraints which require it to be distinguished from the previously specified technologies for GMPLS. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. All extensions to support Eth-LSPs will build on the GMPLS architecture and related specifications. @@ -193,39 +188,40 @@ 1.1. Terminology 1.1.1. Concepts The following are basic Ethernet and GMPLS terms: o Asymmetric Bandwidth This term refers to a property of a Bidirectional service - instance may have differing bandwidth allocation in each + instance that has differing bandwidth allocation in each direction. o Bidirectional Congruent LSP This term refers to the property of a bidirectional LSP that uses only the same nodes, ports, and links in both directions. - Ethernet data planes are normally bidirectional or reverse path - congruent. + Ethernet data planes are normally bidirectional congruent + (sometimes known as reverse path congruent). o Contiguous Eth-LSP - A contiguous Eth-LSP is an Eth-LSP that maps one to one with an - another LSP at a VLAN boundary. Stitched LSPs are contiguous - LSPs. + A contiguous Eth-LSP is an end-to-end Eth-LSP that is formed from + multiple Eth-LSPs each operating within a VLAN and that are + mapped one-to-one at the VLAN boundaries. Stitched LSPs form + contiguous LSPs. o Eth-LSP - This term refers to Ethernet switched paths that may be + This term refers to Ethernet label switched paths that may be controlled via GMPLS. o Hierarchical Eth-LSP Hierarchical Eth-LSPs aggregate Eth-LSPs by creating a hierarchy of Eth-LSPs. o In-band GMPLS Signaling In-band GMPLS Signaling is IP based control messages which are @@ -233,44 +229,44 @@ Ethernet header. Logical links that use a dedicated VID on the same physical links would be considered In-band signaling. o Out-of-band GMPLS Signaling Out-of-band GMPLS Signaling is composed of IP based control messages that are sent between Ethernet switches over links other than the links used by the Ethernet data plane. Out of band signaling typically shares a different fate from the data links. - o Point-to-point (P2P) Traffic Engineering (TE) Service Instance + o Point-to-point (P2P) Traffic Engineering (TE) service instance A TE service instance made up of a single bidirectional P2P or two P2P unidirectional Eth-LSPs. - o Point-to-multipoint (P2MP) Traffic Engineering (TE) Service - Instance + o Point-to-multipoint (P2MP) Traffic Engineering (TE) service + instance - A TE service Instance supported by a set of LSPs which comprises + A TE service instance supported by a set of LSPs which comprises one P2MP LSP from a root to n leaves plus a Bidirectional Congruent point-to-point (P2P) LSP from each of the leaves to the root. o Shared forwarding Shared forwarding is a property of a data path where a single forwarding entry (VID + DMAC) may be used for frames from multiple sources (SMAC). Shared forwarding does not change any data plane behavior. Shared forwarding saves forwarding database (FDB) entries only. Shared forwarding offers similar benefits to merging in the data plane. However in shared forwarding the Ethernet data packets are unchanged when using shared forwarding. With shared forwarding dedicated control plane states for all - Eth-LSP are maintained regardless of shared forwarding entries. + Eth-LSPs are maintained regardless of shared forwarding entries. 1.1.2. Abbreviations and Acronyms The following abbreviations and acronyms are used in this document: CCM Continuity Check Message CFM Connectivity Fault Management DMAC Destination MAC Address Eth-LSP Ethernet Label Switched Path I-SID Service Identifier @@ -299,21 +295,21 @@ 2. Background This section provides background to the types of switching and services that are supported within the defined framework. The former is particularly important as it identifies the switching functions that GMPLS will need to represent and control. The intent is for this document to allow for all standard forms of Ethernet switching and services. The material presented in this section is based on both finished and - on-going work taking place in the IEEE 802.1 Working Group, the ITU + on-going work taking place in the IEEE 802.1 Working Group, the ITU-T and the MEF. This section references and, to some degree, summarizes that work. This section is not a replacement for, or an authoritative description of that work. 2.1. Ethernet Switching In Ethernet switching terminology, the bridge relay is responsible for forwarding and replicating the frames. Bridge relays forward frames based on the Ethernet header fields: Virtual Local Area Network (VLAN) Identifiers (VID) and Destination Media Access Control @@ -412,21 +408,21 @@ In most bridging cases, the header fields cannot be changed, but some translations of VID field values are permitted, typically at the network edges. Across all service types, the Ethernet data plane is bidirectional congruent. This means that the forward and reverse paths share the exact same set of nodes, ports and bidirectional links. This property is fundamental. The 802.1 group has maintained this bidirectional congruent property in the definition of Connectivity Fault Management (CFM) which is part of the overall Operations - Administration and Management (OAM) capability. + Administration and Maintenance (OAM) capability. 2.2. Operations, Administration, and Maintenance (OAM) Robustness is enhanced with the addition of data plane OAM to provide both fault and performance management. Ethernet OAM messages [802.1ag] and [Y.1731], rely on data plane forwarding for both directions. Determining a broken path or misdirected packet in this case relies on OAM following the Eth-LSP. These OAM message identifiers are dependent on the data plane so they @@ -547,21 +543,21 @@ connections. This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service specific documents will define any signaling and routing extensions needed to support a specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS protocol extensions and procedures. It is expected that all such extensions will be consistent with this document. - It is expected that key a requirement for service specific documents + It is expected that a key requirement for service specific documents will be to describe label formats and encodings. It may also be necessary to provide a mechanism to identify the required Ethernet service type in signaling and a way to advertise the capabilities of Ethernet switches in the routing protocols. These mechanisms must make it possible to distinguish between requests for different paradigms including new, future, and existing paradigms. The Switching Type and Interface Switching Capability Descriptor share a common set of values and are defined in [RFC3945], [RFC3471], and [RFC4202] as indicators of the type of switching that should @@ -574,60 +570,60 @@ Ethernet switching paradigm that is supported. For discussion purposes, we decompose the problem of applying GMPLS into the functions of Routing, Signaling, Link Management and Path Selection. It is possible to use some functions of GMPLS alone or in partial combinations. In most cases using all functions of GMPLS leads to less operational overhead than partial combinations. 4. GMPLS Routing and Addressing Model - The GMPLS Routing and Addressing Model is not modified by this - document. GMPLS control for Eth-LSPs uses the Routing and Addressing + The GMPLS routing and addressing model is not modified by this + document. GMPLS control for Eth-LSPs uses the routing and Addressing Model described in [RFC3945]. Most notably this includes the use of IP addresses to identify interfaces and LSP end-points. It also includes support for both numbered and unnumbered interfaces. In the case where another address family or type of identifier is required to support an Ethernet service, extensions may be defined to provide mapping to an IP address. Support of Eth-LSPs is expected to strictly comply to the GMPLS protocol suite addressing as specific in - RFC3471, RFC3473 and related documents. + [RFC3471], [RFC3473] and related documents. 4.1. GMPLS Routing GMPLS routing as defined in [RFC4202] uses IP routing protocols with opaque TLV extensions for the purpose of distributing GMPLS related TE (router and link) information. As is always the case with GMPLS, TE information is populated based on resource information obtained from LMP or from configured information. The bandwidth resources of the links are tracked as Eth-LSPs are set up. Interfaces supporting the switching of Eth-LSPs are identified using the appropriate Interface Switching Capabilities Descriptor. As mentioned in Section 3, the definition of one or more new Interface Switching Capabilities to support Eth-LSPs is expected. Again, the L2SC Interface Switching Capabilities will not be used to represent interfaces capable of supporting Eth-LSPs defined by this document and subsequent documents in support of the transport Ethernet switching paradigms. In addition, Interface Switching Capability specific TE information may be defined as needed to support the requirements of a specific Ethernet Switching Service Type. - GMPLS Routing is an optional functionality but it is highly valuable + GMPLS routing is an optional functionality but it is highly valuable in maintaining topology and distributing the TE database for path management and dynamic path computation. 4.2. Control Plane Network In order for a GMPLS control plane to operate, an IP connectivity - network of sufficient capacity to handle the information exchange - between the GMPLS routing and signaling protocols is necessary. + network of sufficient capacity to handle the information exchange of + the GMPLS routing and signaling protocols is necessary. One way to implement this is with an IP routed network supported by an IGP that views each switch as a terminated IP adjacency. In other words, IP traffic and a simple routing table are available for the control plane but there is no requirement for needing a high performance IP data plane, or for forwarding user traffic over this IP network. This IP connectivity can be provided as a separate independent network (out of band) or integrated with the Ethernet switches (in- @@ -648,42 +644,42 @@ GMPLS signaling supports the establishment and control of bidirectional and unidirectional data paths. Ethernet is bidirectional by nature and CFM has been built to leverage this. Prior to CFM, the emulation of a physical wire and the learning requirements also mandated bidirectional connections. Given this, Eth-LSPs need to be bidirectional congruent. Eth-LSPs may be either P2P or P2MP (see [RFC4875]). GMPLS signaling also allows for full and partial LSP protection; see [RFC4872] and [RFC4873]. Note that standard GMPLS does not support different bandwidth in each - direction of a bidirectional LSP. [GMPLS-ASYM], an Experimental + direction of a bidirectional LSP. [RFC5467], an Experimental document, provides procedures if asymmetric bandwidth bidirectional LSPs are required. 6. Link Management Link discovery has been specified for Ethernet in [802.1AB]. The benefits of running link discovery in large systems are significant. Link discovery may reduce configuration and reduce the possibility of undetected errors in configuration as well as exposing misconnections. However the 802.1AB capability is an optional feature, it is not necessarily operating before a link is operational, and it primarily supports the management plane. In the GMPLS context, LMP [RFC4204] has been defined to support GMPLS control plane link management and discovery features. LMP also supports for the control plane the automated creation of unnumbered interfaces. If LMP is not used there is an additional configuration requirement for GMPLS link identifiers. For large-scale implementations LMP is beneficial. LMP also has optional fault management capabilities, primarily for opaque and transparent network - technology. With IEEE's newer CFM [802.1ag] and ITU's [Y.1731] + technology. With IEEE's newer CFM [802.1ag] and ITU-T's [Y.1731] capabilities, this optional capability may not be needed. It is the goal of the GMPLS Ethernet architecture to allow the selection of the best tool set for the user needs. The full functionality of Ethernet CFM should be supported when using a GMPLS control plane. LMP and 802.1AB are relatively independent. The LMP capability should be sufficient to remove the need for 802.1AB but 802.1 AB can be run in parallel or independently if desired. Figure 2 provides possible ways of using LMP, 802.1AB and 802.1ag in combination. @@ -729,44 +725,44 @@ computed in a fully distributed fashion, on a management station with local computation for rerouting, or on more sophisticated path computation servers. Eth-LSPs may be supported using any path selection or computation mechanism. As is the case with any GMPLS path selection function, and common to all path selection mechanisms, the path selection process should take into consideration Switching Capabilities and Encoding advertised for a particular interface. Eth-LSPs may also make use of the emerging path computation element and selection work; see - [RFC4655] + [RFC4655]. 8. Multiple VLANs - This document allows for the support the signaling of Ethernet + This document allows for the support of the signaling of Ethernet parameters across multiple VLANs supporting both contiguous Eth-LSP and Hierarchical Ethernet LSPs. The intention is to reuse GMPLS hierarchy for the support of Peer to Peer models, UNIs and NNIs. 9. Security Considerations The architecture for GMPLS controlled "transport" Ethernet assumes that the network consists of trusted devices, but does not require that the ports over which a UNI are defined are trusted, nor does - equipment connected to these ports trusted. In general, these - requirements are no different from the security requirements for - operating any GMPLS network. Access to the trusted network will only - occur through the protocols defined for the UNI or NNI or through - protected management interfaces. + equipment connected to these ports require to be trusted. In + general, these requirements are no different from the security + requirements for operating any GMPLS network. Access to the trusted + network will only occur through the protocols defined for the UNI or + NNI or through protected management interfaces. When in-band GMPLS signaling is used for the control plane the security of the control plane and the data plane may affect each - other. When out-of-band GMPLS signaling is used the control plane - the data plane security is decoupled from the control plane and + other. When out-of-band GMPLS signaling is used for the control + plane the data plane security is decoupled from the control plane and therefore the security of the data plane has less impact on overall security. Where GMPLS is applied to the control of VLAN only, the commonly known techniques for mitigation of Ethernet DOS attacks may be required on UNI ports. For a more comprehensive discussion on GMPLS security please see the MPLS and GMPLS Security Framework [SECURITY]. It is expected that solution documents will include a full analysis of the security @@ -784,31 +780,31 @@ Functional Description", January 2003, RFC3471. [RFC3473] Berger, L. (editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003, RFC3473. [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized MPLS", RFC 4202, October 2005 + [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3495. + 11.2. Informative References [G.8031] ITU-T Draft Recommendation G.8031, Ethernet Protection Switching. [G.8011] ITU-T Draft Recommendation G. 8011, Ethernet over Transport - Ethernet services framework. - [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label - Switching (GMPLS) Architecture", RFC 3495. - [802.1AB] "IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery" (2004). [802.1ag] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5:Connectivity Fault Management", (2007). [802.1ah] "IEEE Standard for Local and Metropolitan Area @@ -840,38 +836,40 @@ End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery ", RFC 4872, May 2007. [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 2007. [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions and Mechanisms for Ethernet based Networks ", work in progress. - [GMPLS-ASYM] Berger, L. et al., "GMPLS Asymmetric Bandwidth - Bidirectional LSPs", work in progress. + [RFC5467] Berger, L. et al., "GMPLS Asymmetric Bandwidth + Bidirectional LSPs", RFC5467, March 2009. - [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", work - in progress. + [ETH-TSPEC] Papadimitriou, D., "Ethernet Traffic Parameters", + draft-ietf-ccamp-ethernet-traffic-parameters-09.txt, + work in progress. - [SECURITY] Luyuan Fang, Ed., " Security Framework for MPLS - and GMPLS Networks", work in progress. + [SECURITY] Luyuan Fang, Ed., "Security Framework for MPLSand GMPLS + Networks", draft-ietf-mpls-mpls-and-gmpls-security- + framework-07.txt, work in progress. 12. Acknowledgments There were many people involved in the initiation of this work prior to this document. The GELS framework draft and the PBB-TE extensions drafts were two drafts the helped shape and justify this work. We acknowledge the work of these authors of these initial drafts: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, - Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar. + Himanshu Shah, Greg Sunderwood, Alan McGuire, and Nabil Bitar. George Swallow contributed significantly to this document. 13. Author's Addresses Don Fedyk Alcatel-Lucent Groton, MA, 01450 Phone: +1-978-467-5645 Email: donald.fedyk@alcatel-lucent.com @@ -878,11 +877,11 @@ Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net Loa Andersson Ericsson AB Phone: +46 10 717 52 13 Email: loa.andersson@ericsson.com -Generated on: Wed Oct 14 14:54:18 EDT 2009 +Generated on: Wed Dec 2 12:35:33 EST 2009