Network Working Group
Internet Draft Document                      Dinesh Mohan (Editor)
Internet Draft                                     Nortel Networks
Expires: March April 2005                           Ali Sajassi (Editor)
                                                     Cisco Systems

                                                 September

                                                      October 2004

              VPLS OAM Requirements and Framework
             draft-ietf-l2vpn-oam-req-frmk-00.txt

1.
             draft-ietf-l2vpn-oam-req-frmk-01.txt

Status of this Memo

By submitting this Internet-Draft, we represent that any applicable
patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we are aware have been or will
be disclosed, and any of which we become aware will be disclosed in
accordance with RFC 3668.

This document is an Internet-Draft and is in full conformance with all provisions
Sections 5 and 6 of RFC 3667 and Section 10 5 of RFC2026. RFC 3668.

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.

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
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.
This draft provides framework and requirements for Virtual Private
LAN Service (VPLS) Operation, Administration and Maintenance (OAM).

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

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-
03.txt
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-
01.txt

Mohan and Sajassi     Expires: March 2005                 [Page 1] 

http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mgt-fwk-01.txt
http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls-
fm-00.txt
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls-
pm-00.txt
http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-oam-
req-frmk-00.txt

WHERE DOES THIS FIT IN THE PICTURE OF THE ROUTING WORK

L2VPN

WHY IS IT TARGETED AT THIS WG

This draft describes requirements and framework for VPLS OAM.

JUSTIFICATION

The charter of L2VPN WG includes L2VPN specific OAM extensions,
where the extensions apply to existing OAM solutions for VPLS, VPWS,
and IP-only L2VPNs.
03.txt

Table of Contents

1.

Status of this Memo.............................................1 Memo................................................1
Abstract...........................................................1
Conventions........................................................1
1. Introduction....................................................2
2. Abstract........................................................1
3. Conventions.....................................................1
4. Overview........................................................3
5. L2VPN Services & Networks.......................................4
6.
3. OAM Layering....................................................5
6.1.
3.1. OAM Domains...................................................6
6.2. Maintenance Entity Points
3.2. MEPs & Maintenance Intermediate Points...7
6.2.1. MIPs...................................................7
3.3. MEP and MIP Identifiers.....................................8
7. Identifiers.......................................8
4. VPLS OAM Requirements...........................................9
7.1.
4.1. Discovery.....................................................9
7.2.
4.2. Connectivity Fault Management.................................9
7.2.1.
4.2.1. Connectivity Fault Detection................................9
7.2.2.
4.2.2. Connectivity Fault Verification.............................9
7.2.3.
4.2.3. Connectivity Fault Localization............................10
7.2.4.
4.2.4. Connectivity Fault Alarm...................................10
7.3.
4.3. Frame Loss...................................................10
7.4.
4.4. Frame Delay..................................................10
7.5.
4.5. Frame Delay Variation........................................11
7.6.
4.6. Data Path Execution..........................................11
7.7.
4.7. Scalability..................................................11
7.8.
4.8. Extensibility................................................12
7.9.
4.9. Security.....................................................12
7.10.
4.10. Transport Independence......................................12

7.11.
4.11. Application Independence....................................13
7.12.
4.12. Backward Compatibility......................................13
7.13.
4.13. Availability................................................13
8.
5. Acknowledgments................................................13
9.
6. Security Considerations........................................14
10.
7. Intellectual Property Considerations..........................14
11. Considerations...........................14
8. Full Copyright Statement......................................14 Statement.......................................14
9. IPR Notice.....................................................14
10. Normative References..........................................15
11. Informative References........................................15
12. References....................................................15
13. Authors' Addresses............................................15

4. Overview Addresses............................................16

1.        Introduction

This draft provides framework and requirements for Virtual Private
LAN Service (VPLS) Operation, Administration and Maintenance (OAM).

The scope of OAM for any service and/or transport/network
infrastructure technologies can be very broad in nature. OSI has
defined the following five generic functional areas for network
management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault
Management, b) Performance Management, c) Configuration Management,
d) Accounting Management, and e) Security Management.

This draft focuses on the Fault and Performance Management aspects.
Other functional aspects of FCAPS are for further study.

[L2VPN-FRWK] specified three different types of Layer 2 VPN (i.e.
services). These are VPWS, VPLS and IPLS. The framework and
requirements presented in this draft applies to VPLS.

Fault Management can typically be viewed in terms of 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 device 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
device or link. 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 devices of a fault. For example, when there is a
client/server relationship between two layered networks, Fault
Detection at the server layer will require the following Fault
Notification:
- sending a forward Fault Notification into the client layer
  network(s) using the Fault Notification format appropriate to
  the client layer
- sending a backward Fault Notification, if applicable, in the
  reverse direction in the server layer network

Finally, Fault Recovery deals with recovering from the detected
failure by switching to an alternate available device or link (e.g.,
device redundancy or link redundancy).

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. metric objectives/specifications. Performance Management
typically consists of measurement of Performance Parameters e.g.
Frame Loss, Frame Delay, Frame Delay Variation aka Jitter etc. (aka Jitter) etc
across managed entities when the managed entity are in available
state. Performance Management is suspended across unavailable
managed entities. This draft introduces some of these performance
parameters.

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.

This proposal is aligned with the current discussions in other
standard bodies and groups such as ITU-T Q.3/13, IEEE 802.1, and MEF
which are addressing Ethernet network and service OAM.

5.

2.        L2VPN Services & Networks

As described in [L2VPN-REQ], following Figure 1 shows a L2VPN
reference model. L2VPN A represents a point-to-point service while
L2VPN B represents a bridged service.

 +-----+                                   +-----+
 + CE1 +--+                             +--| CE2 |
 +-----+  |    .....................    |  +-----+
 L2VPN A  |  +----+             +----+  |  L2VPN A
          +--| PE |-- Service --| PE |--+
             +----+   Provider  +----+
            /  .      Backbone     .  \    --------_
 +-----+   /   .         |         .   \  /        \   +-----+
 + CE4 +--+    .         |         .    +-\ Access  \--| CE5 |
 +-----+       .       +----+      .      | Network |  +-----+
 L2VPN B       ........| PE |.......       \       /   L2VPN B
                       +----+   ^           -------
                         |      | logical
                         |      | switching
                      +-----+   | instance
                      | CE3 |
                      +-----+
                      L2VPN B

            Figure 1: L2VPN Reference Model

[L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a
point-to-point service where CEs are presented with point-to-point

virtual circuits. VPLS is a bridged LAN service provided to a set of
CEs that are members of a VPN. CEs that are member of the same
service instance communicate with each other as if they are
connected via a bridged LAN. IPLS is a special VPLS which is used to
carry only IP service packets.

The point-to-point or 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 L2VPN 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.

[L2VPN-REQ] assumes the availability of runtime monitoring protocols
while defining requirements for management interfaces. This draft
specifies the requirements and framework for operations,
administration and maintenance (OAM) protocols between network
devices.

When discussing the OAM mechanisms for VPLS, it is important to
consider that the end-to-end service can span across different types
of L2VPN 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]. 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 [VPLS-BGP], and
distributed VPLS as described in [ROSEN-SIG].

Therefore, it is important that the OAM 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 L2VPNs.
Therefore, for L2VPN OAM, it is important to ensure that the OAM
mechanisms are independent of the underlying transport mechanisms
and solely rely on layer 2 services, e.g. for VPLS service, the
transparency of OAM mechanisms must be ensured over underlying
transport technologies such as MPLS, IP, etc.

6.

3.        OAM Layering

Figure 2 shows an example of a VPLS service (with two CE belonging
to customer A) across a service provider network marked by UPE and
NPE devices. More CE devices belonging to the same Customer A can be
connected across customer's different sites. Service provider
network is segmented into core network and two types of access

network. Figure 2(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 2(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 2: Service specific device view

As shown in Figure 2(B), only the devices with Ethernet
functionality are visible to OAM mechanisms operating at Ethernet
MAC layer and the P devices are invisible. Therefore, the OAM along
the path of P devices (e.g., between two PEs) is covered by
transport layer and it is outside the scope of this document.

6.1.

3.1.          OAM Domains

As described in the previous section, a VPLS service for a given
customer can span across one or more service providers and network
operators. Therefore, when discussing OAM tools for VPLS 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. OAM domains can be
nested but not overlapped. In other words, if there is a hierarchy
of the OAM domains, the OAM messages of a higher-level domain pass
transparently through the lower-level domains but the OAM messages
of a lower-level domain get blocked/filtered at the edge of that
domain.

In order to facilitate the processing of OAM messages, each domain
can be associated with a 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 OAM 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 3 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 3: OAM Domains

6.2. Maintenance Entity Points

3.2.          MEPs & MIPs

Maintenance Intermediate Points

Maintenance Entity End Points (MEPs) are responsible for origination and
termination of OAM messages. MEPs are located at the edge of their
corresponding OAM domains. Maintenance Intermediate Points (MIPs)
are located within their corresponding domains and they normally
pass OAM messages but never initiate them. Since MEPs 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 entering the domain. MEPs and MIPs correspond to a PE or more
specifically to an interface of a PE. For example, an OAM message
can be said to originate from an ingress PE or more specifically an
ingress interface of that PE.

Since OAM domains are hierarchical as described above, the MEPs and
MIPs associated with the OAM domains become hierarchical as well. A
MEP of a higher-level domain is always a MEP of a lower-level domain
but the converse is not always true since the MEP of lower-level
domain can either be MIP or a MEP of a higher-level domain.
Furthermore, the MIPs of a lower-level domain are always transparent

to the higher-level domain (e.g., OAM messages of a higher-level
domain are not seen by MIPs 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)    MEP---MIP--------------------------------MIP---MEP
                           Customer Domain

 (D)          MEP--------MIP-----------MIP-------MEP
                           Provider domain

 (E)          MEP-MIP-MIP-MEP----------MEP-------MEP
                 Operator     Operator    Operator
                  domain       domain      domain

 (F)                      MEP--MIP-MIP-MEP--MIP--MEP
                                MPLS        MPLS
                               domain      domain

            Figure 4: OAM Domains, MEPs & MIPs

As shown in Figure 4, (C) represents those MEPs and MIPs that are
visible within the customer domain. (D) represents the MEPs and MIPs
visible within the service provider domain, while (E) represents the
MEPs and MIPs visible within each operator domain. Further, (F)
represents the MEPs and MIPs corresponding to the MPLS layer and may
apply MPLS based mechanisms. The MPLS layer shown in Figure 4 is
just an example and specific OAM mechanisms are outside the scope of
this document.

6.2.1.

3.3.          MEP and MIP Identifiers

As mentioned previously, L2VPN OAM should be independent of
underlying transport layer and only be dependent on service layer,
e.g. Ethernet MAC layer in case of VPLS service. As an example, for
Ethernet MAC layer, the MEPs and MIPs should be identified with
their Ethernet MAC addresses. As described in [VPLS-LDP], VPLS
instance can be 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 Service Identifier (e.g., VPN identifier).
MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids must be unique
within their corresponding Service Identifiers within the OAM
domains.

For Ethernet services e.g. VPLS, Ethernet frames are used for OAM
messages and the source MAC address of the OAM frames represent the
source MEP in that domain. For unicast Ethernet OAM frames, the
destination MAC address represents the destination MEP in that
domain. For multicast Ethernet OAM frames, the destination MAC
addresses corresponds to all MEPs in that domain.

7.

4.        VPLS OAM Requirements

7.1.

4.1.          Discovery

Discovery allows a service aware device to learn about other devices
that support the same service instance within a given domain.

Discovery also allows a service aware device to learn sufficient
information (e.g. IP addresses, MAC addressed etc.) from other
service aware devices such that OAM messages can be exchanged among
the service aware devices.

(R1) OAM MUST allow a service aware device to discover other devices
that share the same service instance(s) within a given OAM domain.

7.2.

4.2.          Connectivity Fault Management

Service is realized by exchanging service frames/packets between
devices that support the service instance. To allow the exchange of
service frames, connectivity between these service aware devices is
required.

7.2.1.

4.2.1.            Connectivity Fault Detection

To ensure service, pro-active connectivity monitoring is required.
Connectivity monitoring facilitates connectivity fault detection.

(R2a) OAM MUST allow pro-active connectivity monitoring between two
service aware devices that support the same service instance within
a given OAM domain.

7.2.2.

4.2.2.            Connectivity Fault Verification

Once a connectivity fault is detected, connectivity fault
verification may be performed.

(R2b) OAM MUST allow connectivity fault verification between two
service aware devices that support the same service instance within
a given OAM domain.

7.2.3.

4.2.3.            Connectivity Fault Localization

Further, localization of connectivity fault may be carried out.

(R2c) OAM MUST allow connectivity fault localization between two
service aware devices that support the same service instance within
a given OAM domain.

7.2.4.

4.2.4.            Connectivity Fault Alarm

Typically, when connectivity fault is detected and optionally
verified, service device may notify the EMS/NMS (Element Management
System/Network Management System).

However, a single transport/network fault may cause multiple
services to fail causing multiple connectivity faults. Though
independence with transport/network OAM mechanisms is desirable, it
may be useful to suppress service connectivity fault notification
when the fault causing condition is detected at the
transport/network. Therefore,
OAM must allow alarm notification to allow suppression of service
connectivity fault notifications.

(R2d) OAM MUST allow forwarding of transport/network fault
indications to those service aware devices that support service
instance affected by the fault.

7.3.

4.3.          Frame Loss

A service may be considered degraded if it is sensitive to service
frames/packets loss during transit between the service aware
devices. To determine if a service is degraded due to frame/packet
loss, measurement of frame/packet loss is required.

(R3) OAM MUST support measurement of per-service frame/packet loss
between two service aware devices that support the same service
instance within a given OAM domain.

7.4.

4.4.          Frame Delay

A service may be sensitive to delay experienced by the service
frames/packets during transit between the service aware devices. To
determine if a service is degraded due to frame/packet delay,
measurement of frame/packet delay is required.

Frame/packet delay measurement can be of two types:

One-way delay
One-way delay is used to characterize certain applications like
multicast and broadcast applications. The measurement for one-way

delay usually requires clock synchronization between two devices in
question.

Two-way delay
Two-way delay or round-trip delay does not require clock
synchronization between two devices involved in measurement and is
usually sufficient to determine the frame/packet delay being
experienced.

(R4a) OAM MUST support measurement of per-service two-way
frame/packet delay between two service aware devices that support
the same service instance within a given OAM domain.

(R4b) OAM SHOULD support measurement of per-service one-way
frame/packet delay between two service aware devices that support
the same service instance within a given OAM domain.

7.5.

4.5.          Frame Delay Variation

A service may be sensitive to delay variation experienced by the
service frames/packets during transit between the service aware
devices. To determine if a service is degraded due to frame/packet
delay variation, measurement of frame/packet delay variation is
required. For frame/packet delay variation measurements, one-way
mechanisms are considered to be sufficient.

(R5) OAM MUST support measurement of per-service frame/packet delay
variation between two service aware devices that support the same
service instance within a given OAM domain.

7.6.

4.6.          Data Path Execution

If the OAM frames flow across a different path than the one used by
service frames/packets, accurate measurement and/or determination of
service state may not be made. Therefore data path, i.e. the one
being taken by service frames/packets, must be used for the service
OAM.

(R6) OAM frames MUST be forwarded along the same path as the
service/data frames.

7.7.

4.7.          Scalability

Mechanisms developed for OAM need to be such that per-service OAM
can be supported even though the OAM may only be used for limited
services e.g. premium services and may not be used for best effort
services.

Note: The specific numbers or range of services should align with
the [L2VPN-FRWK]

(R7) OAM MUST be scalable such that a service device can support OAM
for each service that is supported by the device.

7.8.

4.8.          Extensibility

Extensibility is intended to allow introduction of additional
functionality in future such that backward compatibility can be
maintained i.e. when working with older version devices, service OAM
with reduced functionality is still possible.

(R8) OAM MUST be extensible such that new functionality and
information elements related to this functionality can be introduced
in future.

7.9.

4.9.          Security

OAM frames belonging to an OAM domain originate and terminate within
that OAM domain. Security implies that an OAM domain must be capable
of filtering OAM frames. The filtering is such that the OAM frames
are prevented from leaking outside their domain. Also, OAM frames
from outside the OAM domains should be either discarded (when such
OAM frames belong to same or lower-level OAM domain) or
transparently passed (when such OAM frames belong to a higher-level
OAM domain).

(R9a) OAM frames MUST be prevented from leaking outside their OAM
domain.

(R9b) OAM frames from outside an OAM domain MUST be prevented from
entering the OAM domain when such OAM frames belong to the same
level or lower-level OAM domain.

(R9c) OAM frames from outside an OAM domain MUST be transported
transparently inside the OAM domain when such OAM frames belong to
the higher-level OAM domain.

7.10.

4.10.           Transport Independence

Service frame/packets delivery is carried out across transport
infrastructure, also called as network infrastructure. Though specific
transport/network technologies may provider provide their own OAM
capabilities, Service OAM must be independently supported as many
different transport/network technologies can be used to carry
service frame/packets.

(R10a) OAM MUST be independent of the underlying transport/network
technologies and specific transport/network OAM capabilities.

(R10b) OAM MAY allow interworking adaptation/interworking with specific
transport/network OAM functions. For example, this would be useful
to utilize allow Fault Notifications from transport/network OAM capabilities.

7.11. layer(s) to be
sent to service layer.

4.11.           Application Independence

Service itself may be used to carry application frame/packets. The
application may use its own OAM; service OAM must not be dependent
on application OAM. As an example, a VPLS service may be used to
carry IP traffic; however, VPLS OAM should not assume IP or rely on
the use of IP level OAM functions.

(R11a) OAM MUST be independent of the application technologies and
specific application OAM capabilities.

(R11b) OAM MAY allow interworking with specific application OAM to
allow applications to utilize service OAM capabilities.

7.12. Backward Compatibility

Service

4.12.           Backward Compatibility

Service OAM should be such that non-service aware and/or OAM
incapable devices in the middle of the OAM domain should be able to
forward the OAM frames similar to the regular service/data
frames/packets.

(R12) OAM MUST be defined such that devices not supporting the OAM
are able to forward the OAM frames in a similar fashion as the
regular service/data frames/packets.

7.13.

4.13.           Availability

A service may be considered unavailable if the service
frames/packets do not reach their intended destination (e.g.
connectivity is down or frame/packet loss is occurring) or the
service is degraded (e.g. frame/packet delay and/or delay variation
threshold is exceeded).

Entry and exit conditions may be defined for unavailable state.
Availability itself may be defined in context of service type.

Since availability measurement may be associated with connectivity,
frame/packet loss, frame/packet delay and frame/packet delay
variation measurements, no additional requirements are specified
currently.

8.

5.        Acknowledgments

The authors would like to thank Shahram Davari, Norm Finn, and Vasile Radoaca
Radoaca, Thomas Nadeau, and Monique Morrow for their contributions
and review.

The authors would also like to thank Yoav Cohen, Marc Holness,
Malcolm Betts, Paul Bottorff, Dave Allan, and Monique Morrow Hamid-ould Brahim for
their valuable feedback.

9.

6.        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.

7.        Intellectual Property Considerations

This document is being submitted for use in IETF standards
discussions.

11.

8.        Full Copyright Statement

Copyright (C) The Internet Society (2001).  All Rights Reserved. (2004). This document and translations of it may be copied and furnished is subject
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 rights, licenses and this paragraph
are included on all such copies and derivative works.  However, this
document itself may not be modified restrictions contained in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, BCP 78 and
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 set forth therein, the Internet Society or its successors or assigns. authors retain all their rights.

This document and the information contained herein is are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

12.

9.        IPR Notice

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this

specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at ietf-
ipr@ietf.org.

10.         Normative References

[NM-Standards] "TMN Management Functions", M.3400, February 2000.

[RFC3036] "LDP Specification", RFC 3036, January 2001.

11.         Informative References

[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
01.txt,
08.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 September 2004.

[L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned
Virtual Private LAN Services (VPLS)",
draft-ietf-ppvpn-vpls-requirements-01.txt, Networks", draft-ietf-l2vpn-requirements-02.txt,
Work in progress, October
2002. September 2004.

[L2VPN-FRWK] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, "Framework for Layer 2 Virtual Private Networks
(L2VPNs)", draft-ietf-l2vpn-l2-framework-05.txt, Work in Progress, February 2003.

[802.1ad]
June 2004.

[IEEE 802.1ad] "IEEE standard for Provider Bridges, Bridges", Work in
Progress,
December 2002"

<To be updated September 2004.

[ROSEN-SIG] "Provisioning Models and Endpoint Identifiers in the next Rev.>

13. L2VPN
Signaling", draft-ietf-l2vpn-signaling-02.txt, Work in progress,
September 2004.

[VPLS-LDP] "Virtual Private LAN Services over MPLS",
draft-ietf-l2vpn-vpls-ldp-05.txt, Work in progress, September 2004.

[VPLS-BGP] "Virtual Private LAN Service",
draft-ietf-l2vpn-vpls-bgp-02.txt, Work in progress, May 2004.

12.         Authors' Addresses

Dinesh Mohan
Nortel Networks
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortelnetworks.com

Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com