draft-ietf-l2vpn-oam-req-frmk-11.txt   rfc6136.txt 
Internet-Draft A. Sajassi (Editor) Internet Engineering Task Force (IETF) A. Sajassi, Ed.
L2VPN Working Group Cisco Request for Comments: 6136 Cisco
Category: Informational Category: Informational D. Mohan, Ed.
D. Mohan (Editor) ISSN: 2070-1721 Nortel
March 2011
Expires: April 24, 2011 October 24, 2010
L2VPN OAM Requirements and Framework Layer 2 Virtual Private Network (L2VPN)
draft-ietf-l2vpn-oam-req-frmk-11.txt Operations, Administration, and Maintenance (OAM)
Requirements and Framework
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with This document provides framework and requirements for Layer 2 Virtual
the provisions of BCP 78 and BCP 79. Private Network (L2VPN) Operations, Administration, and Maintenance
(OAM). The OAM framework is intended to provide OAM layering across
L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN)
tunnels. This document is intended to identify OAM requirements for
L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual
Private Wire Service (VPWS), and IP-only LAN Service (IPLS).
Furthermore, if L2VPN service OAM requirements impose specific
requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN
OAM requirements are also identified.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This document is not an Internet Standards Track specification; it is
months and may be updated, replaced, or obsoleted by other documents published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6136.
Copyright and License Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Table of Contents
This draft provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM). The OAM framework is intended to provide OAM layering across
L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN)
tunnels. The requirements are intended to identify OAM requirement
for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if
L2VPN services OAM requirements impose specific requirements on PW
OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements
are also identified.
Conventions used in this document
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.
When these key words are used in consideration of RFC 2119, these
key words are used in capitalized form as indicated above.
Table of Contents 1. Introduction ....................................................4
1.1. Specification of Requirements ..............................6
1.2. Relationship with Other OAM Work ...........................6
2. Terminology .....................................................7
3. L2VPN Services and Networks .....................................7
4. L2VPN OAM Framework .............................................8
4.1. OAM Layering ...............................................8
4.2. OAM Domains ................................................9
4.3. MEPs and MIPs .............................................10
4.4. MEP and MIP Identifiers ...................................11
5. OAM Framework for VPLS .........................................11
5.1. VPLS as Service/Network ...................................11
5.1.1. VPLS as Bridged LAN Service ........................11
5.1.2. VPLS as a Network ..................................12
5.1.3. VPLS as (V)LAN Emulation ...........................12
5.2. VPLS OAM ..................................................13
5.2.1. VPLS OAM Layering ..................................13
5.2.2. VPLS OAM Domains ...................................14
5.2.3. VPLS MEPs and MIPs .................................15
5.2.4. VPLS MEP and MIP Identifiers .......................16
6. OAM Framework for VPWS .........................................17
6.1. VPWS as Service ...........................................17
6.2. VPWS OAM ..................................................18
6.2.1. VPWS OAM Layering ..................................18
6.2.2. VPWS OAM Domains ...................................19
6.2.3. VPWS MEPs and MIPs .................................21
6.2.4. VPWS MEP and MIP Identifiers .......................23
7. VPLS OAM Requirements ..........................................23
7.1. Discovery .................................................24
7.2. Connectivity Fault Management .............................24
7.2.1. Connectivity Fault Detection .......................24
7.2.2. Connectivity Fault Verification ....................24
7.2.3. Connectivity Fault Localization ....................24
7.2.4. Connectivity Fault Notification and Alarm
Suppression ........................................25
7.3. Frame Loss ................................................25
7.4. Frame Delay ...............................................25
7.5. Frame Delay Variation .....................................26
7.6. Availability ..............................................26
7.7. Data Path Forwarding ......................................26
7.8. Scalability ...............................................27
7.9. Extensibility .............................................27
7.10. Security .................................................27
7.11. Transport Independence ...................................28
7.12. Application Independence .................................28
Conventions used in this document.................................. 2 8. VPWS OAM Requirements ..........................................28
1. Introduction.................................................... 4 8.1. Discovery .................................................29
1.1 Relationship with Other OAM Work............................... 5 8.2. Connectivity Fault Management .............................29
1.2 Terminology.................................................... 6 8.2.1. Connectivity Fault Detection .......................29
2. L2VPN Services & Networks....................................... 6 8.2.2. Connectivity Fault Verification ....................29
3. L2VPN OAM Framework............................................. 7 8.2.3. Connectivity Fault Localization ....................29
3.1. OAM Layering.................................................. 7 8.2.4. Connectivity Fault Notification and Alarm
3.2. OAM Domains................................................... 8 Suppression ........................................30
3.3. MEPs and MIPs................................................. 9 8.3. Frame Loss ................................................30
3.4. MEP and MIP Identifiers...................................... 10 8.4. Frame Delay ...............................................30
4. OAM Framework for VPLS......................................... 10 8.5. Frame Delay Variation .....................................31
4.1. VPLS as Service/Network...................................... 10 8.6. Availability ..............................................31
4.1.1. VPLS as Bridged LAN Service................................ 10 8.7. Data Path Forwarding ......................................32
4.1.2. VPLS as a Network.......................................... 11 8.8. Scalability ...............................................32
4.1.3. VPLS as (V)LAN Emulation................................... 11 8.9. Extensibility .............................................32
4.2. VPLS OAM..................................................... 11 8.10. Security .................................................32
4.2.1. VPLS OAM Layering.......................................... 12 8.11. Transport Independence ...................................33
4.2.2. VPLS OAM Domains........................................... 13 8.12. Application Independence .................................33
4.2.3. VPLS MEPs & MIPs........................................... 13 8.13. Prioritization ...........................................34
4.2.4. VPLS MEP and MIP Identifiers............................... 14 9. VPLS (V)LAN Emulation OAM Requirements .........................34
5. OAM Framework for VPWS......................................... 14 9.1. Partial-Mesh of PWs .......................................34
5.1. VPWS as Service.............................................. 15 9.2. PW Fault Recovery .........................................34
5.2. VPWS OAM..................................................... 15 9.3. Connectivity Fault Notification and Alarm Suppression .....35
5.2.1. VPWS OAM Layering.......................................... 16 10. OAM Operational Scenarios .....................................35
5.2.2. VPWS OAM Domains........................................... 16 10.1. VPLS OAM Operational Scenarios ...........................36
5.2.3. VPWS MEPs & MIPs........................................... 18 11. Security Considerations .......................................37
5.2.4. VPWS MEP and MIP Identifiers............................... 20 12. Contributors ..................................................38
6. VPLS Service OAM Requirements.................................. 20 13. Acknowledgements ..............................................38
6.1. Discovery.................................................... 20 14. References ....................................................38
6.2. Connectivity Fault Management................................ 20 14.1. Normative References .....................................38
6.2.1. Connectivity Fault Detection............................... 21 14.2. Informative References ...................................39
6.2.2. Connectivity Fault Verification............................ 21 Appendix A. Alternate Management Models ...........................41
6.2.3. Connectivity Fault Localization............................ 21 A.1. Alternate Model 1 (Minimal OAM) ..............................41
6.2.4. Connectivity Fault Notification and Alarm Suppression...... 21 A.2. Alternate Model 2 (Segment OAM Interworking) .................41
6.3. Frame Loss................................................... 21
6.4. Frame Delay.................................................. 22
6.5. Frame Delay Variation........................................ 22
6.6. Availability................................................. 22
6.7. Data Path Forwarding......................................... 23
6.8. Scalability.................................................. 23
6.9. Extensibility................................................ 23
6.10. Security.................................................... 24
6.11. Transport Independence...................................... 24
6.12. Application Independence.................................... 24
7. VPWS OAM Requirements.......................................... 25
7.1. Discovery.................................................... 25
7.2. Connectivity Fault Management................................ 25
7.2.1. Connectivity Fault Detection............................... 25
7.2.2. Connectivity Fault Verification............................ 26
7.2.3. Connectivity Fault Localization............................ 26
7.2.4. Connectivity Fault Notification and Alarm Suppression...... 26
7.3. Frame Loss................................................... 27
7.4. Frame Delay.................................................. 27
7.5. Frame Delay Variation........................................ 27
7.6. Availability................................................. 28
7.7. Data Path Forwarding......................................... 28
7.8. Scalability.................................................. 28
7.9. Extensibility................................................ 28
7.10. Security.................................................... 29
7.11. Transport Independence...................................... 29
7.12. Application Independence.................................... 30
7.13. Prioritization.............................................. 30
8. VPLS (V)LAN Emulation OAM Requirements......................... 30
8.1. Partial-mesh of PWs.......................................... 30
8.2. PW Fault Recovery............................................ 31
8.3. Connectivity Fault Notification and Alarm Suppression........ 31
9. OAM Operational Scenarios...................................... 31
9.1. VPLS OAM Operational Scenarios............................... 31
10. Acknowledgments............................................... 33
12. IANA Considerations........................................... 33
11. Security Considerations....................................... 33
13. References.................................................... 33
13.1 Normative References......................................... 33
13.2 Informative References....................................... 34
A1. Appendix 1 - Alternate Management Models...................... 34
A1.1. Alternate Model 1 (Minimal OAM)............................. 34
A1.2. Alternate Model 2 (Segment OAM Interworking)................ 35
Authors' Addresses................................................ 36
1. Introduction 1. Introduction
This draft provides framework and requirements for Layer 2 Virtual This document provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance Private Network (L2VPN) Operation, Administration, and Maintenance
(OAM). (OAM).
The scope of OAM for any service and/or transport/network The scope of OAM for any service and/or transport/network
infrastructure technologies can be very broad in nature. OSI has infrastructure technologies can be very broad in nature. OSI has
defined the following five generic functional areas commonly defined the following five generic functional areas commonly
abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b) abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b)
Performance Management, c) Configuration Management, d) Accounting Configuration Management, c) Accounting Management, d) Performance
Management, and e) Security Management. Management, and e) Security Management.
This draft focuses on the Fault and Performance Management aspects. This document focuses on the Fault and Performance Management
Other functional aspects of FCAPS are for further study. aspects. Other functional aspects of FCAPS are for further study.
Fault Management can typically be viewed in terms of the following Fault Management can typically be viewed in terms of the following
categories: categories:
- Fault Detection
- Fault Verification
- Fault Isolation
- Fault Notification & Alarm Suppression
- Fault Recovery
Fault Detection deals with mechanism(s) that can detect both hard - Fault Detection
- Fault Verification
- Fault Isolation
- Fault Notification and Alarm Suppression
- Fault Recovery
Fault detection deals with mechanism(s) that can detect both hard
failures, such as link and device failures, and soft failures, such failures, such as link and device failures, and soft failures, such
as software failure, memory corruption, mis-configuration, etc. as software failure, memory corruption, misconfiguration, etc.
Typically a lightweight protocol is desirable to detect the fault Typically, a lightweight protocol is desirable to detect the fault
and thus it would be prudent to verify the fault via Fault and thus it would be prudent to verify the fault via a fault
Verification mechanism before taking additional steps in isolating verification mechanism before taking additional steps in isolating
the fault. After verifying that a fault has occurred along the data the fault. After verifying that a fault has occurred along the data
path, it is important to be able to isolate the fault to the level path, it is important to be able to isolate the fault to the level of
of a given device or link. Therefore, a Fault Isolation mechanism is a given device or link. Therefore, a fault isolation mechanism is
needed in Fault Management. Fault Notification mechanism can be used needed in Fault Management. A fault notification mechanism can be
in conjunction with Fault Detection mechanism to notify the devices used in conjunction with a fault detection mechanism to notify the
upstream and downstream to the fault detection point. For example, devices upstream and downstream to the fault detection point. For
when there is a client/server relationship between two layered example, when there is a client/server relationship between two
networks, Fault Detection at the server layer may result in the layered networks, fault detection at the server layer may result in
following Fault Notifications: the following fault notifications:
- sending a forward Fault Notification from server layer to the
client layer network(s) using the Fault Notification format
appropriate to the client layer
- sending a backward Fault Notification at server layer, if
applicable, in the reverse direction
- sending a backward Fault Notification at client layer, if
applicable, in the reverse direction
Finally, Fault Recovery deals with recovering from the detected - Sending a forward fault notification from the server layer to
the client layer network(s) using the fault notification format
appropriate to the client layer
- Sending a backward fault notification at the server layer, if
applicable, in the reverse direction
- Sending a backward fault notification at the client layer, if
applicable, in the reverse direction
Finally, fault recovery deals with recovering from the detected
failure by switching to an alternate available data path using failure by switching to an alternate available data path using
alternate devices or links (e.g., device redundancy or link alternate devices or links (e.g., device redundancy or link
redundancy). redundancy).
Performance Management deals with mechanism(s) that allow Performance Management deals with mechanism(s) that allow determining
determining and measuring the performance of network/services under and measuring the performance of the network/services under
consideration. Performance Management can be used to verify the consideration. Performance Management can be used to verify the
compliance to both the service and network level metric compliance to both the service-level and network-level metric
objectives/specifications. Performance Management typically consists objectives/specifications. Performance Management typically consists
of measurement of performance metrics e.g. Frame Loss, Frame Delay, of measurement of performance metrics, e.g., Frame Loss, Frame Delay,
Frame Delay Variation (aka Jitter) etc. across managed entities when Frame Delay Variation (aka Jitter), etc., across managed entities
the managed entities are in available state. Performance Management when the managed entities are in available state. Performance
is suspended across unavailable managed entities. Management is suspended across unavailable managed entities.
[L2VPN-FRWK] specifies three different types of Layer 2 VPN [L2VPN-FRWK] specifies three different types of Layer 2 VPN services:
services. These are VPWS, VPLS and IPLS. Virtual Private LAN Service (VPLS), (Virtual Private Wire Service
(VPWS), and IP-only LAN Service (IPLS).
This document provides a reference model for OAM as it relates to This document provides a reference model for OAM as it relates to
L2VPN services and their associated Pseudo Wires (PWs) and Public L2VPN services and their associated pseudowires (PWs) and Public
Switched Network (PSN) tunnels. OAM requirement for L2VPN services Switched Network (PSN) tunnels. OAM requirements for L2VPN services
(e.g. VPLS and VPWS) are also identified. Furthermore, if L2VPN (e.g., VPLS and VPWS) are also identified. Furthermore, if L2VPN
services OAM requirements impose requirements for PW and/or PSN OAM, service OAM requirements impose requirements for PW and/or PSN OAM,
those specific PW and/or PSN OAM requirements are also identified. those specific PW and/or PSN OAM requirements are also identified.
1.1 Relationship with Other OAM Work 1.1. Specification of Requirements
This document leverages protocols, mechanisms and concepts defined The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
as part of other OAM work. More specifically: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
IEEE Std. 802.1ag-2007 [IEEE 802.1ag] specifies the Ethernet 1.2. Relationship with Other OAM Work
Connectivity Fault Management protocol, which defines the concepts
of Maintenance Domains, Maintenance End-Points and Maintenance
Intermediate Points. This standard also defines mechanisms and
procedures for proactive fault detection (Continuity Check), fault
notification (Remote Defect Indication - RDI), fault verification
(Loopback) and fault isolation (LinkTrace) in Ethernet networks.
ITU-T Std. Y.1731 [Y.1731] builds upon and extends IEEE 802.1ag in This document leverages protocols, mechanisms, and concepts defined
the following areas: it defines fault notification and alarm as part of other OAM work, specifically the following:
suppression functions for Ethernet (via Alarm Indication Signal -
AIS). It also specifies messages and procedures for Ethernet
performance management, including loss, delay, jitter and throughput
measurement.
1.2 Terminology - IEEE Std. 802.1ag-2007 [IEEE802.1ag] specifies the Ethernet
Connectivity Fault Management protocol, which defines the
concepts of Maintenance Domains, Maintenance End Points, and
Maintenance Intermediate Points. This standard also defines
mechanisms and procedures for proactive fault detection
(Continuity Check), fault notification (Remote Defect
Indication (RDI)), fault verification (Loopback), and fault
isolation (LinkTrace) in Ethernet networks.
This document introduces and uses the following terms. Further, this - ITU-T Std. Y.1731 [Y.1731] builds upon and extends IEEE 802.1ag
document also uses the terms defined in [L2VPN-FRWK] and [L2VPN- in the following areas: it defines fault notification and alarm
TERM]. suppression functions for Ethernet (via Alarm Indication Signal
(AIS)). It also specifies messages and procedures for Ethernet
performance management, including loss, delay, jitter, and
throughput measurement.
2. Terminology
This document introduces and uses the following terms. This document
also uses the terms defined in [L2VPN-FRWK] and [L2VPN-TERM].
AIS Alarm Indication Signal AIS Alarm Indication Signal
FM Fault Management
IPLS IP-only LAN Service IPLS IP-only LAN Service
ME Maintenance Entity which is defined in a given OAM
domain and represents an entity requiring monitoring ME Maintenance Entity, which is defined in a given OAM
MEG Maintenance Entity Group which represents MEs belonging domain and represents an entity requiring management
to the same service instance. MEG is also called as
Maintenance Association (MA). MEG Maintenance Entity Group, which represents MEs belonging
MEP Maintenance End Point is responsible for origination to the same service instance and is also called
and termination of OAM frames for a given MEG Maintenance Association (MA)
MEP Maintenance End Point is responsible for origination and
termination of OAM frames for a given MEG.
MIP Maintenance Intermediate Point is located between peer MIP Maintenance Intermediate Point is located between peer
MEPs and can process OAM frames but does not initiate MEPs and can process and respond to certain OAM frames
or terminate them but does not initiate or terminate them.
OAM Domain OAM Domain represents a region over which OAM frames
can operate unobstructed OAM Domain OAM Domain represents a region over which OAM frames can
PM Performance Management operate unobstructed.
QinQ 802.1Q tag inside another 802.1Q tag
RDI Remote Defect Indication RDI Remote Defect Indication
SLA Service Level Agreement
STP Spanning Tree Protocols
VPLS Virtual Private LAN Service VPLS Virtual Private LAN Service
VPWS Virtual Private Wire Service VPWS Virtual Private Wire Service
2. L2VPN Services & Networks 3. L2VPN Services and Networks
As described in [L2VPN-REQ], following Figure 1 shows a L2VPN Figure 1 shows an L2VPN reference model as described in [L2VPN-REQ].
reference model. L2VPN A represents a point-to-point service while L2VPN A represents a point-to-point service while L2VPN B represents
L2VPN B represents a bridged service. a bridged service.
+-----+ +-----+ +-----+ +-----+
+ CE1 +--+ +--| CE2 | + CE1 +--+ +--| CE2 |
+-----+ | ..................... | +-----+ +-----+ | ..................... | +-----+
L2VPN A | +----+ +----+ | L2VPN A L2VPN A | +----+ +----+ | L2VPN A
+--| PE |-- Service --| PE |--+ +--| PE |-- Service --| PE |--+
+----+ Provider +----+ +----+ Provider +----+
/ . Backbone . \ --------_ / . Backbone . \ --------_
+-----+ / . | . \ / \ +-----+ +-----+ / . | . \ / \ +-----+
+ CE4 +--+ . | . +-\ Access \--| CE5 | + CE4 +--+ . | . +-\ Access \--| CE5 |
+-----+ . +----+ . | Network | +-----+ +-----+ . +----+ . | Network | +-----+
L2VPN B ........| PE |....... \ / L2VPN B L2VPN B ........| PE |....... \ / L2VPN B
+----+ ^ ------- +----+ ^ -------
| | logical | | logical
| | switching | | switching
+-----+ | instance +-----+ | instance
| CE3 | | CE3 |
+-----+ +-----+
L2VPN B L2VPN B
Figure 1: L2VPN Reference Model Figure 1: L2VPN Reference Model
[L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a [L2VPN-FRWK] specifies VPWS, VPLS, and IPLS. VPWS is a point-to-
point-to-point service where CEs are presented with point-to-point point service where Customer Edges (CEs) are presented with point-to-
virtual circuits. VPLS is a bridged LAN service provided to a set of point virtual circuits. VPLS is a bridged LAN service provided to a
CEs that are members of a VPN. CEs that are members of the same set of CEs that are members of a VPN. CEs that are members of the
service instance communicate with each other as if they are same service instance communicate with each other as if they were
connected via a bridged LAN. IPLS is a special VPLS which is used to connected via a bridged LAN. IPLS is a special VPLS that is used to
carry only IP service packets. carry only IP service packets.
[L2VPN-REQ] assumes the availability of runtime monitoring protocols [L2VPN-REQ] assumes the availability of runtime monitoring protocols
while defining requirements for management interfaces. This draft while defining requirements for management interfaces. This document
specifies the requirements and framework for operations, specifies the requirements and framework for operations,
administration and maintenance (OAM) protocols between network administration, and maintenance (OAM) protocols between network
devices. devices.
3. L2VPN OAM Framework 4. L2VPN OAM Framework
3.1. OAM Layering
4.1. OAM Layering
The point-to-point or bridged LAN functionality is emulated by a 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 network of Provider Edges (PEs) to which the CEs are connected. This
can belong to a single network operator or can span across multiple network of PEs can belong to a single network operator or can span
network operators. Furthermore, it can belong to a single service across multiple network operators. Furthermore, it can belong to a
provider or can span across multiple service providers. A service single service provider or can span across multiple service
provider is responsible for providing L2VPN services to its providers. A service provider is responsible for providing L2VPN
customers; whereas, a network operator (aka facility provider) services to its customers, whereas a network operator (aka facility
provides the necessary facilities to the service provider(s) in provider) provides the necessary facilities to the service
support of their services. A network operator and a service provider(s) in support of their services. A network operator and a
provider can be part of same administrative organization or they can service provider can be part of the same administrative organization,
be different administrative organizations. or they can belong to different administrative organizations.
Different layers involved in realizing L2VPNs include service layer The different layers involved in realizing L2VPNs include service
and network layers. Network layers can be iterative. In context of layers and network layers. Network layers can be iterative. In the
L2VPNs, the service layers consists of VPLS, VPWS (e.g. Ethernet, context of L2VPNs, the service layer consists of VPLS, VPWS (e.g.,
ATM, FR, HDLC, SONET, etc. point-to-point emulation), and IPLS. Ethernet, ATM, FR, HDLC, SONET, point-to-point emulation, etc.), and
Similarly in context of L2VPNs, network layers consist of MPLS/IP IPLS. Similarly, in the context of L2VPNs, network layers consist of
networks. The MPLS/IP networks can consist of networks links MPLS/IP networks. The MPLS/IP networks can consist of networks links
realized by different technologies e.g. SONET, Ethernet, ATM etc. realized by different technologies, e.g., SONET, Ethernet, ATM, etc.
Each layer is responsible for its own OAM. This document provides Each layer is responsible for its own OAM. This document provides
the OAM framework and requirements for L2VPN services and networks. the OAM framework and requirements for L2VPN services and networks.
3.2. OAM Domains 4.2. OAM Domains
When discussing OAM tools for L2VPNs it is important to provide OAM When discussing OAM tools for L2VPNs, it is important to provide OAM
capabilities and functionality over each domain that a service capabilities and functionality over each domain for which a service
provider or a network operator is responsible for. For these provider or a network operator is responsible. It is also important
reasons, it is also important that OAM frames are not allowed to that OAM frames not be allowed to enter/exit other domains. We
enter/exit other domains. We define an OAM domain as a network define an OAM domain as a network region over which OAM frames
region over which OAM frames operate unobstructed as explained operate unobstructed, as explained below.
below.
At the edge of an OAM domain, filtering constructs should prevent At the edge of an OAM domain, filtering constructs should prevent OAM
OAM frames from exiting and entering that domain. OAM domains can be frames from exiting and entering that domain. OAM domains can be
nested but not overlapped. In other words, if there is a hierarchy nested but not overlapped. In other words, if there is a hierarchy
of the OAM domains, the OAM frames of a higher-level domain pass of the OAM domains, the OAM frames of a higher-level domain pass
transparently through the lower-level domains but the OAM frames of transparently through the lower-level domains, but the OAM frames of
a lower-level domain get blocked/filtered at the edge of that a lower-level domain get blocked/filtered at the edge of that domain.
domain.
In order to facilitate the processing of OAM frames, each OAM domain In order to facilitate the processing of OAM frames, each OAM domain
can be associated with a level at which it operates. Higher level can be associated with the level at which it operates. Higher-level
OAM domains can contain lower level OAM domains but the converse is OAM domains can contain lower-level OAM domains, but the converse is
not true. It may be noted that the higher level domain does not not true. It may be noted that the higher-level domain does not
necessarily mean a higher numerical value of the level encoding in necessarily mean a higher numerical value of the level encoding in
the OAM frame. the OAM frame.
A PE can be part of several OAM domains with each interface A PE can be part of several OAM domains, with each interface
belonging to the same or a different OAM domain. A PE shall block belonging to the same or a different OAM domain. A PE, with an
outgoing OAM frames and filter out incoming OAM frames whose domain interface at the boundary of an OAM domain, shall block outgoing OAM
level is lower or same to the one configured on that interface and frames, filter out incoming OAM frames whose domain level is lower or
pass through the OAM frames whose domain level is higher than the the same as the one configured on that interface, and pass through
one configured on that interface. the OAM frames whose domain level is higher than the one configured
on that interface.
Generically, L2VPNs can be viewed as consisting of customer OAM Generically, L2VPNs can be viewed as consisting of a customer OAM
domain, service provider OAM domain, and network operator OAM domain domain, a service provider OAM domain, and network operator OAM
as depicted in Figure 2. domains as depicted in Figure 2.
--- --- --- ---
/ \ ------ ------- ----- / \ / \ ------ ------- ----- / \
| CE-- / \ / \ / \ --CE | | CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --PE P P PE-- --- --- --PE P P PE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ----- ------ ------- -----
Customer OAM Domain Customer OAM Domain
|<-------------------------------------------->| |<-------------------------------------------->|
Service Provider OAM Domain Service Provider OAM Domain
|<------------------------------>| |<------------------------------>|
Operator Operator Operator Operator Operator Operator
|<-------->|<--------->|<------->| |<-------->|<--------->|<------->|
OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain
Figure 2: OAM Domains Figure 2: OAM Domains
The OAM Domains can be categorized as: The OAM Domains can be categorized as follows:
8 Hierarchical OAM Domains: Hierarchical OAM Domains result from - Hierarchical OAM Domains: Hierarchical OAM Domains result from
OAM Layering and imply a contractual agreement among the OAM OAM Layering and imply a contractual agreement among the OAM
Domain ownerships. In the above example, Customer OAM Domain, Domain owning entities. In Figure 2, the customer OAM domain,
Service Provider OAM Domain and Operator OAM Domains are the service provider OAM domain, and the operator OAM domains
hierarchical. are hierarchical.
8 Adjacent OAM Domains: Adjacent OAM Domains are typically
independent of each other and do not have any relationship
among them. In the above example, the different Operator OAM
Domains are independent of each other.
3.3. MEPs and MIPs - Adjacent OAM Domains: Adjacent OAM Domains are typically
independent of each other and do not have any relationship
among them. In Figure 2, the different operator OAM domains
are independent of each other.
4.3. MEPs and MIPs
Maintenance End Points (MEPs) are responsible for origination and Maintenance End Points (MEPs) are responsible for origination and
termination of OAM frames. MEPs are located at the edge of their termination of OAM frames. MEPs are located at the edge of their
corresponding OAM domains. Maintenance Intermediate Points (MIPs) corresponding OAM domains. Maintenance Intermediate Points (MIPs)
are located within their corresponding OAM domains and they normally are located within their corresponding OAM domains, and they normally
pass OAM frames but never initiate them. Since MEPs are located at pass OAM frames but never initiate them. Since MEPs are located at
the edge of their OAM domains, they are responsible for filtering the edge of their OAM domains, they are responsible for filtering
outbound OAM frames from leaving the OAM domain or inbound OAM outbound OAM frames from leaving the OAM domain or inbound OAM frames
frames from entering the OAM domain. from entering the OAM domain.
An OAM frame is generally associated with a Maintenance Entity (ME) An OAM frame is generally associated with a Maintenance Entity Group
or a Maintenance Entity Group (MEG), where a MEG consists of a set (MEG), where a MEG consists of a set of Maintenance Entities (MEs)
of MEs associated with the same service instance. A ME is a point- associated with the same service instance. An ME is a point-to-point
to-point association between a pair of MEPs and represents a association between a pair of MEPs and represents a monitored entity.
monitored entity. For example, in a VPLS service which involves n For example, in a VPLS that involves n CEs, all the MEs associated
CEs, all the MEs associated with the VPLS service in the customer with the VPLS in the customer OAM domain (i.e., from CE to CE) can be
OAM domain (i.e. from CE to CE) can be considered to be part of a considered to be part of a VPLS MEG, where the n-point MEG consists
VPLS MEG, where the n-point MEG consists of a maximum of n(n-1)/2 of a maximum of n(n-1)/2 MEs. MEPs and MIPs correspond to a PE, or,
MEs. MEPs and MIPs correspond to a PE or more specifically to an more specifically, to an interface of a PE. For example, an OAM
interface of a PE. For example, an OAM frame can be said to frame can be said to originate from an ingress PE or more
originate from an ingress PE or more specifically an ingress specifically an ingress interface of that PE. A MEP on a PE receives
interface of that PE. A MEP on a PE receives messages from n-1 other messages from n-1 other MEPs (some of them may reside on the same PE)
MEPs (some of them may reside on the same PE) for a given MEG. for a given MEG.
In Hierarchical OAM Domains, a MEP of lower-level OAM domain can In Hierarchical OAM Domains, a MEP of lower-level OAM domain can
correspond to a MIP or a MEP of a higher-level OAM domain. correspond to a MIP or a MEP of a higher-level OAM domain.
Furthermore, the MIPs of a lower-level OAM domain are always Furthermore, the MIPs of a lower-level OAM domain are always
transparent to the higher-level OAM domain (e.g., OAM frames of a transparent to the higher-level OAM domain (e.g., OAM frames of a
higher-level OAM domain are not seen by MIPs of a lower-level OAM higher-level OAM domain are not seen by MIPs of a lower-level OAM
domain and get passed through them transparently). Further, the MEs domain and get passed through them transparently). Further, the MEs
(or MEGs) are hierarchically organized in hierarchical OAM domains. (or MEGs) are hierarchically organized in hierarchical OAM domains.
For example, in a VPWS service, the VPWS ME in Customer OAM domain For example, in a VPWS, the VPWS ME in the customer OAM domain can
can coincide with the Attachment Circuit (AC) ME, PW ME and another overlap with the Attachment Circuit (AC) ME, PW ME, and another AC ME
AC ME in Service Provider OAM Domain. Similarly, the PW ME can in service provider OAM domain. Similarly, the PW ME can overlap
coincide with different ME in Operator OAM Domains. with different ME in operator OAM domains.
3.4. MEP and MIP Identifiers 4.4. MEP and MIP Identifiers
As mentioned previously, OAM at each layer should be independent of As mentioned previously, OAM at each layer should be independent of
other layers e.g. service layer OAM should be independent of other layers, e.g., a service layer OAM should be independent of an
underlying transport layer. MEPs and MIPs at each layer should be underlying transport layer. MEPs and MIPs at each layer should be
identified with layer specific identifiers. identified with layer-specific identifiers.
4. OAM Framework for VPLS 5. OAM Framework for VPLS
Virtual Private LAN Service (VPLS) is used in different contexts. In Virtual Private LAN Service (VPLS) is used in different contexts,
general, VPLS is used in the following contexts: a) as a bridged LAN such as the following: a) as a bridged LAN service over networks,
service over networks, some of which are MPLS/IP, b) as an MPLS/IP some of which are MPLS/IP, b) as an MPLS/IP network supporting these
network supporting these bridged LAN services, and c) as (V)LAN bridged LAN services, and c) as (V)LAN emulation.
emulation.
4.1. VPLS as Service/Network 5.1. VPLS as Service/Network
4.1.1. VPLS as Bridged LAN Service 5.1.1. VPLS as Bridged LAN Service
The most common definition for VPLS is for bridged LAN service over The most common definition for VPLS is for bridged LAN service over
an MPLS/IP network. The service coverage is considered end-to-end an MPLS/IP network. The service coverage is considered end-to-end
from UNI to UNI (or AC to AC) among the CE devices and it provides a from UNI to UNI (or AC to AC) among the CE devices, and it provides a
virtual LAN service to the attached CEs belonging to that service virtual LAN service to the attached CEs belonging to that service
instance. The reason it is called bridged LAN service is because the instance. The reason it is called bridged LAN service is because the
VPLS-capable PE providing this end-to-end virtual LAN service is VPLS-capable PE providing this end-to-end virtual LAN service is
performing bridging functions (either full or a subset) as described performing bridging functions (either full or a subset) as described
in the [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN- in [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN-REQ],
REQ], includes both bridge module and LAN emulation module (as includes both bridge module and LAN emulation module (as specified in
specified in [L2VPN-FRWK]). [L2VPN-FRWK]).
A VPLS service instance is also analogous to a VLAN provided by IEEE Throughout this document, whenever the term "VPLS" is used by itself,
802.1Q networks since each VLAN provides a Virtual LAN service to it refers to the service as opposed to network or LAN emulation.
its MAC users. Therefore, when a part of the service provider
network is Ethernet based (such as H-VPLS with QinQ access network),
there is a one-to-one correspondence between a VPLS service instance
and its corresponding provider VLAN in the service provider Ethernet
network. To check the end-to-end service integrity, the OAM
mechanism needs to cover the end-to-end VPLS service as defined in
[L2VPN-REQ] which is from AC to AC including bridge module, VPLS
forwarder, and the associated PWs for this service. This draft
specifies the framework and requirements for such OAM mechanism.
4.1.2. VPLS as a Network A VPLS instance is also analogous to a VLAN provided by IEEE 802.1Q
networks since each VLAN provides a Virtual LAN service to its Media
Access Control (MAC) users. Therefore, when a part of the service
provider network is Ethernet based (such as H-VPLS with QinQ access
network), there is a one-to-one correspondence between a VPLS
instance and its corresponding provider VLAN in the service provider
Ethernet network. To check the end-to-end service integrity, the OAM
mechanism needs to cover the end-to-end VPLS as defined in
[L2VPN-REQ], which is from AC to AC, including bridge module, VPLS
forwarder, and the associated PWs for this service. This document
specifies the framework and requirements for such OAM mechanisms.
5.1.2. VPLS as a Network
Sometimes VPLS is also used to refer to the underlying network that Sometimes VPLS is also used to refer to the underlying network that
supports bridged LAN services. This network can be an end-to-end supports bridged LAN services. This network can be an end-to-end
MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid MPLS/IP network, as in H-VPLS with MPLS/IP access, or it can be a
network consisting of MPLS/IP core and Ethernet access network as in hybrid network consisting of MPLS/IP core and Ethernet access
H-VPLS with QinQ access. In either case, the network consists of a network, as in H-VPLS with QinQ access. In either case, the network
set of VPLS-capable PE devices capable of performing bridging consists of a set of VPLS-capable PE devices capable of performing
functions (either full or a subset). These VPLS-capable PE devices bridging functions (either full or a subset). These VPLS-capable PE
can be arranged in a certain topology such as hierarchical topology devices can be arranged in a certain topology, such as hierarchical
(H-VPLS) or distributed topology (D-VPLS) or some other topologies topology, distributed topology, or some other topologies such as
such as multi-tier or star topologies. To check the network multi-tier or star topologies. To check the network integrity
integrity regardless of the network topology, network-level OAM regardless of the network topology, network-level OAM mechanisms
mechanisms (such as OAM for MPLS/IP networks) are needed. The (such as OAM for MPLS/IP networks) are needed. The discussion of
discussion of network-level OAM is outside of the scope of this network-level OAM is outside of the scope of this document.
draft.
4.1.3. VPLS as (V)LAN Emulation 5.1.3. VPLS as (V)LAN Emulation
Sometimes VPLS also refers to (V)LAN emulation. In such context, Sometimes VPLS also refers to (V)LAN emulation. In this context,
VPLS only refers to the full mesh of PWs with split horizon that VPLS only refers to the full mesh of PWs with split horizon that
emulates a LAN segment over MPLS/IP network for a given service emulates a LAN segment over a MPLS/IP network for a given service
instance and its associated VPLS forwarder. Since the emulated LAN instance and its associated VPLS forwarder. Since the emulated LAN
segment is presented as a Virtual LAN (VLAN) to the bridge module of segment is presented as a Virtual LAN (VLAN) to the bridge module of
a VPLS-capable PE, the emulated segment is also referred to as an a VPLS-capable PE, the emulated segment is also referred to as an
emulated VLAN. The OAM mechanisms in this context refer primarily to emulated VLAN. The OAM mechanisms in this context refer primarily to
integrity check of VPLS forwarders and its associated full-mesh of integrity check of VPLS forwarders and their associated full mesh of
PWs and the ability to detect and notify a partial mesh failure. PWs and the ability to detect and notify a partial mesh failure.
This draft also covers the OAM framework and requirements for such This document also covers the OAM framework and requirements for such
OAM mechanism. OAM mechanisms.
4.2. VPLS OAM 5.2. VPLS OAM
When discussing the OAM mechanisms for VPLS, it is important to When discussing the OAM mechanisms for VPLS, it is important to
consider that the end-to-end service can span across different types 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 of L2VPN networks. For example, the access network on one side can
network on one side can be bridged network e.g. [IEEE 802.1ad], as be a bridged network, e.g., [IEEE802.1ad], as described in Section 11
described in section 11 of [VPLS-LDP]. The access network can also of [VPLS-LDP]. The access network can also be a [IEEE802.1ah]-based
be a [IEEE 802.1ah] based bridged network. The access network on bridged network. The access network on the other side can be MPLS-
other side can be MPLS based as described in section 10 of [VPLS- based, as described in Section 10 of [VPLS-LDP], and the core network
LDP]; and the core network connecting them can be IP, MPLS, ATM, or connecting them can be IP, MPLS, ATM, or SONET. Similarly, the VPLS
SONET. Similarly, the VPLS service instance can span across [VPLS- instance can span across [VPLS-BGP] and distributed VPLS as described
BGP], and distributed VPLS as described in [L2VPN-SIG]. in [L2VPN-SIG].
Therefore, it is important that the OAM mechanisms can be applied to Therefore, it is important that the OAM mechanisms can be applied to
all these network types. Each such network may be associated with a all these network types. Each such network may be associated with a
separate administrative domain and also multiple such networks may separate administrative domain, and multiple such networks may be
be associated with a single administrative domain. It is important associated with a single administrative domain. It is important to
to ensure that the OAM mechanisms are independent of the underlying ensure that the OAM mechanisms are independent of the underlying
transport mechanisms and solely rely on VPLS service, i.e. the transport mechanisms and solely rely on VPLS, i.e., the transparency
transparency of OAM mechanisms must be ensured over underlying of OAM mechanisms must be ensured over underlying transport
transport technologies such as MPLS, IP, etc. technologies such as MPLS, IP, etc.
This proposal is aligned with the discussions in other standard This proposal is aligned with the discussions in other standard
bodies and groups such as ITU-T Q.5/13, IEEE 802.1, and MEF which bodies and groups such as ITU-T Q.5/13, IEEE 802.1, and Metro
address Ethernet network and service OAM. Ethernet Forum (MEF), which address Ethernet network and service OAM.
4.2.1. VPLS OAM Layering 5.2.1. VPLS OAM Layering
Figure 3 shows an example of a VPLS service (with two CE belonging Figure 3 shows an example of a VPLS (with two CEs belonging to
to customer A) across a service provider network marked by UPE and customer A) across a service provider network marked by UPE and NPE
NPE devices. More CE devices belonging to the same Customer A can be devices. More CE devices belonging to the same customer A can be
connected across different customer sites. Service provider network connected across different customer sites. The service provider
is segmented into core network and two types of access network. network is segmented into a core network and two types of access
Figure 3(A) shows the bridged access network represented by its networks. In Figure 3, (A) shows the bridged access network
bridge components marked B, and the MPLS access and core network represented by its bridge components marked B and the MPLS access and
represented by MPLS components marked P. Figure 3(B) shows the core network represented by MPLS components marked P. In Figure 3,
service/network view at the Ethernet MAC layer marked by E. (B) shows the service/network view at the Ethernet MAC layer marked
by E.
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A | | A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ---- ------ ------- ----
(A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE (A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE
(B) E------E---E--E---E------------E----------E-----E (B) E------E---E--E---E------------E----------E-----E
Figure 3: VPLS specific device view Figure 3: VPLS-Specific Device View
As shown in Figure 3(B), only the devices with Ethernet As shown in (B) of Figure 3, only the devices with Ethernet
functionality are visible to OAM mechanisms operating at Ethernet functionality are visible to OAM mechanisms operating at the Ethernet
MAC layer and the P devices are invisible. Therefore, the OAM along 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 the path of P devices (e.g., between two PEs) is covered by the
transport layer and it is outside the scope of this document. transport layer, and it is outside the scope of this document.
However, VPLS services may impose some specific requirements on PSN However, VPLSs may impose some specific requirements on PSN OAM.
OAM. This document aims to identify such requirements. This document aims to identify such requirements.
4.2.2. VPLS OAM Domains 5.2.2. VPLS OAM Domains
As described in the previous section, a VPLS service for a given As described in the previous section, a VPLS for a given customer can
customer can span across one or more service providers and network span across one or more service providers and network operators.
operators. Figure 4 depicts three OAM domains: (A) customer domain Figure 4 depicts three OAM domains: (A) customer domain, which is
which is among the CEs of a given customer, (B) service provider among the CEs of a given customer, (B) service provider domain, which
domain which is among the edge PEs of the given service provider, is among the edge PEs of the given service provider, and (C) network
and (C) network operator domain which is among the PEs of a given operator domain, which is among the PEs of a given operator.
operator.
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| CE-- / \ / \ / \ --CE | | CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ---- ------ ------- ----
Customer OAM Domain Customer OAM Domain
(A) |<----------------------------------------------->| (A) |<----------------------------------------------->|
Provider OAM Domain Provider OAM Domain
(B) |<---------------------------------->| (B) |<---------------------------------->|
Operator Operator Operator Operator Operator Operator
(C) |<--------->|<---------->|<-------->| (C) |<--------->|<---------->|<-------->|
OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain
Figure 4: VPLS OAM Domains Figure 4: VPLS OAM Domains
4.2.3. VPLS MEPs & MIPs 5.2.3. VPLS MEPs and MIPs
As shown in Figure 5, (C) represents those MEPs and MIPs that are As shown in Figure 5, (C) represents those MEPs and MIPs that are
visible within the customer domain. The MIP associated with (C) are visible within the customer domain. The MIPs associated with (C) are
expected to be implemented in the bridge module/VPLS forwarder of a expected to be implemented in the bridge module/VPLS forwarder of a
PE device, as per the [L2VPN-FRWK]. (D) represents the MEPs and MIPs PE device, as per [L2VPN-FRWK]. (D) represents the MEPs and MIPs
visible within the service provider domain. These MEPs and MIPs are visible within the service provider domain. These MEPs and MIPs are
expected to be implemented in the bridge module/VPLS forwarder of a expected to be implemented in the bridge module/VPLS forwarder of a
PE device, as per the [L2VPN-FRWK]. (E) represents the MEPs and MIPs PE device, as per [L2VPN-FRWK]. (E) represents the MEPs and MIPs
visible within each operator domain where MIPs only exist in an visible within each operator domain, where MIPs only exist in an
Ethernet access network (e.g., an MPLS access network doesn't have Ethernet access network (i.e., an MPLS access network does not have
MIPs at the operator level). Further, (F) represents the MEPs and MIPs at the operator level). Further, (F) represents the MEPs and
MIPs corresponding to the MPLS layer and may apply MPLS based MIPs corresponding to the MPLS layer and may apply MPLS-based
mechanisms. The MPLS layer shown in Figure 5 is just an example and mechanisms. The MPLS layer shown in Figure 5 is just an example;
specific OAM mechanisms are outside the scope of this document. specific OAM mechanisms are outside the scope of this document.
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A | | A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ---- ------ ------- ----
(A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE (A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE
(B) E------E---E------E------------E----------E-----E (B) E------E---E------E------------E----------E-----E
Customer OAM domain Customer OAM Domain
(C) MEP---MIP--------------------------------MIP---MEP (C) MEP---MIP--------------------------------MIP---MEP
Provider OAM domain Provider OAM Domain
(D) MEP--------MIP-----------MIP-------MEP (D) MEP--------MIP-----------MIP-------MEP
Operator Operator Operator Operator Operator Operator
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
OAM domain OAM domain OAM domain OAM domain OAM domain OAM domain
MPLS OAM MPLS OAM MPLS OAM MPLS OAM
(F) MEP--MIP--MEP|MEP-MIP-MEP (F) MEP--MIP--MEP|MEP-MIP-MEP
domain domain domain domain
Figure 5: VPLS OAM Domains, MEPs & MIPs Figure 5: VPLS OAM Domains, MEPs, and MIPs
4.2.4. VPLS MEP and MIP Identifiers 5.2.4. VPLS MEP and MIP Identifiers
In VPLS, for Ethernet MAC layer, the MEPs and MIPs should be In VPLS, for the Ethernet MAC layer, the MEPs and MIPs should be
identified with their Ethernet MAC addresses. As described in [VPLS- identified with their Ethernet MAC addresses and Maintenance Entity
LDP], VPLS instance can be identified in an Ethernet domain (e.g., Group Identifier (MEG ID). As described in [VPLS-LDP], a VPLS
802.1ad domain) using VLAN tag (service tag) while in an MPLS/IP instance can be identified in an Ethernet domain (e.g., 802.1ad
network, PW-ids are used. Both PW-ids and VLAN tags for a given VPLS domain) using a VLAN tag (service tag) while in an MPLS/IP network,
instance are associated with a Service Identifier (e.g., VPN PW-ids are used. Both PW-ids and VLAN tags for a given VPLS instance
identifier). MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids, are associated with a Service Identifier (e.g., VPN identifier).
must be unique within their corresponding Service Identifiers within MEPs and MIPs Identifiers, i.e., MEP Ids and MIP Ids, must be unique
the OAM domains. within their corresponding Service Identifiers within the OAM
domains.
For Ethernet services, e.g. VPLS, Ethernet frames are used for OAM For Ethernet services, e.g., VPLS, Ethernet frames are used for OAM
frames and the source MAC address of the OAM frames represent the frames, and the source MAC address of the OAM frames represent the
source MEP in that domain. For unicast Ethernet OAM frames, the source MEP in that domain for a specific MEG. For unicast Ethernet
destination MAC address represents the destination MEP in that OAM frames, the destination MAC address represents the destination
domain. For multicast Ethernet OAM frames, the destination MAC MEP in that domain for a specific MEG. For multicast Ethernet OAM
addresses corresponds to all MEPs in that domain. frames, the destination MAC addresses correspond to all MEPs in that
domain for a specific MEG.
5. OAM Framework for VPWS 6. OAM Framework for VPWS
Figure 6 shows the VPWS reference model. VPWS is a point-to-point Figure 6 shows the VPWS reference model. VPWS is a point-to-point
service where CEs are presented with point-to-point virtual service where CEs are presented with point-to-point virtual circuits.
circuits. VPWS is realized by combining a pair of Attachment VPWS is realized by combining a pair of Attachment Circuits (ACs) and
Circuits between the CEs and PEs and a PW between PEs. a single PW between two PEs.
|<------------- VPWS1 <AC11,PW1,AC12> ------------>| |<------------- VPWS1 <AC11,PW1,AC12> ------------>|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC11---| |.......PW1........| |--AC12----| | | |---AC11---| |.......PW1........| |--AC12----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
| |---AC21---| |.......PW2........| |--AC22----| | | |---AC21---| |.......PW2........| |--AC22----| |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| +----+ PSN Tunnel +----+ | | +----+ PSN Tunnel +----+ |
| | | |
|<------------- VPWS2 <AC21,PW2,AC22> ------------>| |<------------- VPWS2 <AC21,PW2,AC22> ------------>|
Figure 6: VPWS Reference Model Figure 6: VPWS Reference Model
5.1. VPWS as Service 6.1. VPWS as Service
VPWS service can be categorized as: VPWS can be categorized as follows:
8 VPWS with homogeneous ACs (where both ACs are same type)
8 VPWS with heterogeneous ACs (where the ACs are of different
Layer-2 encapsulation)
Further, the VPWS can itself be classified as: - VPWS with homogeneous ACs (where both ACs are same type)
8 Homogeneous VPWS (when two ACs and PW are of the same type)
8 Heterogeneous VPWS (when at least one AC or PW is different - VPWS with heterogeneous ACs (where the ACs are of different
type than the others) Layer-2 encapsulation)
Further, the VPWS can itself be classified as follows:
- Homogeneous VPWS (when two ACs and PW are of the same type)
- Heterogeneous VPWS (when at least one AC or PW is a different
type than the others)
Based on the above classifications, the heterogeneous VPWS may have Based on the above classifications, the heterogeneous VPWS may have
either homogeneous or heterogeneous ACs. On the other hand, either homogeneous or heterogeneous ACs. On the other hand,
homogeneous VPWS can have only homogeneous ACs. homogeneous VPWS can have only homogeneous ACs.
5.2. VPWS OAM Throughout this document, whenever the term "VPWS" is used by itself,
it refers to the service.
6.2. VPWS OAM
When discussing the OAM mechanisms for VPWS, it is important to When discussing the OAM mechanisms for VPWS, it is important to
consider that the end-to-end service can span across different types consider that the end-to-end service can span across different types
of networks. As an example, the access network between CE and PE on of networks. As an example, the access network between the CE and PE
one side can be Ethernet bridged network, ATM network, etc. In on one side can be an Ethernet-bridged network, an ATM network, etc.
common scenarios, it could simply be a point-to-point interface such In common scenarios, it could simply be a point-to-point interface
as Ethernet PHY. The core network connecting PEs can be IP, MPLS, such as Ethernet Physical Layer (PHY). The core network connecting
etc. PEs can be IP, MPLS, etc.
Therefore, it is important that the OAM mechanisms can be applied to Therefore, it is important that the OAM mechanisms can be applied to
different network types some of which are mentioned above. Each such different network types, some of which are mentioned above. Each
network may be associated with a separate administrative domain and such network may be associated with a separate administrative domain,
also multiple such networks may be associated with a single and multiple such networks may be associated with a single
administrative domain. administrative domain.
5.2.1. VPWS OAM Layering 6.2.1. VPWS OAM Layering
Figure 7 shows an example of a VPWS service (with two CE devices Figure 7 shows an example of a VPWS (with two CE devices belonging to
belonging to customer A) across a service provider network marked by customer A) across a service provider network marked by PE devices.
PE devices. Service provider network can be considered to be The service provider network can be considered to be segmented into a
segmented into a core network and two types of access network. core network and two types of access networks.
In the most general case, a PE can be client service aware when it In the most general case, a PE can be client service aware when it
processes client service PDUs and is responsible for encapsulating processes client service PDUs and is responsible for encapsulating
and de-encapsulating client service PDUs onto PWs and ACs. This is and de-encapsulating client service PDUs onto PWs and ACs. This is
particularly relevant for homogeneous VPWS. The service specific particularly relevant for homogeneous VPWS. The service-specific
device view for such a deployment is highlighted by Figure 7(A) for device view for such a deployment is highlighted by (A) in Figure 7,
these are the devices that are expected to be involved in end-to-end for these are the devices that are expected to be involved in end-to-
VPWS OAM. end VPWS OAM.
In other instances, a PE can be client service unaware when it does In other instances, a PE can be client service unaware when it does
not process native service PDUs but instead encapsulates access not process native service PDUs but instead encapsulates access
technology PDUs over PWs. This may be relevant for VPWS with technology PDUs over PWs. This may be relevant for VPWS with
heterogeneous ACs. For example, if the service is Ethernet VPWS heterogeneous ACs, such as Ethernet VPWS, which is offered across an
which is offered across an ATM AC, ATM PW and Ethernet AC. In this ATM AC, ATM PW, and Ethernet AC. In this case, the PE that is
case, the PE which is attached to ATM AC and ATM PW may be attached to ATM AC and ATM PW may be transparent to the client
transparent to the client Ethernet service PDUs. On the other hand, Ethernet service PDUs. On the other hand, the PE that is attached to
the PE which is attached to ATM PW and Ethernet AC is expected to be ATM PW and Ethernet AC is expected to be client Ethernet service
client Ethernet service aware. The service specific device view for aware. The service-specific device view for such a deployment is
such a deployment is highlighted by Figure 7(B) for these are the highlighted by (B) in Figure 7, for these are the devices that are
devices that are expected to be involved in end-to-end VPWS OAM, expected to be involved in end-to-end VPWS OAM, where PE1 is expected
where PE1 is expected to be client service unaware. to be client service unaware.
|<--------------- VPWS <AC1,PW,AC2> -------------->| |<--------------- VPWS <AC1,PW,AC2> -------------->|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
access core access access core access
|<---------->|<---------------------->|<------------>| |<---------->|<---------------------->|<------------>|
(A).CE----------PE-----------------------PE-------------CE (A) CE----------PE-----------------------PE-------------CE
(B).CE-----------------------------------PE-------------CE (B) CE-----------------------------------PE-------------CE
Figure 7: VPWS specific device view Figure 7: VPWS-Specific Device View
5.2.2. VPWS OAM Domains 6.2.2. VPWS OAM Domains
As described in the previous section, a VPWS service for a given
customer can span across one or more network operators.
Figure 8a and 8b depicts three OAM domains: (A) customer domain As described in the previous section, a VPWS for a given customer can
span across one or more network operators.
Figures 8a and 8b depict three OAM domains: (A) customer domain,
which is among the CEs of a given customer, (B) service provider which is among the CEs of a given customer, (B) service provider
domain which depends on the management model, and (C) network domain, which depends on the management model, and (C) network
operator domain which is among the PEs of a given operator and could operator domain, which is among the PEs of a given operator and could
also be present in the access network if the ACs are provided by a also be present in the access network if the ACs are provided by a
different network operator. The core network operator may be different network operator. The core network operator may be
responsible for managing the PSN Tunnel in these examples. responsible for managing the PSN Tunnel in these examples.
For the first management model, as shown in Figure 8a, the CEs are For the first management model, shown in Figure 8a, the CEs are
expected to be managed by the customer and the customer is expected to be managed by the customer, and the customer is
responsible for running end-to-end service OAM, if needed. The responsible for running end-to-end service OAM if needed. The
service provider is responsible for monitoring the PW ME and the service provider is responsible for monitoring the PW ME, and the
monitoring of the AC is the shared responsibility of the customer monitoring of the AC is the shared responsibility of the customer and
and the service provider. In most simple cases, when the AC is the service provider. In most simple cases, when the AC is realized
realized across a physical interface that connects the CE to PE, the across a physical interface that connects the CE to PE, the
monitoring requirements across the AC ME are minimal. monitoring requirements across the AC ME are minimal.
|<--------------- VPWS <AC1,PW,AC2> -------------->| |<--------------- VPWS <AC1,PW,AC2> -------------->|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
Customer OAM Domain Customer OAM Domain
(A).|<------------------------------------------------->| (A) |<------------------------------------------------->|
Service Provider OAM Domain Service Provider OAM Domain
(B) |<--------------------------->| (B) |<--------------------------->|
Operator OAM Domain Operator OAM Domain
(C) |<---------------->| (C) |<---------------->|
Figure 8a: VPWS OAM Domains - Management Model 1 Figure 8a: VPWS OAM Domains - Management Model 1
Figure 8b highlights another management model, where the CEs are Figure 8b highlights another management model, where the CEs are
managed by the Service Provider and where CEs and PEs are connected managed by the service provider and where CEs and PEs are connected
via an access network. The access network between the CEs and PEs via an access network. The access network between the CEs and PEs
may or may not be provided by a distinct network operator. In this may or may not be provided by a distinct network operator. In this
model, the VPWS service ME spans between the CEs in the Service model, the VPWS ME spans between the CEs in the service provider OAM
Provider OAM Domain, as shown by Figure 8b(B). The Service Provider domain, as shown by (B) in Figure 8b. The service provider OAM
OAM Domain may additionally monitor the AC MEs and PW MEs domain may additionally monitor the AC MEs and PW MEs individually,
individually, as shown by Figure 8b(C). The network operators may be as shown by (C) in Figure 8b. The network operators may be
responsible for managing the access service MEs (e.g. access responsible for managing the access service MEs (e.g., access
tunnels) and core PSN Tunnel MEs, as shown by Figure 8b(D). The tunnels) and core PSN Tunnel MEs, as shown by (D) in Figure 8b. The
distinction between Figure 8b-(C) and 8(b)-D) is that in (C), MEs distinction between (C) and (D) in Figure 8b is that in (C), MEs have
have MEPs at CEs and at PEs, and have no MIPs. While in (D) MEs have MEPs at CEs and at PEs and have no MIPs. While in (D), MEs have MEPs
MEPs at CEs and at PEs and furthermore, MIPs may be present in at CEs and at PEs; furthermore, MIPs may be present in between the
between the MEPs; thereby, providing visibility of the network to MEPs, thereby providing visibility of the network to the operator.
the operator.
|<--------------- VPWS <AC1,PW,AC2> -------------->| |<--------------- VPWS <AC1,PW,AC2> -------------->|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
Customer OAM Domain Customer OAM Domain
(A) |<-------------------------------------------------->| (A) |<-------------------------------------------------->|
Service Provider (SP) OAM Domain Service Provider (SP) OAM Domain
(B) |<------------------------------------------------>| (B) |<------------------------------------------------>|
SP OAM SP OAM SP OAM SP OAM SP OAM SP OAM
(C) |<--------->|<----------------------->|<---------->| (C) |<--------->|<----------------------->|<---------->|
Domain Domain Domain Domain Domain Domain
Operator Operator Operator Operator Operator Operator
(D) |<--------->|<----------------------->|<---------->| (D) |<--------->|<----------------------->|<---------->|
OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain
Figure 8b: VPWS OAM Domains - Management Model 2 Figure 8b: VPWS OAM Domains - Management Model 2
Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where
multiple operator domains may occur between the U-PE devices, VPWS multiple operator domains may occur between the User-facing PE (U-PE)
OAM domain in Figure 8a and 8b highlight a single Operator domain devices, VPWS OAM domain in Figures 8a and 8b highlights a single
between PE devices. This is since unlike the distributed VPLS PE operator domain between PE devices. This is since, unlike the
case (H-VPLS) where VPLS service aware U-PEs and N-PEs may be used distributed VPLS PE case (D-VPLS), where VPLS-aware U-PEs and
to realize a distributed PE, the VPWS has no such distributed PE Network-facing PEs (N-PEs) may be used to realize a distributed PE,
model. If the PSN involves multiple Operator domains, resulting in a the VPWS has no such distributed PE model. If the PSN involves
Multi-segment PW [Ms-PW Arch], VPWS OAM Domains remain unchanged multiple operator domains, resulting in a Multi-segment PW
since S-PEs are typically not aware of native service. [MS-PW-Arch], VPWS OAM Domains remain unchanged since switched PEs
are typically not aware of native service.
5.2.3. VPWS MEPs & MIPs 6.2.3. VPWS MEPs and MIPs
The location of MEPs and MIPs can be based upon the management model The location of MEPs and MIPs can be based upon the management model
used in the VPWS scenarios. The interest remains in being able to used in the VPWS scenarios. The interest remains in being able to
monitor end-to-end service and also support segment monitoring in monitor end-to-end service and also support segment monitoring in the
the network to allow isolation of faults to specific areas within network to allow isolation of faults to specific areas within the
the network. network.
The end-to-end service monitoring is provided by end-to-end ME and The end-to-end service monitoring is provided by an end-to-end ME,
additional segment OAM monitoring is provided by segment MEs, all in and additional segment OAM monitoring is provided by segment MEs, all
the Service Provider OAM Domain. The end-to-end MEs and segment MEs in the service provider OAM domain. The end-to-end MEs and segment
are hierarchically organized as mentioned earlier for hierarchical MEs are hierarchically organized as mentioned in Section 4.2 for
OAM domains. This is shown in Figure 8b (B) and (C). hierarchical OAM domains. This is shown in (B) and (C) in Figure 8b.
The CE interfaces support MEPs at the end-to-end Service Provider The CE interfaces support MEPs at the end-to-end service provider OAM
OAM level for VPWS as an end-to-end service as shown in Figure 9 level for VPWS as an end-to-end service as shown in (B1) and (B2) in
(B1) and (B2). In addition, PE interfaces may support MIPs at end- Figure 9. In addition, PE interfaces may support MIPs at the end-to-
to-end Service Provider OAM level when PEs are client service aware, end service provider OAM level when PEs are client service aware, as
as shown in Figure 9 (B2). As an example, if one considers an end- shown in (B2) in Figure 9. As an example, if one considers an end-
to-end Ethernet line service offered to a subscriber between CE1 and to-end Ethernet line service offered using ATM transport (ATM over
CE2 which is realized via ATM type AC1 and AC2 and PW which MPLS PW), then the PEs are considered to be Ethernet service unaware
encapsulates ATM over MPLS, the PEs can be considered as Ethernet and therefore cannot support any Ethernet MIPs. (B1) in Figure 9
service unaware, and therefore cannot support any Ethernet MIPs. represents this particular situation. Of course, another view of the
Figure 9 (B1) represents this particular situation. Of course, end-to-end service can be ATM, in which case PE1 and PE2 can be
another view of the end-to-end service can be ATM, in which case PE1 considered to be service aware and therefore support ATM MIPs. (B2)
and PE2 can be considered to be service aware, and therefore support in Figure 9 represents this particular situation.
ATM MIPs. Figure 9 (B2) represents this particular situation.
In addition, CEs and PE interfaces support MEPs at a segment (lower In addition, CEs and PE interfaces support MEPs at a segment (lower
level) Service Provider OAM level for AC and PW MEs and no MIPs are level) service provider OAM level for AC and PW MEs, and no MIPs are
involved at this segment Service Provider OAM Level, as shown in involved at this segment service provider OAM level, as shown in (C)
Figure 9 (C). Operators may also run segment OAM by having MEPs at in Figure 9. Operators may also run segment OAM by having MEPs at
Network Operator OAM level, as shown in Figure 9 (D). network operator OAM level, as shown in (D) in Figure 9.
The advantage of having layered OAM is that end-to-end and segment The advantage of having layered OAM is that end-to-end and segment
OAM can be carried out in an independent manner. It is also possible OAM can be carried out in an independent manner. It is also possible
to carry out some optimizations, e.g. when proactive segment OAM to carry out some optimizations, e.g., when proactive segment OAM
monitoring is performed, proactive end-to-end monitoring may not be monitoring is performed, proactive end-to-end monitoring may not be
needed since client layer end-to-end ME could simply use fault needed since client layer end-to-end ME could simply use fault
notifications from the server layer segment MEs. notifications from the server layer segment MEs.
Although many different OAM layers are possible, as shown in Figure Although many different OAM layers are possible, as shown in Figure
9, not all may be realized. For example, Figure (B2) and (D) may be 9, not all may be realized. For example, (B2) and (D) in Figure 9
adequate in some cases. may be adequate in some cases.
|<--------------- VPWS <AC1,PW,AC2> -------------->| |<--------------- VPWS <AC1,PW,AC2> -------------->|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
(B1) MEP-----------------------------------------------MEP (B1) MEP-----------------------------------------------MEP
(B2) MEP----------MIP---------------------MIP----------MEP (B2) MEP----------MIP---------------------MIP----------MEP
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure 9: VPWS MEPs & MIPs
5.2.4. VPWS MEP and MIP Identifiers Figure 9: VPWS MEPs and MIPs
6.2.4. VPWS MEP and MIP Identifiers
In VPWS, the MEPs and MIPs should be identified with their native In VPWS, the MEPs and MIPs should be identified with their native
addressing schemes. MEPs and MIPs Identifiers, i.e. MEP Ids and MIP addressing schemes. MEPs and MIPs Identifiers, i.e., MEP Ids and MIP
Ids, must be unique within their corresponding OAM domains and must Ids, must be unique to the VPWS instance and in the context of their
also be unique to the VPWS service instance. corresponding OAM domains.
6. VPLS Service OAM Requirements 7. VPLS OAM Requirements
These requirements are applicable to VPLS PE offering VPLS as an These requirements are applicable to VPLS PE offering VPLS as an
Ethernet Bridged LAN service, as described in Section 4.1.1. Ethernet Bridged LAN service, as described in Section 5.1.1.
Further, the performance metrics used in requirements are based on Further, the performance metrics used in requirements are based on
[MEF10.1] and [RFC2544]. [MEF10.1] and [RFC2544].
It is noted that OAM solutions that meet the following requirements It is noted that OAM solutions that meet the following requirements
may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, may make use of existing OAM mechanisms, e.g., Ethernet OAM, VCCV,
etc. however must not break these existing OAM mechanisms. If etc.; however, they must not break these existing OAM mechanisms. If
extensions are required to existing OAM mechanisms, these should be extensions are required to existing OAM mechanisms, these should be
coordinated with relevant groups responsible for these OAM coordinated with relevant groups responsible for these OAM
mechanisms. mechanisms.
6.1. Discovery 7.1. Discovery
Discovery allows a VPLS service aware device to learn about other Discovery allows a VPLS-aware device to learn about other devices
devices that support the same VPLS service instance within a given that support the same VPLS instance within a given domain.
domain.
Discovery also allows a VPLS service aware device to learn Discovery also allows a VPLS-aware device to learn sufficient
sufficient information (e.g. IP addresses, MAC addressed etc.) from information (e.g., IP addresses, MAC addresses, etc.) from other
other VPLS service aware devices such that VPLS OAM frames can be VPLS-aware devices such that VPLS OAM frames can be exchanged among
exchanged among the service aware devices. the service-aware devices.
(R1) VPLS OAM MUST allow a VPLS service aware device to discover (R1) VPLS OAM MUST allow a VPLS-aware device to discover other
other devices that share the same VPLS service instance(s) within a devices that share the same VPLS instance(s) within a given OAM
given OAM domain. domain.
6.2. Connectivity Fault Management 7.2. Connectivity Fault Management
VPLS service is realized by exchanging service frames/packets VPLS is realized by exchanging service frames/packets between devices
between devices that support the same VPLS service instance. To that support the same VPLS instance. To allow the exchange of
allow the exchange of service frames, connectivity between these service frames, connectivity between these service-aware devices is
service aware devices is required. required.
6.2.1. Connectivity Fault Detection 7.2.1. Connectivity Fault Detection
To ensure service, pro-active connectivity monitoring is required. To ensure service, proactive connectivity monitoring is required.
Connectivity monitoring facilitates connectivity fault detection. Connectivity monitoring facilitates connectivity fault detection.
(R2a) VPLS OAM MUST allow pro-active connectivity monitoring between (R2a) VPLS OAM MUST allow proactive connectivity monitoring between
two VPLS service aware devices that support the same VPLS service two VPLS-aware devices that support the same VPLS instance within a
instance within a given OAM domain. given OAM domain.
6.2.2. Connectivity Fault Verification 7.2.2. Connectivity Fault Verification
Once a connectivity fault is detected, connectivity fault Once a connectivity fault is detected, connectivity fault
verification may be performed. verification may be performed.
(R2b) VPLS OAM MUST allow connectivity fault verification between (R2b) VPLS OAM MUST allow connectivity fault verification between two
two VPLS service aware devices that support the same VPLS service VPLS-aware devices that support the same VPLS instance within a given
instance within a given OAM domain. OAM domain.
6.2.3. Connectivity Fault Localization 7.2.3. Connectivity Fault Localization
Further, localization of connectivity fault may be carried out. Further, localization of connectivity fault may be carried out.
(R2c) VPLS OAM MUST allow connectivity fault localization between (R2c) VPLS OAM MUST allow connectivity fault localization between two
two VPLS service aware devices that support the same VPLS service VPLS-aware devices that support the same instance within a given OAM
instance within a given OAM domain. domain.
6.2.4. Connectivity Fault Notification and Alarm Suppression 7.2.4. Connectivity Fault Notification and Alarm Suppression
Typically, when connectivity fault is detected and optionally Typically, when a connectivity fault is detected and optionally
verified, VPLS service device may notify the NMS (Network Management verified, the VPLS device may notify the NMS (Network Management
System) via alarms. System) via alarms.
However, a single transport/network fault may cause multiple However, a single transport/network fault may cause multiple services
services to fail simultaneously causing multiple service alarms. to fail simultaneously, thereby causing multiple service alarms.
Therefore, VPLS OAM must allow service level fault notification to Therefore, VPLS OAM must allow service-level fault notification to be
be triggered at the client layer as a result of transport/network triggered at the client layer as a result of transport/network faults
faults in the service layer. This fault notification should be used in the service layer. This fault notification should be used for the
for the suppression of service level alarms at the client layer. suppression of service-level alarms at the client layer.
(R2d) VPLS OAM MUST support fault notification to be triggered as a (R2d) VPLS OAM MUST support fault notification to be triggered as a
result of transport/network faults. This fault notification SHOULD result of transport/network faults. This fault notification SHOULD
be used for the suppression of redundant service level alarms. be used for the suppression of redundant service-level alarms.
6.3. Frame Loss 7.3. Frame Loss
A VPLS service may be considered degraded if service-layer A VPLS may be considered degraded if service-layer frames/packets are
frames/packets are lost during transit between the VPLS service lost during transit between the VPLS-aware devices. To determine if
aware devices. To determine if a VPLS service is degraded due to a VPLS is degraded due to frame/packet loss, measurement of
frame/packet loss, measurement of frame/packet loss is required. frame/packet loss is required.
(R3) VPLS OAM MUST support measurement of per-service frame/packet (R3) VPLS OAM MUST support measurement of per-service frame/packet
loss between two VPLS service aware devices that support the same loss between two VPLS-aware devices that support the same VPLS
VPLS service instance within a given OAM domain. instance within a given OAM domain.
6.4. Frame Delay 7.4. Frame Delay
A VPLS service may be sensitive to delay experienced by the VPLS A VPLS may be sensitive to delay experienced by the VPLS
frames/packets during transit between the VPLS service aware frames/packets during transit between the VPLS-aware devices. To
devices. To determine if a VPLS service is degraded due to determine if a VPLS is degraded due to frame/packet delay,
frame/packet delay, measurement of frame/packet delay is required. measurement of frame/packet delay is required.
VPLS frame/packet delay measurement can be of two types: VPLS frame/packet delay measurement can be of two types:
One-way delay 1) One-way delay is used to characterize certain applications like
One-way delay is used to characterize certain applications like multicast and broadcast applications. The measurement for one-
multicast and broadcast applications. The measurement for one-way way delay usually requires clock synchronization between the two
delay usually requires clock synchronization between two devices in devices in question.
question.
Two-way delay 2) Two-way delay or round-trip delay does not require clock
Two-way delay or round-trip delay does not require clock synchronization between the two devices involved in measurement
synchronization between two devices involved in measurement and is and is usually sufficient to determine the frame/packet delay
usually sufficient to determine the frame/packet delay being being experienced.
experienced.
(R4a) VPLS OAM MUST support measurement of per-service two-way (R4a) VPLS OAM MUST support measurement of per-service two-way
frame/packet delay between two VPLS service aware devices that frame/packet delay between two VPLS-aware devices that support the
support the same VPLS service instance within a given OAM domain. same VPLS instance within a given OAM domain.
(R4b) VPLS OAM SHOULD support measurement of per-service one-way (R4b) VPLS OAM SHOULD support measurement of per-service one-way
frame/packet delay between two VPLS service aware devices that frame/packet delay between two VPLS-aware devices that support the
support the same VPLS service instance within a given OAM domain. same VPLS instance within a given OAM domain.
6.5. Frame Delay Variation 7.5. Frame Delay Variation
A VPLS service may be sensitive to delay variation experienced by A VPLS may be sensitive to delay variation experienced by the VPLS
the VPLS frames/packets during transit between the VPLS service frames/packets during transit between the VPLS-aware devices. To
aware devices. To determine if a VPLS service is degraded due to determine if a VPLS is degraded due to frame/packet delay variation,
frame/packet delay variation, measurement of frame/packet delay measurement of frame/packet delay variation is required. For
variation is required. For frame/packet delay variation frame/packet delay variation measurements, one-way mechanisms are
measurements, one-way mechanisms are considered to be sufficient. considered to be sufficient.
(R5) VPLS OAM MUST support measurement of per-service frame/packet (R5) VPLS OAM MUST support measurement of per-service frame/packet
delay variation between two VPLS service aware devices that support delay variation between two VPLS-aware devices that support the same
the same VPLS service instance within a given OAM domain. VPLS instance within a given OAM domain.
6.6. Availability 7.6. Availability
A service may be considered unavailable if the service
frames/packets do not reach their intended destination (e.g. A service may be considered unavailable if the service frames/packets
connectivity is down or frame/packet loss is occurring) or the do not reach their intended destination (e.g., connectivity is down
service is degraded (e.g. frame/packet delay and/or delay variation or frame/packet loss is occurring) or the service is degraded (e.g.,
threshold is exceeded). frame/packet delay and/or delay variation threshold is exceeded).
Entry and exit conditions may be defined for unavailable state. Entry and exit conditions may be defined for unavailable state.
Availability itself may be defined in context of service type. Availability itself may be defined in context of service type.
Since availability measurement may be associated with connectivity, Since availability measurement may be associated with connectivity,
frame/packet loss, frame/packet delay and frame/packet delay frame/packet loss, frame/packet delay, and frame/packet delay
variation measurements, no additional requirements are specified variation measurements, no additional requirements are specified
currently. currently.
6.7. Data Path Forwarding 7.7. Data Path Forwarding
If the VPLS OAM frames flow across a different path than the one If the VPLS OAM frames flow across a different path than the one used
used by VPLS service frames/packets, accurate measurement and/or by VPLS frames/packets, accurate measurement and/or determination of
determination of service state may not be made. Therefore data path, service state may not be made. Therefore, data path, i.e., the one
i.e. the one being taken by VPLS service frames/packets, must be being taken by VPLS frames/packets, must be used for the VPLS OAM.
used for the VPLS OAM.
(R6) VPLS OAM frames MUST be forwarded along the same path (i.e. (R6) VPLS OAM frames MUST be forwarded along the same path (i.e.,
links and nodes) as the VPLS service/data frames. links and nodes) as the VPLS frames.
6.8. Scalability 7.8. Scalability
Mechanisms developed for VPLS OAM need to be such that per-service Mechanisms developed for VPLS OAM need to be such that per-service
OAM can be supported even though the OAM may only be used for OAM can be supported even though the OAM may only be used for limited
limited VPLS service instances, e.g. premium VPLS service instances, VPLS instances, e.g., premium VPLS instances, and may not be used for
and may not be used for best-effort VPLS services. best-effort VPLSs.
(R7) VPLS OAM MUST be scalable such that a service aware device can (R7) VPLS OAM MUST be scalable such that a service-aware device can
support OAM for each VPLS service that is supported by the device. support OAM for each VPLS that is supported by the device.
6.9. Extensibility 7.9. Extensibility
Extensibility is intended to allow introduction of additional OAM Extensibility is intended to allow introduction of additional OAM
functionality in future such that backward compatibility can be functionality in the future such that backward compatibility can be
maintained when interoperating with older version devices. In such a maintained when interoperating with older version devices. In such a
case, VPLS OAM with reduced functionality should still be possible. case, VPLS OAM with reduced functionality should still be possible.
Further, VPLS Service OAM should be defined such that OAM incapable Further, VPLS OAM should be defined such that OAM incapable devices
devices in the middle of the OAM domain should be able to forward in the middle of the OAM domain should be able to forward the VPLS
the VPLS OAM frames similar to the regular VPLS service/data OAM frames similar to the regular VPLS data frames/packets.
frames/packets.
(R8a) VPLS OAM MUST be extensible such that new functionality and (R8a) VPLS OAM MUST be extensible such that new functionality and
information elements related to this functionality can be introduced information elements related to this functionality can be introduced
in future. in the future.
(R8b) VPLS OAM MUST be defined such that devices not supporting the (R8b) VPLS OAM MUST be defined such that devices not supporting the
OAM are able to forward the OAM frames in a similar fashion as the OAM are able to forward the OAM frames in a similar fashion as the
regular VPLS service/data frames/packets. regular VPLS data frames/packets.
6.10. Security 7.10. Security
VPLS OAM frames belonging to an OAM domain originate and terminate VPLS OAM frames belonging to an OAM domain originate and terminate
within that OAM domain. Security implies that an OAM domain must be within that OAM domain. Security implies that an OAM domain must be
capable of filtering OAM frames. The filtering is such that the OAM capable of filtering OAM frames. The filtering is such that the OAM
frames are prevented from leaking outside their domain. Also, OAM frames are prevented from leaking outside their domain. Also, OAM
frames from outside the OAM domains should be either discarded (when frames from outside the OAM domains should be either discarded (when
such OAM frames belong to same or lower-level OAM domain) or such OAM frames belong to the same level or to a lower-level OAM
transparently passed (when such OAM frames belong to a higher-level domain) or transparently passed (when such OAM frames belong to a
OAM domain). higher-level OAM domain).
(R9a) VPLS OAM frames MUST be prevented from leaking outside their (R9a) VPLS OAM frames MUST be prevented from leaking outside their
OAM domain. OAM domain.
(R9b) VPLS OAM frames from outside an OAM domain MUST be prevented (R9b) VPLS OAM frames from outside an OAM domain MUST be prevented
from entering the OAM domain when such OAM frames belong to the same from entering the OAM domain when such OAM frames belong to the same
level or lower-level OAM domain. level or to a lower-level OAM domain.
(R9c) VPLS OAM frames from outside an OAM domain MUST be transported (R9c) VPLS OAM frames from outside an OAM domain MUST be transported
transparently inside the OAM domain when such OAM frames belong to transparently inside the OAM domain when such OAM frames belong to a
the higher-level OAM domain. higher-level OAM domain.
6.11. Transport Independence 7.11. Transport Independence
VPLS service frame/packets delivery is carried out across transport VPLS frame/packets delivery is carried out across transport
infrastructure, also called network infrastructure. Though specific infrastructure, also called network infrastructure. Though specific
transport/network technologies may provide their own OAM transport/network technologies may provide their own OAM
capabilities, VPLS OAM must be independently supported as many capabilities, VPLS OAM must be independently supported as many
different transport/network technologies can be used to carry different transport/network technologies can be used to carry service
service frame/packets. frame/packets.
(R10a) VPLS OAM MUST be independent of the underlying (R10a) VPLS OAM MUST be independent of the underlying
transport/network technologies and specific transport/network OAM transport/network technologies and specific transport/network OAM
capabilities. capabilities.
(R10b) VPLS OAM MAY allow adaptation/interworking with specific (R10b) VPLS OAM MAY allow adaptation/interworking with specific
transport/network OAM functions. For example, this would be useful transport/network OAM functions. For example, this would be useful
to allow Fault Notifications from transport/network layer(s) to be to allow fault notifications from transport/network layer(s) to be
sent to the VPLS service layer. sent to the VPLS layer.
6.12. Application Independence 7.12. Application Independence
VPLS service itself may be used to carry application frame/packets. VPLS itself may be used to carry application frame/packets. The
The application may use its own OAM; service OAM must not be application may use its own OAM; service OAM must not be dependent on
dependent on application OAM. As an example, a VPLS service may be application OAM. As an example, a VPLS may be used to carry IP
used to carry IP traffic; however, VPLS OAM should not assume IP or traffic; however, VPLS OAM should not assume IP or rely on the use of
rely on the use of IP level OAM functions. IP-level OAM functions.
(R11a) VPLS OAM MUST be independent of the application technologies (R11a) VPLS OAM MUST be independent of the application technologies
and specific application OAM capabilities. and specific application OAM capabilities.
7. VPWS OAM Requirements 8. VPWS OAM Requirements
These requirements are applicable to VPWS PE. The performance These requirements are applicable to VPWS PE. The performance
metrics used in requirements are based on [MEF10.1] and [RFC2544], metrics used in requirements are based on [MEF10.1] and [RFC2544],
which are applicable to Ethernet Services. which are applicable to Ethernet services.
It is noted that OAM solutions that meet the following requirements It is noted that OAM solutions that meet the following requirements
may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, may make use of existing OAM mechanisms, e.g., Ethernet OAM, VCCV,
etc. however must not break these existing OAM mechanisms. If etc.; however, they must not break these existing OAM mechanisms. If
extensions are required to existing OAM mechanisms, these should be extensions are required to existing OAM mechanisms, these should be
coordinated with relevant groups responsible for these OAM coordinated with relevant groups responsible for these OAM
mechanisms. mechanisms.
7.1. Discovery 8.1. Discovery
Discovery allows a VPWS service aware device to learn about other Discovery allows a VPWS-aware device to learn about other devices
devices that support the same VPWS service instance within a given that support the same VPWS instance within a given domain. Discovery
domain. Discovery also allows a VPWS service aware device to learn also allows a VPWS-aware device to learn sufficient information
sufficient information (e.g. IP addresses, MAC addresses etc.) from (e.g., IP addresses, MAC addresses, etc.) from other VPWS-aware
other VPWS service aware devices such that OAM frames can be devices such that OAM frames can be exchanged among the VPWS-aware
exchanged among the VPWS service aware devices. devices.
(R12) VPWS OAM MUST allow a VPWS service aware device to discover (R12) VPWS OAM MUST allow a VPWS-aware device to discover other
other devices that share the same VPWS service instance(s) within a devices that share the same VPWS instance(s) within a given OAM
given OAM domain. domain.
7.2. Connectivity Fault Management 8.2. Connectivity Fault Management
VPWS Service is realized by exchanging service frames/packets VPWS is realized by exchanging service frames/packets between devices
between devices that support the same VPWS service instance. To that support the same VPWS instance. To allow the exchange of
allow the exchange of service frames, connectivity between these service frames, connectivity between these service-aware devices is
service aware devices is required. required.
7.2.1. Connectivity Fault Detection 8.2.1. Connectivity Fault Detection
To ensure service, pro-active connectivity monitoring is required. To ensure service, proactive connectivity monitoring is required.
Connectivity monitoring facilitates connectivity fault detection. Connectivity monitoring facilitates connectivity fault detection.
(R13a) VPWS OAM MUST allow pro-active connectivity monitoring (R13a) VPWS OAM MUST allow proactive connectivity monitoring between
between two VPWS service aware devices that support the same VPWS two VPWS-aware devices that support the same VPWS instance within a
service instance within a given OAM domain. given OAM domain.
(R13b) VPWS OAM mechanism SHOULD allow detection of misbranching or (R13b) VPWS OAM mechanism SHOULD allow detection of mis-branching or
misconnections. mis-connections.
7.2.2. Connectivity Fault Verification 8.2.2. Connectivity Fault Verification
Once a connectivity fault is detected, connectivity fault Once a connectivity fault is detected, connectivity fault
verification may be performed. verification may be performed.
(R13c) VPWS OAM MUST allow connectivity fault verification between (R13c) VPWS OAM MUST allow connectivity fault verification between
two VPWS service aware devices that support the same VPWS service two VPWS-aware devices that support the same VPWS instance within a
instance within a given OAM domain. given OAM domain.
7.2.3. Connectivity Fault Localization 8.2.3. Connectivity Fault Localization
Further, localization of connectivity fault may be carried out. This Further, localization of connectivity fault may be carried out. This
may amount to identifying the specific AC and/or PW that is may amount to identifying the specific AC and/or PW that is resulting
resulting in the VPWS connectivity fault. in the VPWS connectivity fault.
(R13d) VPWS OAM MUST allow connectivity fault localization between (R13d) VPWS OAM MUST allow connectivity fault localization between
two VPWS service aware devices that support the same VPWS service two VPWS-aware devices that support the same VPWS instance within a
instance within a given OAM domain. given OAM domain.
7.2.4. Connectivity Fault Notification and Alarm Suppression 8.2.4. Connectivity Fault Notification and Alarm Suppression
Typically, when connectivity fault is detected and optionally Typically, when a connectivity fault is detected and optionally
verified, service device may notify the NMS (Network Management verified, the service device may notify the NMS (Network Management
System) via alarms. System) via alarms.
However, a single transport/network fault may cause multiple However, a single transport/network fault may cause multiple services
services to fail simultaneously causing multiple service alarms. to fail simultaneously causing multiple service alarms. Therefore,
Therefore, OAM must allow service level fault notification to be OAM must allow service-level fault notification to be triggered at
triggered at the client layer as a result of transport/network the client layer as a result of transport/network faults in the
faults in the service layer. This fault notification should be used service layer. This fault notification should be used for the
for the suppression of service level alarms at the client layer. suppression of service-level alarms at the client layer.
For example, if an AC fails, both local CE and local PE which are For example, if an AC fails, both the local CE and the local PE,
connected via AC may detect the connectivity failure. The local CE which are connected via the AC, may detect the connectivity failure.
must notify the remote CE about the failure while the local PE must The local CE must notify the remote CE about the failure while the
notify the remote PE about the failure. local PE must notify the remote PE about the failure.
(R13e) VPWS OAM MUST MUST support fault notification to be triggered (R13e) VPWS OAM MUST support fault notification to be triggered as a
as a result of transport/network faults. This fault notification result of transport/network faults. This fault notification SHOULD
SHOULD be used for the suppression of redundant service level be used for the suppression of redundant service-level alarms.
alarms.
(R13f) VPWS OAM SHOULD support fault notification in backward (R13f) VPWS OAM SHOULD support fault notification in backward
direction, to be triggered as a result of transport/network faults. direction, to be triggered as a result of transport/network faults.
This fault notification SHOULD be used for the suppression of This fault notification SHOULD be used for the suppression of
redundant service level alarms. redundant service-level alarms.
7.3. Frame Loss 8.3. Frame Loss
A VPWS service may be considered degraded if service-layer A VPWS may be considered degraded if service-layer frames/packets are
frames/packets are lost during transit between the VPWS service lost during transit between the VPWS-aware devices. To determine if
aware devices. To determine if a VPWS service is degraded due to a VPWS is degraded due to frame/packet loss, measurement of
frame/packet loss, measurement of frame/packet loss is required. frame/packet loss is required.
(R14) VPWS OAM MUST support measurement of per-service frame/packet (R14) VPWS OAM MUST support measurement of per-service frame/packet
loss between two VPWS service aware devices that support the same loss between two VPWS-aware devices that support the same VPWS
VPWS service instance within a given OAM domain. instance within a given OAM domain.
7.4. Frame Delay 8.4. Frame Delay
A VPWS service may be sensitive to delay experienced by the VPWS A VPWS may be sensitive to delay experienced by the VPWS
service frames/packets during transit between the VPWS service aware frames/packets during transit between the VPWS-aware devices. To
devices. To determine if a VPWS service is degraded due to determine if a VPWS is degraded due to frame/packet delay,
frame/packet delay, measurement of frame/packet delay is required. measurement of frame/packet delay is required.
VPWS frame/packet delay measurement can be of two types: VPWS frame/packet delay measurement can be of two types:
- One-way delay
One-way delay is used to characterize certain applications like 1) One-way delay is used to characterize certain applications like
multicast and broadcast applications. The measurement for one-way multicast and broadcast applications. The measurement for one-
delay usually requires clock synchronization between two devices in way delay usually requires clock synchronization between the two
question. devices in question.
- Two-way delay
Two-way delay or round-trip delay does not require clock 2) Two-way delay or round-trip delay does not require clock
synchronization between two devices involved in measurement and is synchronization between the two devices involved in measurement
usually sufficient to determine the frame/packet delay being and is usually sufficient to determine the frame/packet delay
experienced. being experienced.
(R15a) VPWS OAM MUST support measurement of per-service two-way (R15a) VPWS OAM MUST support measurement of per-service two-way
frame/packet delay between two VPWS service aware devices that frame/packet delay between two VPWS-aware devices that support the
support the same VPWS service instance within a given OAM domain. same VPWS instance within a given OAM domain.
(R15b) VPWS OAM SHOULD support measurement of per-service one-way (R15b) VPWS OAM SHOULD support measurement of per-service one-way
frame/packet delay between two VPWS service aware devices that frame/packet delay between two VPWS-aware devices that support the
support the same VPWS service instance within a given OAM domain. same VPWS instance within a given OAM domain.
7.5. Frame Delay Variation 8.5. Frame Delay Variation
A VPWS service may be sensitive to delay variation experienced by A VPWS may be sensitive to delay variation experienced by the VPWS
the VPWS frames/packets during transit between the VPWS service frames/packets during transit between the VPWS-aware devices. To
aware devices. To determine if a VPWS service is degraded due to determine if a VPWS is degraded due to frame/packet delay variation,
frame/packet delay variation, measurement of frame/packet delay measurement of frame/packet delay variation is required. For
variation is required. For frame/packet delay variation frame/packet delay variation measurements, one-way mechanisms are
measurements, one-way mechanisms are considered to be sufficient. considered to be sufficient.
(R16) VPWS OAM MUST support measurement of per-service frame/packet (R16) VPWS OAM MUST support measurement of per-service frame/packet
delay variation between two VPWS service aware devices that support delay variation between two VPWS-aware devices that support the same
the same VPWS service instance within a given OAM domain. VPWS instance within a given OAM domain.
7.6. Availability 8.6. Availability
A service may be considered unavailable if the service A service may be considered unavailable if the service frames/packets
frames/packets do not reach their intended destination (e.g. do not reach their intended destination (e.g., connectivity is down
connectivity is down or frame/packet loss is occurring) or the or frame/packet loss is occurring) or the service is degraded (e.g.,
service is degraded (e.g. frame/packet delay and/or delay variation frame/packet delay and/or delay variation threshold is exceeded).
threshold is exceeded).
Entry and exit conditions may be defined for unavailable state. Entry and exit conditions may be defined for unavailable state.
Availability itself may be defined in context of service type. Availability itself may be defined in context of service type.
Since availability measurement may be associated with connectivity, Since availability measurement may be associated with connectivity,
frame/packet loss, frame/packet delay and frame/packet delay frame/packet loss, frame/packet delay, and frame/packet delay
variation measurements, no additional requirements are specified variation measurements, no additional requirements are specified
currently. currently.
7.7. Data Path Forwarding 8.7. Data Path Forwarding
If the VPWS OAM frames flow across a different path than the one If the VPWS OAM frames flow across a different path than the one used
used by VPWS service frames/packets, accurate measurement and/or by VPWS frames/packets, accurate measurement and/or determination of
determination of service state may not be made. Therefore data path, service state may not be made. Therefore data path, i.e., the one
i.e. the one being taken by VPWS service frames/packets, must be being taken by VPWS frames/packets, must be used for the VPWS OAM.
used for the VPWS OAM.
(R17a) VPWS OAM frames MUST be forwarded along the same path as the (R17a) VPWS OAM frames MUST be forwarded along the same path as the
VPWS service/data frames. VPWS data frames.
(R17b) VPWS OAM MUST be forwarded using the transfer plane (data (R17b) VPWS OAM MUST be forwarded using the transfer plane (data
plane) as regular VPWS service/data frames/packets and must not rely plane) as regular VPWS data frames/packets and must not rely on
on control plane messages. control plane messages.
7.8. Scalability 8.8. Scalability
Mechanisms developed for VPWS OAM need to be such that per-service Mechanisms developed for VPWS OAM need to be such that per-service
OAM can be supported even though the OAM may only be used for OAM can be supported even though the OAM may only be used for limited
limited VPWS service instances, e.g. premium VPWS service instance, VPWS instances, e.g., premium VPWS instance, and may not be used for
and may not be used for best-effort services. best-effort services.
(R18) VPWS OAM MUST be scalable such that a service aware device can (R18) VPWS OAM MUST be scalable such that a service-aware device can
support OAM for each VPWS service that is supported by the device. support OAM for each VPWS that is supported by the device.
7.9. Extensibility 8.9. Extensibility
Extensibility is intended to allow introduction of additional OAM Extensibility is intended to allow introduction of additional OAM
functionality in future such that backward compatibility can be functionality in the future such that backward compatibility can be
maintained when interoperating with older version devices. In such a maintained when interoperating with older version devices. In such a
case, VPWS service OAM with reduced functionality should still be case, VPWS OAM with reduced functionality should still be possible.
possible. Further, VPWS service OAM should be such that OAM Further, VPWS OAM should be such that OAM incapable devices in the
incapable devices in the middle of the OAM domain should be able to middle of the OAM domain should be able to forward the VPWS OAM
forward the VPWS OAM frames similar to the regular VPWS service/data frames similar to the regular VPWS data frames/packets.
frames/packets.
(R19a) VPWS OAM MUST be extensible such that new functionality and (R19a) VPWS OAM MUST be extensible such that new functionality and
information elements related to this functionality can be introduced information elements related to this functionality can be introduced
in future. in the future.
(R19b) VPWS OAM MUST be defined such that devices not supporting the (R19b) VPWS OAM MUST be defined such that devices not supporting the
OAM are able to forward the VPWS OAM frames in a similar fashion as OAM are able to forward the VPWS OAM frames in a similar fashion as
the regular VPWS service/data frames/packets. the regular VPWS data frames/packets.
7.10. Security 8.10. Security
VPWS OAM frames belonging to an OAM domain originate and terminate VPWS OAM frames belonging to an OAM domain originate and terminate
within that OAM domain. Security implies that an OAM domain must be within that OAM domain. Security implies that an OAM domain must be
capable of filtering OAM frames. The filtering is such that the VPWS capable of filtering OAM frames. The filtering is such that the VPWS
OAM frames are prevented from leaking outside their domain. Also, OAM frames are prevented from leaking outside their domain. Also,
VPWS OAM frames from outside the OAM domains should be either VPWS OAM frames from outside the OAM domains should be either
discarded (when such OAM frames belong to same or lower-level OAM discarded (when such OAM frames belong to the same level or to a
domain) or transparently passed (when such OAM frames belong to a lower-level OAM domain) or transparently passed (when such OAM frames
higher-level OAM domain). belong to a higher-level OAM domain).
(R20a) VPWS OAM frames MUST be prevented from leaking outside their (R20a) VPWS OAM frames MUST be prevented from leaking outside their
OAM domain. OAM domain.
(R20b) VPWS OAM frames from outside an OAM domain MUST be prevented (R20b) VPWS OAM frames from outside an OAM domain MUST be prevented
from entering the OAM domain when such OAM frames belong to the same from entering the OAM domain when such OAM frames belong to the same
level or lower-level OAM domain. level or to a lower-level OAM domain.
(R20c) VPWS OAM frames from outside an OAM domain MUST be (R20c) VPWS OAM frames from outside an OAM domain MUST be transported
transported transparently inside the OAM domain when such OAM frames transparently inside the OAM domain when such OAM frames belong to a
belong to the higher-level OAM domain. higher-level OAM domain.
7.11. Transport Independence 8.11. Transport Independence
VPWS service frame/packets delivery is carried out across transport VPWS frame/packets delivery is carried out across transport
infrastructure, also called network infrastructure. Though specific infrastructure, also called network infrastructure. Though specific
transport/network technologies may provide their own OAM transport/network technologies may provide their own OAM
capabilities, VPWS OAM must be independently supported as many capabilities, VPWS OAM must be independently supported as many
different transport/network technologies can be used to carry different transport/network technologies can be used to carry service
service frame/packets. frame/packets.
(R21a) VPWS OAM MUST be independent of the underlying (R21a) VPWS OAM MUST be independent of the underlying
transport/network technologies and specific transport/network OAM transport/network technologies and specific transport/network OAM
capabilities. capabilities.
(R21b) VPWS OAM MAY allow adaptation/interworking with specific (R21b) VPWS OAM MAY allow adaptation/interworking with specific
transport/network OAM functions. For example, this would be useful transport/network OAM functions. For example, this would be useful
to allow Fault Notifications from transport/network layer(s) to be to allow fault notifications from transport/network layer(s) to be
sent to the VPWS service layer. sent to the VPWS layer.
7.12. Application Independence 8.12. Application Independence
VPWS service itself may be used to carry application frame/packets. VPWS itself may be used to carry application frame/packets. The
The application may use its own OAM; VPWS OAM must not be dependent application may use its own OAM; VPWS OAM must not be dependent on
on application OAM. As an example, a VPWS service may be used to application OAM. As an example, a VPWS may be used to carry IP
carry IP traffic; however, VPWS OAM should not assume IP or rely on traffic; however, VPWS OAM should not assume IP or rely on the use of
the use of IP level OAM functions. IP-level OAM functions.
(R22a) OAM MUST be independent of the application technologies and (R22a) OAM MUST be independent of the application technologies and
specific application OAM capabilities. specific application OAM capabilities.
7.13. Prioritization 8.13. Prioritization
VPWS service could be composed of several data flows each related to VPWS could be composed of several data flows, each related to a given
a given usage/application with specific requirements in term of usage/application with specific requirements in terms of connectivity
connectivity and/or performances. Dedicated VPWS OAM should be and/or performance. Dedicated VPWS OAM should be applicable to these
applicable to these flows. flows.
(R23) VPWS OAM SHOULD support configurable prioritization for OAM (R23) VPWS OAM SHOULD support configurable prioritization for OAM
packet/frames to be compatible with associated VPWS service packet/frames to be compatible with associated VPWS packets/frames.
packets/frames.
8. VPLS (V)LAN Emulation OAM Requirements 9. VPLS (V)LAN Emulation OAM Requirements
8.1. Partial-mesh of PWs 9.1. Partial-Mesh of PWs
As indicated in [BRIDGE-INTEROP], VPLS service OAM relies upon As indicated in [BRIDGE-INTEROP], VPLS OAM relies upon bidirectional
bidirectional Ethernet links or (V)LAN segments and failure in one Ethernet links or (V)LAN segments and failure in one direction or
direction or link results in failure of the whole link or (V)LAN link results in failure of the whole link or (V)LAN segment.
segment. Therefore, when partial-mesh failure occurs in (V)LAN Therefore, when partial-mesh failure occurs in (V)LAN emulation,
emulation, either the entire PW mesh should be shutdown when only an either the entire PW mesh should be shut down when only an entire
entire VPLS service is acceptable or a subset of PWs should be VPLS is acceptable or a subset of PWs should be shut down such that
shutdown such that the remaining PWs have full connectivity among the remaining PWs have full connectivity among them when partial VPLS
them, when partial VPLS service is acceptable. is acceptable.
(R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow (R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow
detection of partial-mesh failure condition. detection of a partial-mesh failure condition.
(R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the (R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the
entire mesh of PWs to be shutdown upon detection of a partial-mesh entire mesh of PWs to be shut down upon detection of a partial-mesh
failure condition. failure condition.
(R13c) PW OAM for PWs related to a (V)LAN emulation MUST allow the (R13c) PW OAM for PWs related to a (V)LAN emulation MUST allow the
subset of PWs to be shutdown upon detection of a partial-mesh subset of PWs to be shut down upon detection of a partial-mesh
failure condition in a manner such that full mesh is present across failure condition in a manner such that full mesh is present across
the remaining subset. the remaining subset.
Note: Shutdown action in R13b and R13c may not necessarily involve Note: Shutdown action in R13b and R13c may not necessarily involve
withdrawal of labels etc. withdrawal of labels, etc.
8.2. PW Fault Recovery 9.2. PW Fault Recovery
As indicated in [BRIDGE-INTEROP], VPLS service OAM fault detection As indicated in [BRIDGE-INTEROP], VPLS OAM fault detection and
and recovery relies upon (V)LAN emulation recovery such that fault recovery relies upon (V)LAN emulation recovery such that fault
detection and recovery time in (V)LAN emulation should be less than detection and recovery time in (V)LAN emulation should be less than
the VPLS service fault detection and recovery time to prevent the VPLS fault detection and recovery time to prevent unnecessary
unnecessary switch-over and temporary flooding/loop within customer switch-over and temporary flooding/loop within the customer OAM
OAM domain that is dual-homed to provider OAM domain. domain that is dual-homed to the provider OAM domain.
(R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a (R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a
fault detection time in the provider OAM domain faster than the VPLS fault detection time in the provider OAM domain faster than the VPLS
fault detection time in the customer OAM domain. fault detection time in the customer OAM domain.
(R14b) PW OAM for PWs related to a (V)LAN emulation MUST support a (R14b) PW OAM for PWs related to a (V)LAN emulation MUST support a
fault recovery time in the provider OAM domain faster than the VPLS fault recovery time in the provider OAM domain faster than the VPLS
fault recovery time in the customer OAM domain. fault recovery time in the customer OAM domain.
8.3. Connectivity Fault Notification and Alarm Suppression 9.3. Connectivity Fault Notification and Alarm Suppression
When connectivity fault is detected in (V)LAN emulation, PE devices When a connectivity fault is detected in (V)LAN emulation, PE devices
may notify the NMS (Network Management System) via alarms. However, may notify the NMS (Network Management System) via alarms. However,
a single (V)LAN emulation fault may result in CE devices or U-PE a single (V)LAN emulation fault may result in CE devices or U-PE
devices detecting connectivity fault in VPLS service and therefore devices detecting a connectivity fault in VPLS and therefore also
also notifying the NMS. To prevent multiple alarms for the same notifying the NMS. To prevent multiple alarms for the same fault,
fault, (V)LAN emulation OAM must provide alarm suppression (V)LAN emulation OAM must provide alarm suppression capability in the
capability in the VPLS service OAM. VPLS OAM.
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support (R15) PW OAM for PWs related to a (V)LAN emulation MUST support
interworking with VPLS service OAM to trigger fault notification and interworking with VPLS OAM to trigger fault notification and allow
allow alarm suppression in the VPLS service upon fault detection in alarm suppression in the VPLS upon fault detection in (V)LAN
(V)LAN emulation. emulation.
9. OAM Operational Scenarios 10. OAM Operational Scenarios
This section highlights how the different OAM mechanisms can be This section highlights how the different OAM mechanisms can be
applied as per the OAM framework for different L2VPN services. applied as per the OAM framework for different L2VPN services.
9.1. VPLS OAM Operational Scenarios 10.1. VPLS OAM Operational Scenarios
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
Customer OAM domain
(C) MEP---MIP--------------------------------MIP---MEP
Service Provider(SP) OAM domain --- ---
(D) MEP--------MIP-----------MIP-------MEP / \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
SP OAM SP OAM SP OAM Customer OAM Domain
(D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP (C) MEP---MIP--------------------------------MIP---MEP
domain domain domain
Operator Operator Operator Service Provider (SP) OAM Domain
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP (D) MEP--------MIP-----------MIP-------MEP
OAM domain OAM domain OAM domain
MPLS OAM MPLS OAM SP OAM SP OAM SP OAM
(F) MEP--MIP-----MEP--MIP--MEP (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
domain domain domain domain domain
Figure 10: VPLS OAM Domains, MEPs & MIPs Operator Operator Operator
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
OAM domain OAM domain OAM domain
Among the different MEs identified in Figure 5, for VPLS OAM in MPLS OAM MPLS OAM
Customer OAM domain, [IEEE 802.1ag] and [Y.1731] Ethernet OAM (F) MEP--MIP-----MEP--MIP--MEP
mechanisms can be applied, to meet various requirements identified domain domain
in Section 6. The mechanisms can be applied across Figure 10 (C)
Figure 10: VPLS OAM Domains, MEPs, and MIPs
Among the different MEs identified in Figure 5 for VPLS OAM in the
customer OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM
mechanisms can be applied to meet the various requirements identified
in Section 7. The mechanisms can be applied across (C) in Figure 10
MEs. MEs.
Similarly, inside the Service Provider OAM domain, [IEEE 802.1ag] Similarly, inside the service provider OAM domain, [IEEE802.1ag] and
and [Y.1731] Ethernet OAM mechanisms can be applied across Figure 10 [Y.1731] Ethernet OAM mechanisms can be applied across (D) MEs in
(D) MEs to meet functional requirements identified in Section 6. Figure 10 to meet the functional requirements identified in Section
7.
It may be noted that in the interim, when [IEEE 802.1ag] and It may be noted that in the interim, when [IEEE802.1ag] and [Y.1731]
[Y.1731] capabilities are not available across the PE devices, the capabilities are not available across the PE devices, the Fault
fault management option using segment OAM introduced in Section Management option using segment OAM introduced in Section 6.2.3 can
5.2.3 can be applied, with the limitations cited below. In this be applied, with the limitations cited below. In this option, the
option, the Service Provider can run segment OAM across the Figure service provider can run segment OAM across the (D1) MEs in Figure
10 (D1) MEs. The OAM mechanisms across the Figure 10 (D1) MEs can be 10. The OAM mechanisms across the (D1) MEs in Figure 10 can be non-
non-Ethernet e.g. VCCV, or BFD when network technology is MPLS. The Ethernet, e.g., Virtual Circuit Connectivity Verification (VCCV), or
Service Provider can monitor each sub-network segment ME using the Bidirectional Forwarding Detection (BFD) when network technology is
native technology OAM and by performing interworking across the MPLS. The service provider can monitor each sub-network segment ME
segment MEs, attempt to realize end-to-end monitoring between a pair using the native technology OAM and, by performing interworking
of VPLS end-points. However, such mechanisms do not fully utilize across the segment MEs, attempt to realize end-to-end monitoring
the data plane forwarding as experienced by native (i.e. Ethernet) between a pair of VPLS endpoints. However, such mechanisms do not
service PDUs and therefore monitoring is severely limited in the fully exercise the data plane forwarding constructs as experienced by
sense that monitoring at Figure 10 (D1) and interworking across them native (i.e., Ethernet) service PDUs. As a result, service
could lead to an indication that the ME between VPLS end-points is monitoring ((D1) in Figure 10) is severely limited in the sense that
it may lead to an indication that the ME between VPLS endpoints is
functional while the customer may be experiencing end-to-end functional while the customer may be experiencing end-to-end
connectivity issues in the data plane. connectivity issues in the data plane.
Inside the Network Operator OAM domain, [IEEE 802.1ag] and [Y.1731] Inside the network operator OAM domain, [IEEE802.1ag] and [Y.1731]
Ethernet OAM mechanisms can also be applied across Figure 10 (E) MEs Ethernet OAM mechanisms can also be applied across MEs in (E) in
to meet functional requirements identified in Section 6. In Figure 10 to meet the functional requirements identified in Section
addition, the network operator could decide to use native OAM 7. In addition, the network operator could decide to use native OAM
mechanisms e.g. VCCV or BFD across Figure 10 (F) MEs for additional mechanisms, e.g., VCCV or BFD, across (F) MEs for additional
monitoring or as an alternative to monitoring across Figure 10 (E) monitoring or as an alternative to monitoring across (E) MEs.
MEs.
10. Acknowledgments 11. Security Considerations
The authors would like to thank Deborah Brungard, Vasile Radoaca, This specification assumes that L2VPN components within the OAM
Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their domain are mutually trusted. Based on that assumption,
reviews and comments. confidentiality issues are fully addressed by filtering to prevent
OAM frames from leaking outside their designated OAM domain.
Similarly, authentication issues are addressed by preventing OAM
frames generated outside a given OAM domain from entering the domain
in question. Requirements to prevent OAM messages from leaking
outside an OAM domain and for OAM domains to be transparent to OAM
frames from higher OAM domains are specified in Sections 7.10 and
8.10.
Authors would also like to thank Shahram Davari, Norm Finn, Dave For additional levels of security, solutions may be required to
Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness, encrypt and/or authenticate OAM frames inside an OAM domain.
Malcolm Betts, Paul Bottorff, Hamid-ould Brahim, Lior Shabtay, and However, these solutions are out of the scope of this document.
Dan Cauchy for their feedback.
12. IANA Considerations 12. Contributors
This document has no actions for IANA. In addition to the authors listed above, the following individuals
also contributed to this document.
11. Security Considerations Simon Delord
Uecomm
658 Church St
Richmond, VIC, 3121, Australia
EMail: sdelord@uecomm.com.au
This document takes into account the security considerations and Philippe Niger
imposes requirements on solutions to prevent OAM messages from France Telecom
leaking outside an OAM domain and for OAM domains to be transparent 2 av. Pierre Marzin
to OAM frames from higher OAM domains, as specified in Section 6.10 22300 LANNION, France
and 7.10. EMail: philippe.niger@francetelecom.com
For additional levels of security, the solutions may be required to Samer Salam
encrypt and/or authenticate OAM frames inside an OAM domain however Cisco Systems, Inc.
solutions are out of the scope of this draft. 170 West Tasman Drive
San Jose, CA 95134
EMail: ssalam@cisco.com
13. References 13. Acknowledgements
13.1 Normative References The authors would like to thank Deborah Brungard, Vasile Radoaca, Lei
Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their
reviews and comments.
[IEEE 802.1ad] "IEEE Standard for Local and metropolitan area The authors would also like to thank Shahram Davari, Norm Finn, Dave
networks - virtual Bridged Local Area Networks, Amendment 4: Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness,
Provider Bridges", 2005 Malcolm Betts, Paul Bottorff, Hamid-Ould Brahim, Lior Shabtay, and
Dan Cauchy for their feedback.
[IEEE 802.1ag] "IEEE Standard for Local and metropolitan area 14. References
networks - virtual Bridged Local Area Networks, Amendment 5:
Connectivity Fault Management", 2007
[IEEE 802.1ah] "IEEE Standard for Local and metropolitan area 14.1. Normative References
networks - virtual Bridged Local Area Networks, Amendment 6:
Provider Backbone Bridges", 2008
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
mechanisms for Ethernet based networks", February 2008 Requirement Levels", BCP 14, RFC 2119, March 1997.
[L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks [IEEE802.1ad] "IEEE Standard for Local and metropolitan area
(L2VPNs)", RFC 4664 networks - Virtual Bridged Local Area Networks,
Amendment 4: Provider Bridges", 2005.
[L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned [IEEE802.1ag] "IEEE Standard for Local and metropolitan area
Virtual Private Networks", RFC 4665 networks - Virtual Bridged Local Area Networks,
Amendment 5: Connectivity Fault Management", 2007.
[L2VPN-TERM] "Provider Provisioned Virtual Private Network (VPN) [IEEE802.1ah] "IEEE Standard for Local and metropolitan area
Terminology", RFC 4026 networks - Virtual Bridged Local Area Networks,
Amendment 6: Provider Backbone Bridges", 2008.
[MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1, 2006 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions
and mechanisms for Ethernet based networks",
February 2008.
[NM-Standards] "TMN Management Functions", M.3400, February 2000 [L2VPN-FRWK] Andersson, L., Ed., and E. Rosen, Ed., "Framework
for Layer 2 Virtual Private Networks (L2VPNs)", RFC
4664, September 2006.
[VPLS-BGP] "Virtual Private LAN Service", RFC 4761, Jan 2007 [L2VPN-REQ] Augustyn, W., Ed., and Y. Serbest, Ed., "Service
Requirements for Layer 2 Provider-Provisioned
Virtual Private Networks", RFC 4665, September 2006.
[VPLS-LDP] "Virtual Private LAN Services over MPLS", RFC 4762, Jan [L2VPN-TERM] Andersson, L. and T. Madsen, "Provider Provisioned
2007 Virtual Private Network (VPN) Terminology", RFC
4026, March 2005.
13.2 Informative References [MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1,
2006.
[BRIDGE-INTEROP] "VPLS Interoperability with CE Bridges", draft- [NM-Standards] "TMN Management Functions", M.3400, February 2000.
ietf-l2vpn-vpls-bridge-interop-05.txt, Work in progress, March 2010
[L2VPN-SIG] "Provisioning, Autodiscovery, and Signaling in L2VPNs", [VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual
draft-ietf-l2vpn-signaling-08.txt, Work in progress, May 2006 Private LAN Service (VPLS) Using BGP for Auto-
Discovery and Signaling", RFC 4761, January 2007.
[MS-PW Arch] "An Architecture for Multi-segment Pseudowire Emulation [VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-04.txt, Work in progress, Private LAN Service (VPLS) Using Label Distribution
June 2008 Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC2544] "Benchmarking Methodology for Network Interconnect 14.2. Informative References
Devices", RFC 2544, 1999
A1. Appendix 1 - Alternate Management Models [BRIDGE-INTEROP] Sajassi, A. Ed., Brockners, F., Mohan, D., Ed., and
Y. Serbest, "VPLS Interoperability with CE Bridges",
Work in Progress, October 2010.
[L2VPN-SIG] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in
Layer 2 Virtual Private Networks (L2VPNs)", RFC
6074, January 2011.
[MS-PW-Arch] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC
5659, October 2009.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking
Methodology for Network Interconnect Devices", RFC
2544, March 1999.
Appendix A. Alternate Management Models
In consideration of the management models that can be deployed In consideration of the management models that can be deployed
besides the hierarchical models elaborated in this document, this besides the hierarchical models elaborated in this document, this
section highlights some alternate models that are not recommended appendix highlights some alternate models that are not recommended
due to their limitations, as pointed out below. These alternatives due to their limitations, as pointed out below. These alternatives
have been highlighted as potential interim models while the network have been highlighted as potential interim models while the network
equipments are upgraded to support full functionality and meet the equipment is upgraded to support full functionality and meet the
requirements set forward by this document. requirements set forward by this document.
A1.1. Alternate Model 1 (Minimal OAM) A.1. Alternate Model 1 (Minimal OAM)
In this model, the end-to-end service monitoring is provided by In this model, the end-to-end service monitoring is provided by
applying CE to CE ME in the Service Provider OAM Domain. applying CE to CE ME in the service provider OAM domain.
A MEP is located at each CE interface that is part of the VPWS A MEP is located at each CE interface that is part of the VPWS, as
service, as shown in Figure A1.1 (B). The network operators can shown in (B) in Figure A.1. The network operators can carry out
carry out segment (e.g. PSN Tunnel ME, etc.) monitoring independent segment (e.g., PSN Tunnel ME, etc.) monitoring independent of the
of the VPWS end-to-end service monitoring, as shown in Figure A1.1 VPWS end-to-end service monitoring, as shown in (D) in Figure A.1.
(D).
The advantage of this option is that VPWS service monitoring is The advantage of this option is that VPWS monitoring is limited to
limited to CEs. The limitation of this option is that the CEs. The limitation of this option is that the localization of
localization of faults at the VPWS Service level. faults is at the VPWS level.
|<--------------- VPWS <AC1,PW,AC2> -------------->| |<--------------- VPWS <AC1,PW,AC2> -------------->|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
(B) MEP-----------------------------------------------MEP (B) MEP-----------------------------------------------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A1.1: VPWS MEPs & MIPs - Minimal OAM Figure A.1: VPWS MEPs and MIPs (Minimal OAM)
A1.2. Alternate Model 2 (Segment OAM Interworking) A.2. Alternate Model 2 (Segment OAM Interworking)
In this model, the end-to-end service monitoring is provided by In this model, end-to-end service monitoring is provided by
interworking OAM across each segment. Typical segments involved in interworking OAM across each segment. Typical segments involved in
this case include two AC MEs and PW ME, as shown in Figure A1.2 (C). this case include two AC MEs and a PW ME, as shown in (C) in Figure
These segments are expected in the Service Provider OAM Domain. An A.2. These segments are expected in the service provider OAM domain.
interworking function is required to transfer the OAM information An interworking function is required to transfer the OAM information
flows across the OAM segments for the purposes of end-to-end flows across the OAM segments for the purposes of end-to-end
monitoring. Depending on whether homogenous VPWS is deployed or monitoring. Depending on whether homogenous VPWS is deployed or
heterogeneous VPWS is deployed, the interworking function could be heterogeneous VPWS is deployed, the interworking function could be
straightforward or more involved. straightforward or more involved.
In this option, the CE and PE interfaces support MEPs for AC and PW In this option, the CE and PE interfaces support MEPs for AC and PW
MEs and no MIPs are involved at the Service Provider OAM Level, as MEs, and no MIPs are involved at the service provider OAM level, as
shown in Figure A1.2 (C). The network operators may run segment OAM shown in (C) in Figure A.2. Network operators may run segment OAM by
by having MEPs at Network Operator OAM level, as shown in Figure having MEPs at the network operator OAM level, as shown in (D) in
A1.2 (D). Figure A.2.
The limitations of this model are that it requires interworking The limitations of this model are that it requires interworking
across the OAM segments and does not conform to the OAM layering across the OAM segments and does not conform to the OAM layering
principles, where each OAM layer ought to be independent of the principles, where each OAM layer ought to be independent of the
other. For end-to-end OAM determinations, the end-to-end service others. For end-to-end OAM determinations, the end-to-end service
frame path is not necessarily exercised. Further, it requires frame path is not necessarily exercised. Further, it requires
interworking function implementation for all possible technologies interworking function implementation for all possible technologies
across access and core that may be used to realize end-to-end across access and core that may be used to realize end-to-end
services. services.
|<--------------- VPWS <AC1,PW,AC2> -------------->| |<--------------- VPWS <AC1,PW,AC2> -------------->|
| | | |
| +----+ +----+ | | +----+ +----+ |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A1.2: VPWS MEPs & MIPs - Segment OAM Interworking Figure A.2: VPWS MEPs and MIPs (Segment OAM Interworking)
Authors' Addresses Authors' Addresses
Ali Sajassi Ali Sajassi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Email: sajassi@cisco.com USA
EMail: sajassi@cisco.com
Dinesh Mohan Dinesh Mohan (editor)
Nortel Nortel
3500 Carling Ave Ottawa, ON K2K3E5
Ottawa, ON K2H8E9 EMail: dinmohan@hotmail.com
Email: mohand@nortel.com
Simon Delord
Uecomm
658 Church St
Richmond, VIC, 3121, Australia
E-mail: sdelord@uecomm.com.au
Philippe Niger
France Telecom
2 av. Pierre Marzin
22300 LANNION, France
E-mail: philippe.niger@francetelecom.com
Samer Salam
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: ssalam@cisco.com
 End of changes. 358 change blocks. 
1153 lines changed or deleted 1209 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/