One document matched: draft-sajassi-mohan-l2vpn-vpls-fm-00.txt
Internet Draft Document Ali Sajassi
Layer-2 VPN Working Group Cisco Systems
draft-sajassi-mohan-l2vpn-vpls-fm-00.txt Dinesh Mohan
Nortel Networks
Norm Finn Shahram Davari
Thomas Nadeau PMC Sierra
Monique Morrow
Cisco Systems Vasile Radoaca
Nortel Networks
Expires: November 2004 March 2004
Fault Management for Virtual Private LAN Services
draft-sajassi-mohan-l2vpn-vpls-fm-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 Internet Area
RELATED DOCUMENTS
Sajassi, Mohan et al. [Page 1]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-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 Internet WORK
L2VPN
WHY IS IT TARGETED AT THIS WG
This draft describes Fault Management mechanisms/procedures for VPLS
which is a Layer-2 VPN.
JUSTIFICATION
This draft describes Fault Management mechanisms/procedures 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. Fault Management Mechanisms.....................................8
6.1. Fault Detection...............................................8
6.2. Fault Verification...........................................10
6.3. Fault Isolation..............................................10
7. Fault Management Messages......................................11
7.1. Generic Ethernet OAM Frame - Header Information..............11
7.2. Generic Ethernet OAM Frame û OAM Body Information............12
7.3. Continuity Check.............................................12
7.4. Loopback.....................................................13
7.5. TraceRoute...................................................13
7.5.1. TraceRoute Request Format..................................13
7.5.2. TraceRoute Reply Format....................................13
8. Acknowledgments................................................14
9. Security Considerations........................................14
Sajassi, Mohan et al. [Page 2]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
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, Configuration
Management, Accounting Management, and Security Management. This
draft only deals with Fault Management aspects of OAM&P for VPLS and
defines mechanisms and procedures for it. Performance management
aspects of OAM&P for VPLS are addressed in a companion draft [PM-
MOHAN-SAJASSI].
Fault Management can further be sub-divided into the following
categories:
- Fault Detection
- Fault Verification
- Fault Isolation
- Fault Notification
- Fault Recovery
Fault Detection deals with mechanism(s) that can detect both hard
failures, such as link and node failures, and soft failures, such as
software failure, memory corruption, mis-configuration, etc.
Typically a lightweight protocol is desirable to detect the fault
and thus it would be prudent to verify the fault via Fault
Verification mechanism before taking additional steps in isolating
the fault. After verifying that a fault has occurred along the data
path, it is important to be able to isolate the fault to a given
node or link (e.g., diagnose the fault). Therefore, a Fault
Isolation mechanism is needed in Fault Management. Fault
Notification mechanism can be used in conjunction with Fault
Detection mechanism to notify the upstream and downstream nodes of a
fault. Finally, Fault Recovery deals with recovering from the
detected failure by switching to an alternate available node or link
(e.g., node redundancy or link redundancy).
The scope of this draft is limited to the first three aspects of the
Fault Management, i.e. Fault Detection, Fault Verification and Fault
Isolation, in the context of provider networks.
Sajassi, Mohan et al. [Page 3]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
This document first starts off with 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 describes mechanisms and procedures for fault
detection, verification, and isolation 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 fault 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 fault 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 fault management, it is important to
ensure that the fault management mechanisms for VPLS are independent
Sajassi, Mohan et al. [Page 4]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
of the underlying transport mechanisms (e.g., 802.3, MPLS, IP, ATM,
SONET, etc.) and solely rely on Ethernet MAC layer.
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 Fault Management mechanisms operating at Ethernet MAC
layer and the P nodes are invisible. Therefore, the fault management
along the path of P nodes (e.g., between two PEs) is covered by
transport layer FM (e.g., MPLS FM) 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. fault
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 messages are not allowed to enter/exit other domains. We
define an OAM domain as a network region over which OAM messages
operate unobstructed as explained below.
At the edge of an OAM domain, filtering constructs should prevent
OAM messages from exiting and entering that domain. FM domains can
Sajassi, Mohan et al. [Page 5]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
be nested but not overlapped. In other words, if there is a
hierarchy of the FM domains, the FM messages of a higher-level
domain pass transparently through the lower-level domains but the FM
messages of a lower-level domain get blocked/filtered at the edge of
that domain.
In order to facilitate the processing of FM 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 FM 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/FM messages. Maintenance points are located at the edge of
their corresponding domains. Intermediate points are located within
their corresponding domains and they can process and respond to OAM
Sajassi, Mohan et al. [Page 6]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
messages but they never initiate them. Since Maintenance points are
located at the edge of their domains, they are responsible for
filtering outbound OAM messages from leaving the domain or inbound
OAM messages from entering the domain. Maintenance and intermediate
points correspond to a PE or more specifically to an interface of a
PE. For example, an OAM/FM 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/FM 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
Sajassi, Mohan et al. [Page 7]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
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
operator domain. Further, (F) represents the maintenance points and
intermediate points corresponding to the MPLS layer and may apply
MPLS based mechanisms like [LSP-PING], [VCCV] etc. 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/FM 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/FM messages and the source MAC
address of the OAM/FM frames represent the source maintenance or
intermediate point in that domain. For Unicast OAM/FM frames, the
destination MAC address represents the destination maintenance or
intermediate point in that domain. For multicast OAM/FM frames, the
destination MAC addresses correspond to all maintenance and
optionally to all intermediate points in that domain.
6. Fault Management Mechanisms
6.1. Fault Detection
Ethernet Continuity Check (CC) provides a means to detect both hard
failures and soft failures such as software failure, memory
corruption, or mis-configuration. The failure detection is achieved
by each maintenance point (e.g., each edge PE) transmitting a
heartbeat message periodically for each VPLS (service) instance.
Therefore, each edge PE receives a set of heartbeat messages
periodically from other edge PEs of that service instance. Once the
local PE stops receiving the periodic heartbeats from the remote PE,
it assumes that either the remote PE has failed or an unrecoverable
failure on the path has happened. The PE can subsequently notify the
Sajassi, Mohan et al. [Page 8]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
operator of the failure, using mechanisms that are out of scope of
this draft, and initiate the failure verification and isolation
steps either automatically or through operator command.
If a PE is put out of commission, then in order to avoid triggering
false failure detection, the out-of-commissioned PE shall indicate
its soon to be out-of-state status to other member PEs for each
service instance that it participates through a flag in the CC
message. The other member PEs of the service instance, upon
receiving this indication, would deactivate the corresponding timer
for the heartbeat of that PE. Once PE devices have received and
processed the CC messages, each PE will have a view of all active
PEs for a given VPLS instance (service instance).
Upon receiving CC messages, at the receiving maintenance point, a CC
validity timer is started which is used to determine the loss of CC
messages. A CC loss is assumed when the next CC message is not
received within the timeout of this validity timer. If n consecutive
CC messages are lost, a fault for that remote maintenance point is
detected. Subsequent fault verification and isolation procedures can
be exercised. Fault notification mechanisms, which may also follow
the fault detection, are out of scope for this document.
The fault may correspond to a hard failure or a soft failure within
the network. Also a hard failure may result in network isolation
which leads to loss of CC messages for many service instances. If
the hard failure can be detected and reported to the Management
entity, additional notifications by each maintenance point may not
be needed û e.g., it is desirable to have an alarm suppression
mechanism for notifications that get generated as the result of CC
timeouts.
Since this message is sent periodically, in order to facilitate the
processing and filtering of this message, both the message type and
domain level is embedded in the multicast MAC address. It may be
noted, that the associated Multicast MAC address will be specified
in IEEE 802.1.
A CC messages does not require a response and requires only O (n)
message transmission within its member group. In other words, if a
service instance has N member PEs, only N CC messages need to be
transmitted periodically û one from each PE. However, if this was to
be done by point-to-point Ping messages, then O (N**2) messages
would have been required.
The maintenance points shall allow the filtering of CC messages from
either entering or exiting its OAM domain.
Sajassi, Mohan et al. [Page 9]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
6.2. Fault Verification
This non-intrusive unicast loopback is a mechanism similar to IP
Ping function that sends a request message from a source bridge to
another bridge and expects a response from that bridge.
To verify the connectivity between maintenance/intermediate points,
the request message is initiated by a maintenance point with a DA
MAC address set to the MAC address of either a intermediate point or
the peer maintenance point.
The maintenance points shall allow the filtering of fault
verification messages from either entering or exiting its OAM
domain.
6.3. Fault Isolation
TraceRoute function is used to isolate faults visible at Ethernet
MAC layer. TraceRoute can be used to isolate a fault associated with
a given VPLS service instance. It should be noted that fault
isolation in a connection-less (multi-point) environment is more
challenging than a connection-oriented (point-to-point) environment.
In case of Ethernet, fault isolation can be even more challenging
since the MAC address of a target node can age out in several
minutes (e.g. typically 5 min) when the fault results in isolating
the target node. As a result of this age-out, the occurrence of a
network-isolating fault results in erasure of information leading to
the location of the fault!
The TraceRoute function uses OAM message with a well-defined
multicast MAC address. The TraceRoute Request gets initiated by a
maintenance point and traverses hop-by-hop and each intermediate
point along the path intercepts the TraceRoute Request and forwards
it onto the next hop only after processing it. The processing
includes looking at the target MAC address contained in the
TraceRoute message. The originating maintenance point expects a
response to its TraceRoute request. It should be noted that the
source maintenance point sends a single request message to the next
hop along the trace path; however, it can receive many responses
from different intermediate points (and the peer maintenance point)
along the trace path as the result of the message traversing hop by
hop.
Similar to CC messages, TraceRoute multicast MAC address will be
specified by IEEE 802.1.
Given that an end-to-end TraceRoute flow is different from that of a
user data flow (TraceRoute goes through the control plane of each
hop; whereas, user data flow doesnÆt), there can exist rare
Sajassi, Mohan et al. [Page 10]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
situation in which the fault can not be detected by the TraceRoute
flow. Given that the TraceRoute flow can identify all the points
along the traced path (based on responses received at the source
maintenance point) one can run multiple Loopback messages between
the source maintenance point and different intermediate points (and
the peer maintenance point) to further isolate the data-plane
fault/corruption in such rare situations.
As mentioned previously, the age-out of MAC address entries can lead
to erasure of information at intermediate nodes, which is used for
the TraceRoute mechanism. Possible ways to address this behavior
include:
- Launching TraceRoute mechanism following fault
detection/isolation such that it gets exercised within the
window of age-out.
- Maintaining information about the destination maintenance point
at the intermediate points along the path (Note: this can be
facilitated by the CC messages.)
- Maintaining visibility of path at the source maintenance points
through periodic TraceRoute messages (Note: this periodicity
should be larger than the CC periodicity)
7. Fault Management Messages
Since OAM/FM mechanisms for VPLS solely dependent on Ethernet MAC
layer, the corresponding messages are based on Ethernet frames. A
generic format can be defined for all Ethernet OAM messages.
The information carried in the Ethernet OAM messages is described
next for the purpose of discussion. Since these discussions are
still on-going in ITU-T Q3/13, IEEE 802.1 and MEF, a specific frame
format is not presented here.
7.1. Generic Ethernet OAM Frame - Header Information
- OAM Destination MAC Address: This MAC address can either be the
unicast address of a maintenance/intermediate point, or it can
be a well-defined multicast address.
- OAM Source MAC Address: This MAC address corresponds to the
maintenance or intermediate point.
- VLAN Ether Type and Tag: This optional VLAN tag represents the
service instance within an Ethernet Access domain.
Note: Different Ethernet Access domains can use different VLAN
tags corresponding to the same service instance. However, each
Sajassi, Mohan et al. [Page 11]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
S-VLAN tag is unique within an access domain and corresponds to
a single service instance.
- OAM Ethernet Type: It identifies that message is of type OAM.
- OAM Version: The Version field identifies the OAM version
number.
- Opcode: The Opcode identifies the type of OAM frame. The OAM
frame types that may be defined are:
. Continuty Check (0x00)
. TraceRoute Request (0x02)
. TraceRoute Reply (0x03)
. Loopback Request (0x04)
. Loopback Reply (0x05)
. Vendor Specific (0xFF). The vendor specific op-code is
provided to allow vendors or other organizations to
extend OAM functions in proprietary ways.
. Other op-codes may be defined in the future.
- Domain Level: This identifies the hierarchy of OAM domain
associated with the OAM message.
7.2. Generic Ethernet OAM Frame û OAM Body Information
- Service ID TLV: Identifies the VPLS/Service instance across the
entire VPLS network and relates to the VPLS Service identifiers
within each sub-network (e.g. VLAN tags within bridged access
domains etc).
- Transaction ID: Supplied by the originator of the FM message
and returned in the reply message (Loopback or TraceRoute).
- OAM Data: This is a data field associated with the
corresponding OAM opcode and information contained is dependent
on the type of OAM message. The OAM frame including OAM data
portion should result in an Ethernet frame with valid length.
Therefore, if necessary the OAM frame may be padded with zeros
for a minimum size frame.
7.3. Continuity Check
OAM data field for CC Messages may include the following TLVs:
Sajassi, Mohan et al. [Page 12]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
- Lifetime TLV: Specifies the number of seconds, after the
receipt of CC message, that the information related to CC
message may be discarded by the recipient.
- Maintenance Point State TLV: Identifies the state of the
maintenance point and/or ports associated with it.
- Device Management Address TLV: May identify the Layer 3 address
required to access the source Maintenance PointÆs control MIB.
7.4. Loopback
Specific OAM data field information is FFS.
7.5. TraceRoute
7.5.1. TraceRoute Request Format
The OAM data field of a TraceRoute Request may contain the following
TLVs:
- Source Maintenance Point MAC TLV: Specifies the MAC address of
the maintenance point that originated the TraceRoute request.
It may be different from the source MAC address of a TraceRoute
request, because each bridge along the path puts its own MAC
address in the source MAC address field, while retaining the
Source Maintenance Point MAC TLV.
- Target Maintenance Point MAC TLV: Specifies the MAC address of
the peer maintenance point. This TLV is passed on to the next
hop.
- Hop Count TLV: Hop Count TLV is the hop count of the
intermediate/maintenance point(s) from where the response is
expected by source maintenance point.
7.5.2. TraceRoute Reply Format
The OAM data field of a TraceRoute Reply contains the following
TLVs:
- Hop Count TLV: It is the number of hops between the responding
intermediate/maintenance point and the source maintenance
point.
- Ingress Device Management Address TLV: The TLV specifies the
Layer 3 address required to access the control MIB for the
Sajassi, Mohan et al. [Page 13]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
Maintenance Point or Intermediate Point on which the TraceRoute
Request was received.
8. Acknowledgments
We wish to thank Marc Holness, Tim Mancour, and Paul Bottorff 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
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
Sajassi, Mohan et al. [Page 14]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
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
Ali Sajassi Dinesh Mohan
Cisco Systems, Inc. Nortel Networks
170 West Tasman Drive 3500 Carling Ave.
San Jose, CA 95134 Ottawa, ON K2H 8E9
Email: sajassi@cisco.com Email: mohand@nortelnetworks.com
Norm Finn Vasile Radoaca
Cisco Systems, Inc. Nortel Networks
170 West Tasman Drive 600 Technology Park
San Jose, CA 95134 Billerica, MA 01821
Email: nfinn@cisco.com Email: vasile@nortelnetworks.com
Thomas D. Nadeau Shahram Davari
Sajassi, Mohan et al. [Page 15]
Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004
Cisco Systems, Inc. PMC Sierra
300 Beaver Brook Road 411 Legget Drive
Boxborough, MA 01719 Ottawa, ON K2K 3C9
Email: tnadeau@cisco.com Email: shahram_davari@pmc-
sierra.com
Monique Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland
Email: mmorrow@cisco.com
Sajassi, Mohan et al. [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 18:37:58 |