One document matched: draft-mohan-sajassi-l2vpn-vpls-pm-00.txt
Internet Draft Document Dinesh Mohan
Layer-2 VPN Working Group Nortel Networks
draft-mohan-sajassi-l2vpn-vpls-pm-00.txt Ali Sajassi
Cisco Systems
Shahram Davari
PMC Sierra
Vasile Radoaca
Nortel networks
Expires: November 2004 March 2004
Performance Management for Virtual Private LAN Services
draft-mohan-sajassi-l2vpn-vpls-pm-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119
Placement of this Memo in Routing Area
RELATED DOCUMENTS
Mohan, Sajassi et al. [Page 1]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-
requirements-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-
03.txt
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-01.txt
WHERE DOES THIS FIT IN THE PICTURE OF THE ROUTING WORK
L2VPN
WHY IS IT TARGETED AT THIS WG
This draft describes Performance Management mechanisms for VPLS
which is a Layer-2 VPN.
JUSTIFICATION
This draft describes Performance Management mechanisms for VPLS
which is a Layer-2 VPN.
Table of Contents
1. Status of this Memo.............................................1
2. Abstract........................................................1
3. Conventions.....................................................1
4. Overview........................................................3
5. Layering........................................................4
5.1. OAM Domains...................................................5
5.2. Maintenance & Intermediate Points.............................6
5.2.1. Maintenance and Intermediate Points IDs.....................8
6. Performance Parameters..........................................8
6.1. Frame Loss (FL)...............................................8
6.2. Frame Delay (FD)..............................................8
6.3. Frame Delay Variation (FDV)...................................8
6.4. Availability..................................................9
6.5. Other Parameters..............................................9
6.5.1. Errored Frame Seconds (FL)..................................9
6.5.2. Frame Throughput............................................9
6.5.3. Frame Tx....................................................9
6.5.4. Frame Rx....................................................9
6.5.5. Frame Drop.................................................10
7. Performance Measurement Mechanisms.............................10
7.1. Performance Management Collection Method.....................11
7.2. Frame Loss Measurement.......................................11
7.2.1. Unsolicited Method.........................................12
Mohan, Sajassi et al. [Page 2]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
7.2.2. Solicited Method...........................................12
7.3. Frame Delay Measurement......................................13
7.4. Frame Delay Variation Measurement............................13
7.5. Availability Measurement.....................................14
8. Acknowledgments................................................14
9. Security Considerations........................................14
10. Intellectual Property Considerations..........................14
11. Full Copyright Statement......................................14
12. References....................................................15
13. Authors' Addresses............................................15
4. Overview
The Scope of network management functionality (aka OAM&P: Operation,
Administration, Maintenance, and Provisioning) for any network
technology is very broad in nature.
OSI has defined the following five generic functional areas for
network management, commonly abbreviated as ôFCAPSö [NM-Standards]:
Fault Management (FM), Performance Management (PM), Configuration
Management, Accounting Management, and Security Management. This
draft only deals with Performance Management aspects of OAM&P for
VPLS and defines mechanisms and procedures for it. Fault management
aspects of OAM&P for VPLS are addressed in a companion draft [FM-
SAJASSI-MOHAN].
Performance Management deals with mechanism(s) that allow
determining and measuring the performance of network/services under
consideration and notification of them. Performance Management can
be used to verify the compliance to both the service and network
level specifications. However, only the service-level aspects of the
performance management (corresponding to VPLS instances) are
addressed here.
Performance Management typically consists of measurement of
Performance Parameters e.g. Frame Loss, Frame Delay, Frame Delay
Variation aka Jitter etc. This draft focuses on the following
performance parameters and measurements:
- Frame Loss Measurement
- Delay Measurement
- Delay Variation Measurement
- Availability Measurement
Other performance parameters are briefly introduced in this draft
and are for FFS.
Mohan, Sajassi et al. [Page 3]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
This document provides a description and a reference model for OAM
layering and furthermore emphasizes the importance of proper
independent layering in design and development of OAM functionality.
Next it defines the performance parameters and specifies the
mechanisms and procedures for performance measurement for VPLS.
This proposal is aligned with the current discussions in other
standard bodies such as ITU-T Q3/13, IEEE 802.1, and MEF which are
addressing OAM for both Ethernet-based services and Ethernet-based
networks.
5. Layering
As defined in [L2-FRWK], Virtual Private LAN Service is a bridged
LAN service provided to a set of CEs that are members of a VPN. The
CEs that are member of the same VPN (e.g., the same VPLS instance)
communicate with each other as if they are connected via a bridged
LAN. The bridged LAN functionality is emulated by a network of PEs
to which the CEs are connected. This network of PEs can belong to a
single network operator or can span across multiple network
operators. Furthermore, it can belong to a single service provider
or can span across multiple service providers. A service provider is
responsible for providing VPLS services to its customers; whereas, a
network operator (aka facility provider) provides the necessary
facilities to the service provider(s) in support of their services.
A network operator and a service provider can be the same entity or
they can be different administrative organizations.
When discussing the performance management mechanisms for VPLS, it
is important to consider that the end-to-end service can span across
different types of VPLS networks. As an example, in case of [VPLS-
LDP], the access network on one side can be bridged network e.g.
[IEEE 802.1ad], as described in section 11 of [VPLS-LDP]; whereas,
the access network on other side can be MPLS based as described in
section 10 of [VPLS-LDP]; and the core network connecting them can
be IP, MPLS, ATM, or SONET. Similarly, the VPLS service instance can
span across distributed VPLS as described in [VPLS-ROSEN].
Therefore, it is important that the performance management
mechanisms can be applied to all these network types. Each such
network may be associated with a separate administrative domain and
also multiple such networks may be associated with a single
administrative domain. Different types of pseudo wires may be in use
to support end-to-end VPLS. Therefore, for VPLS performance
management, it is important to ensure that the performance
management mechanisms for VPLS are independent of the underlying
transport mechanisms (e.g., 802.3, MPLS, IP, ATM, SONET, etc.) and
solely rely on Ethernet MAC layer.
Mohan, Sajassi et al. [Page 4]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
As shown in Figure 1, an example of VPLS service is shown across a
service provider network marked by UPE and NPE devices. The customer
A is represented by CE devices across its different sites. The
service provider network is segmented into core network and two
types of access network. Figure 1(A) shows the bridged access
network represented by its bridge components marked ôBö, and the
MPLS access and core network represented by MPLS components marked
ôPö. Figure 1(B) shows the service/network view at the Ethernet MAC
layer marked by ôEö.
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE
(B) E------E---E--E---E------------E----------E-----E
Figure 1
As shown in Figure 1(B), only the nodes with Ethernet functionality
are visible to Performance Management mechanisms operating at
Ethernet MAC layer and the P nodes are invisible. Therefore, the
Performance management along the path of P nodes (e.g., between two
PEs) is covered by transport layer and it is outside the scope of
this document.
5.1. OAM Domains
As described in the previous section, a VPLS instance for a given
customer can span across one or more service providers and network
operators. Therefore, when discussing OAM tools for VPLS, e.g.
performance management, it is important to provide OAM capabilities
and functionality over each domain that a service provider or a
network operator is responsible for. For these reasons, it is also
important that OAM frames are not allowed to enter/exit other
domains. We define an OAM domain as a network region over which OAM
frames operate unobstructed as explained below.
At the edge of an OAM domain, filtering constructs should prevent
OAM frames from exiting and entering that domain. FM domains can be
nested but not overlapped. In other words, if there is a hierarchy
of the PM domains, the PM messages of a higher-level domain pass
transparently through the lower-level domains but the PM messages of
Mohan, Sajassi et al. [Page 5]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
a lower-level domain get blocked/filtered at the edge of that
domain.
In order to facilitate the processing of PM messages, we associate
each domain with a one-octet level at which it operates. Domains
with larger level numbers can contain domain with smaller level
numbers but the converse is not true.
A PE can be part of several domains with each interface belonging to
same or different domains. A PE shall block outgoing PM messages and
filter out incoming messages whose domain level is lower or equal to
the one configured on that interface and pass through the messages
whose domain level is greater than the one configured on that
interface.
Figure 2 depicts three domains: (A) customer domain which is among
the CEs of a given customer, (B) service provider domain which is
among the edge PEs of the given service provider, and (C) network
operator domain which is among the PEs of a given operator.
--- ---
/ \ ------ ------- ---- / \
| CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) |<----------------------------------------------->|
customer
(B) |<---------------------------------->|
provider
(C) |<--------->|<----------->|<-------->|
operator operator operator
Figure 2
5.2. Maintenance & Intermediate Points
Maintenance points are responsible for origination and termination
of OAM/PM messages. Maintenance points are located at the edge of
their corresponding domains. Intermediate points are located within
their corresponding domains and they normally pass OAM/PM messages
but never initiate them. Since Maintenance points are located at the
edge of their domains, they are responsible for filtering outbound
OAM frames from leaving the domain or inbound OAM frames from
Mohan, Sajassi et al. [Page 6]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
entering the domain. Maintenance and intermediate points correspond
to a PE or more specifically to an interface of a PE. For example,
an OAM/PM message can be said to originate from an ingress PE or
more specifically an ingress interface of that PE.
Since domains are hierarchical as described above, the maintenance
and intermediate points that are associated with the domains become
hierarchical as well. A maintenance point of a higher-level domain
is always a maintenance point of a lower-level domain but the
converse is not always true since the maintenance point of lower-
level domain can either be intermediate point or a maintenance point
of a higher-level domain. Furthermore, the intermediate points of a
lower-level domain are always transparent to the higher-level domain
(e.g., OAM/PM messages of a higher-level domain are not seen by
intermediate points of a lower-level domain and get passed through
them transparently).
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE
(B) E------E---E--E---E------------E----------E-----E
(C) MP----IP----------------------------------IP---MP
Customer Domain
(D) MP---------IP-----------IP-------MP
Provider domain
(E) MP--IP--IP--MP----------MP-------MP
Operator Operator Operator
domain domain domain
(F) MP--IP--IP--MP--IP---MP
MPLS MPLS
domain domain
Figure 3
As shown in Figure 3, (C) represents that maintenance points and
intermediate points that are visible within the customer domain. (D)
represents the maintenance points and intermediate points visible
within the service provider domain, while (E) represents the
maintenance points and intermediate points visible within each
Mohan, Sajassi et al. [Page 7]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
operator domain. Further, (F) represents the maintenance points and
intermediate points corresponding to the MPLS layer and may apply
MPLS based mechanisms. The MPLS layer shown in this Figure is just
an example and is outside the scope of this document.
5.2.1. Maintenance and Intermediate Points IDs
As mentioned previously, VPLS OAM/PM should be independent of
underlying transport layer and should dependent on Ethernet MAC
layer. Therefore, at Ethernet MAC layer, the Maintenance points and
Intermediate points should be identified with their Ethernet MAC
addresses. As described in [VPLS-LDP], VPLS instance is identified
in an Ethernet domain (e.g., 8021.d domain) using VLAN tag (service
tag) while in an MPLS/IP network, PW-ids are used. Both PW-ids and
VLAN tags for a given VPLS instance are associated with a globally
unique service instance identifier (e.g., VPN identifier).
Maintenance and Intermediate Points ID shall be unique within their
corresponding domain.
Ethernet frames are used for OAM/PM messages and the source MAC
address of the OAM/PM frames represent the source maintenance point
in that domain. For Unicast OAM/PM frames, the destination MAC
address represents the destination maintenance point in that domain.
For multicast OAM/PM frames, the destination MAC addresses
correspond to all maintenance points in that domain.
6. Performance Parameters
The following performance parameters are proposed:
6.1. Frame Loss (FL)
Difference between the number of data frames sent from source
maintenance point and the number of data frames received at
destination maintenance point for a given VPLS instance during the
measurement interval.
6.2. Frame Delay (FD)
Frame delay can be specified in terms of round-trip delay, which is
defined as the time elapsed since start of the transmission of the
first bit of a frame by the source maintenance point until the
reception of the last bit of the loop-backed frame by the same
source maintenance point for a given VPLS instance, when the
loopback is performed at the destination maintenance point.
6.3. Frame Delay Variation (FDV)
Mohan, Sajassi et al. [Page 8]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
Frame Delay Variation can be specified in terms of variations in
one-way delay. Measurement of the variations in the frame arrival
pattern at the destination maintenance point belonging to the same
CoS/priority instance compared to the transmission pattern at the
source maintenance point for a given VPLS instance.
6.4. Availability
Function of time the Maintenance Entity within a VPLS instance
(associating pair of maintenance points) is in available state. It
is specified as a ratio of:
Total Time ME is in Available State / Total Time
where, Total Time is number of measurement time intervals and
Available State is viewed as interval when network/service meets FL,
FD and FDV bounds. Unavailable state is encountered when at least
one of the FL, FD or FDV measures exceed their bounds/thresholds
during a time interval. These bounds/thresholds are determined by
the class of service (CoS).
6.5. Other Parameters
These parameters are briefly introduced here and are FFS.
6.5.1. Errored Frame Seconds (FL)
Indicates if an error (e.g., frame error due to FCS or 8B/10B coding
violation) has occurred within the second. This does not take into
consideration errors when frames are received error free but are not
delivered.
6.5.2. Frame Throughput
Number of frames and/or bytes transmitted at a maintenance point.
6.5.3. Frame Tx
Number of frames transmitted out of a maintenance point within the
(previous) time interval (e.g. 1 second).
6.5.4. Frame Rx
Number of frames received at a maintenance point within the
(previous) time interval (e.g. 1 second).
Mohan, Sajassi et al. [Page 9]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
6.5.5. Frame Drop
Number of frames dropped at a maintenance point within the
(previous) time interval (e.g. 1 second).
7. Performance Measurement Mechanisms
Different measurement mechanisms are possible to perform performance
measurements. One significant difference across these mechanisms is
the level of accuracy. These mechanisms include:
- (A) Statistical Methods
Statistical methods use OAM frames to estimate data path
behavior. Such methods are least accurate since they apply
approximation to emulate data frames.
The limitation lies in that the behavior of actual data frames
may be quite different due to different addressing, processing,
transient congestion conditions etc. Also, error conditions in
networks typically happens in bursts thus statistical methods
can likely miss those bursts and represent different results.
- (B) Date path managed objects using management plane
OAM frames use data path managed objects to calculate
performance parameters and are inserted and/or extracted via
management plane. These methods are fairly accurate since they
use data path counters to measure data path performance.
The limitation lies in that since the insertion and extraction
of these OAM frames is done via management plane, in-flight
frames need to be accounted for. In-flight frames refer to data
path frames that flow between the time management plane
accesses data path managed objects and the time management
plane transmits/receives the PM OAM frame. However, this
limitation can be addressed by averaging such measurements
across multiple time intervals.
- (C) Data path managed objects using data plane
OAM frames use data path managed objects and are inserted
and/or extracted via data plane. This method tends to be most
Mohan, Sajassi et al. [Page 10]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
accurate since it does not have the limitation associated with
the in-flight frames.
However, the current data path hardware/chips do not support
the implementation of such methods since this requires Ethernet
data path capability to include automatic insertion and/or
extraction of OAM frames. Moreover, it would also require
changes in hardware/chips to allow ingress and egress filtering
rules across OAM frames to protect service provider
administrative domains from unintended OAM frames.
It may be noted that (B) is preferable for cases where many samples
are needed such as Frame Loss (FL) but in other cases such as Frame
Delay (FD) or Frame Delay Variation (FDV) (A) based approach can be
used.
Among these methods, it is recommended to use the method (B) for
Frame Loss (FL) since this method requires no changes in the
existing hardware/chips and requires only software changes for PM
OAM. The steps involved in such measurement mechanism include:
- Collection of managed objects information
- Calculation of performance parameters
7.1. Performance Management Collection Method
To collect managed object information, a generic method is used to
collect information across different managed objects e.g. using TLVs
for information elements.
It is possible to use either a solicited or unsolicited collection
method, where solicited method requires a reply after a PM OAM
request message is sent while unsolicited methods does not require a
reply to a PM message. Current examples of solicited and unsolicited
methods include Loopback and CC (Continuity Check) respectively, as
described in [FM-SAJASSI-MOHAN]. For PM, similar methods can be
applied.
7.2. Frame Loss Measurement
Mohan, Sajassi et al. [Page 11]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
7.2.1. Unsolicited Method
PM OAM frame is sent every N seconds (e.g. N=1) with Frames-
Transmitted-OK value at source maintenance point. Upon receiving
this PM OAM frame, Frames-Transmitted-OK value is compared with
Frames-Received-OK value at destination maintenance point. Between
two such consecutive PM OAM frames, the FL is measured as:
Frame Loss = |CT2-CT1| - |CR2-CR1|,
where CT and CR are Frames-Transmitted-OK and Frames-Received-OK
counts. Consecutive messages help in reducing error introduced by
in-flight frames and lack of timing synchronization between sender
and receiver. Within a measurement time interval, the FL count can
be averaged to improve the accuracy of measurement.
Information elements that can be applied to PM OAM Data include:
- Transaction ID
- Frames-Transmitted-OK TLV
7.2.2. Solicited Method
Requestor sends PM OAM request frame to receiver every N seconds
(e.g. N=1) with its managed objects (MOs) information and expects a
PM OAM reply frame with receiverÆs MOs information.
Requestor sends Frames-Transmitted-OK value at source maintenance
point and requests Frames-Received-OK value from destination
maintenance point. Upon receiving the PM OAM request frame, receiver
compares received MO information with its corresponding MO
information and sends a reply PM OAM frame back to requestor with
requested MO information. Receiver compares received Frames-
Transmitted-OK value with its own Frames-Received-OK value and
responds with its Frames-Received-OK value. Upon receiving PM OAM
reply frame, requestor compares originally sent value with received
values, similar to receiver.
It is possible that receiver returns its FL result instead of MO
information in response, however, if the MO information is returned,
the performance collection method remains generic.
Between two such consecutive PM OAM frames, the FL is measured as:
Mohan, Sajassi et al. [Page 12]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
Frame Loss = |CT2-CT1| - |CR2-CR1|,
where CT and CR are Frames-Transmitted-OK and Frames-Received-OK
counts. Consecutive PM OAM frames help in reducing error introduced
by in-flight frames and lack of timing synchronization between
sender and receiver. Within a measurement time interval, the FL
count can be averaged to improve the accuracy of this measurement.
Information elements that can be applied to PM OAM Data include:
- Transaction ID
- Frames-Transmitted-OK TLV
- Frames-Received-OK TLV
7.3. Frame Delay Measurement
This method measures round-trip or two-way frame delay. Requestor
sends PM OAM request message with its timestamp to the receiver.
Receiver replies copying the requestorÆs timestamp. At the
requestor, the difference between the timestamps at the time of
receiving the PM OAM reply frame and original timestamp in the PM
OAM reply frame measures round trip frame delay.
Information elements that can be applied to PM OAM Data include:
- Transaction ID
- Request TimeStamp TLV
7.4. Frame Delay Variation Measurement
This method measures round-trip or two-way frame delay per request
and reply frame. Within the period of observation, requestor keeps
track of maximum frame delay FD(max) and minimum frame delay FD(min).
Frame delay variation is calculated as:
Frame Delay Variation = FD(max) û FD(min)
Information elements that can be applied to PM OAM Data include:
- Transaction ID
- Request TimeStamp TLV
Mohan, Sajassi et al. [Page 13]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
7.5. Availability Measurement
Measurement is based on FL, FD and FDV methods. Availability time
interval (e.g. 24hr) can be divided into measurement time intervals
(e.g. 1 minute). FL, FD and FDV are measured per measurement time
interval. If any of the three measures crosses its corresponding
thresholds, the measurement time interval is considered to be
unavailable else it is considered to be available.
Availability = (# of available measurement time intervals)/
(# of total measurement time intervals)
8. Acknowledgments
We wish to thank Yoav Cohen, Marc Holness, Malcolm Betts, Paul
Bottorff, Norm Finn, and Monique Morrow for their valuable feedback.
9. Security Considerations
Security issues resulting from this draft will be discussed in
greater depth at a later point. It is recommended in [RFC3036] that
LDP security (authentication) methods be applied. This would
prevent unauthorized participation by a PE in a VPLS. Traffic
separation for a VPLS is effected by using VC labels. However, for
additional levels of security, the customer MAY deploy end-to-end
security, which is out of the scope of this draft. In addition, the
L2FRAME] document describes security issues in greater depth.
10. Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 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
Mohan, Sajassi et al. [Page 14]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
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.
12. References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
01.txt, Work in progress, November 2002.
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-
1993 "MAC Bridges".
[802.1D-REV] 802.1D - "Information technology - Telecommunications
and information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Media Access Control
(MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993,
802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e." ISO/IEC 15802-3: 1998.
[802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE
Standards for Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks", July 1998.
[VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)",
draft-ietf-ppvpn-vpls-requirements-01.txt, Work in progress, October
2002.
[L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work
in Progress, February 2003.
[802.1ad] ôIEEE standard for Provider Bridges, Work in Progress,
December 2002ö
<To be updated in the next Rev.>
13. Authors' Addresses
Dinesh Mohan Ali Sajassi
Mohan, Sajassi et al. [Page 15]
Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004
Nortel Networks Cisco Systems, Inc.
3500 Carling Ave. 170 West Tasman Drive
Ottawa, ON K2H 8E9 San Jose, CA 95134
Email: mohand@nortelnetworks.com Email: sajassi@cisco.com
Vasile Radoaca Norm Finn
Nortel Networks Cisco Systems, Inc.
600 Technology Park 170 West Tasman Drive
Billerica, MA 01821 San Jose, CA 95134
Email: vasile@nortelnetworks.com Email: nfinn@cisco.com
Shahram Davari Yoav Cohen
PMC Sierra Native Networks
411 Legget Drive
Ottawa, ON K2K 3C9
Email: shahram_davari@pmc-sierra.com
Mohan, Sajassi et al. [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 07:42:09 |