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

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