--- 1/draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt 2009-02-26 05:12:12.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt 2009-02-26 05:12:12.000000000 +0100 @@ -1,886 +1,705 @@ Internet Draft Don Fedyk, Nortel Category: Standards Track Himanshu Shah, Ciena -Expiration Date: January 14, 2009 Nabil Bitar, Verizon +Expiration Date: August 25, 2009 Nabil Bitar, Verizon Attila Takacs, Ericsson - July 14, 2008 + February 25, 2009 - GMPLS control of Ethernet PBB-TE + Generalized Multiprotocol Label Switching (GMPLS) control of + Ethernet PBB-TE - draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt + draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt Status of this Memo + This Internet-Draft is submitted to IETF in full conformance with + the provisions of BCP 78 and BCP 79. + + This memo provides information for the Internet community. It + does not specify an Internet standard of any kind. Distribution + of this memo is unlimited. + 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. + 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." + 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 January 14, 2009. + This Internet-Draft will expire on August 25, 2009. -Copyright Notice +Copyright and License Notice - Copyright (C) The IETF Trust (2008). + 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with + respect to this document. Abstract This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] and describes the technology specific - aspects of GMPLS control for Provider Backbone Bridging Traffic + aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. Table of Contents - 1 Introduction .............................................. 3 - 1.1 Co-authors ................................................ 3 - 2 Terminology ............................................... 4 - 2.1 PBB-TE Terminology ........................................ 5 - 3 Creation and Maintenance of PBB-TE Service Instances ...... 6 - 3.1 Ethernet Service .......................................... 7 - 3.2 Addresses, Interfaces, and Labels ......................... 7 - 4 Specific Procedures ....................................... 10 - 4.1 P2P connections ........................................... 10 - 4.1.1 Shared Forwarding ......................................... 11 - 4.1.2 P2P connections with shared forwarding .................... 12 - 4.1.3 Dynamic P2P symmetry with shared forwarding ............... 13 - 4.1.4 Planned P2P symmetry ...................................... 13 - 4.1.5 P2P Path Maintenance ...................................... 13 - 4.2 P2MP Signaling ............................................ 14 - 4.3 P2MP ESP-MAC DA Connections ............................... 14 - 4.3.1 Setup procedures .......................................... 14 - 4.3.2 Maintenance Procedures .................................... 14 - 4.4 Ethernet Label ............................................ 15 - 4.5 OAM MEP ID and MA ID synchronization ...................... 16 - 4.6 Protection Paths .......................................... 16 - 5 Error conditions .......................................... 17 - 5.1 Invalid ESP-VID value for PBB-TE MSTI range ............... 17 - 5.2 Invalid MAC Address ....................................... 17 - 5.3 Invalid ERO for UPSTREAM_LABEL Object ..................... 17 - 5.4 Invalid ERO for LABEL_SET Object .......................... 18 - 5.5 Switch is not ESP P2MP capable ............................ 18 - 5.6 Invalid ESP-VID in UPSTREAM_LABEL object .................. 18 - 6 Deployment Scenarios ...................................... 18 - 7 Security Considerations ................................... 18 - 8 IANA Considerations ....................................... 18 - 9 References ................................................ 19 - 9.1 Normative References ...................................... 19 - 9.2 Informative References .................................... 19 -10 Acknowledgments ........................................... 21 -11 Author's Address .......................................... 21 - A. Rational and mechanism for PBB_TE Ethernet Forwarding ..... 22 - A.1. Overview of configuration of VID/DMAC tuples .............. 25 - A.2 Overview of configuration of VID port membership .......... 28 - A.3 OAM Aspects ............................................... 28 - A.4 QOS Aspects ............................................... 29 - A.5 Resiliency Aspects ........................................ 29 - A.5.1 E2E Path protection ....................................... 29 -12 Full Copyright Statement .................................. 30 -13 Intellectual Property ..................................... 30 + 1 Introduction .............................................. 4 + 1.1 Co-authors ................................................ 4 + 2 Terminology ............................................... 5 + 2.1 PBB-TE and GMPLS Terminology .............................. 5 + 3 Creation and Maintenance of PBB-TE paths using GMPLS ...... 6 + 4 Specific Procedures ....................................... 9 + 4.1 P2P Ethernet LSPs ........................................ 9 + 4.1.1 Shared Forwarding ......................................... 10 + 4.1.2 P2P connections procedures for shared forwarding .......... 11 + 4.1.3 P2P Path Maintenance ...................................... 11 + 4.2 P2MP Ethernet-LSPs ........................................ 12 + 4.2.1 Maintenance Procedures .................................... 12 + 4.3 PBB-TE Ethernet Label ..................................... 12 + 4.4 Protection Paths .......................................... 13 + 4.5 Service Instance Identification .......................... 13 + 5 Error conditions .......................................... 15 + 5.1 Invalid ESP-VID value for PBB-TE ......................... 15 + 5.2 Invalid MAC Address ....................................... 15 + 5.3 Switch is not ESP P2MP capable ............................ 15 + 6 Security Considerations ................................... 15 + 7 IANA Considerations ....................................... 16 + 7.1 Error Codes ............................................... 16 + 8 References ................................................ 16 + 8.1 Normative References ...................................... 16 + 8.2 Informative References .................................... 16 + 9 Acknowledgments ........................................... 17 +10 Author's Address .......................................... 17 Conventions used in this document 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 [RFC2119]. 1. Introduction - IEEE 802.1 is specifying Traffic Engineered Ethernet paths in the - Provider Backbone Bridged network (PBB-TE) [IEEE 802.1Qay] based on - managed objects that can be separated from the Spanning Tree Control - Plane and statically configured or managed by another control plane. - These paths have minor changes to Ethernet data plane specified in - the IEEE. IEEE 802 termed these paths "PBB-TE service instances". + The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE) + [IEEE 802.1Qay] standard supports the establishment of explicitly + routed traffic engineered paths within Provider Backbone Bridged + (PBB) networks. PBB-TE allows disabling: the Spanning Tree Protocol, + unknown destination address forwarding and source address learning + for administratively selected VLAN Identifiers. With PBB-TE an + external provisioning system or control plane can be used to + configure static entries in the managed objects of bridges and so + establish traffic engineered paths in the network. Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including Layer 2 Switching capable networks (L2SC). The purpose of this document is to specify extensions for a - GMPLS based control plane to manage PBB-TE service instances. This - draft is aligned with the GMPLS Ethernet Label Switching Architecture - and Framework [ARCH]. - - It should be noted that due to the changes in the separation of the - Spanning Tree Control plane and PBB-TE forwarding, the behavior of - PBB-TE for the specified VLAN range is a new behavior. (It does not - default to conventional Ethernet forwarding with learning at any - time). Note, currently PBB-TE is under specification in the - Interworking Task Group of the IEEE 802.1 Working Group (WG), the - actual draft has version 3.5. Appendix A summarizes the rational for - this data plane technology until the IEEE specification is released - for Working Group Ballot in the IEEE 802.1 WG. + GMPLS based control plane to manage PBB-TE explicitly routed traffic + engineered paths. This draft is complementary to with the GMPLS + Ethernet Label Switching Architecture and Framework [ARCH]. 1.1. Co-authors This document is the result the a large team of authors and contributors. The following is a list of the co-authors: Don Fedyk (Nortel) David Allan (Nortel) Himanshu Shah (Ciena) Nabil Bitar (Verizon) Attila Takacs (Ericsson) Diego Caviglia (Ericsson) Alan McGuire (BT) Nurit Sprecher (Nokia Siemens Networks) Lou Berger (LabN) 2. Terminology In addition to well understood GMPLS terms, this memo uses - terminology from IEEE 802.1 and introduces a few new terms: + terminology from IEEE 802.1 [IEEE 802.1Qah] [IEEE 802.1Qay]: + - BCB Backbone Core Bridge - BEB Backbone Edge Bridge - B-MAC Backbone MAC - B-VID Backbone VLAN ID - B-VLAN Backbone VLAN - CBP Customer Backbone Port - CCM Continuity Check Message - - COS Class of Service - - CLI Command Line Interface - - CIP Customer Instance Port + - CNP Customer Network Port - C-MAC Customer MAC - C-VID Customer VLAN ID - C-VLAN Customer VLAN - DMAC Destination MAC Address - ESP Ethernet Switched Path + - ESP-MAC SA ESP Source MAC Address + - ESP-MAC DA ESP Destination MAC Address + - ESP-VID ESP VLAN ID - Eth-LSP Ethernet Label Switched Path + - IB-BEB A BEB comprising of both I and B components - I-SID Ethernet Service Instance Identifier - - LBM Loopback Message - - LBR Loopback Reply - - LLDP Link Layer Discovery Protocol - - LMM Loss Measurement Message - - LMR Loss Measurement Reply - MAC Media Access Control - - MMAC Multicast MAC - - MSTID Multiple Spanning Tree Identifier - - MP2MP Multipoint to multipoint + - MMAC Multicast or Group MAC address - PBB Provider Backbone Bridges - PBB-TE Provider Backbone Bridges Traffic Engineering - PIP Provider Instance Port - - PCP Priority Code Points - PNP Provider Network Port - P2P Point to Point - P2MP Point to Multipoint - - QOS Quality of Service - - ESP-MAC SA Source MAC Address - - S-VID Service VLAN ID - SVL Shared VLAN Learning - - TE-MSTID Traffic Engineering MSTID + - TESI TE Service Instance - VID VLAN ID - VLAN Virtual LAN -2.1. PBB-TE Terminology +2.1. PBB-TE and GMPLS Terminology - The PBB-TE specification has defined some additional terminology to - clarify the PBB-TE functions. We repeat these here in expanded - context to translate from IEEE to GMPLS terminology. + The PBB-TE specification [IEEE 802.1Qay] defines some additional + terminology to clarify the PBB-TE functions. We repeat these here in + expanded context to translate from IEEE to GMPLS terminology. - Ethernet Switched Path (ESP): A provisioned traffic engineered unidirectional connectivity path between two or more Customer Backbone Ports (CBPs) which extends over a Provider Backbone Bridge Network (PBBN). The path is - identified by the 3-tuple where - the ESP-VID value is allocated to the PBB-TE Multiple Spanning - Tree Identifier (MSTID). (A set of VIDs for PBB-TE is allocated - to the new TE-MSTID.) An ESP is analogous to a GMPLS LSP. - - - Point-to-Point PBB-TE service instance: - An instance of the MAC service provided by two unidirectional co- - routed ESPs forming a bidirectional service. A GMPLS - bidirectional path is analogous to a P2P PBB-TE Service instance. - - - Point-to-Multipoint PBB-TE service instance: - An instance of the MAC service provided by a set of ESPs which - comprises one point-to-multipoint ESP plus n unidirectional - point-to-point ESPs. The n P2P ESPs are co-routed but in the - opposite direction from the root-to-leaf sub-ESPs comprising the - P2MP ESP. Note that due to traditional Ethernet data plane - design this definition is different to the way P2MP connections - are generally defined. That is, while P2MP connections are - generally root-to-leaves unidirectional trees, P2MP PBB-TE - services can be regarded as bidirectional trees. - -3. Creation and Maintenance of PBB-TE Service Instances - - PBB-TE is an Ethernet connection oriented technology, being specified - in the IEEE, which can be controlled by configuration of static - filtering entries (see Appendix A for some details on the rational - for the data plane). PBB-TE ESPs are created switch by switch by - simple configuration of Ethernet logical ports and assignment of PBB- - TE labels or by a control plane. This document describes GMPLS as a - valid control plane for Eth-LSPs that are based on PBB-TE ESPs. A - Point-to-Point PBB-TE service instance is a form of Ethernet LSP - (Eth-LSP) which is more broadly defined in [ARCH]. This memo - describes GMPLS as a mechanism to automate set-up teardown, - protection and recovery of PBB-TE ESPs and specifies the specific - TLVs for control of PBB-TE service instances. - - When configuring a PBB-TE ESP with GMPLS, the ESP-MAC DA and ESP-VID - are carried in a generalized label object and are assigned hop by hop - but are invariant within a domain. This invariance is similar to - GMPLS operation in transparent optical networks. As is typical with - other technologies controlled by GMPLS, the data plane receiver must - accept, and usually assigns, labels from its available label pool. - This, together with the label invariance requirement mentioned above, - result in each PBB-TE label being a domain wide unique label, with a - unique ESP-VID + ESP-MAC DA, for each direction. - - The following illustrates the identifiers for Labels and ESPs. + identified by the 3-tuple . An + ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP + is analogous to a (unidirectional) point-to-point or point-to- + multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS + established ESPs. - GMPLS Upstream Label (60 bits) - GMPLS Downstream Label (60 bits) - Upstream PBB-TE ESP 3-tuple (108 bits) - Downstream PBB-TE ESP 3-tuple (108 bits) + - Point-to-point ESP: + An ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's + 3- tuple identifier are the individual MAC addresses of the two + CBPs. - Table 1 Labels and ESPs - The MAC is domain wide unique in the network. PBB-TE defines the - tuple of as a unique connection - identifier in the data plane but the forwarding operation only uses - the ESP-MAC DA (DMAC) and the ESP-VID in each direction. Note that - the MAC addresses for PBB-TE are part of the Backbone Component - Relay (B-Component) and are associated with Provider addresses - corresponding to the Customer Backbone ports (CBP) of the Backbone - Component (B-Component) as described in section 3.2. - The ESP-VID (VID) typically comes from a small number of VIDs - dedicated to PBB-TE MSTID. The ESP-VID (VID) can be reused across - ESPs. There is no requirement the ESP-VID for two ESPs that form a - PBB-TE Service instance be the same. + - Point-to-multipoint ESP: + An ESP among one root CBP and n leaf CBPs. The ESP-DA in the + ESP's 3-tuple identifier is a group MAC address identifying the n + leaf CBPs, and the ESP-SA is the individual MAC address of the + root. + - Point-to-Point PBB-TE service instance (P2P TESI): + A service instance supported by two point-to-point ESPs where the + ESPs' endpoints have the same CBP MAC addresses. The two + unidirectional ESP are forming a bidirectional service. The PBB- + TE standard [IEEE 802.1Qay] notes the following: for reasons + relating to TE service monitoring diagnostics, operational + simplicity, etc. the IEEE PBB-TE standard assumes that the point- + to-point ESPs associated with a point-to-point TESI are co- + routed. Support for a point-to-point TE services which comprises + non co-routed ESPs is problematic, and is not defined in this + standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P + TE Service instance. We use the term bidirectional Ethernet-LSP + (Eth-LSP) for GMPLS established P2P PBB-TE Service instances. - Several attributes may be associated with an Eth-LSP. These are - reviewed in Section 3 of [ARCH]. Several other aspects of GMPLS - covered by [ARCH] also apply equally to PBB-TE. This includes the - GMPLS routing and addressing model, link management, path - computation and selection, and multiple domains. +3. Creation and Maintenance of PBB-TE paths using GMPLS -3.1. Ethernet Service + IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs + are created switch by switch by simple configuration of Ethernet + forwarding entries. This document describes the use of GMPLS as a + valid control plane for the set-up, teardown, protection and + recovery of ESPs and TESIs and specifies the required RSVP-TE + extensions for the control of PBB-TE service instances. - Ethernet Switched Paths that are setup either by configuration or - signaling can be used to provide an Ethernet service to customers of - the Ethernet network. The Metro Ethernet Forum has defined some - services in [MEF.6] (e.g., Ethernet Private Line), and these are also - aligned with ITU-T G.8011-x Recommendations. Of particular interest - are the bandwidth profile parameters in [MEF.10] and whose associated - bandwidth profile algorithm are based on [RFC4115] [RFC3270]. - Consideration should be given to supporting these in any signaling - extensions for Ethernet LSPs. This will be addressed in a future - version of this specification. + PBB-TE ESP and services are always originated and terminated on IB- + Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B + components, this is illustrated in Figure 1. -3.2. Addresses, Interfaces, and Labels + An Ethernet service supported by a PBB-TE TESI is always attached to + a Customer Network Port (CNP) of the I-component. A Service Instance + Identifier (I-SID) is assigned for the service. The I and B + components have internal ports which are connected via an internal + LAN. These internal ports are the Provider Instance Ports (PIPs) and + Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside + the IB-BEB. ESPs are always originated and terminated on CBP ports + and use the MAC address of that port. The I-Component encapsulates + the service frames arriving from the CNP by adding an I-SID and a + complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The + B-Component adds the ESP-VID. - This specification uses an addressing scheme and a label space for - the ingress/egress connection; the hierarchical TE Router - ID/Interface ID and the Ethernet ESP-VID/ESP-MAC DA tuple or ESP- - VID/Multicast MAC as a label space. This draft is intended to be - consistent with GMPLS addressing and Routing [ARCH]. + GMPLS is being defined here to establish ESPs and TESIs. As it can be + seen from the above this requires configuration of both the I and B + components of the IB-BEBs connected by the ESPs. - PBB-TE is defined for a PBB Network. As with PBB services, PBB-TE is - typically implemented in the Service and Backbone components of an - IB-Backbone Edge Bridge (BEB). This is illustrated in Figure 1. The - Ethernet service is attached to a Customer Instance Port (CIP) of the - Backbone Service Instance (I-component) Relay. The CIP is connected - via the I-Component Relay to a Virtual instance port (VIP) which is - identified with a configured service instance (I-SID) and attached to - a Provider Instance Port (PIP). The PIP is configured to be attached - to a customer Backbone port (CBP). (A point to point service instance - is illustrated. A point to multipoint service could allow more than - one CBP to be attached to a single PIP.) The CBP has a B-MAC that - defines the MAC for the PBB-TE Service Instance. That source B-MAC - address is the PIP MAC address which in the case of backbone service - instances that are supported by TE service instances is configured to - take the same value as the CBP B-MAC of the internally connected CBP - on the B-component. As a result, the backbone MAC addresses of - frames associated with traffic engineered services, the ESP-MACs, are - always equal to the CBP B-MAC. The I-Component PIP adds the ESP-MAC - DA and the ESP-MAC SA. The B-Component CBP adds the ESP-VID. GMPLS - is being defined here to connect CBP MACs to signal the PBB-TE - service Instance before the association of ESP-MAC DA and ESP-MAC SA - is defined. + In the GMPLS control plane TE Router IDs are used to identify the IB- + BEBs and Backbone Core Bridges (BCBs), and TE Links that describes + links connected to PNPs and CNPs. TE Links are not associated with + CBPs or PIPs. - The diagram also shows the addition of a TE Router ID to the PBB - switch and the TE Link identifier to enable GMPLS. TE Links are not - associated with CBPs. TE Links are associated with PNPs. TE links are - associated with bridge identifiers of backbone edge bridges (BEB) and - backbone core bridges (BCB). CBPs are also associated with these - bridge ids. For GMPLS the bridge IDs are expressed as IP addresses - as TE- Router IDs. [RFC4990] + Note that since multiple internal CBPs may exit an IB-BEB receiving a + PATH message must be able to determine the appropriate CBP that is + the termination point of the ESP. To this end, IB-BEBs SHOULD + advertises the CNP TE Links in the GMPLS control plane and RSVP-TE + signaling SHOULD use the CNP TE Links to identify the termination + point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one + of its CNPs can locally determine which CBPs have internal + connectivity to the I-component supporting the given CNP. In the case + there are more than one suitable CBPs, and no I-SID information is + provided in the PATH message or previously in the associated Call + setup, then the IB-BEB can decide freely which CBP to assign to the + requested connection. On the other hand, if there is information on + the service (I-SID) that the given ESP will support, then the IB-BEB + MUST first determine which PIP and CBP is configured with the I-SID + and MUST assign that CBP to the ESP. Backbone Edge Bridge (BEB) +------------------------------------------------------+ | | | | | I-Component Relay B-Component Relay | | +-----------------------+ +---------------------+ | | | +---+ | | B-VID | | | | |VIP| | | +---+ +---+ | | | | +---+ | +---|CBP| |PNP|------ | | | | | +---+ +---+ | | | | +---+ +---+ | | | | | - ------|CIP| |PIP|----+ | | | + ------|CNP| |PIP|----+ | | | | | +---+ +---+ | | | | | +-----------------------+ +---------------------+ | | | | PBB Edge Bridge | +------------------------------------------------------+ ^--------Configured--------------^ - ^-GMPLS or Configured-^ - - Figure 2 Ethernet/GMPLS Addressing & Label Space - TE Router ID TE Router ID - | (TE Link) | - V | V N=named port - +----+ | +-----+ - | | | label=ESP:VID/MAC DA | | - | PB | V label=ESP:VID/MMAC | | - -----N N----------------------------N PBB N---------- - | | |(MAC)| \ - | | / | Customer - +----+ /+-----+ Facing - BCB ESP:MAC BEB Ports + ^-----------GMPLS or Configured------^ - Figure 3 Ethernet/GMPLS Addressing & Label Space + Figure 1 IB-BEBs and GMPLS identifiers - For a GMPLS based system, the TE Router ID/logical port is the - logical signaling identifier for the control plane via which Ethernet - layer label bindings are solicited. In order to create a P2P path an - association must be made between the ingress and egress switch. The - actual label distributed via signaling and instantiated in the switch - forwarding tables identifies the upstream and downstream egress ESP- - VID/ESP-MAC DA of the PBB-TE ESP (see Figure 3). + Control TE Router ID TE Router ID + Plane | (TE Link) | + V | V + +----+ | +-----+ + Data | | | label=ESP:VID/MAC DA | | + Plane | | V label=ESP:VID/MMAC | | + -----N N----------------------------N N---------- + | | PBB-TE | | \ Network + | | / | Or + +----+ /+-----+ Customer + BCB ESP:MAC IB-BEB Facing + Ethernet + Ports - GMPLS uses identifiers in the form of 32 bit numbers which are in the - IP address notation which may or may not be IP addresses. The - provider MAC port addresses are exchanged by the LLDP [IEEE 802.1AB] - and by LMP [RFC4204] if supported. However these identifiers are - merely for link control and legacy Ethernet support and have local - link scope. Actual label assignment is performed by the ingress and - egress switches using CBP MAC addresses. + Figure 2 Ethernet/GMPLS Addressing & Label Space - A particular PNP would have: + PBB-TE defines the tuple of as a + unique connection identifier in the data plane but the forwarding + operation only uses the ESP-MAC DA and the ESP-VID in each direction. + The ESP-VID typically comes from a small number of VIDs dedicated to + PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement + that ESP-VIDs for two ESPs that form a P2P TESI be the same. - - A VID/MAC - - An IP address, which is typically the TE router ID, plus a 32 bit - interface Identifier also call an unnumbered link. - - One (or more) Mnemonic String Identifiers + When configuring a ESP with GMPLS, the ESP-MAC DA and ESP-VID are + carried in a generalized label object and are assigned hop by hop but + are invariant within a domain. This invariance is similar to GMPLS + operation in transparent optical networks. As is typical with other + technologies controlled by GMPLS, the data plane receiver must + accept, and usually assigns, labels from its available label pool. + This, together with the label invariance requirement mentioned above, + result in each PBB-TE Ethernet Label being a domain wide unique + label, with a unique ESP-VID + ESP-MAC DA, for each direction. - This multiple naming convention leaves the issue of resolving the set - given one of the port identifiers. On a particular switch, mapping is - relatively straightforward. Per [ARCH], standard GMPLS mechanisms - are used for signaling resolution. In so doing, the problem of - setting up a path is reduced to figuring out what switch supports an - egress CBP MAC address and then finding the corresponding egress IP - address and performing all signaling and routing with respect to the - egress. + The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P + TESI. - There are several options to achieve this: + GMPLS Upstream Label (60 bits) + GMPLS Downstream Label (60 bits) + Upstream PBB-TE ESP 3-tuple (108 bits) + Downstream PBB-TE ESP 3-tuple (108 bits) - - Provisioning - Auto discovery protocols that carry MAC address - - Augmenting Routing TE with MAC Addresses - - Name Servers with identifier/address registration - The specific procedures will be clarified in a subsequent version - of this document. + Table 1 Labels and ESPs 4. Specific Procedures -4.1. P2P connections - - The PBB-TE Service Instance is defined by the ESP 3-tuples for each - of the unidirectional ESPs. From a GMPLS control plane point of view - an Ethernet LSP is also identified as any other LSP using the 5- - tuple [Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID, - Extended_Tunnel_ID]. The ESP-VID and ESP-MAC DA tuple identifies the - forwarding multiplex at transit switches and a simple degenerate form - of the multiplex is a single P2P connection. - - This results in unique labels end to end. The data streams MAY merge, - the forwarding entries MAY be shared but the headers are still unique - allowing the connection to be de-multiplexed downstream. Note that - in addition to the ESP 3-tuples the I-SID in the I-TAG also provides - for unambiguous identification of frames belonging to a certain - service. This adds further protection against misconfiguration and - misconnectivity errors, by allowing simple detection and immediate - squelching of unintended traffic. +4.1. P2P Ethernet LSPs - On the initiating and terminating switches, a function administers - the ESP-VIDs associated with the ESP-MAC SA and ESP-MAC DA - respectively. PBB-TE is designed to be bidirectional and - symmetrically routed just like Ethernet. Therefore in PBB-TE, the - packet ESP-MAC SA and ESP- MAC DA pair is same in the forwarding path - and the associated reverse path except they are flipped in the - reverse direction. + Note, PBB-TE is designed to be bidirectional and symmetrically routed + just like Ethernet. That is, complete and proper functionality of + Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. - To initiate a bidirectional ESP-VID/ESP-MAC DA P2P or P2MP path, the - initiator of the PATH message uses procedures outlined in [RFC3473] - possibly augmented with [RFC4875], it: + To initiate a bidirectional Eth-LSP, the initiator of the PATH + message uses procedures outlined in [RFC3473], it: 1) Sets the LSP encoding type to Ethernet. - 2) Sets the LSP switching type to 802_1 PBB-TE [IANA to define]. + 2) Sets the LSP switching type to 802_1 PBB-TE suggested value 40 + [IANA to define]. - 3) Sets the GPID to service type [IANA to define]. + 3) Sets the GPID to service type. - 4) Sets the UPSTREAM_LABEL to the ESP-VID/ESP-MAC SA tuple where the - ESP-VID is administered from the configured ESP-VID/ESP-MAC DA range. + 4) Sets the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the + ESP-VID1 is administered locally for the local MAC address: MAC1 5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA. 6) Optionally look at Call / Connection ID for Carrying I-SID. Intermediate and egress switch processing is not modified by this - document, i.e., is per [RFC3473] and, in the case of P2MP, as - extended in [RFC4875]. Note, as previously stated intermediate - bridges supporting the 802_1 switching type may not modify LABEL - values. + document, i.e., is per [RFC3473]. Note, as previously stated + intermediate bridges supporting the 802_1 PBB-TE switching type MUST + NOT modify LABEL values. - The ESP-VID/ESP-MAC SA tuple contained in the UPSTREAM_LABEL is used + The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL is used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction. This behavior is - inferred from the switching type which is 802_1 [IANA to define]. - The port derived from the RSVP_HOP object and the ESP-VID and ESP- - MAC DA included in the label constitute the static entry. + inferred from the switching type which is 802_1 PBB-TE. The port + derived from the RSVP_HOP object and the ESP-VID1 and ESP- MAC1 + included in the PBB-TE Ethernet Label constitute the static entry. - At the destination, a ESP-VID is allocated in the local MAC range for - the ESP-MAC DA and the ESP-VID/ESP-MAC DA tuple is passed in a LABEL + At the destination, an ESP-VID2 is allocated for the local MAC + address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL object in the RESV message. As with the PATH message, intermediate - switch processing is per [RFC3473] and [RFC4875], and the LABEL - object is passed on unchanged, upstream. The ESP-VID/ESP-MAC DA - tuple contained in the LABEL Object is installed in the forwarding - table as a static forwarding entry at each hop. This creates a - bidirectional path as the PATH and RESV messages follow the same - path. + switch processing is per [RFC3473], and the LABEL object is passed on + unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained in the + LABEL Object is installed in the forwarding table as a static + forwarding entry at each hop. This creates a bidirectional path as + the PATH and RESV messages follow the same path. 4.1.1. Shared Forwarding One capability of a connectionless Ethernet data plane is to reuse destination forwarding entries for packets from any source within a VLAN to a destination. When setting up P2P PBB-TE connections for multiple sources sharing a common destination this capability MAY be preserved provided certain requirements are met. We refer to this capability as Shared Forwarding. Shared forwarding is invoked based - on policy when conditions are met. It is a local decision by label - allocation at each end. Shared forwarding has no impact on the actual - paths setup, but it allows the reduction of forwarding entries. - Shared forwarding paths are identical to independently routed paths - with the exception that they share the same labels and same path from - the merge point. + allocation at each end plus the path constraints. Shared forwarding + has no impact on the actual paths setup, but it allows the reduction + of forwarding entries. Shared forwarding paths are identical in + function to independently routed paths that share a path from an + intersecting switch or link except they share a single forwarding + entry. - To achieve shared forwarding, a Path computation engine [PATHCOMP] - should ensure the ERO is consistent with an existing path for the - shared segments. If a path satisfies the consistency check, the - upstream end of the signaling may chose to share an existing ESP- - VID/ESP-MAC DA for the upstream traffic with an existing Eth-LSP. - The criteria for shared forwarding is the Eth-LSPs must share the - same destination port and the paths of the Eth-LSP share one or more - hops consecutively. Once the paths converge they must remain - converged. If no existing path has this behavior when a new path is - being created, the new path will be created without sharing either by - using another ESP-VID or another ESP-MAC DA or both. + Share forwarding savings can be quite dramatic in some topologies + where a high degree of meshing is required however it is typically + easier to achieve when the connectivity is know in advance. Normally + the originating GMPLS switch will not have knowledge of the set of + shared forwarding paths rooted on the source or destination switch. - In other words, shared forwarding is possible when paths share - segments either from the source or the destination. There is no - requirement that the paths share reservations or other attributes. - For the source, the UPSTREAM_LABEL is chosen to be the same as an - existing path that shares the ERO for some number of hops. Similarly - for the destination, shared forwarding is possible when an existing - path that shares segments with the new paths ERO, viewed from the - destination switch. The downstream label in this case is chosen to - be the same as the existing path. In this manner shared forwarding is - a function that is controlled primarily by policy and in combination - with the local label allocation at the end points of the path. + Use of a Path Computation Server [PATHCOMP] or other planning style + of tool with more complete knowledge of the network configuration is + a way to impose pre-selection of shared forwarding multiplexes to use + for both directions. In this scenario the originating switch uses + the LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the + shared forwarding multiplexes at both ends. -4.1.2. P2P connections with shared forwarding +4.1.2. P2P connections procedures for shared forwarding The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding identifier or label for a multiplex consisting of some number of P2P connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- - MAC SA tuple. In some ways this is analogous to an LDP label merge - but in the shared forwarding case only the forwarding entry is - reused. Resources can continue to be allocated per LSP. + MAC SA tuple. This is analogous to an LDP label merge but in the + shared forwarding case the original ESP header still identifies the + complete path. Resources can continue to be allocated per LSP with + Shared forwarding. VLAN tagged Ethernet packets include priority marking. Priority bits MAY be used to indicate class of Service (COS) and drop priority. Thus, traffic from multiple COSs could be multiplexed on the same Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are made based on the p-bits. This means that the queue selection can be done based on a per flow (i.e., Eth-LSP + priority) basis and is decoupled from the actual steering of the packet at any given switch. A switch terminating an Eth-LSP will frequently have more than one - suitable candidate path and it may choose to share a forwarding entry - (common ESP-VID/ESP-MAC DA, unique ESP-MAC SA). It is a local - - decision of how this is performed but the best choice is a path that - maximizes the shared forwarding. + suitable candidate for sharing a forwarding entry (common ESP- + VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how + this is performed but the best choice is a path that maximizes the + shared forwarding. The concept of bandwidth management still applies equally well with shared forwarding. As an example consider a PBB-TE edge switch that terminates an Ethernet LSP with the following attributes: bandwidth B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D, ESP-MAC SA S2, ESP-VID V) can be accepted provided there is sufficient link capacity remaining. -4.1.3. Dynamic P2P symmetry with shared forwarding - - Similar to how a destination switch MAY select a ESP-VID/ESP-MAC DA - from the set of existing shared forwarding multiplexes rooted at the - destination switch, the originating switch MAY also do so for the - reverse path. Once the initial ERO has been computed and the set of - existing Ethernet LSPs that include the target ESP-MAC DA have been - pruned, the originating switch may select the optimal (by whatever - criteria) existing shared forwarding multiplex for the new - destination to merge with and offer its own ESP-VID/ESP-MAC DA tuple - for itself as a destination. - -4.1.4. Planned P2P symmetry - - Normally the originating switch will not have knowledge of the set of - shared forwarding paths rooted on the destination switch. - - Use of a Path Computation Server [PATHCOMP] or other planning style - of tool with more complete knowledge of the network configuration may - wish to impose pre-selection of shared forwarding multiplexes to use - for both directions. In this scenario the originating switch uses - the LABEL_SET and UPSTREAM_LABEL objects to indicate complete - selection of the shared forwarding multiplexes at both ends. This may - also result in the establishment of a new ESP-VID/ESP-MAC DA path as - the LABEL_SET object may legitimately refer to a path that does not - yet exist. - -4.1.5. P2P Path Maintenance +4.1.3. P2P Path Maintenance Make before break procedures can be employed to modify the - characteristics of a P2P Ethernet LSP. As described in [RFC3209], the - LSP ID in the sender template is updated as the new path is signaled. - The procedures (including those for shared forwarding) are identical - to those employed in establishing a new LSP, with the extended tunnel - ID in the signaling exchange ensuring that double booking of the + characteristics of a P2P Eth LSP. As described in [RFC3209], the LSP + ID in the sender template is updated as the new path is signaled. The + procedures (including those for shared forwarding) are identical to + those employed in establishing a new LSP, with the extended tunnel ID + in the signaling exchange ensuring that double booking of the associated resources does not occur. Where individual paths in a protection group are modified, signaling procedures may be combined with Protection Switching (PS) coordination to administratively force PS switching operations such that modifications are only ever performed on the protection path. -4.2. P2MP Signaling - - Note specifics for P2MP paths are being defined. This section will be - updated to align with the PBB-TE specification [IEEE 802.1Qay]. - - To initiate a P2MP VID/Multicast MAC (MMAC) path the initiator of the - PATH message uses procedures outlined in [RFC3473] and [RFC4875]. A - P2MP tree consists of a VID tree forward direction (from root to - leaves) and a set of P2P paths running on identical paths from Tree - leaves to root in the reverse direction. The result is a composite - path with a ESP- MMAC DA label with a single ESP-MMAC DA in the - forward direction and a symmetric set of unidirectional ESP-VID/ESP- - MAC DA labels in the reverse direction: - - 1-4) Same points as P2P paths previously specified. - - 5) Sets the downstream label as the ESP-MMAC DA. - -4.3. P2MP ESP-MAC DA Connections +4.2. P2MP Ethernet-LSPs -4.3.1. Setup procedures + PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In P2MP + the whole tree in the forward direction has the same destination MMAC + ESP-MAC-DA. - The group ESP-MMAC DA is administered from a central pool of - multicast addresses and the VLAN selected from the PBB-TE VID range. - The P2MP tree is constructed via incremental addition of leaves to - the tree in signaling exchanges where the root is the originating - switch (as per (RFC4875). The multicast VID/ESP-MMAC DA is encoded in - the LABEL_SET (as a member of one) object using the Ethernet label - encoding. + The procedures outlined in [RFC3473] and [RFC4875]could be adapted to + signal P2MP LSPs for the source (point) to destination (multipoint) + direction. Each one of the branches of the P2MP Eth-LSP would be + associated with a reverse path symmetric and congruent P2P Eth-LSP. - Where a return path is required the unicast MAC corresponding to the - originating interface and a VID selected from the configured VID/ESP- - MAC DA range is encoded as an Ethernet label in the UPSTREAM_LABEL - object. + Complete procedures for signaling bidirectional P2MP are out of scope + for this document. -4.3.2. Maintenance Procedures +4.2.1. Maintenance Procedures Maintenance and modification to a P2MP tree can be achieved by a number of means. The preferred technique is to modify existing VLAN configuration vs. assignment of a new label and completely constructing a new tree. Make before break on a live tree reusing existing label assignments requires a 1:1 or 1+1 construct. The protection switch state of the traffic is forced on the working tree and locked (PS not allowed) while the backup tree is modified. Explicit path tear of leaves to be modified is required to ensure no loops are left behind as artifacts of tree modification. Once modifications are complete, a forced switch to the backup tree occurs and the original tree may be similarly modified. This also suggests that 1+1 or 1:1 resilience can be achieved for P2MP trees for any single failure (switch on any failure and use restoration techniques to repair the failed tree). -4.4. Ethernet Label +4.3. PBB-TE Ethernet Label - The Ethernet label is a new generalized label with a suggested format - of: + The PBB-TE Ethernet Label is a new generalized label with the + following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Figure 3 PBB-TE Ethernet Label - This format can be used to carry P2P and P2MP labels. For P2P labels - the fields specify ESP . The semantics for a P2MP label - using a MMAC DA is that that the label is passed unchanged. This - label is also a domain wide label. This has similarity to the way in - which a wavelength label is handled at an intermediate switch that - cannot perform wavelength conversion, and is described in [RFC3473]. + This format is used to carry for both P2P and P2MP Eth-LSPs. For P2P + Eth-LSPs labels the fields specify a VID and a unicast MAC address, + while for P2MP Eth-LSPs a VID and a group MAC address is carried in + the label. The PBB-TE Ethernet Label is a domain wide unique label + and MUST be passed unchanged at each hop. This has similarity to the + way in which a wavelength label is handled at an intermediate switch + that cannot perform wavelength conversion, and is described in + [RFC3473]. - Label Allocation for Domain wide labels is similar to other label - switching technologies with the exception that the labels are owned - by the switch where the path is terminated. In Ethernet, unique MAC - based labels can be created using one of two methods. One option is - to allocate the ESP-MAC DAs from globally unique addresses assigned - to the either the switch manufacturer. The other option is to use - ESP-MAC DAs out of the local admin space and ensure these labels are - unique within the domain. Labels only have significance within the - domain. +4.4. Protection Paths - In the case of local label allocation there is no need to use - globally assigned OUIs. However when using this configuration, some - way of ensuring label consistency should be provided to make sure - that labels were unique. When using GMPLS signaling it is assumed a - unique pool of labels would be owned or assigned to each switch. The - ESP-MAC DA addresses are domain wide unique and so is the combination - of ESP . It is intended that the ESP be - only used by one destination. However, should an error occur and a - somehow a duplicate label be assigned to one or more destination - switches GMPLS signaling procedures would allow the first assignment - of the label and prevent any duplicate label from colliding. If a - collision occurs an alarm would be generated. In fact some of these - procedures have been defined in GMPLS control of photonic networks - where a lambda may exist as a form of domain wide label. + When protection is used for path recovery it is required to associate + the working and protection paths into a protection group. This is + achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION + and PROTECTION objects. -4.5. OAM MEP ID and MA ID synchronization +4.5. Service Instance Identification - This section is aligned with [IEEE 802.1Qay]. At present Ethernet OAM - is signaled in Ethernet protocol data units. Extensions to GMPLS - [OAM-EXT] are proposed to automatically setup OAM for Ethernet LSPs. + The I-SID is used to uniquely identify services within the network. + Unambiguous identification is achieved by ensuring global uniqueness + of the I-SIDs within the network or at least between any pair of edge + switches. On IB-BEBs the Backbone Service Instance Table is used to + configure the mapping between I-SIDs and ESPs. This configuration can + be either manual or semi-automated by signaling described here. - The Maintenance association point IDs (MEP IDs) and maintenance - association IDs for the switched path endpoints can be synchronized - using the ETH-MCC (maintenance communication channel) transaction set - once the switched path has been established. + RSVP-TE signaling can be used to automate I-SID to ESP mapping. By + relying on signaling it is ensured that the same I-SID is assigned to + the service and mapped to the same ESP. Note, by signaling the I-SID + associated to the ESP one can ensure that IB-BEBs select the + appropriate CBP port. - MEPs are located at the endpoints of the Ethernet LSP. Typical - configuration associated with a MEP is Maintenance Domain Name, Short - Maintenance Association Name, and MD Level, MEP ID, and CCM - transmission rate (when ETH-CC functionality is desired). As part of - the synchronization, it is verified that the Maintenance Domain Name, - Short Maintenance Association Name, MD Level, and CCM transmission - rate are the same. It is also determined that MEP IDs are unique for - each MEP. + The CALL signaling [RFC4974] can be used to create the I-SID + association between the endpoints prior to Eth-LSP establishment. + Alternatively, the PATH messages can carry the I-SID association at + the time of Eth-LSP signaling. Therefore it is possible to create I- + SID association either when the path is set up or at a later time. - Besides the unicast CCM functionality, the PBB-TE MEPs can also offer - the LBM/LBR and LMM/LMR functionalities for on-demand connectivity - verification and loss measurement purposes. + A new Service ID TLV is defined for the CALL_ATTRIBUTES object. The + format is depicted below. -4.6. Protection Paths + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (TBA) | Length (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | I-SID Set 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : + : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | I-SID Set n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Figure 4 Service ID TLV - The IEEE is currently defining protection procedures for PBB-TE [IEEE - 802.1Qay]. This section will be updated when these procedures are - documented. + - Flags: are used to control properties of service configuration. + This document does not define flags. - When protection is used for path recovery it is required to associate - the working and protection paths into a protection group. This is - achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION - and PROTECTION objects. Protection may be used for P2P VID/ESP-MAC - DA, P2MP VID/ESP-MMAC DA and P2MP VID configured modes of operation. - The 'P' bit in the protection object indicates the role (working or - protection) of the LSP currently being signaled. + - I-SID Set TLV: is used to define a list or range of I-SIDs. + Multiple I-SID Set TLVs can be present. At least one I-SID Set + TLV MUST be present. In most of the cases a single I-SID Set with + a single I-SID value is used. The I-SID Set TLV is used to define + a list or range of I-SIDs. The format of the I-SID Set TLV is + based on the LABEL_SET Object: + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | I-SID 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : + : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | I-SID n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Figure 5 I-SID Set TLV + - Action: 8 bits - If the initiating switch wishes to use G.8031 [G-8031] data plane - protection switching coordination (vs. control plane notifications), - it sets the N bit to 1 in the protection object. This must be - consistently applied for all paths associated as a protection group. + The following actions are defined: list (0), range (1). - If the terminating switch does not support G.8031, the error - "Admission Control Failure/Unsupported Notification Type" is used. + - I-SID: 24 bits + + The I-SID value identifies a particular backbone service + instance. 5. Error conditions - The following errors have been identified as being unique to these - procedures and in addition to those already defined. This will be - addressed in a proper IANA considerations section in a future version - of the document: + The following errors are possible. They are extension of some base + error types that arise due to the constraints on the label. -5.1. Invalid ESP-VID value for PBB-TE MSTI range +5.1. Invalid ESP-VID value for PBB-TE The originator of the error is not configured to use the ESP-VID - value in conjunction with GMPLS signaling of - tuples. This may be originated by any switch along the path. + value for PBB-TE in conjunction with GMPLS signaling of tuples. This may be originated by any switch along the path. + + Note this is a refinement of the more general Unacceptable label + value Error code. 5.2. Invalid MAC Address The MAC address is out of a reserved range that cannot be used by the switch which is processing the address. While almost all MAC addresses are valid there are a small number of IEEE reserved MAC addresses. -5.3. Invalid ERO for UPSTREAM_LABEL Object - - The ERO offered has discontinuities with the identified ESP- - VID/ESP-MAC DA path in the UPSTREAM_LABEL object. - -5.4. Invalid ERO for LABEL_SET Object - - The ERO offered has discontinuities with the identified ESP-VID/ESP- - MAC DA path in the LABEL_SET object. + Note this is a refinement of the more general Unacceptable label + value Error code. -5.5. Switch is not ESP P2MP capable +5.3. Switch is not ESP P2MP capable This error may arise only in P2MP Tree allocation. -5.6. Invalid ESP-VID in UPSTREAM_LABEL object - - The ESP-VID in the UPSTREAM_LABEL object for the "asymmetrical ESP- - VID" P2MP tree did not correspond to the ESP-VID used in previous - transactions. - -6. Deployment Scenarios - - Deployment scenarios are covered in [ARCH]. This section will detail - more specific PBB-TE deployment scenarios in a later revision of this - document. - -7. Security Considerations +6. Security Considerations The architecture assumes that the GMPLS controlled Ethernet subnet consists of trusted devices and that the UNI ports or in this case BEB Ethernet UNI Ports to the domain are untrusted. Care is required to ensure untrusted access to the trusted domain does not occur. 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. -8. IANA Considerations +7. IANA Considerations - New values are required for signaling and error codes as indicated. - This section will be completed in a later version. + New values are required for signaling and error codes as indicated + IANA to define. Value are needed for: -9. References + - Switching type: 802_1 PBB-TE suggested value 40. -9.1. Normative References +7.1. Error Codes + + - Invalid ESP-VID value for PBB-TE + - Invalid MAC Address + - Switch is not ESP P2MP capable + +8. References + +8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label Switching Architecture and Framework", work in progress. [RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003. [RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", IETF RFC 3945, October 2004. -9.2. Informative References +8.2. Informative References [IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic Engineering", work in progress. - [RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate, - Three-Color Marker with Efficient Handling of in-Profile Traffic", - [G-8031] ITU-T Recommendation G.8031 (2006), Ethernet Protection - Switching. - - [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area - Networks, Station and Media Access Control Connectivity - Discovery". - [IEEE 802.1ag] "IEEE Standard for Connectivity Fault Management", (2007). [IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", (2008) - - [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, - October 2005 - [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services - Definitions - Phase I". - - [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services - Attributes Phase 1". - - [RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching - (MPLS) Support of Differentiated Services" IETF RFC 3270, May - 2002. - [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to [PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE) Architecture", work in progress. - [RFC3985] Bryant, S., Pate, P. et al., "Pseudo Wire Emulation Edge- - to Edge (PWE3) Architecture", IETF RFC 3985, March 2005. - - [RFC4872] Lang et.al., "RSVP-TE Extensions in support of End-to-End + [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of 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. - [RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP + [RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, December 2001. + [RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS) + RSVP-TE Signaling Extensions in Support of Calls", August 2007. + [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions and Mechanisms for Ethernet based Networks ", (2006). - [RFC4990] Shimoto, K., Papneja, R., Rabbat, R., "Use of Addresses in - Generalized Multi-Protocol Label Switching (GMPLS) Networks", - IETF RFC4990, September 2007. - - [OAM-EXT] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to Control - Ethernet OAM", work in progress. - -10. Acknowledgments +9. Acknowledgments The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen Shew, Dave Martin and Sandra Ballarte for their contributions to this document. -11. Author's Address +10. Author's Address Don Fedyk Nortel Networks 600 Technology Park Drive Billerica, MA, 01821 Email: dwfedyk@nortel.com David Allan Nortel Networks 3500 Carling Ave. @@ -923,412 +742,11 @@ COO RTP IE Fixed 3 Hanagar St. Neve Ne'eman B, 45241 Hod Hasharon, Israel Email: nurit.sprecher@nsn.com Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net - A. Rational and mechanism for PBB_TE Ethernet Forwarding - - This appendix describes work currently being undertaken in the 802.1 - PBB-TE [IEEE 802.1Qay] project. This information is for reference - only and will be removed when 802.1Qay becomes mature. This text - captures some of the original rational for changing Ethernet - forwarding. The PBB-TE [IEEE 802.1Qay] document simply documents the - PBB-TE data plane. - - Ethernet as specified today is a complete system consisting of a data - plane and a number of control plane functions. Spanning tree, data - plane flooding and MAC learning combine to populate forwarding tables - and produce resilient any-to-any behavior in a bridged network. - - Ethernet consists of a very simple and reliable data plane that has - been optimized and mass produced. By simply disabling some Ethernet - control plane functionality, it is possible to employ alternative - control planes and obtain different forwarding behaviors. - - Customer Provider Provider - Bridge/ Bridge Backbone - Bridge - - C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID - S-VID-----------802.1ad------------S-VID - B-MAC---802.1ah---B-MAC - B-VID---802.1ah---B-VID - - Figure A.1 802.1 MAC/VLAN Hierarchy - - Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 are - defining a separation of Ethernet functions permitting an increasing - degree of provider control. The result is that the Ethernet service - to the customer appears the same, yet the provider components and - behaviors have become decoupled from the customer presentation and - the provider has gained control of all VID/B-MAC endpoints. - - One example of this is the 802.1ah work in hierarchical bridging - whereby customer Ethernet frames are fully encapsulated into a - provider Ethernet frame, isolating the customer VID/C-MAC space from - the provider VID/B-MAC space. In this case, the forwarding behavior - of the of the Backbone MAC in the provider's network is as per - 802.1Q. - - The Ethernet data plane provides protocol multiplexing via the - Ethertype field which allows encapsulation of different protocols - supporting various applications. More recently, the Carrier Ethernet - effort has created provider and customer separation that enables - another level of multiplexing. This in effect creates provider MAC - endpoints in the Ethernet sub-network controlled by the provider. In - this appendix we concentrate on the provider solutions and therefore - subsequent references to VLAN, VID and MAC refer to those under - provider control, be it in the backbone layer of 802.1ah. The - Customer Ethernet service is the same native Ethernet service with - functions such as bridging, learning and spanning trees all - functioning over the provider infrastructure. - - Bridging offers a simple solution for any-to-any connectivity within - a VLAN partition via the Spanning tree, flooding and MAC learning. - Spanning tree provides some unnecessary capabilities for P2P services - and since the Spanning tree must interconnect all MACs with the same - VLAN IDs (VIDs) it consumes a scarce resource (VIDs). In this - document we present that it is easier to modify Ethernet to scale - engineered P2P services and this is the approach we take with PBB-TE. - (The number of usable VLANs IDs in conventional Ethernet bridging is - constrained to 4094, therefore the use of VLAN only configuration for - all forwarding could be limited for some applications where large - number of P2P connections are required.) This is because in - Ethernet, each Spanning tree is associated with one or more VLAN IDs. - Also Port membership in a VLAN is configured which controls the - connectivity of all MAC interfaces participating in the VLAN. - - The roots for PBB-TE capability exist in the Ethernet management - plane. The management of Ethernet switches provides for static - configuration of Ethernet forwarding. The Ethernet Control plane - allows for forwarding entries that are statically provisioned or - configured. In this document we are expanding the meaning of - "configured" from an Ethernet Control plane sense to mean either - provisioned, or controlled by GMPLS. The connectivity aspects of - Ethernet forwarding is based upon VLANs and MAC addresses. In other - words the VLAN + DMAC are an Ethernet Label that can be looked up at - each switch to determine the egress link (or links in the case of - link aggregation). - - This is a finer granularity than traditional VLAN networks since each - P2P connection is independent. By provisioning MAC addresses - independently of Spanning tree in a domain, both the VLAN and the - VLAN/DMAC configured forwarding can be exploited. This greatly - extends the scalability of what can be achieved in a pure Ethernet - bridged sub network. - - The global/domain wide uniqueness and semantics of MAC addresses as - interface names or multicast group addresses has been preserved. (In - Ethernet overlap of MAC addresses across VLANs is allowed. However - for PBB-TE MAC addresses should be unique for all VLANs assigned to - PBB-TE. With PBB-TE it is an operational choice if the operator uses - PBT-TE labels out of the global MAC address space or the local admin - space.) We then redefine the semantics associated with administration - and uses of VLAN values for the case of explicit forwarding such as - with statically configured Ethernet. - - The PBB_TE is Ethernet Forwarding where configured VID + DMAC provide - a forwarding table that is consistent with existing PBB and Ethernet - switching. At the same time it provides domain wide labels that can - be controlled by a common GMPLS control plane. This makes GMPLS - control and resource management procedures ideal to create paths. The - outcome is that the GMPLS control plane can be utilized to set up the - following atomic modes of connectivity: - - 1) P2P connectivity and MP2P multiplexed connectivity based - on configuration of unicast MAC addresses in conjunction - with a VID from a set of pre-configured VIDs. - 2) P2MP connectivity based on configuration of multicast MAC - address in conjunction with a VID from a set of pre- - configured VIDs. This corresponds to (Source, Group) or - (S,G) multicast. - 3) P2MP connectivity based on configuration of VID port - membership. This corresponds to (S,*) or (*,*) multicast - (where * represents the extent of the VLAN Tree). - 4) MP2MP connectivity based on configuration of VID port - membership (P2MP trees in which leaves are permitted to - communicate). Although, we caution that this approach - poses resilience issues (discussed in section 5) and hence - is not recommended. - - The modes above are not completely distinct. Some modes involve - combinations of P2P connections in one direction and MP connectivity - in the other direction. Also, more than one mode may be combined in - a single GMPLS transaction. One example is the incremental addition - of a leaf to a P2MP tree with a corresponding MP2P return path - (analogous to a root initiated join). - - In order to realize the above connectivity modes, a partition of the - VLAN IDs from traditional Ethernet needs to be established. The - partition allows for a pool of Ethernet labels for manual - configuration and/or for GMPLS control plane usage. The VID partition - actually consists of a "configured VID/DMAC range" and "configured - VID range" since in some instances the label is a VID/ DMAC and - sometimes the label is a VID/Multicast DMAC. - - A.1. Overview of configuration of VID/DMAC tuples - - Statically configured MAC and VID entries are a complete 60 bit - lookup. The basic operation of an Ethernet switch is filtering on VID - and forwarding on DMAC. The resulting operation is the same as - performing a full 60 bit lookup (VID (12) + DMAC(48)) for P2P - operations, only requiring uniqueness of the full 60 bits for - forwarding to resolve correctly. This is an Ethernet domain wide - label. - - Complete route freedom is available for each domain wide label (60 - bit VLAN/DMAC tuple) and the ability to define multiple connectivity - instances or paths per DMAC for each of the VIDs in the "configured - VID/DMAC range". - - The semantics of MAC addresses are preserved, and simply broaden the - potential interpretations of VLAN ID from spanning tree identifier to - topology instance identifier. Therefore, operation of both standard - bridging and configured unicast/multicast operation is available side - by side. The VID space is partitioned and a range of VIDs is - allocated(say 'n' VIDs) as only significant when combined with a - configured DMAC address (the aforementioned "configured VID/DMAC - range" of VIDs). A VID in that range is considered as an individual - connectivity instance identifier for a configured P2P path - terminating at the associated DMAC address. Or in the case of P2MP, a - P2MP multicast tree corresponding to the destination multicast group - address. Note that this is destination based forwarding consistent - with how Ethernet works today. The only thing changed is the - mechanism of populating the forwarding tables. - - Ethernet MAC addresses are typically globally unique since the 48 - bits consists of 24 bit Organizational Unique Identifier and a 24 bit - serial number. There is also a bit set aside for Multicast and for - local addresses out of the OUI field. We define domain wide as within - a single organization, or more strictly within a single network - within an organization. For provider MAC addresses that will only be - used in a domain wide sense we can define MAC addresses out of a - either the local space or the global space since they both have the - domain wide unique property. When used in the context of GMPLS, it is - useful to think of a domain wide pool of labels where switches are - assigned a set of MAC addresses. These labels are assigned traffic - that terminates on the respective switches. - - It is also worth noting that unique identification of source in the - form of the ESP-MAC SA is carried e2e in the MAC header. So although - we have a 60 bit domain wide unique label, it may be shared by - multiple sources and the full connection identifier for an individual - P2P instance is 108 bits (ESP-MAC SA, VID and DMAC). The ESP-MAC SA - is not referenced in forwarding operations but it would allow - additional context for tracing or other operations at the end of the - path. - - For multicast group addresses, the VID/DMAC concatenated label can be - distributed by the source but label assignment (as it encodes global - multicast group information) requires coordination within the GMPLS - controlled domain. - - As mentioned earlier, this technique results in a single unique and - invariant identifier, in our case a VID/DMAC label associated with - the path termination or the multicast group. There can be up to 4094 - labels to any one MAC address. However, practically, from an - Ethernet network wide aspect; there would be only a handful of VLANs - allocated for PBB-TE. In addition, all 48 bits are not completely - available for the MAC addresses. One way to maximize the space is to - use the locally administered space. This is a large number for - - P2P applications and even larger when shared or multiplexed - forwarding is leveraged. In practice, most network scaling - requirements may be met via allocation of only a small portion of the - VID space, to the configured VID/DMAC range. The result is minimal - impact on the number of remaining bridging VLANs that can be - concurrently supported. - - In order to use this unique 60 bit label, we disable the normal - mechanisms by which Ethernet populates the forwarding table for the - allocated range of VIDs. When a path is setup, for a specific label - across a contiguous sequence of Ethernet switches, a unidirectional - connection is the functional building block for an Ethernet Label - Switched path (Eth-LSP). - - In P2P mode a bidirectional path is composed of two unidirectional - paths that are created with a single RSVP-TE session. The technique - does not require the VID to be common in both directions. However, - keeping in line with regular Ethernet these paths are symmetrical - such that a single bidirectional connection is composed of two - unidirectional paths that have common routing (i.e. traverse the same - switches and links) in the network and hence share the same fate. - - In P2MP mode a bidirectional path is composed of a unidirectional - multicast tree and a number of P2P paths from the leaves of the tree - to the root. Similarly these paths may have bandwidth and must have - common routing as in the P2P case. - - There are a few modifications required to standard Ethernet to make - this approach robust: - - 1. In Standard Ethernet, discrepancies in forwarding table - configuration in the path of a connection will normally result in - packets being flooded as "unknown". For configured operation (e.g. - PBB-TE), unknown addresses are indicative of a fault or configuration - error and the flooding of these is undesirable in meshed topologies. - Therefore flooding of "unknown" unicast/multicast MAC addresses must - be disabled for the "configured VID/DMAC range". - - 2. MAC learning is not required, and although it will not interfere - with management/control population of the forwarding tables, since - static entries are not overridden, it appears prudent to explicitly - disable MAC learning for the configured VID/DMAC and VID range. - - 3. Spanning tree is disabled for the allocated VID/DMAC and VID range - and port blocking must be disabled to achieve complete configured - route freedom. As noted earlier, it is a control plane requirement to - ensure configured paths are loop free. - - All three modifications described above are within the scope of - acceptable configuration options defined in IEEE 802.1Q - specification. - - A.2 Overview of configuration of VID port membership - - Procedures almost identical to that for configuration of P2P VID/DMAC - tuples can also be used for the incremental configuration of P2MP VID - trees. For the replication of forwarding in this case the label is - common for the multipoint destinations. The MAC field is set to - multicast address and is common to the multicast community. The VID - is a distinguisher common to the multicast community. The signaling - procedures are per that for [RFC4875]. - - Since VID translation is relatively new and is not a ubiquitously - deployed capability, we consider a VID to be a domain global value. - Therefore, the VID value to be used by the originating switch may be - assigned by management and nominally is required to be invariant - across the network. The ability to indicate permissibility of - translation will be addressed in a future version of the document. - - A procedure known as "asymmetrical VID" may be employed to constrain - connectivity (root to leaves, and leaves to root only) when switches - also support shared VLAN learning (or SVL). This would be consistent - with the root as a point of failure. - - A.3 OAM Aspects - - Robustness is enhanced with the addition of data plane OAM to provide - both fault and performance management. - - For the configured VID/DMAC unicast mode of behavior, the hardware - performs unicast packet forwarding of known MAC addresses exactly as - Ethernet currently operates. The OAM currently defined, [802.1ag and - Y.1731] can also be reused minor modification of the protocols. - - An additional benefit of domain wide path identifiers, for data plane - forwarding, is the tight coupling of the 60 bit unique connection ID - (VID/DMAC) and the associated OAM packets. It is a simple matter to - determine a broken path or misdirected packet since the unique - connection ID cannot be altered on the Eth-LSP. This is in fact one - of the most powerful and unique aspects of the domain wide label for - any type of rapid diagnosis of the data plane faults. It is also - independent of the control plane so it works equally well for - provisioned or GMPLS controlled paths. - - Bidirectional transactions (e.g. ETH-LB) and reverse direction - transactions MAY have a different VID for each direction. PBB-TE is - specifying this aspect of CFM. - - For configured multicast VID/DMAC mode, the current versions of - 802.1ag and Y.1731] make no representation as to how PDUs which are - not using unicast addresses or which use OAM reserved multicast - - addresses are handled. Therefore this specification makes no - representation as to whether such trees can be instrumented. - - When configured VID mode of operation is used PBB-TE can be forced to - use the same VID in both directions, emulating the current Ethernet - data plane and the OAM functions as defined in the current versions - of 802.1ag and Y.1731 can be used with no restriction. - - A.4 QOS Aspects - - Ethernet VLAN tags include priority tagging in the form of the PCP - priority bits. When combined with configuration of the paths via - management or control plane, priority tagging produces the Ethernet - equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged Ethernet - PDUs self-identify the required queuing discipline independent of the - configured connectivity. - - It should be noted that the consequence of this is that there is a - common COS model across the different modes of configured operation - specified in this document. - - The actual QOS objects required for signaling will be in a future - version of this memo. - - A.5 Resiliency Aspects - - A.5.1 E2E Path protection - - One plus One(1+1) protection is a primary LSP with a disjoint - dedicated back up LSP. One for one (1:1) protection is a primary LSP - with a disjoint backup LSP that may share resources with other LSPs. - One plus One and One for One Automatic Protection Switching - strategies are supported. Such schemes offer: - 1) Engineered disjoint protection paths that can protect both - directions of traffic. - 2) Fast switchover due to tunable OAM mechanisms. - 3) Revertive path capability when primary paths are restored. - 4) Option for redialing paths under failure. - - Specific procedures for establishment of protection paths and - associating paths into "protection groups" are TBD. - - Note that E2E path protection is able to respond to failures with a - number of configurable intervals. The loss of CCM OAM frames in the - data plane can trigger paths to switch. In the case of CCM OAM - frames, the detection time is typically 3.5 times the CCM interval - plus the propagation delay from the fault. - -12. 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. - -13. Intellectual Property - - 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 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. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - -Generated on: Mon Jul 14 00:52:55 EDT 2008 +Generated on: Wed Feb 25 13:53:58 EST 2009