Network Working Group Marc Holness Michael Chen Internet Draft: Dinesh Mohan draft-holness-network-l2vpsp-02.txt Nortel Networks Category: Informational Expiration Date: October 2004 April 2004 The Nortel Networks Ethernet Layer 2 Virtual Private Service Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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 Abstract This draft specifies an Ethernet Layer 2 Virtual Private Service Protocol using Ethernet addressing hierarchy and service separation. This protocol enables Service Providers to deploy an Ethernet Network and offer scalable and manageable layer 2 Transparent LAN Services (L2TLS). The primary goal of this protocol is to eliminate the need of the Service Provider to manage customer address information and forwarding within its network. Another goal is to allow auto provisioning of VPN service instances within the Service Provider networks. This solution maintains customer benefits of simplicity of access to the VPN, allows efficient utilization of Service Provider network resources, and overcomes distance limitations of customer's LANs. Holness, et. al Informational [Page 1] The Nortel Networks Ethernet Layer 2 VPS Protocol Table of Contents Status of this Memo............................................1 Abstract.......................................................1 1. Introduction................................................2 1.1 Transparent Domain.........................................3 1.2 Transparent Domain Identifier..............................3 1.3 Network Devices............................................3 1.4 User-Network Interface.....................................4 1.5 Network-Network Interface..................................4 1.6 Common Abbreviations.......................................4 2. Protocol Operation..........................................5 2.1.2 Handling Traffic Leaving SP Network......................6 2.2 P Device Encapsulation and Forwarding Operation............7 2.2.1 Receiving SP Network Data Traffic........................7 2.2.2 Transmitting SP Network Data Traffic.....................7 2.3 Protocol Information Element Formats.......................7 2.3.1 Service Header...........................................7 2.3.2 Version (VER)............................................8 2.3.3 Node Mode (M)............................................8 2.3.4 Type (T).................................................8 2.3.5 Reserved.................................................9 2.3.6 TDI......................................................9 3. Packet Flow.................................................9 3.1 Service Tunnel Discovery Procedure.........................11 4. Quality of Service Handling.................................14 5. Management of Ethernet Layer 2 Virtual Private Service .....15 6. Security Considerations.....................................15 7. Intellectual Property Considerations........................15 8. References..................................................15 9. Acknowledgements............................................16 11. Full Copyright Statement...................................16 1. Introduction This draft specifies an Ethernet Layer 2 Virtual Private Service Protocol using Ethernet addressing hierarchy and service separation. This protocol enables Service Providers (SPs) to deploy an Ethernet Network and offer scalable and manageable layer 2 Transparent LAN Services (L2TLS), which is a specialized layer 2 VPN service offering. The primary goal of this protocol is to eliminate the need of a SP to manage customer address information and forwarding within its network. Another goal is to allow auto provisioning of VPN service instances within SP networks. This solution maintains customer benefits of simplicity of access to the VPN, allows efficient utilization of SP network resources, and overcomes distance limitations of customer's LANs. A VPN is a service in which a SP provides a customer with what appears to be a network of dedicated resources, when in fact the information is running over a shared infrastructure. Holness, et. al Informational [Page 2] The Nortel Networks Ethernet Layer 2 VPS Protocol VPNs deliver the benefits of a private network (security and availability) and the benefits of a public network (economies of scale and freedom from management burden). L2TLS is straightforward for SPs to provision and simple for customer to use. With an Ethernet network, customers work with familiar technology, thus decreasing their administrative costs and providing a seamless connection to the SP network. Because a L2TLS is fully managed by the SP, the customer is relieved of additional maintenance tasks. A SP network realizing L2TLS service is henceforth called a L2TLS network in this draft. 1.1 Transparent Domain A transparent domain (TD) denotes the SP resources used to support a transparent network dedicated to serving a single customer (seen from the customer's perspective). The resources in a TD are only visible to the SP. They are transparent to the customer. Customer traffic from different TDs is kept separate by an Ethernet tunneling mechanism. Each TD has no visibility of other TDs inside the SP network. Consequently, a TD is a secure, logical separation of SP resources. The customer can view the TD as an instance of a single virtual Ethernet switch that spans the L2TLS network, providing isolation of layer 2 broadcast domains. A customer might subscribe to a single TD from the SP to connect all of its different metro sites together. Alternately, a customer may wish to subscribe to multiple TDs to connect different types of traffic to only certain of its locations. A TD might even be used to connect multiple different organizations, if they want secure layer 2 connectivity on an ongoing basis. 1.2 Transparent Domain Identifier A transparent domain identifier (TDI) uniquely identifies the TD within the SP network. 1.3 Network Devices A provider (P) device is a network element found within the SP's network. A P device, participating in the Ethernet layer 2 virtual private service protocol, can be viewed to have two possible types of logical interfaces, user-network and/or network-network interfaces. The User-Network Interface (UNI) is connected to Holness, et. al Informational [Page 3] The Nortel Networks Ethernet Layer 2 VPS Protocol customer edge (CE) devices while the Network-Network Interface (NNI) can be connected to other P device NNIs or to a P device void of a service interface (i.e., UNI and NNI). A service interface is an interface that may have awareness of the customer's TD. A P device with at least one UNI is considered a provider edge (PE) device. A CE device gains access to the SP's network via a PE device. An example of a CE device could be a customer host station, or customer switch. The connection between the CE device and PE device is an Ethernet link. This solution does not impose the restriction that P devices, found within the core of the SP's Ethernet network, have a NNI. P devices containing an NNI instance are typically used to connect multiple SP networks participating in the service or disparate administrative subnet boundaries. 1.4 User-Network Interface A PE device UNI is connected to at least one CE device. It provides the customer traffic access to the SP network. Consequently, the UNI provides a mechanism to identify the TD associated with the customer traffic. The PE device containing the UNI initiates auto discovery (provisioning) of the TD based Ethernet tunneled path through the SP's network and maintains Ethernet tunneled path information through the network without the need for any customer administration or knowledge. Once the TD resources within the SP network have been identified, and applicable path associations have been established, the customer traffic generated by the CE device is passed through the SP's network seamlessly. 1.5 Network-Network Interface A P device with NNI can be connected to other P devices void of service interfaces or other P device with NNIs. NNI is used to assist in the management of the TD based Ethernet tunneled path information. To maintain scalability of the SP network, P devices void of service interfaces do not maintain any customer addressing space information. Consequently, as the customer address space grows, the core of the SP Ethernet network remains bounded. 1.6 Common Abbreviations CE Customer Edge DA Destination Address ET Ethernet Type Holness, et. al Informational [Page 4] The Nortel Networks Ethernet Layer 2 VPS Protocol FCS Frame Check Sequence FDB Filter Database VPN Virtual Private Networks L2TLS Layer 2 Transparent LAN Service LAN Local Area Networks NNI Network Network Interface P Provider PE Provider Edge QT Q-Tag SA Source Address SNMP Simple Network Management Protocol SP Service Provider STP Spanning Tree Protocol TD Transparent Domain TDI Transparent Domain Identifier UNI User Network Interface 2. Protocol Operation The Nortel Network Ethernet Layer 2 Virtual Private Service protocol is designed to efficiently transport multi-protocol customer traffic through the SP's network. A primary feature of the protocol is its ability to automatically discover TDs, through the SP network, while maintaining the scalability of the network. Traffic associated with a service instance and transported via the provided VPN is tagged with a TDI while within the SP's network. This facilitates separation of customer traffic, improves the SP network bandwidth utilization, and allows the SP to provide service differentiation of individual service instances through its network. The separation of service instance traffic allows secure transport. Service instance traffic being tunneled through the SP network does not have visibility to other service instance's tunneled traffic. Service instance traffic is also encapsulated with a SP Ethernet header. The address space associated with this SP Ethernet header is that of the SP network. Consequently, multi-protocol transport is achieved through the network while maintaining scalability of the network. All service instance traffic entering the SP's network will be tagged with a TDI and encapsulated with a SP Ethernet header. Upon leaving the network, both the TDI and SP Ethernet header will be stripped. Thus, native customer traffic received by the SP network will be presented to the terminating CE device. 2.1 PE Device Operation Holness, et. al Informational [Page 5] The Nortel Networks Ethernet Layer 2 VPS Protocol The operation of the PE device UNI is dependent upon whether the UNI is receiving or transmitting customer's service instance traffic The operation of the PE device NNI is dependent upon whether the NNI is receiving or transmitting traffic, and on the type of traffic (i.e., customer data traffic, or SP network management traffic). 2.1.1 Handling Traffic Entering SP Network The PE device will identify the TD associated with the service instance traffic. Once the TDI is determined, the PE device will update and maintain filtering databases on a TDI basis, to define the TD based Ethernet tunnel endpoints associated with the TDI. Learned entries of the database are set up, used, aged, and removed as required to support the transparent network dedicated to serving the customer. The learning process of the PE device filter database is described in Section 3.1. Customer originated traffic traveling through the SP network is tagged with the TDI. This is accomplished by encapsulating the native customer packet with a service header (defined in Section 2.3.1) before it gets transported. To support scalability of the network, and transport of customer multi-protocol traffic, the native customer frame is also encapsulated within a SP Ethernet header. The SP Ethernet header encapsulation is defined in Section 3. Ports associated with a UNI should be able to manage service instance traffic associated with one or more TDs. To support this, two modes are specified. o Transparent UNI ports – The purpose of this mode is to provide single L2TLS instance across a UNI port. Customer frames are accepted on this port to the SP network as long as the frame starts with a MAC destination address (DA) and MAC source address (SA), is less than or equal to the maximum frame length, and ends with a verifiable FCS. Customer frames may or may not be [802.1q] tagged. All Customer frames received on this port are associated with the same TDI. o Mapped UNI ports – The purpose of this mode is to provide the SP with the capability for tag (e.g., 802.1q VLAN) translation to a TDI. A mapping between customer tags to the associated TDIs is provided. The mapping of customer tag to TDI can be many to one. 2.1.2 Handling Traffic Leaving SP Network Holness, et. al Informational [Page 6] The Nortel Networks Ethernet Layer 2 VPS Protocol The PE device will transmit native customer frames to the connecting CE device. As described in Section 2.1.1, the PE device maintains a filtering database, which associates the service instance identification parameters (e.g., CE device MAC addresses) with the Ethernet tunneled endpoints. CE devices associated with the TDI of the received frame are presented in native format to the correct CEs. Prior to dispatch to the appropriate CE(s), the service header and SP Ethernet header are stripped, and the filtering database is updated to reflect the TD based Ethernet tunnel start- point and end-point. 2.2 P Device Encapsulation and Forwarding Operation The operation of the P device NNI is dependent upon whether the NNI is receiving or transmitting traffic, and on the type of traffic (i.e., customer data traffic, or SP network management traffic). 2.2.1 Receiving SP Network Data Traffic The P device's forwarding machine operates on a layer 2 MAC header for packets received from its NNI. It translates between the VPN tunnel endpoint defined in the source address of the SP Ethernet header, and the address of the interface associated with the sourced customer frame. This association is maintained in the filtering database associated with this P device. 2.2.2 Transmitting SP Network Data Traffic For packets to be transmitted onto the NNI, the filtering database identified by the TDI of the received frame is indexed using the destination MAC address found in the SP Ethernet header. If a P device address association is found, the destination MAC address of the SP Ethernet header is updated. If no association is found, the SP Ethernet header destination address is set to a broadcast MAC address. The frame is then transmitted. 2.3 Protocol Information Element Formats 2.3.1 Service Header The service header is used to tag the service instance traffic through the SP network. It is used to effectively identify the VPN for the service instance. The header definition is shown in Figure 1 below. Holness, et. al Informational [Page 7] The Nortel Networks Ethernet Layer 2 VPS Protocol Figure 1: Service Header Format 0 1 2 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER |M|T| Reserved | +-----------+-+-+-------------------------------+ | TD Identifier (TDI) | +-----------------------------------------------+ The fields are described below. 2.3.2 Version (VER) This 6-bit field defines the version of the service header. Value Description 0 – 7 Used 8 L2TLS 9-11 Reserved for future L2TLS Usage 12-63 Unassigned 2.3.3 Node Mode (M) This field denotes the PE device port mode. Value Description 0 Transparent Mode 1 Mapped Mode See Section 2.1.1 for a description of the specified modes. 2.3.4 Type (T) This 1 bit field defines the type of data that is being transported through the L2TLS network. Value Description 0 Data 1 Control A value of 0 signifies customer traffic passing through the TD. A value of 1 signifies either intra transparent network dedicated to serving a single customer network management traffic or control traffic associated with network elements found within the L2TLS network. Holness, et. al Informational [Page 8] The Nortel Networks Ethernet Layer 2 VPS Protocol 2.3.5 Reserved This 16-bit field is reserved for future expansion. 2.3.6 TDI The TDI, a 24-bit field, identifies the TD. The TDI values 0 to 99 are reserved for special use by the Layer 2 Virtual Private Service Protocol. They are not to be used for customer frame encapsulation. Customer TDI values start with 100 and can go up to 16,777,216 (2^24). Value Description 0 Reserved 1 Reserved for Management traffic 2 Reserved for untagged Layer 2 Control traffic 3 Reserved for untagged Layer 3 Control traffic 4..99 Reserved 100..2^24 Used for Customer TDs TDI with value 1 is used for management traffic, such as SNMP and Telnet, accessing the network elements of the SP domain. TDI with value 2 is used for untagged [802.1q] Layer 2 control protocols, such as passing the Spanning Tree Protocol (STP) messages between network elements. 3. Packet Flow Consider the following example Layer 2 Service Network Architecture. Figure 2: Example Layer 2 Network Architecture ----- ----- / \ +--------+ / \ [U]/ \[N] | | [N]/ \[U] CE1 -[N] PE A [N]===| P |===[N] PE B [N] – CE2 [I]\ /[I] | | [I]\ /[I] \ / +--------+ \ / ----- ----- Figure 2 above depicts two LAN segments, specified by CE1 and CE2, connected using a SP network. The SP network is composed of two PE devices (PE A and PE B), and a connecting P device. Holness, et. al Informational [Page 9] The Nortel Networks Ethernet Layer 2 VPS Protocol In order to maintain the Ethernet Layer 2 Virtual Private Service network's transparency and scalability, the incoming packet traversing the network goes through various stages of encapsulation. An Ethernet Layer 2 tunneling technique is used. The CE device (e.g., CE1) generates an Ethernet packet (shown in Figure 3). It can be [802.1q] tagged or untagged. It can also be a broadcast, multicast, or unicast frame. For example, when a broadcast packet is [802.1q] tagged, the broadcast domain is all hosts associated with the VLAN id specified by the [802.1q] tag. Figure 3: Customer Packet 6 6 2 4 +----+----+--+--------+ +---+ (1) | DA | SA |ET| Data | + |FCS| +---------------------+ +---+ 6 6 2 2 2 4 +----+----+--+--+--+--------+ +---+ (2) | DA | SA |ET|QT|ET| Data | + |FCS| +---------------------------+ +---+ NOTE: The first encapsulation type (1) depicts an untagged (802.1q) frame. Encapsulation type (2) represents an 802.1q tagged frame. The source address (SA) denotes the MAC address of the originating CE device. The destination address (DA) denotes the MAC address of the terminating CE device. The Ethernet type (ET) of 0x8100 denotes that an [802.1] tag is to follow. The [802.1q] tag specifies both the VLAN that the originating host belongs to along with the priority of that session. The ingress UNI at PE A, initiates procedures to dynamically establish a TD based Ethernet Layer 2 tunnel across the network. This establishes security and separation between customer VPNs through the network. The ingress PE (A) encapsulates a SP Ethernet header to define the TD based Ethernet tunnel endpoints. PE A encapsulates a service header (shown in Figure 1) onto the originating customer frame. In addition, the TD based Ethernet Layer 2 tunnel is encapsulated (shown in Figure 4). The PE A virtual machine indexes the filtering database to determine what the provider encapsulation SA and DA should be for the Layer 2 tunnel. If the Ethernet Layer 2 tunnel DA is unknown, the Ethernet Layer 2 Virtual Private Service protocol will automatically discover it. See Section 3.1 for a description of the tunnel discovery procedure. Holness, et. al Informational [Page 10] The Nortel Networks Ethernet Layer 2 VPS Protocol Figure 4: Layer 2 Tunnel Packet 6 6 2 2 2 6 4 +----+----+--+--+--+-----+-------------------+ +---+ | DA | SA |ET|QT|ET|L2TLS| Customer Frame | + |FCS| | | | | | | | (See Figure 3) | | | +--------------------------------------------+ +---+ NOTE: The basic customer frame is 64 to 1518 bytes long. If an 802.1q tag is applied, and additional 4 bytes needs to be accounted for. This results in a maximum 1522 bytes for 802.1q tagged frames only. The service header adds 8 bytes, the encapsulated SP Ethernet header adds 16 bytes, and the FCS adds 4 bytes. P devices must support these larger frame sizes. The Ethernet Type (ET) indicating the presence of the service header is denoted by 0x886B. Next, the P device, receives the frame (shown in Figure 4). The MAC SA and DA, associated with the Ethernet Layer 2 tunnel header, belong to the SP network domain. In addition, the [802.1q] tag provides indication of the priority of the traffic through the service domain. These information elements have SP domain relevance only. The frame gets passed on, until it arrives at the egress point of the SP network (e.g., PE B). At this virtual machine, the Layer 2 Ethernet tunnel header, along with the service header, is stripped from the frame, and the native customer frame (shown in Figure 3) is dispatched to CE2. 3.1 Service Tunnel Discovery Procedure The originating PE device initiates the TD based Ethernet tunnel discovery procedure. The Ethernet tunnel header gets built once the TDI is determined. The originating Ethernet Layer 2 tunnel SA is the originating PE device MAC address. The Ethernet Layer 2 tunnel DA (denoting the tunnel termination point) is either found in the PE device Filter Data Base (FDB) or is learnt. If learning of the tunnel endpoint is required, a broadcast address is copied to the Layer 2 tunnel DA. Once the Layer 2 tunnel DA is learned, the FDB will be updated to reflect the MAC address of the tunnel DA endpoint. The Layer 2 tunnel header may also add an [802.1q] tag. The priority setting found in this tag is described in Section 4. The tunnel discovery procedure initiated by the originating PE device is depicted in Figure 5. Holness, et. al Informational [Page 11] The Nortel Networks Ethernet Layer 2 VPS Protocol Figure 5: PE_A Tunnel Discovery Initiation +---------------+ | Calculate TDI | +---------------+ | v +----------------------+ | Build service header | +----------------------+ | v +-----------+ Y +-----------+ Y < Unicast > --> < Customer DA > -----------+ < customer DA > < in FDB > | +-----------+ +-----------+ | | N | N | | <------------------+ | v v +-----------------+ +------------------+ | L2 Tunnel DA = | | L2 Tunnel DA = | | Bcast (0xFFFFFF)| | FDB(Customer DA) | +-----------------+ +------------------+ | | v <-------------------------------------+ +------------------------+ | Build L2 Tunnel Header | +------------------------+ | v +----------------------------+ | Encapsulate Service Header | | and L2 Tunnel | +-----------------------------+ | v +------------------------------+ | DISPATCH Encapsulated Packet | +------------------------------+ The P devices participation in the tunnel discovery procedure is depicted in Figure 6. The FDB associated with the P device gets updated. An association between the Layer 2 tunnel SA and SA of the customer interface connected to the PE device that sent the message, is made. NOTE: Control and management traffic can terminate on any network element found within the TD. If P devices void of service interfaces are used to connect P device with service interfaces, it may be necessary for the service interfaced P device to strip the service header prior to dispatch. Holness, et. al Informational [Page 12] The Nortel Networks Ethernet Layer 2 VPS Protocol Figure 6: Provider device with Service Interface (Leaving NNI) +---------------+ Y +----------------------+ < Mgmt or Control > --> | Strip service header | < Traffic > +----------------------+ +---------------+ | | N v | +-----------------+ v | Update FDB | +-------------------+ | ( L2 SA, UNI SA)| | Update FDB | +-----------------+ | ( L2 Tunnel SA, | | | Source CE Addr) | | +-------------------+ | | | v <------------------------+ +-----------------+ | DISPATCH Packet | +-----------------+ The packet flow at the PE B for packets received from a P device is shown below in Figure 7. The FDB associated with the NNI port gets updated. An association between the Layer 2 tunnel SA and the P device SA are made. NOTE: If the P device contains a service interface, the service header would already be contained in the received packet. If the P device is void of service interfaces, then the NNI would have to build and encapsulate a service header onto the packet. Figure 7: Provider device with Service Interface (Entering NNI) +---------------+ Y +----------------------+ < Mgmt or Control > --> | Build service header | < Traffic > +----------------------+ +---------------+ | | N v | +----------------------------+ v | Encapsulate service header | +-----------------+ +----------------------------+ | Update FDB | | | ( L2 Tunnel SA, | v | Customer SA) | +---------------+ +-----------------+ | Update FDB | | | ( L2 SA, | | | Client SA) | | +---------------+ | | | <----------------------+ v +-----------------+ | DISPATCH Packet | +-----------------+ Holness, et. al Informational [Page 13] The Nortel Networks Ethernet Layer 2 VPS Protocol The Ethernet Layer 2 tunnel discovery processing done at the egress PE device is shown below in Figure 8. The flow is independent of the received packet being marked as broadcast, multicast or unicast. The Ethernet Layer 2 tunnel, and service headers are stripped. If the TDI, in the service header, matches the TDI associated with the PE device, the original customer packet (see Figure 3) is dispatched to the destination CE device. Otherwise, the packet is discarded. Figure 8: PE_B UNI Tunnel Discovery at Egress +------------------------+ | Strip L2 tunnel header | +------------------------+ | v +----------------------+ | Strip service header | +----------------------+ | v +-------------------+ +---------------+ Y | Update FDB | < L2TLS TDI match > --> | ( Customer SA, | < UNI Port TDI > | L2 Tunnel SA) | +---------------+ +-------------------+ | N | | | v v +----------------+ +-----------------+ | DISCARD Packet | | DISPATCH Packet | +----------------+ +-----------------+ 4. Quality of Service Handling The SP network uses [802.1p] bits, included in the Ethernet Layer 2 Tunnel header, to convey priority of the VPN traffic within its network. A priority mapping function should be provided per TDI, at each ingress PE device UNI port. Customer provided priorities need to be mapped to SP domain [802.1p] bits. When a CE device generates unprioritized frames (e.g., untagged frames), a default priority and VLAN should be provided. This assignment should be provisionable, per PE device UNI port. The [802.1p] priority mapping primarily affects the transit priority of service encapsulated frames through the network. On a TD, the customer frame emitted at the egress point should have the original, unmodified priority demarcation (e.g., p bits if Holness, et. al Informational [Page 14] The Nortel Networks Ethernet Layer 2 VPS Protocol originally provided). On a mapped TD, the p bits used on egress should be the ones in the original frame (if original was tagged). 5. Management of Ethernet Layer 2 Virtual Private Service Network SP's control and network management traffic uses an address space that is within the SP Ethernet Layer 2 Virtual Private Service domain. This control and management traffic does not get Ethernet Layer 2 tunneled through the SP network. Some limitations of this protocol include the containment of broadcast at TDI level and specific multicast handling. 6. Security Considerations The Layer 2 tunneling mechanism provides separation of customer traffic within the SP network. Customer traffic being tunneled does not have visibility to other customer's tunneled traffic. Consequently, the customer traffic is secured through the Ethernet Layer 2 Virtual Private Service network. 7. Intellectual Property Considerations Nortel Networks may pursue, or is pursuing, patent protection on technology described in this document. If this document becomes, in part or whole, an IETF Standard, and if such patented technology is essential for practice of an IETF Standard incorporating in whole or part this document, Nortel Networks is willing to make available nonexclusive licenses on fair, reasonable, and non-discriminatory terms and conditions, to such patent rights it owns, solely to the extent such technology is essential to practice with such IETF standard. Also, in the event that a Nortel patent is subsequently identified as essential to an IETF Standard incorporating in whole or part this document, Nortel Networks is willing to make available a nonexclusive license under such patent(s), on fair, reasonable, and non-discriminatory terms and conditions. The terms apply to those patents for which Nortel Networks has the right to grant licenses. 8. References [802.1q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Std 802.1Q-1998. [802.1w] "IEEE Standard for Local and metropolitan area networks: Common specifications Part 3: Media Access Control (MAC) Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std 802.1w-2001. Holness, et. al Informational [Page 15] The Nortel Networks Ethernet Layer 2 VPS Protocol [802.1D] "Information technology: Telecommunications and information exchange between systems: Local and metropolitan area networks: Common specifications: Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D-1998. [802.3] “IEEE Standard for Information technology: Telecommunications and information exchange between systems: Local and metropolitan area networks Specific requirements: Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications”, IEEE Std 802.3- 2002. 9. Acknowledgements The authors would like to thank all those in Nortel Networks who contributed in furthering the content of Ethernet Layer 2 Virtual Private Service Protocol. 10. Author's Address Marc Holness Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 2840 Email: holness@nortelnetworks.com Michael Chen Nortel Networks 4010 E Chapel Hill-Nelson Hwy Research Triangle Park, NC 27709 USA Phone: +1 (919) 997 3840 Email: mchen@nortelnetworks.com Dinesh Mohan Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 763 4794 Email: mohand@nortelnetworks.com 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without Holness, et. al Informational [Page 16] The Nortel Networks Ethernet Layer 2 VPS Protocol restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."