Internet DRAFT - draft-holness-network-l2vpsp
draft-holness-network-l2vpsp
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."
