RFC 6136
Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework
RFC 6136: L2VPN OAM Requirements and Framework 💖
Part 1 of 8 🎀
Bestie, this one's the L2VPN OAM Requirements and Framework doc 🧚. Here's the title block tea ☕:
- Number and date: RFC 6136, published March 2011 🌸
- Authors: A. Sajassi, Ed. (Cisco) and D. Mohan, Ed. (Nortel) 👑
- Category: Informational, so it's for info, not a standards-track spec 🦋
- ISSN: 2070-1721
- Obsoletes and updates: the title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own ✨
Abstract
okay so this doc gives a framework and requirements for OAM (Operations, Administration, and Maintenance) on Layer 2 Virtual Private Networks, aka L2VPN 💅. The whole point of the OAM framework is to set up OAM layering across three things: L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels 🌈.
It's specifically about the OAM requirements for three L2VPN services: Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS) 🫶.
And if the L2VPN service OAM requirements end up putting specific demands on PW OAM and/or PSN OAM, the doc calls those out too, so nothing gets lost in the shuffle 🔥.
Status of This Memo
ngl this section is the "what kind of doc is this" part 🙈. It is not an Internet Standards Track specification. It's just published for informational purposes 💜.
It is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ✨. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🎀. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the details 💅.
Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc6136 🦋.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date it was published. Please read these carefully, because they spell out your rights and restrictions for this doc 🌸. Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🍓.
Some of this doc may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 ✨. The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process 🙈. So, unless you get an adequate license from whoever controls that copyright, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 😭. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🫶.
Table of Contents
1. Introduction ....................................................4
1.1. Specification of Requirements ..............................6
1.2. Relationship with Other OAM Work ...........................6
2. Terminology .....................................................7
3. L2VPN Services and Networks .....................................7
4. L2VPN OAM Framework .............................................8
4.1. OAM Layering ...............................................8
4.2. OAM Domains ................................................9
4.3. MEPs and MIPs .............................................10
4.4. MEP and MIP Identifiers ...................................11
5. OAM Framework for VPLS .........................................11
5.1. VPLS as Service/Network ...................................11
5.1.1. VPLS as Bridged LAN Service ........................11
5.1.2. VPLS as a Network ..................................12
5.1.3. VPLS as (V)LAN Emulation ...........................12
5.2. VPLS OAM ..................................................13
5.2.1. VPLS OAM Layering ..................................13
5.2.2. VPLS OAM Domains ...................................14
5.2.3. VPLS MEPs and MIPs .................................15
5.2.4. VPLS MEP and MIP Identifiers .......................16
6. OAM Framework for VPWS .........................................17
6.1. VPWS as Service ...........................................17
6.2. VPWS OAM ..................................................18
6.2.1. VPWS OAM Layering ..................................18
6.2.2. VPWS OAM Domains ...................................19
6.2.3. VPWS MEPs and MIPs .................................21
6.2.4. VPWS MEP and MIP Identifiers .......................23
7. VPLS OAM Requirements ..........................................23
7.1. Discovery .................................************24
7.2. Connectivity Fault Management .............................24
7.2.1. Connectivity Fault Detection .......................24
7.2.2. Connectivity Fault Verification ....................24
7.2.3. Connectivity Fault Localization ....................24
7.2.4. Connectivity Fault Notification and Alarm
Suppression ........................................25
7.3. Frame Loss ................................................25
7.4. Frame Delay ...............................................25
7.5. Frame Delay Variation .....................................26
7.6. Availability ..............................................26
7.7. Data Path Forwarding ......................................26
7.8. Scalability ...............................................27
7.9. Extensibility .............................................27
7.10. Security .................................................27
7.11. Transport Independence ...................................28
7.12. Application Independence .................................28
8. VPWS OAM Requirements ..........................................28
8.1. Discovery .................................................29
8.2. Connectivity Fault Management .............................29
8.2.1. Connectivity Fault Detection .......................29
8.2.2. Connectivity Fault Verification ....................29
8.2.3. Connectivity Fault Localization ....................29
8.2.4. Connectivity Fault Notification and Alarm
Suppression ........................................30
8.3. Frame Loss ................................................30
8.4. Frame Delay ...............................................30
8.5. Frame Delay Variation .....................................31
8.6. Availability ..............................................31
8.7. Data Path Forwarding ......................................32
8.8. Scalability ...............................................32
8.9. Extensibility .............................................32
8.10. Security .................................................32
8.11. Transport Independence ...................................33
8.12. Application Independence .................................33
8.13. Prioritization ...........................................34
9. VPLS (V)LAN Emulation OAM Requirements .........................34
9.1. Partial-Mesh of PWs .......................................34
9.2. PW Fault Recovery .........................................34
9.3. Connectivity Fault Notification and Alarm Suppression .....35
10. OAM Operational Scenarios .....................................35
10.1. VPLS OAM Operational Scenarios ...........................36
11. Security Considerations .......................................37
12. Contributors ..................................................38
13. Acknowledgements ..............................................38
14. References ....................................................38
14.1. Normative References .....................................38
14.2. Informative References ...................................39
Appendix A. Alternate Management Models ...........................41
A.1. Alternate Model 1 (Minimal OAM) ..............................41
A.2. Alternate Model 2 (Segment OAM Interworking) .................411. Introduction ✨
okay so bestie, this doc is all about the framework and requirements for L2VPN OAM 🎀 (that's Layer 2 Virtual Private Network Operation, Administration, and Maintenance, which is a mouthful, I know 💀).
OAM can be super broad. OSI came up with five functional areas that people call "FCAPS" [NM-Standards]: a) Fault Management, b) Configuration Management, c) Accounting Management, d) Performance Management, and e) Security Management. 🧚
This doc only focuses on Fault and Performance Management 💜. The other FCAPS parts are for further study, so they're not in here yet.
Fault Management is usually split into five categories:
- Fault Detection
- Fault Verification
- Fault Isolation
- Fault Notification and Alarm Suppression
- Fault Recovery
Fault detection is about catching both hard failures (like link and device failures) and soft failures (like software failure, memory corruption, misconfiguration, etc.) 🔥. A lightweight protocol is usually the move here, and it's smart to verify the fault with a fault verification mechanism before you go digging into isolation 🧐. Once you've confirmed a fault is on the data path, you need to be able to isolate it down to a specific device or link, which is why fault isolation is needed in Fault Management 💅.
Fault notification works with fault detection to tell the devices upstream and downstream of the detection point that something's wrong 📣. Like, if two layered networks have a client/server relationship, a fault at the server layer can trigger:
- Sending a forward fault notification from the server layer to the client layer network(s), using the fault notification format that fits the client layer
- Sending a backward fault notification at the server layer, if applicable, in the reverse direction
- Sending a backward fault notification at the client layer, if applicable, in the reverse direction
And then fault recovery is the glow-up 🦋: it recovers from the failure by switching over to an alternate available data path, using alternate devices or links (for example, device redundancy or link redundancy).
Performance Management is all about mechanisms that let you figure out and measure how well the network or services are doing 📊. You can use it to check compliance with both service-level and network-level metric objectives and specifications 🎯. It usually means measuring performance metrics like Frame Loss, Frame Delay, and Frame Delay Variation (aka Jitter) across managed entities, but only while those entities are in an available state. If an entity is unavailable, Performance Management gets paused for it ⏸️.
[L2VPN-FRWK] names three types of Layer 2 VPN services: Virtual Private LAN Service (VPLS), (Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS) 🌈.
This doc gives you a reference model for OAM as it applies to L2VPN services and their pseudowires (PWs) and Public Switched Network (PSN) tunnels 🧵. It also lists the OAM requirements for L2VPN services (like VPLS and VPWS). And if those L2VPN service requirements mean the PW and/or PSN need OAM too, those specific PW and/or PSN OAM requirements are listed as well 🫶.
1.1. Specification of Requirements
Okay, the key word rules: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in [RFC2119] 📖. Those capital words are the official ones, so don't mess with them 🙈.
1.2. Relationship with Other OAM Work
This doc borrows protocols, mechanisms, and concepts from other OAM work, specifically:
- IEEE Std. 802.1ag-2007 [IEEE802.1ag] is the Ethernet Connectivity Fault Management protocol 💜. It defines Maintenance Domains, Maintenance End Points, and Maintenance Intermediate Points. It also covers proactive fault detection (Continuity Check), fault notification (Remote Defect Indication (RDI)), fault verification (Loopback), and fault isolation (LinkTrace) in Ethernet networks 🔍.
- ITU-T Std. Y.1731 [Y.1731] builds on and extends IEEE 802.1ag 🌸. 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 📈.
2. Terminology
This doc introduces and uses the following terms 📝. It also uses the terms defined in [L2VPN-FRWK] and [L2VPN-TERM], so check those too 🧚.
AIS Alarm Indication Signal
IPLS IP-only LAN Service
ME Maintenance Entity, which is defined in a given OAM
domain and represents an entity requiring management
MEG Maintenance Entity Group, which represents MEs belonging
to the same service instance and is also called
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 and respond to certain OAM frames
but does not initiate or terminate them.
OAM Domain OAM Domain represents a region over which OAM frames can
operate unobstructed.
QinQ 802.1Q tag inside another 802.1Q tag
RDI Remote Defect Indication
VPLS Virtual Private LAN Service
VPWS Virtual Private Wire Service3. L2VPN Services and Networks
Figure 1 shows the L2VPN reference model from [L2VPN-REQ] 🦋. L2VPN A is a point-to-point service, and L2VPN B is a bridged service 💖.
+-----+ +-----+
+ CE1 +--+ +--| CE2 |
+-----+ | ..................... | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |-- Service --| PE |--+
+----+ Provider +----+
/ . Backbone . \ --------_
+-----+ / . | . \ / \ +-----+
+ CE4 +--+ . | . +-\ Access \--| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B ........| PE |....... \ / L2VPN B
+----+ ^ -------
| | logical
| | switching
+-----+ | instance
| CE3 |
+-----+
L2VPN BFigure 1: L2VPN Reference Model
[L2VPN-FRWK] specifies VPWS, VPLS, and IPLS 🌟. VPWS is a point-to-point service where Customer Edges (CEs) get 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, and those CEs in the same service instance talk to each other as if they were on a bridged LAN 🌈. IPLS is a special kind of VPLS that carries only IP service packets 🌸.
[L2VPN-REQ] assumes runtime monitoring protocols are already available when it defines requirements for management interfaces 👀. This doc is the one that specifies the requirements and framework for OAM protocols between network devices ⚙️.
4. L2VPN OAM Framework
4.1. OAM Layering
The point-to-point or bridged LAN functionality is emulated by a network of Provider Edges (PEs) that the CEs connect to 🏗️. That PE network can belong to a single network operator or span multiple network operators, and it can belong to a single service provider or span multiple service providers 💅. A service provider is in charge of giving L2VPN services to its customers 💼. A network operator (aka facility provider) supplies the facilities the service provider(s) need to run their services 🔧. The network operator and the service provider can be in the same administrative organization, or they can be in different ones 🫶.
The layers involved in making L2VPNs happen include service layers and network layers 🍰. Network layers can be iterative 🔁. For L2VPNs, the service layer covers VPLS, VPWS (e.g., Ethernet, ATM, FR, HDLC, SONET, point-to-point emulation, etc.), and IPLS 🌈. For L2VPNs, network layers consist of MPLS/IP networks 🧚. Those MPLS/IP networks can be built from network links made with different technologies, e.g., SONET, Ethernet, ATM, etc. 💜
Each layer is responsible for its own OAM ✨. This doc gives the OAM framework and requirements for L2VPN services and networks 💖.
4.2. OAM Domains 🦋
okay so when we talk about OAM tools for L2VPNs, it's giving "every domain a service provider or network operator is responsible for needs OAM that actually works" 💅 And it's just as important that OAM frames don't wander into other domains. 🙈 So we define an OAM domain as a network region where OAM frames operate unobstructed, as explained below ✨
At the edge of an OAM domain, filtering constructs should stop OAM frames from leaving or getting into that domain 🫶 OAM domains can be nested but not overlapped, bestie. 🧚 Picture a hierarchy: OAM frames from a higher-level domain pass transparently through the lower-level domains, but OAM frames from a lower-level domain get blocked or filtered at that domain's edge 💜
To keep processing OAM frames simple, each OAM domain can be associated with the level it operates at 🌈 Higher-level OAM domains can contain lower-level OAM domains, but the converse is not true. ⭐ Also, a higher-level domain does not necessarily mean a higher numerical value of the level encoding in the OAM frame. 🙃 Easy to mix up, so watch out!
A PE can be part of several OAM domains, and each interface can belong to the same domain or a different one 🎀 A PE with an interface at the boundary of an OAM domain shall block outgoing OAM frames, filter out incoming OAM frames whose domain level is lower than or the same as the one configured on that interface, and pass through the OAM frames whose domain level is higher than the one configured on that interface. 💅 Very precise, very iconic.
Generically, L2VPNs can be viewed as having a customer OAM domain, a service provider OAM domain, and network operator OAM domains, as shown in Figure 2 🍓
--- ---
/ \ ------ ------- ----- / \
| CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ /
--- --PE P P PE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- -----
Customer OAM Domain
|<-------------------------------------------->|
Service Provider OAM Domain
|<------------------------------>|
Operator Operator Operator
|<-------->|<--------->|<------->|
OAM Domain OAM Domain OAM Domain
Figure 2: OAM DomainsThe OAM Domains can be sorted into two categories, and this part is so good 😭
- Hierarchical OAM Domains: these result from OAM Layering and imply a contractual agreement among the OAM Domain owning entities. In Figure 2, the customer OAM domain, the service provider OAM domain, and the operator OAM domains are hierarchical. 💖
- Adjacent OAM Domains: these are typically independent of each other and don't have any relationship among them. In Figure 2, the different operator OAM domains are independent of each other. 🌸
4.3. MEPs and MIPs 🧚
okay, Maintenance End Points (MEPs) are in charge of originating and terminating OAM frames 👑 They sit at the edge of their corresponding OAM domains 🫶 Maintenance Intermediate Points (MIPs) live inside their corresponding OAM domains, and they normally pass OAM frames but never initiate them. 🦋 Since MEPs are at the edge, they handle filtering outbound OAM frames from leaving the OAM domain, or inbound OAM frames from entering it. 💅
An OAM frame is generally associated with a Maintenance Entity Group (MEG). A MEG is a set of Maintenance Entities (MEs) associated with the same service instance 🎀 An ME is a point-to-point association between a pair of MEPs, and it represents a monitored entity. ✨ For example, in a VPLS that involves n CEs, all the MEs associated with the VPLS in the customer OAM domain (that is, from CE to CE) can be considered part of a VPLS MEG. That 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 from 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 a lower-level OAM domain can correspond to a MIP or a MEP of a higher-level OAM domain. 🧚 The MIPs of a lower-level OAM domain are always transparent to the higher-level OAM domain. So OAM frames of a higher-level OAM domain are not seen by MIPs of a lower-level OAM domain, and they get passed through them transparently 🫶 The MEs (or MEGs) are also hierarchically organized in hierarchical OAM domains. For example, in a VPWS, the VPWS ME in the customer OAM domain can overlap with the Attachment Circuit (AC) ME, the PW ME, and another AC ME in the service provider OAM domain. Similarly, the PW ME can overlap with different MEs in operator OAM domains. 💜 Layers within layers, iykyk 🤭
4.4. MEP and MIP Identifiers 🏷️
as mentioned before, OAM at each layer should be independent of other layers. For instance, service layer OAM should be independent of an underlying transport layer 🌸 MEPs and MIPs at each layer should be identified with layer-specific identifiers. 💖
5. OAM Framework for VPLS 🌈
Virtual Private LAN Service (VPLS) gets used in different contexts, such as the following: 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. 👑 Three personalities, one acronym! 🎀
5.1. VPLS as Service/Network 💅
5.1.1. VPLS as Bridged LAN Service ✨
The most common definition of VPLS is a bridged LAN service over an MPLS/IP network 🦋 The service coverage is end-to-end, from UNI to UNI (or AC to AC) among the CE devices, and it provides a virtual LAN service to the attached CEs belonging to that service instance 🫶 It's called a bridged LAN service because the VPLS-capable PE providing this end-to-end virtual LAN service performs bridging functions (either full or a subset), as described in [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN-REQ], includes both the bridge module and the LAN emulation module (as specified in [L2VPN-FRWK]). 🧚
Throughout this document, whenever the term "VPLS" is used by itself, it refers to the service, as opposed to the network or LAN emulation. 💜
A VPLS instance is also analogous to a VLAN provided by IEEE 802.1Q networks, since each VLAN provides a Virtual LAN service to its Media Access Control (MAC) users 🍓 So when part of the service provider network is Ethernet based (such as H-VPLS with QinQ access network), there is a one-to-one correspondence between a VPLS instance and its corresponding provider VLAN in the service provider Ethernet network. 🌈 To check end-to-end service integrity, the OAM mechanism needs to cover the end-to-end VPLS as defined in [L2VPN-REQ], which runs from AC to AC. That includes the bridge module, the VPLS forwarder, and the associated PWs for this service. 🔥 This document specifies the framework and requirements for such OAM mechanisms. ✨
5.1.2. VPLS as a Network 🌐
Sometimes VPLS is also used to refer to the underlying network that supports bridged LAN services 🎀 This network can be an end-to-end MPLS/IP network, as in H-VPLS with MPLS/IP access, or it can be a hybrid network made of an MPLS/IP core and an Ethernet access network, as in H-VPLS with QinQ access 💖 Either way, the network consists of a set of VPLS-capable PE devices that can perform bridging functions (either full or a subset). 🫶 These PE devices can be arranged in a certain topology, such as hierarchical topology, distributed topology, or other topologies like multi-tier or star topologies 🦋 To check 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 the scope of this document, so we're leaving that one for another day 🙈
5.1.3. VPLS as (V)LAN Emulation 🪞
Sometimes VPLS also refers to (V)LAN emulation. In this context, VPLS only refers to the full mesh of PWs with split horizon that emulates a LAN segment over an 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 called an emulated VLAN. 🌸 The OAM mechanisms in this context refer primarily to integrity checks of VPLS forwarders and their associated full mesh of PWs, plus the ability to detect and notify a partial mesh failure. 💜 This document also covers the OAM framework and requirements for such OAM mechanisms. 🎀
5.2. VPLS OAM 🌈
When discussing OAM mechanisms for VPLS, it's important to remember that the end-to-end service can span different types of L2VPN networks 💅 For example, the access network on one side can be a bridged network, e.g., [IEEE802.1ad], as described in Section 11 of [VPLS-LDP]. The access network can also be an [IEEE802.1ah]-based bridged network. The access network on the 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 instance can span across [VPLS-BGP] and distributed VPLS, as described in [L2VPN-SIG]. 🧚
Therefore, it's important that OAM mechanisms can be applied to all these network types 🫶 Each such network may be associated with a separate administrative domain, and multiple such networks may be associated with a single administrative domain. It's important to ensure that OAM mechanisms are independent of the underlying transport mechanisms and solely rely on VPLS, i.e., the transparency of OAM mechanisms must be ensured over underlying transport technologies such as MPLS, IP, etc. 🔥 Full transparency, no exceptions!
This proposal is aligned with discussions in other standards bodies and groups, such as ITU-T Q.5/13, IEEE 802.1, and the Metro Ethernet Forum (MEF), which address Ethernet network and service OAM. 👑
5.2.1. VPLS OAM Layering ✨
Okay so picture this: 🧚 Figure 3 shows a VPLS with two CEs belonging to customer A, sitting across a service provider network made of UPE and NPE devices. More CE devices from that same customer can hook up at other sites too. The provider network splits into a core network and two kinds of access networks. In Figure 3, (A) shows the bridged access network, drawn as its bridge components marked B, plus the MPLS access and core network, drawn as MPLS components marked P. In (B), you get the service/network view at the Ethernet MAC layer, marked by E. 💅
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE
(B) E------E---E--E---E------------E----------E-----E
Figure 3: VPLS-Specific Device ViewHere's the tea 🍓: as (B) shows, only the devices with Ethernet functionality can be seen by OAM mechanisms working at the Ethernet MAC layer. The P devices are totally invisible to them. So the OAM along the P device path (for example, between two PEs) is covered by the transport layer, and it's outside the scope of this document. Not me going "that's a different room" 🙈
That said, VPLSs may come with some specific requirements on PSN OAM. This document is here to figure out what those requirements are. 🎀
5.2.2. VPLS OAM Domains
Remember how we said a VPLS for one customer can stretch across one or more service providers and network operators? Figure 4 shows three OAM domains: (A) the customer domain, which covers the CEs of a given customer; (B) the service provider domain, which covers the edge PEs of the given service provider; and (C) the network operator domain, which covers the PEs of a given operator. Main character energy for each domain 👑
--- ---
/ \ ------ ------- ---- / \
| CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
Customer OAM Domain
(A) |<----------------------------------------------->|
Provider OAM Domain
(B) |<---------------------------------->|
Operator Operator Operator
(C) |<--------->|<---------->|<-------->|
OAM Domain OAM Domain OAM Domain
Figure 4: VPLS OAM Domains5.2.3. VPLS MEPs and MIPs 🦋
Okay, this one is where the MEPs and MIPs get their spots. In Figure 5, (C) represents the MEPs and MIPs visible within the customer domain. The MIPs in (C) are expected to be implemented in the bridge module/VPLS forwarder of a PE device, as per [L2VPN-FRWK]. Then (D) represents the MEPs and MIPs visible within the service provider domain. Those are also expected to live in the bridge module/VPLS forwarder of a PE device, as per [L2VPN-FRWK]. ✨
(E) is the MEPs and MIPs visible within each operator domain, and this is the plot twist: MIPs only exist in an Ethernet access network. An MPLS access network doesn't have MIPs at the operator level. 😭 Last one, (F), represents the MEPs and MIPs for the MPLS layer, which may apply MPLS-based mechanisms. The MPLS layer in Figure 5 is only an example, though. Specific OAM mechanisms are outside the scope of this document. 🌸
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE
(B) E------E---E------E------------E----------E-----E
Customer OAM Domain
(C) MEP---MIP--------------------------------MIP---MEP
Provider OAM Domain
(D) MEP--------MIP-----------MIP-------MEP
Operator Operator Operator
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
OAM domain OAM domain OAM domain
MPLS OAM MPLS OAM
(F) MEP--MIP--MEP|MEP-MIP-MEP
domain domain
Figure 5: VPLS OAM Domains, MEPs, and MIPs5.2.4. VPLS MEP and MIP Identifiers 🎀
Here's how identification works in VPLS. For the Ethernet MAC layer, the MEPs and MIPs should be identified with their Ethernet MAC addresses and their Maintenance Entity Group Identifier (MEG ID). As described in [VPLS-LDP], a VPLS instance can be identified in an Ethernet domain (for example, an 802.1ad domain) using a VLAN tag (service tag). In an MPLS/IP network, PW-ids are used instead. Both PW-ids and VLAN tags for a given VPLS instance are associated with a Service Identifier (for example, a VPN identifier). 🧚
MEP Ids and MIP Ids, aka the MEPs and MIPs Identifiers, must be unique within their corresponding Service Identifiers inside the OAM domains. Unique IDs, no drama 💅
For Ethernet services like VPLS, Ethernet frames are used for OAM frames. The source MAC address of an OAM frame represents the source MEP in that domain for a specific MEG. For unicast Ethernet OAM frames, the destination MAC address represents the destination MEP in that domain for a specific MEG. For multicast Ethernet OAM frames, the destination MAC addresses correspond to all MEPs in that domain for a specific MEG. 🦋
6. OAM Framework for VPWS ✨
Figure 6 shows the VPWS reference model. VPWS is a point-to-point service, where CEs are presented with point-to-point virtual circuits. It's realized by combining a pair of Attachment Circuits (ACs) with a single PW between two PEs. Simple, clean, iconic 💖
|<------------- VPWS1 <AC11,PW1,AC12> ------------>|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC11---| |.......PW1........| |--AC12----| |
| CE1| |PE1 | | PE2| |CE2 |
| |---AC21---| |.......PW2........| |--AC22----| |
+----+ | |==================| | +----+
| +----+ PSN Tunnel +----+ |
| |
|<------------- VPWS2 <AC21,PW2,AC22> ------------>|
Figure 6: VPWS Reference Model6.1. VPWS as Service 🌈
VPWS can be categorized in these ways:
- VPWS with homogeneous ACs (where both ACs are the same type)
- VPWS with heterogeneous ACs (where the ACs are of different Layer-2 encapsulation)
The VPWS can also be classified like this:
- Homogeneous VPWS (when the two ACs and the PW are of the same type)
- Heterogeneous VPWS (when at least one AC or PW is a different type from the others)
Based on the above, a heterogeneous VPWS may have either homogeneous or heterogeneous ACs. A homogeneous VPWS, on the other hand, can have only homogeneous ACs. 🫶
Throughout this document, whenever the term "VPWS" is used by itself, it refers to the service. 💜
6.2. VPWS OAM 🔥
When we talk about OAM mechanisms for VPWS, it's important to remember that the end-to-end service can span different types of networks. For example, the access network between the CE and PE on one side could be an Ethernet-bridged network, an ATM network, and so on. In common scenarios, it could simply be a point-to-point interface such as an Ethernet Physical Layer (PHY). The core network connecting PEs can be IP, MPLS, and so on. 🌸
So the OAM mechanisms need to be applicable to different network types, some of which are mentioned above. Each such network may be associated with a separate administrative domain, and multiple such networks may be associated with a single administrative domain. Different networks, same domain energy 🧚
6.2.1. VPWS OAM Layering ✨
Figure 7 shows an example of a VPWS (with two CE devices belonging to customer A) across a service provider network marked by PE devices. The service provider network can be seen as segmented into a core network and two types of access networks. 💅
In the most general case, a PE can be client service aware. That means it processes client service PDUs and is responsible for encapsulating and de-encapsulating client service PDUs onto PWs and ACs. This is especially relevant for homogeneous VPWS. The service-specific device view for this kind of deployment is highlighted by (A) in Figure 7, because these are the devices expected to be involved in end-to-end VPWS OAM. 👑
In other instances, a PE can be client service unaware. It doesn't process native service PDUs, and instead encapsulates access technology PDUs over PWs. This may be relevant for VPWS with heterogeneous ACs, such as an Ethernet VPWS offered across an ATM AC, an ATM PW, and an Ethernet AC. In this case, the PE attached to the ATM AC and ATM PW may be transparent to the client Ethernet service PDUs. On the other hand, the PE attached to the ATM PW and the Ethernet AC is expected to be client Ethernet service aware. The service-specific device view for this deployment is highlighted by (B) in Figure 7, since these are the devices expected to be involved in end-to-end VPWS OAM, where PE1 is expected to be client service unaware. 🦋
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
access core access
|<---------->|<---------------------->|<------------>|
(A) CE----------PE-----------------------PE-------------CE
(B) CE-----------------------------------PE-------------CE
Figure 7: VPWS-Specific Device View6.2.2. VPWS OAM Domains ✨
okay so, like we said in the last bit, a VPWS for one customer can stretch across one or more network operators 🌈
Figures 8a and 8b show three OAM domains 🦋 (A) is the customer domain, which covers the CEs belonging to a given customer. (B) is the service provider domain, and what it looks like depends on the management model. (C) is the network operator domain, which covers the PEs of a given operator and could also show up in the access network if a different network operator provides the ACs. The core network operator may be the one managing the PSN Tunnel in these examples 💅
For the first management model, the one 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 they need it 💖 The service provider handles monitoring the PW ME, and watching the AC is a shared job between the customer and the service provider 🫶 In most simple cases, where the AC is a physical interface connecting the CE to the PE, the monitoring needs across the AC ME are minimal ✨
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
Customer OAM Domain
(A) |<------------------------------------------------->|
Service Provider OAM Domain
(B) |<--------------------------->|
Operator OAM Domain
(C) |<---------------->|
Figure 8a: VPWS OAM Domains - Management Model 1Figure 8b is a different management model 🌸 Here the CEs are managed by the service provider, and the CEs and PEs are connected through an access network. That access network may or may not belong to a separate network operator 💜 In this model, the VPWS ME stretches between the CEs inside the service provider OAM domain, as you can see at (B) in Figure 8b. The service provider OAM domain can also monitor the AC MEs and PW MEs one at a time, as shown at (C) in Figure 8b. The network operators may be responsible for the access service MEs (e.g., access tunnels) and the core PSN Tunnel MEs, as shown at (D) in Figure 8b 🧚
Now the difference between (C) and (D) is the part that gets me 🙈 In (C), the MEs have MEPs at the CEs and at the PEs, and they have no MIPs. In (D), the MEs also have MEPs at the CEs and PEs, but MIPs may sit in between those MEPs, which gives the operator visibility into the network 👑
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
Customer OAM Domain
(A) |<-------------------------------------------------->|
Service Provider (SP) OAM Domain
(B) |<------------------------------------------------>|
SP OAM SP OAM SP OAM
(C) |<--------->|<----------------------->|<---------->|
Domain Domain Domain
Operator Operator Operator
(D) |<--------->|<----------------------->|<---------->|
OAM Domain OAM Domain OAM Domain
Figure 8b: VPWS OAM Domains - Management Model 2Note: quick heads up 🦋 Unlike the VPLS OAM Domain in Figure 4, where you can have several operator domains between the User-facing PE (U-PE) devices, the VPWS OAM domain in Figures 8a and 8b shows a single operator domain between PE devices. That's because the VPWS doesn't have a distributed PE model the way VPLS does. In the distributed VPLS PE case (D-VPLS), VPLS-aware U-PEs and Network-facing PEs (N-PEs) can be used together to make one distributed PE, but VPWS has no equivalent of that 💅 If the PSN involves several operator domains, which results in a Multi-segment PW [MS-PW-Arch], the VPWS OAM Domains stay the same, since switched PEs are typically not aware of the native service 🌈
6.2.3. VPWS MEPs and MIPs
The location of MEPs and MIPs can depend on the management model used in the VPWS scenarios 🎀 What we care about is being able to monitor the end-to-end service, and also doing segment monitoring in the network so faults can be isolated to specific areas 😭
The end-to-end service monitoring is handled by an end-to-end ME, and the extra segment OAM monitoring is handled by segment MEs. Both sit in the service provider OAM domain 💖 The end-to-end MEs and segment MEs are organized hierarchically, as mentioned in Section 4.2 for hierarchical OAM domains. You can see this at (B) and (C) in Figure 8b ✨
The CE interfaces support MEPs at the end-to-end service provider OAM level for VPWS as an end-to-end service, as shown at (B1) and (B2) in Figure 9 🍓 On top of that, PE interfaces may support MIPs at the end-to-end service provider OAM level when the PEs are client service aware, as shown at (B2) in Figure 9 🧚 For example, if you think about an end-to-end Ethernet line service carried over ATM transport (ATM over MPLS PW), then the PEs are considered Ethernet service unaware, so they can't support any Ethernet MIPs. (B1) in Figure 9 is this exact situation 💅 Another way to look at the same end-to-end service is as ATM. In that case, PE1 and PE2 can be considered service aware and so can support ATM MIPs. (B2) in Figure 9 shows that one 👑
CEs and PE interfaces also support MEPs at a segment (lower level) service provider OAM level for the AC and PW MEs. No MIPs are involved at this segment service provider OAM level, as shown at (C) in Figure 9 🌸 Operators can also run segment OAM by putting MEPs at the network operator OAM level, as shown at (D) in Figure 9 🫶
Layered OAM is great because end-to-end OAM and segment OAM can run independently of each other 🦋 It's also possible to do some optimizations. For example, when proactive segment OAM monitoring is running, proactive end-to-end monitoring may not be needed, because the client layer end-to-end ME could just use fault notifications from the server layer segment MEs 🌈
Even though lots of different OAM layers are possible, as shown in Figure 9, not all of them may actually be realized. For example, (B2) and (D) in Figure 9 may be adequate in some cases 🎀
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
(B1) MEP-----------------------------------------------MEP
(B2) MEP----------MIP---------------------MIP----------MEP
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure 9: VPWS MEPs and MIPs6.2.4. VPWS MEP and MIP Identifiers
In VPWS, the MEPs and MIPs should be identified with their native addressing schemes 🧚 The MEP Ids and MIP Ids must be unique to the VPWS instance, and also in the context of their corresponding OAM domains 💜
7. VPLS OAM Requirements ✨
These requirements apply to a VPLS PE that offers VPLS as an Ethernet Bridged LAN service, as described in Section 5.1.1 🌈 The performance metrics used in the requirements are based on [MEF10.1] and [RFC2544] 💅
OAM solutions that meet the following requirements may make use of existing OAM mechanisms, e.g., Ethernet OAM, VCCV, etc. 🫶 However, they must not break these existing OAM mechanisms. If extensions are needed to existing OAM mechanisms, they should be coordinated with the relevant groups responsible for those OAM mechanisms 🎀
7.1. Discovery
Discovery lets a VPLS-aware device learn about other devices that support the same VPLS instance within a given domain 🦋
Discovery also lets a VPLS-aware device learn enough information (e.g., IP addresses, MAC addresses, etc.) from other VPLS-aware devices that VPLS OAM frames can be exchanged among the service-aware devices 🧚
(R1) VPLS OAM MUST allow a VPLS-aware device to discover other devices that share the same VPLS instance(s) within a given OAM domain 👑
7.2. Connectivity Fault Management
VPLS works by exchanging service frames/packets between devices that support the same VPLS instance 🌸 To allow service frames to be exchanged, connectivity between these service-aware devices is required 💖
7.2.1. Connectivity Fault Detection
To keep the service running, proactive connectivity monitoring is required 😭 Connectivity monitoring is what makes connectivity fault detection possible ✨
(R2a) VPLS OAM MUST allow proactive connectivity monitoring between two VPLS-aware devices that support the same VPLS instance within a given OAM domain 🍓
7.2.2. Connectivity Fault Verification
Once a connectivity fault is detected, connectivity fault verification may be performed 🎀
(R2b) VPLS OAM MUST allow connectivity fault verification between two VPLS-aware devices that support the same VPLS instance within a given OAM domain 💅
7.2.3. Connectivity Fault Localization
After that, localization of the connectivity fault may be carried out 🌈
(R2c) VPLS OAM MUST allow connectivity fault localization between two VPLS-aware devices that support the same instance within a given OAM domain 👑
7.2.4. Connectivity Fault Notification and Alarm Suppression
Typically, when a connectivity fault is detected and optionally verified, the VPLS device may notify the NMS (Network Management System) via alarms 🦋
But here's the tea ☕ a single transport/network fault can make multiple services fail at once, which means multiple service alarms going off 😭 So 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 💜 That fault notification should be used to suppress service-level alarms at the client layer 🫶
(R2d) VPLS OAM MUST support fault notification to be triggered as a result of transport/network faults. This fault notification SHOULD be used for the suppression of redundant service-level alarms 🧚
7.3. Frame Loss
A VPLS may be considered degraded if service-layer frames/packets get lost in transit between the VPLS-aware devices 🌸 To figure out whether a VPLS is degraded because of frame/packet loss, you need to measure that loss 🎀
(R3) VPLS OAM MUST support measurement of per-service frame/packet loss between two VPLS-aware devices that support the same VPLS instance within a given OAM domain 🌈
7.4. Frame Delay 🕒✨
Okay so a VPLS can be lowkey sensitive to how long its frames/packets take to travel between the VPLS-aware devices 🐢. To figure out if a VPLS is degraded because of frame/packet delay, you literally need to measure it 📏. No cap.
There are two flavors of delay measurement 🎀:
- One-way delay is the one you want for certain apps like multicast and broadcast 📡. Measuring it usually means the two devices have to be clock-synced first ⏰, which is a whole thing 😭.
- Two-way delay (aka round-trip delay) doesn't need the clocks synced between the two devices in the measurement 🙌, and it's usually enough to tell you what frame/packet delay is being experienced 💖.
(R4a) VPLS OAM MUST support measurement of per-service two-way frame/packet delay between two VPLS-aware devices that support the same VPLS instance within a given OAM domain 💅.
(R4b) VPLS OAM SHOULD support measurement of per-service one-way frame/packet delay between two VPLS-aware devices that support the same VPLS instance within a given OAM domain 🦋.
7.5. Frame Delay Variation 🌊
A VPLS can also be sensitive to delay variation 🫠 experienced by its frames/packets during transit between the VPLS-aware devices. To check if a VPLS is degraded by frame/packet delay variation, you need to measure it 📊. For delay variation measurements, one-way mechanisms are considered sufficient ✨.
(R5) VPLS OAM MUST support measurement of per-service frame/packet delay variation between two VPLS-aware devices that support the same VPLS instance within a given OAM domain 💜.
7.6. Availability 🟢
A service may count as unavailable if its frames/packets don't reach their intended destination (e.g., connectivity is down or frame/packet loss is happening) 💀, or if the service is degraded (e.g., the frame/packet delay and/or delay variation threshold gets exceeded) 📉.
Entry and exit conditions may be defined for the unavailable state 🚪. Availability itself may be defined in the context of the service type 🎀.
Since availability measurement can be tied to connectivity, frame/packet loss, frame/packet delay, and frame/packet delay variation measurements, no additional requirements are specified right now 🙈.
7.7. Data Path Forwarding 🛣️
If the VPLS OAM frames flow across a different path than the one the VPLS frames/packets use, your accuracy in measuring or determining service state might be off 😬. So the data path (the one VPLS frames/packets actually take) must be used for VPLS OAM 🫶.
(R6) VPLS OAM frames MUST be forwarded along the same path (i.e., links and nodes) as the VPLS frames 🧚.
7.8. Scalability 📈
VPLS OAM mechanisms need to work so that per-service OAM can be supported, even though OAM may only get used on limited VPLS instances (e.g., premium VPLS instances) and may not be used for best-effort VPLSs 👑.
(R7) VPLS OAM MUST be scalable, such that a service-aware device can support OAM for each VPLS that the device supports 🔥.
7.9. Extensibility 🧩
Extensibility is about letting new OAM functionality get added later while keeping backward compatibility when interoperating with older-version devices 🕰️. In that case, VPLS OAM with reduced functionality should still be possible 🌸. Also, VPLS OAM should be defined so that OAM-incapable devices in the middle of the OAM domain can forward VPLS OAM frames similarly to regular VPLS data frames/packets 🚚.
(R8a) VPLS OAM MUST be extensible, such that new functionality and information elements related to that functionality can be introduced in the future 🌈.
(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 data frames/packets 🫶.
7.10. Security 🔐
VPLS OAM frames that belong to an OAM domain originate and terminate within that OAM domain 🏠. Security means an OAM domain must be capable of filtering OAM frames 🚧. The filtering keeps OAM frames from leaking outside their domain. Also, OAM frames from outside the OAM domains should either be discarded (when they belong to the same level or a lower-level OAM domain) or transparently passed (when they belong to a higher-level OAM domain) 🧼.
(R9a) VPLS OAM frames MUST be prevented from leaking outside their OAM domain 🚫.
(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 to a lower-level OAM domain 🛑.
(R9c) VPLS OAM frames from outside an OAM domain MUST be transported transparently inside the OAM domain when such OAM frames belong to a higher-level OAM domain 🫧.
7.11. Transport Independence 🚀
VPLS frame/packet delivery happens across transport infrastructure, also called network infrastructure. Some transport/network technologies come with their own OAM capabilities 🙃, but VPLS OAM must be supported independently, because lots of different transport/network technologies can carry service frames/packets 🌍.
(R10a) VPLS OAM MUST be independent of the underlying transport/network technologies and of specific transport/network OAM capabilities 💖.
(R10b) VPLS OAM MAY allow adaptation/interworking with specific transport/network OAM functions 🤝. For example, this would be useful to let fault notifications from transport/network layer(s) get sent up to the VPLS layer 🔔.
7.12. Application Independence 📱
A VPLS can itself carry application frames/packets 🎁. The application may use its own OAM, but service OAM must not depend on application OAM 🙅♀️. For example, a VPLS may carry IP traffic, but VPLS OAM should not assume IP or rely on IP-level OAM functions 💜.
(R11a) VPLS OAM MUST be independent of the application technologies and of specific application OAM capabilities 🌟.
8. VPWS OAM Requirements 💌
These requirements apply to the VPWS PE 👩💻. The performance metrics used in the requirements are based on [MEF10.1] and [RFC2544], which apply to Ethernet services 🍓.
OAM solutions that meet the following requirements may make use of existing OAM mechanisms (e.g., Ethernet OAM, VCCV, etc.) 🦋. They must not break these existing OAM mechanisms, though 🙈. If extensions to existing OAM mechanisms are required, they should be coordinated with the relevant groups responsible for those OAM mechanisms 🫶.
8.1. Discovery 🔍
Discovery lets a VPWS-aware device learn about other devices that support the same VPWS instance within a given domain 👀. Discovery also lets a VPWS-aware device learn enough information (e.g., IP addresses, MAC addresses, etc.) from other VPWS-aware devices so OAM frames can be exchanged among them 📬.
(R12) VPWS OAM MUST allow a VPWS-aware device to discover other devices that share the same VPWS instance(s) within a given OAM domain 💅.
8.2. Connectivity Fault Management 🛠️
VPWS works by exchanging service frames/packets between devices that support the same VPWS instance 🤝. For those service frames to get exchanged, connectivity between these service-aware devices is required 🔌.
8.2.1. Connectivity Fault Detection 🚨
To keep the service healthy, proactive connectivity monitoring is required 💗. Connectivity monitoring is what makes connectivity fault detection possible ✨.
(R13a) VPWS OAM MUST allow proactive connectivity monitoring between two VPWS-aware devices that support the same VPWS instance within a given OAM domain 👑.
(R13b) VPWS OAM mechanism SHOULD allow detection of mis-branching or mis-connections 🕵️♀️.
8.2.2. Connectivity Fault Verification ✅
Once a connectivity fault is detected, connectivity fault verification may be performed 🧐.
(R13c) VPWS OAM MUST allow connectivity fault verification between two VPWS-aware devices that support the same VPWS instance within a given OAM domain 🫧.
8.2.3. Connectivity Fault Localization 📍
Further, connectivity fault localization may be carried out 🗺️. This may mean identifying the specific AC and/or PW that is causing the VPWS connectivity fault 🎯.
(R13d) VPWS OAM MUST allow connectivity fault localization between two VPWS-aware devices that support the same VPWS instance within a given OAM domain 🔎.
8.2.4. Connectivity Fault Notification and Alarm Suppression 📣
Typically, when a connectivity fault is detected and optionally verified, the service device may notify the NMS (Network Management System) via alarms 🔔.
But one transport/network fault can make multiple services fail at the same time, which means multiple service alarms 😵💫. So 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 to suppress service-level alarms at the client layer 🤫.
For example, if an AC fails, both the local CE and the local PE (the ones connected via the AC) may detect the connectivity failure 👯. The local CE must notify the remote CE about the failure, and the local PE must notify the remote PE about the failure 📨.
Heads up 💅: the notification piece is what keeps your alarm dashboard from turning into a full-blown fire drill 🔥.
(R13e) VPWS OAM MUST support fault notification to be triggered as a result of transport/network faults 🌷. This fault notification SHOULD be used for the suppression of redundant service-level alarms 🫶.
(R13f) VPWS OAM SHOULD support fault notification in the backward direction, to be triggered as a result of transport/network faults 🔙. This fault notification SHOULD be used for the suppression of redundant service-level alarms 🧹.
8.3. Frame Loss 🫥
A VPWS may be considered degraded if service-layer frames/packets get lost during transit between the VPWS-aware devices 📉. To find out if a VPWS is degraded due to frame/packet loss, you need to measure frame/packet loss 📏.
(R14) VPWS OAM MUST support measurement of per-service frame/packet loss between two VPWS-aware devices that support the same VPWS instance within a given OAM domain 💜.
8.4. Frame Delay ⏱️
A VPWS can be sensitive to the delay its frames/packets experience during transit between the VPWS-aware devices 🐌. To check if a VPWS is degraded by frame/packet delay, you need to measure it 📊.
Delay measurement comes in two types 🎀:
- One-way delay characterizes certain applications, like multicast and broadcast 📡. Measuring it usually requires clock synchronization between the two devices in question ⏰.
- Two-way delay (or round-trip delay) doesn't need clock synchronization between the two devices involved in the measurement 🙌, and it's usually sufficient to determine the frame/packet delay being experienced 💖.
(R15a) VPWS OAM MUST support measurement of per-service two-way frame/packet delay between two VPWS-aware devices that support the same VPWS instance within a given OAM domain 🌸.
(R15b) VPWS OAM SHOULD support measurement of per-service one-way frame/packet delay between two VPWS-aware devices that support the same VPWS instance within a given OAM domain 🦋.
8.5. Frame Delay Variation ✨
okay so VPWS can be sensitive to delay variation 🌊 (aka jitter, the wobble in timing) that frames/packets pick up while they're travelling between the VPWS-aware devices. To figure out whether a VPWS is degraded because of that wobble, you NEED to measure frame/packet delay variation 📏. For those measurements, one-way mechanisms are considered good enough 💖
(R16) VPWS OAM MUST support measurement of per-service frame/packet delay variation between two VPWS-aware devices that support the same VPWS instance within a given OAM domain. 🦋
8.6. Availability 🌸
a service can be called unavailable if its frames/packets don't reach where they're supposed to go (like connectivity is down or frames are getting lost 😭), or if the service is just degraded (like the delay or delay variation goes past a threshold). it's giving "not working properly" energy 💀
entry and exit conditions can be defined for the unavailable state, and availability itself can be defined based on the service type 🧚
since availability measurement can be tied to connectivity, frame/packet loss, frame/packet delay, and frame/packet delay variation measurements, no extra requirements are specified for it right now ✨
8.7. Data Path Forwarding 🛣️
if the VPWS OAM frames take a different route than the VPWS frames/packets, you might not get an accurate measurement or read on the service state 🙈 so the data path (the one the VPWS frames/packets actually take) has to be used for the VPWS OAM. no cap, this is important 👑
(R17a) VPWS OAM frames MUST be forwarded along the same path as the VPWS data frames. 💜
(R17b) VPWS OAM MUST be forwarded using the transfer plane (data plane) as regular VPWS data frames/packets and must not rely on control plane messages. 🫶
8.8. Scalability 📈
the mechanisms for VPWS OAM need to be built so per-service OAM can still happen even though OAM might only get used on a limited number of VPWS instances, like a premium VPWS instance, and not on best-effort services 💅
(R18) VPWS OAM MUST be scalable such that a service-aware device can support OAM for each VPWS that is supported by the device. 🔥
8.9. Extensibility 🌈
extensibility is there so new OAM functionality can be added later while backward compatibility still works when talking to older version devices. in that case, VPWS OAM with reduced functionality should still be possible ✨ also, VPWS OAM should be set up so that devices in the middle of the OAM domain that can't do OAM can still forward the VPWS OAM frames just like regular VPWS data frames/packets 🦋
(R19a) VPWS OAM MUST be extensible such that new functionality and information elements related to this functionality can be introduced in the future. 💖
(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 data frames/packets. 🎀
8.10. Security 🔐
okay this one is SERIOUS bestie 😭 VPWS OAM frames that belong to an OAM domain start and end inside that OAM domain. security means an OAM domain has to be able to filter OAM frames 🚫 so VPWS OAM frames can't leak outside their domain. also, VPWS OAM frames coming from outside the OAM domains should either get discarded (if they belong to the same level or a lower-level OAM domain) or passed through transparently (if they belong to a higher-level OAM domain). it's giving fortress energy 🏰
(R20a) VPWS OAM frames MUST be prevented from leaking outside their OAM domain. 🛑
(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 to a lower-level OAM domain. 🚫
(R20c) VPWS OAM frames from outside an OAM domain MUST be transported transparently inside the OAM domain when such OAM frames belong to a higher-level OAM domain. ✨
8.11. Transport Independence 🚀
VPWS frame/packet delivery goes across transport infrastructure, which is also called network infrastructure. transport/network technologies might have their own OAM capabilities, but VPWS OAM still has to be supported on its own, because lots of different transport/network technologies can carry service frames/packets 🧚
(R21a) VPWS OAM MUST be independent of the underlying transport/network technologies and specific transport/network OAM capabilities. 💅
(R21b) VPWS OAM MAY allow adaptation/interworking with specific transport/network OAM functions. for example, this would be useful to allow fault notifications from transport/network layer(s) to be sent to the VPWS layer. 🌸
8.12. Application Independence 🎀
VPWS itself can be used to carry application frames/packets. the application can have its own OAM, but VPWS OAM must not be dependent on application OAM. as an example, a VPWS might carry IP traffic, but VPWS OAM should not assume IP or rely on IP-level OAM functions 🙈
(R22a) OAM MUST be independent of the application technologies and specific application OAM capabilities. 🫶
8.13. Prioritization 🍓
a VPWS could be made of several data flows, each tied to a usage/application with its own connectivity and/or performance needs. dedicated VPWS OAM should be applicable to these flows 💜
(R23) VPWS OAM SHOULD support configurable prioritization for OAM packet/frames to be compatible with associated VPWS packets/frames. 👑
9. VPLS (V)LAN Emulation OAM Requirements 🦋
9.1. Partial-Mesh of PWs 🕸️
as [BRIDGE-INTEROP] points out, VPLS OAM relies on bidirectional Ethernet links or (V)LAN segments, and a failure in one direction or link means the whole link or (V)LAN segment fails 😬 so when a partial-mesh failure happens in (V)LAN emulation, either the entire PW mesh should be shut down (when only a full VPLS is acceptable), or a subset of PWs should be shut down so the remaining PWs still have full connectivity among themselves (when a partial VPLS is acceptable) 💖
(R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow detection of a partial-mesh failure condition. 🔍
(R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the entire mesh of PWs to be shut down upon detection of a partial-mesh failure condition. 🛑
(R13c) PW OAM for PWs related to a (V)LAN emulation MUST allow the subset of PWs to be shut down upon detection of a partial-mesh failure condition in a manner such that full mesh is present across the remaining subset. 🌈
Note: Shutdown action in R13b and R13c may not necessarily involve withdrawal of labels, etc. ⚠️
9.2. PW Fault Recovery 🛠️
as [BRIDGE-INTEROP] says, VPLS OAM fault detection and recovery depends on (V)LAN emulation recovery. the fault detection and recovery time in (V)LAN emulation should be less than the VPLS fault detection and recovery time, so you don't get unnecessary switch-overs and temporary flooding/loops inside the customer OAM domain that's dual-homed to the provider OAM domain 🔁
(R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a fault detection time in the provider OAM domain faster than the VPLS fault detection time in the customer OAM domain. ⚡
(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. ⭐
9.3. Connectivity Fault Notification and Alarm Suppression 🔔
when a connectivity fault is detected in (V)LAN emulation, PE devices may notify the NMS (Network Management System) via alarms. but one (V)LAN emulation fault can cause CE devices or U-PE devices to detect a connectivity fault in VPLS too, so they'd notify the NMS as well 😩 to stop multiple alarms for the same fault, (V)LAN emulation OAM must provide alarm suppression capability in the VPLS OAM 🫶
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support interworking with VPLS OAM to trigger fault notification and allow alarm suppression in the VPLS upon fault detection in (V)LAN emulation. 🎀
10. OAM Operational Scenarios 🗺️
this section shows how the different OAM mechanisms can be applied, following the OAM framework, for different L2VPN services 💖
10.1. VPLS OAM Operational Scenarios 🌐
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
Customer OAM Domain
(C) MEP---MIP--------------------------------MIP---MEP
Service Provider (SP) OAM Domain
(D) MEP--------MIP-----------MIP-------MEP
SP OAM SP OAM SP OAM
(D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
domain domain domain
Operator Operator Operator
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
OAM domain OAM domain OAM domain
MPLS OAM MPLS OAM
(F) MEP--MIP-----MEP--MIP--MEP
domain domain
Figure 10: VPLS OAM Domains, MEPs, and MIPsamong the different MEs identified in Figure 5 for VPLS OAM in the customer OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied to meet the various requirements identified in Section 7. those mechanisms can be applied across the (C) MEs in Figure 10 🧩
similarly, inside the service provider OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied across the (D) MEs in Figure 10 to meet the functional requirements identified in Section 7 💅
it may be noted that in the interim, when [IEEE802.1ag] and [Y.1731] capabilities are not available across the PE devices, the Fault Management option using segment OAM introduced in Section 6.2.3 can be applied, with the limitations cited below 🙈 in this option, the service provider can run segment OAM across the (D1) MEs in Figure 10. the OAM mechanisms across the (D1) MEs in Figure 10 can be non-Ethernet, e.g., Virtual Circuit Connectivity Verification (VCCV), or Bidirectional Forwarding Detection (BFD) when the 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 endpoints. however, such mechanisms do not fully exercise the data plane forwarding constructs as experienced by native (i.e., Ethernet) service PDUs. as a result, service monitoring ((D1) in Figure 10) is severely limited 😩 in the sense that it may lead to an indication that the ME between VPLS endpoints is functional while the customer may be experiencing end-to-end connectivity issues in the data plane 💀
inside the network operator OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can also be applied across the (E) MEs in Figure 10 to meet the functional requirements identified in Section 7. in addition, the network operator could decide to use native OAM mechanisms, e.g., VCCV or BFD, across the (F) MEs for additional monitoring or as an alternative to monitoring across the (E) MEs ✨
11. Security Considerations 🔒✨
Okay bestie, security is serious, so I'm keeping this part fully intact. The big assumption here is that the L2VPN components inside the OAM domain are mutually trusted 🤝. Given that, confidentiality is fully handled by filtering, which stops OAM frames from leaking outside their own OAM domain 🚫. Authentication is handled too, by blocking OAM frames that were generated outside a given OAM domain from getting in. The requirements to stop OAM messages leaking out of an OAM domain, and to make OAM domains transparent to OAM frames from higher OAM domains, are in Sections 7.10 and 8.10. Go check those, they're the receipts 🧾💅.
If you want extra levels of security, you might need to encrypt and/or authenticate OAM frames inside an OAM domain 🔐. Heads up though: those solutions are out of the scope of this document, so they're a whole other story 📖.
12. Contributors 🎀
Besides the authors listed above, these people also helped with this document, and they deserve all the flowers 💐.
Simon Delord Uecomm 658 Church St Richmond, VIC, 3121, Australia EMail: sdelord@uecomm.com.au
Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France EMail: philippe.niger@francetelecom.com
Samer Salam Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: ssalam@cisco.com
13. Acknowledgements 🫶
The authors want to thank Deborah Brungard, Vasile Radoaca, Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their reviews and comments 💖.
The authors also want 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 🌸. Iconic group, no notes.
14. References 📚
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[IEEE802.1ad] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", 2005.
[IEEE802.1ag] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management", 2007.
[IEEE802.1ah] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", 2008.
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and mechanisms for Ethernet based networks", February 2008.
[L2VPN-FRWK] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2VPN-REQ] Augustyn, W., Ed., and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[L2VPN-TERM] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1, 2006.
[NM-Standards] "TMN Management Functions", M.3400, February 2000.
[VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
14.2. Informative References
[BRIDGE-INTEROP] Sajassi, A. Ed., Brockners, F., Mohan, D., Ed., and Y. Serbest, "VPLS Interoperability with CE Bridges", Work in Progress, October 2010.
[L2VPN-SIG] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[MS-PW-Arch] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
Appendix A. Alternate Management Models 🦋
In consideration of the management models that can be deployed besides the hierarchical models elaborated in this document, this appendix 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 equipment is upgraded to support full functionality and meet the requirements set forward by this document. Think of these as temporary bandaids, not the main event 🩹.
A.1. Alternate Model 1 (Minimal OAM)
In this model, the end-to-end service monitoring is provided by 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, as shown in (B) in Figure A.1. The network operators can carry out segment (e.g., PSN Tunnel ME, etc.) monitoring independent of the VPWS end-to-end service monitoring, as shown in (D) in Figure A.1.
The advantage of this option is that VPWS monitoring is limited to CEs. The limitation of this option is that the localization of faults is at the VPWS level. Lowkey a trade-off, but it's giving simple 💅.
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
(B) MEP-----------------------------------------------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A.1: VPWS MEPs and MIPs (Minimal OAM)A.2. Alternate Model 2 (Segment OAM Interworking)
In this model, end-to-end service monitoring is provided by interworking OAM across each segment. Typical segments involved in this case include two AC MEs and a PW ME, as shown in (C) in Figure A.2. 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 MEs, and no MIPs are involved at the service provider OAM level, as shown in (C) in Figure A.2. Network operators may run segment OAM by having MEPs at the network operator OAM level, as shown in (D) in Figure A.2.
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 others. 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. Yikes, the interworking headache is real 😩.
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A.2: VPWS MEPs and MIPs (Segment OAM Interworking)Authors' Addresses 💌
Ali Sajassi (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: sajassi@cisco.com
Dinesh Mohan (editor) Nortel Ottawa, ON K2K3E5 EMail: dinmohan@hotmail.com
That's the whole spec, bestie! 🌈👑 Every requirement, figure, and reference is in place, and that's a wrap on RFC 6136 💖✨
📦 where this page comes from
- ietf: rfc6136 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms