diff options
Diffstat (limited to 'doc/rfc/rfc6136.txt')
| -rw-r--r-- | doc/rfc/rfc6136.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc6136.txt b/doc/rfc/rfc6136.txt new file mode 100644 index 0000000..89f891a --- /dev/null +++ b/doc/rfc/rfc6136.txt @@ -0,0 +1,2355 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Sajassi, Ed. +Request for Comments: 6136 Cisco +Category: Informational D. Mohan, Ed. +ISSN: 2070-1721 Nortel + March 2011 + + + Layer 2 Virtual Private Network (L2VPN) + Operations, Administration, and Maintenance (OAM) + Requirements and Framework + +Abstract + + This document provides framework and requirements for Layer 2 Virtual + Private Network (L2VPN) Operations, Administration, and Maintenance + (OAM). The OAM framework is intended to provide OAM layering across + L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) + tunnels. This document is intended to identify OAM requirements for + L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual + Private Wire Service (VPWS), and IP-only LAN Service (IPLS). + Furthermore, if L2VPN service OAM requirements impose specific + requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN + OAM requirements are also identified. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6136. + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 1] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 2] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +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 + + + + +Sajassi & Mohan Informational [Page 3] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + 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) .................41 + +1. Introduction + + This document provides framework and requirements for Layer 2 Virtual + Private Network (L2VPN) Operation, Administration, and Maintenance + (OAM). + + The scope of OAM for any service and/or transport/network + infrastructure technologies can be very broad in nature. OSI has + defined the following five generic functional areas commonly + abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b) + Configuration Management, c) Accounting Management, d) Performance + Management, and e) Security Management. + + + + +Sajassi & Mohan Informational [Page 4] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + This document focuses on the Fault and Performance Management + aspects. Other functional aspects of FCAPS are for further study. + + Fault Management can typically be viewed in terms of the following + categories: + + - Fault Detection + + - Fault Verification + + - Fault Isolation + + - Fault Notification and Alarm Suppression + + - Fault Recovery + + Fault detection deals with mechanism(s) that can detect both hard + failures, such as link and device failures, and soft failures, such + as software failure, memory corruption, misconfiguration, etc. + Typically, a lightweight protocol is desirable to detect the fault + and thus it would be prudent to verify the fault via a 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. A fault notification mechanism can be + used in conjunction with a 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 the server layer to + the client layer network(s) using the fault notification format + appropriate to the client layer + + - Sending a backward fault notification at the server layer, if + applicable, in the reverse direction + + - Sending a backward fault notification at the client layer, if + applicable, in the reverse direction + + Finally, fault recovery deals with recovering from the detected + failure by switching to an alternate available data path using + alternate devices or links (e.g., device redundancy or link + redundancy). + + + + + +Sajassi & Mohan Informational [Page 5] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + Performance Management deals with mechanism(s) that allow determining + and measuring the performance of the network/services under + consideration. Performance Management can be used to verify the + compliance to both the service-level 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. + + [L2VPN-FRWK] specifies three different types of Layer 2 VPN services: + Virtual Private LAN Service (VPLS), (Virtual Private Wire Service + (VPWS), and IP-only LAN Service (IPLS). + + This document provides a reference model for OAM as it relates to + L2VPN services and their associated pseudowires (PWs) and Public + Switched Network (PSN) tunnels. OAM requirements for L2VPN services + (e.g., VPLS and VPWS) are also identified. Furthermore, if L2VPN + service OAM requirements impose requirements for PW and/or PSN OAM, + those specific PW and/or PSN OAM requirements are also identified. + +1.1. Specification of Requirements + + 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 [RFC2119]. + +1.2. Relationship with Other OAM Work + + This document leverages protocols, mechanisms, and concepts defined + as part of other OAM work, specifically the following: + + - IEEE Std. 802.1ag-2007 [IEEE802.1ag] specifies the Ethernet + Connectivity Fault Management protocol, which defines the + concepts of Maintenance Domains, Maintenance End Points, and + Maintenance Intermediate Points. This standard also defines + mechanisms and procedures for proactive fault detection + (Continuity Check), fault notification (Remote Defect + Indication (RDI)), fault verification (Loopback), and fault + isolation (LinkTrace) in Ethernet networks. + + - 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. + + + + +Sajassi & Mohan Informational [Page 6] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +2. Terminology + + This document introduces and uses the following terms. This document + also uses the terms defined in [L2VPN-FRWK] and [L2VPN-TERM]. + + AIS Alarm Indication Signal + + 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 Service + +3. L2VPN Services and Networks + + Figure 1 shows an L2VPN reference model as described in [L2VPN-REQ]. + L2VPN A represents a point-to-point service while L2VPN B represents + a bridged service. + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 7] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + +-----+ +-----+ + + CE1 +--+ +--| CE2 | + +-----+ | ..................... | +-----+ + L2VPN A | +----+ +----+ | L2VPN A + +--| PE |-- Service --| PE |--+ + +----+ Provider +----+ + / . Backbone . \ --------_ + +-----+ / . | . \ / \ +-----+ + + CE4 +--+ . | . +-\ Access \--| CE5 | + +-----+ . +----+ . | Network | +-----+ + L2VPN B ........| PE |....... \ / L2VPN B + +----+ ^ ------- + | | logical + | | switching + +-----+ | instance + | CE3 | + +-----+ + L2VPN B + + Figure 1: L2VPN Reference Model + + [L2VPN-FRWK] specifies VPWS, VPLS, and IPLS. VPWS is a point-to- + point service where Customer Edges (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 were + connected via a bridged LAN. IPLS is a special VPLS that is used to + carry only IP service packets. + + [L2VPN-REQ] assumes the availability of runtime monitoring protocols + while defining requirements for management interfaces. This document + specifies the requirements and framework for operations, + administration, and maintenance (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) 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 + + + +Sajassi & Mohan Informational [Page 8] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + service provider can be part of the same administrative organization, + or they can belong to different administrative organizations. + + The different layers involved in realizing L2VPNs include service + layers and network layers. Network layers can be iterative. In the + context of L2VPNs, the service layer consists of VPLS, VPWS (e.g., + Ethernet, ATM, FR, HDLC, SONET, point-to-point emulation, etc.), and + IPLS. Similarly, in the 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. + +4.2. OAM Domains + + When discussing OAM tools for L2VPNs, it is important to provide OAM + capabilities and functionality over each domain for which a service + provider or a network operator is responsible. It is also important + that OAM frames not be allowed to enter/exit other domains. We + define an OAM domain as a network region over which OAM frames + operate unobstructed, as explained below. + + At the edge of an OAM domain, filtering constructs should prevent OAM + frames from exiting and entering that domain. OAM domains can be + nested but not overlapped. In other words, if there is a hierarchy + of the OAM domains, the OAM 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. + + In order to facilitate the processing of OAM frames, each OAM domain + can be associated with the 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. + + A PE can be part of several OAM domains, with each interface + belonging to the same or a different OAM domain. 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 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. + + Generically, L2VPNs can be viewed as consisting of a customer OAM + domain, a service provider OAM domain, and network operator OAM + domains as depicted in Figure 2. + + + +Sajassi & Mohan Informational [Page 9] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + --- --- + / \ ------ ------- ----- / \ + | 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 Domains + + The OAM Domains can be categorized as follows: + + - Hierarchical OAM Domains: Hierarchical OAM Domains 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: Adjacent OAM Domains are typically + independent of each other and do not have any relationship + among them. In Figure 2, the different operator OAM domains + are independent of each other. + +4.3. MEPs and MIPs + + Maintenance End Points (MEPs) are responsible for origination and + 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 Group + (MEG), where a MEG consists of a set of Maintenance Entities (MEs) + + + +Sajassi & Mohan Informational [Page 10] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + associated with the same service instance. An ME is a point-to-point + association between a pair of MEPs and 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 (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 + correspond to a MIP or a MEP of a higher-level OAM domain. + Furthermore, the MIPs of a lower-level OAM domain are always + 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, the VPWS ME in the customer OAM domain can + overlap with the Attachment Circuit (AC) ME, PW ME, and another AC ME + in service provider OAM domain. Similarly, the PW ME can overlap + with different ME in operator OAM domains. + +4.4. MEP and MIP Identifiers + + As mentioned previously, OAM at each layer should be independent of + other layers, e.g., a service layer OAM should be independent of an + underlying transport layer. MEPs and MIPs at each layer should be + identified with layer-specific identifiers. + +5. OAM Framework for VPLS + + Virtual Private LAN Service (VPLS) is 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. + +5.1. VPLS as Service/Network + +5.1.1. VPLS as Bridged LAN Service + + The most common definition for VPLS is for bridged LAN service over + an MPLS/IP network. The service coverage is considered end-to-end + from UNI to UNI (or AC to AC) among the CE devices, and it provides a + virtual LAN service to the attached CEs belonging to that service + instance. The reason it is called bridged LAN service is because the + VPLS-capable PE providing this end-to-end virtual LAN service is + + + +Sajassi & Mohan Informational [Page 11] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + performing bridging functions (either full or a subset) as described + in [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN-REQ], + includes both bridge module and 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 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. Therefore, when a part of the service + provider network is Ethernet based (such as H-VPLS with QinQ access + network), there is a one-to-one correspondence between a VPLS + instance and its corresponding provider VLAN in the service provider + Ethernet network. To check the end-to-end service integrity, the OAM + mechanism needs to cover the end-to-end VPLS as defined in + [L2VPN-REQ], which is from AC to AC, including bridge module, VPLS + forwarder, and the associated PWs for this service. This document + specifies the framework and requirements for such OAM mechanisms. + +5.1.2. VPLS as a Network + + Sometimes VPLS is also used to refer to the underlying network that + 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 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, distributed topology, 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 document. + +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 a 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 their associated full mesh of + + + + + +Sajassi & Mohan Informational [Page 12] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + PWs and 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 the OAM mechanisms for VPLS, it is important to + consider that the end-to-end service can span across 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 a [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 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 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, i.e., the transparency + of OAM mechanisms must be ensured over underlying transport + technologies such as MPLS, IP, etc. + + This proposal is aligned with the discussions in other standard + bodies and groups such as ITU-T Q.5/13, IEEE 802.1, and Metro + Ethernet Forum (MEF), which address Ethernet network and service OAM. + +5.2.1. VPLS OAM Layering + + Figure 3 shows an example of a VPLS (with two CEs 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. The service provider + network is segmented into a core network and two types of access + networks. In 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. In Figure 3, + (B) shows the service/network view at the Ethernet MAC layer marked + by E. + + + + + + + + + +Sajassi & Mohan Informational [Page 13] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + --- --- + / \ ------ ------- ---- / \ + | 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 View + + As shown in (B) of Figure 3, only the devices with Ethernet + functionality are visible to OAM mechanisms operating at the Ethernet + MAC layer, and the P devices are invisible. Therefore, the OAM along + the path of P devices (e.g., between two PEs) is covered by the + transport layer, and it is outside the scope of this document. + + However, VPLSs may impose some specific requirements on PSN OAM. + This document aims to identify such requirements. + +5.2.2. VPLS OAM Domains + + As described in the previous section, a VPLS for a given customer can + span across one or more service providers and network operators. + Figure 4 depicts three OAM domains: (A) customer domain, which is + among the CEs of a given customer, (B) service provider domain, which + is among the edge PEs of the given service provider, and (C) network + operator domain, which is among the PEs of a given operator. + + + + + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 14] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + --- --- + / \ ------ ------- ---- / \ + | 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 Domains + +5.2.3. VPLS MEPs and MIPs + + As shown in Figure 5, (C) represents those MEPs and MIPs that are + visible within the customer domain. The MIPs associated with (C) are + expected to be implemented in the bridge module/VPLS forwarder of a + PE device, as per [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 [L2VPN-FRWK]. (E) represents the MEPs and MIPs + visible within each operator domain, where MIPs only exist in an + Ethernet access network (i.e., an MPLS access network does not 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; + specific OAM mechanisms are outside the scope of this document. + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 15] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + --- --- + / \ ------ ------- ---- / \ + | 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 MIPs + +5.2.4. VPLS MEP and MIP Identifiers + + In VPLS, for the Ethernet MAC layer, the MEPs and MIPs should be + identified with their Ethernet MAC addresses and Maintenance Entity + Group Identifier (MEG ID). As described in [VPLS-LDP], a VPLS + instance can be identified in an Ethernet domain (e.g., 802.1ad + domain) using a 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 + frames, and the source MAC address of the OAM frames represent 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. + + + +Sajassi & Mohan Informational [Page 16] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +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. + VPWS is realized by combining a pair of Attachment Circuits (ACs) and + a single PW between two PEs. + + |<------------- VPWS1 <AC11,PW1,AC12> ------------>| + | | + | +----+ +----+ | + +----+ | |==================| | +----+ + | |---AC11---| |.......PW1........| |--AC12----| | + | CE1| |PE1 | | PE2| |CE2 | + | |---AC21---| |.......PW2........| |--AC22----| | + +----+ | |==================| | +----+ + | +----+ PSN Tunnel +----+ | + | | + |<------------- VPWS2 <AC21,PW2,AC22> ------------>| + + Figure 6: VPWS Reference Model + +6.1. VPWS as Service + + VPWS can be categorized as follows: + + - VPWS with homogeneous ACs (where both ACs are same type) + + - VPWS with heterogeneous ACs (where the ACs are of different + Layer-2 encapsulation) + + Further, the VPWS can itself be classified as follows: + + - Homogeneous VPWS (when two ACs and PW are of the same type) + + - Heterogeneous VPWS (when at least one AC or PW is a different + type than the others) + + Based on the above classifications, the heterogeneous VPWS may have + either homogeneous or heterogeneous ACs. On the other hand, + homogeneous VPWS can have only homogeneous ACs. + + Throughout this document, whenever the term "VPWS" is used by itself, + it refers to the service. + + + + + + + + +Sajassi & Mohan Informational [Page 17] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +6.2. VPWS OAM + + 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 the CE and PE + on one side can be an Ethernet-bridged network, an ATM network, etc. + In common scenarios, it could simply be a point-to-point interface + such as Ethernet Physical Layer (PHY). The core network connecting + PEs can be IP, MPLS, etc. + + 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 multiple such networks may be associated with a single + administrative domain. + +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 considered to be segmented into a + core network and two types of access networks. + + In the most general case, a PE can be client service aware when it + processes client service PDUs and is responsible for encapsulating + 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 (A) in Figure 7, + 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 + not process native service PDUs but instead encapsulates access + technology PDUs over PWs. This may be relevant for VPWS with + heterogeneous ACs, such as Ethernet VPWS, which is offered across an + ATM AC, ATM PW, and Ethernet AC. In this case, the PE that is + attached to ATM AC and ATM PW may be transparent to the client + Ethernet service PDUs. On the other hand, the PE that 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 (B) in Figure 7, 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. + + + + + + + + +Sajassi & Mohan Informational [Page 18] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + |<--------------- 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 View + +6.2.2. VPWS OAM Domains + + As described in the previous section, a VPWS for a given customer can + span across one or more network operators. + + Figures 8a and 8b depict three OAM domains: (A) customer domain, + which is among the CEs of a given customer, (B) service provider + domain, which depends on the management model, and (C) network + operator domain, which is among the PEs of a given operator and could + also be present in the access network if the ACs are provided by a + different network operator. The core network operator may be + responsible for managing the PSN Tunnel in these examples. + + For the first management model, 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 + monitoring of the AC is the shared responsibility of the customer and + the service provider. In most simple cases, when the AC is realized + across a physical interface that connects the CE to PE, the + monitoring requirements across the AC ME are minimal. + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 19] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + |<--------------- 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 1 + + Figure 8b highlights another management model, where the CEs are + managed by the service provider and where CEs and PEs are connected + via an access network. The access network between the CEs and PEs + may or may not be provided by a distinct network operator. In this + model, the VPWS ME spans between the CEs in the service provider OAM + domain, as shown by (B) in Figure 8b. The service provider OAM + domain may additionally monitor the AC MEs and PW MEs individually, + as shown by (C) in Figure 8b. The network operators may be + responsible for managing the access service MEs (e.g., access + tunnels) and core PSN Tunnel MEs, as shown by (D) in Figure 8b. The + distinction between (C) and (D) in Figure 8b 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; furthermore, MIPs may be present in between the + MEPs, thereby providing visibility of the network to the operator. + + + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 20] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + |<--------------- 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 2 + + Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where + multiple operator domains may occur between the User-facing PE (U-PE) + devices, VPWS OAM domain in Figures 8a and 8b highlights a single + operator domain between PE devices. This is since, unlike the + distributed VPLS PE case (D-VPLS), where VPLS-aware U-PEs and + Network-facing PEs (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 switched PEs + are typically not aware of native service. + +6.2.3. VPWS MEPs and MIPs + + The location of MEPs and MIPs can be based upon the management model + used in the VPWS scenarios. The interest remains in being able to + monitor end-to-end service and also support segment monitoring in the + network to allow isolation of faults to specific areas within the + network. + + + + + + + + +Sajassi & Mohan Informational [Page 21] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + The end-to-end service monitoring is provided by an 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 in Section 4.2 for + hierarchical OAM domains. This is shown in (B) and (C) in Figure 8b. + + The CE interfaces support MEPs at the end-to-end service provider OAM + level for VPWS as an end-to-end service as shown in (B1) and (B2) in + Figure 9. In addition, PE interfaces may support MIPs at the end-to- + end service provider OAM level when PEs are client service aware, as + shown in (B2) in Figure 9. As an example, if one considers an end- + to-end Ethernet line service offered using ATM transport (ATM over + MPLS PW), then the PEs are considered to be Ethernet service unaware + and therefore cannot support any Ethernet MIPs. (B1) in Figure 9 + 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. (B2) + in Figure 9 represents this particular situation. + + 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 (C) + in Figure 9. Operators may also run segment OAM by having MEPs at + network operator OAM level, as shown in (D) in Figure 9. + + The advantage of having layered OAM is that end-to-end and segment + OAM can be carried out in an independent manner. It is also possible + 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 + 9, not all may be realized. For example, (B2) and (D) in Figure 9 + may be adequate in some cases. + + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 22] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + |<--------------- 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 MIPs + +6.2.4. VPWS MEP and MIP Identifiers + + In VPWS, the MEPs and MIPs should be identified with their native + addressing schemes. MEPs and MIPs Identifiers, i.e., MEP Ids and MIP + Ids, must be unique to the VPWS instance and in the context of their + corresponding OAM domains. + +7. VPLS OAM Requirements + + These requirements are applicable to VPLS PE offering VPLS as an + Ethernet Bridged LAN service, as described in Section 5.1.1. + Further, the performance metrics used in requirements are based on + [MEF10.1] and [RFC2544]. + + 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, they 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. + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 23] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +7.1. Discovery + + Discovery allows a VPLS-aware device to learn about other devices + that support the same VPLS instance within a given domain. + + Discovery also allows a VPLS-aware device to learn sufficient + information (e.g., IP addresses, MAC addresses, etc.) from other + VPLS-aware devices such 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 is realized by exchanging service frames/packets between devices + that support the same VPLS instance. To allow the exchange of + service frames, connectivity between these service-aware devices is + required. + +7.2.1. Connectivity Fault Detection + + To ensure service, proactive connectivity monitoring is required. + Connectivity monitoring facilitates connectivity fault detection. + + (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 + + Further, localization of 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. + + + + + +Sajassi & Mohan Informational [Page 24] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +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. + + However, a single transport/network fault may cause multiple services + to fail simultaneously, thereby 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. + + (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 are + lost during transit between the VPLS-aware devices. To determine if + a VPLS 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 + loss between two VPLS-aware devices that support the same VPLS + instance within a given OAM domain. + +7.4. Frame Delay + + A VPLS may be sensitive to delay experienced by the VPLS + frames/packets during transit between the VPLS-aware devices. To + determine if a VPLS is degraded due to frame/packet delay, + measurement of frame/packet delay is required. + + VPLS frame/packet delay measurement can be of two types: + + 1) 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 the two + devices in question. + + 2) Two-way delay or round-trip delay does not require clock + synchronization between the two devices involved in measurement + and is usually sufficient to determine the frame/packet delay + being experienced. + + + + + +Sajassi & Mohan Informational [Page 25] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + (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 may be sensitive to delay variation experienced by the VPLS + frames/packets during transit between the VPLS-aware devices. To + determine if a VPLS is degraded due to frame/packet delay variation, + measurement of frame/packet delay variation is required. For + frame/packet delay variation measurements, one-way mechanisms are + considered to be sufficient. + + (R5) 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 be considered unavailable if the service frames/packets + do not reach their intended destination (e.g., connectivity is down + or frame/packet loss is occurring) or the service is degraded (e.g., + frame/packet delay and/or delay variation threshold is exceeded). + + Entry and exit conditions may be defined for unavailable state. + Availability itself may be defined in context of service type. + + Since availability measurement may be associated with connectivity, + frame/packet loss, frame/packet delay, and frame/packet delay + variation measurements, no additional requirements are specified + currently. + +7.7. Data Path Forwarding + + If the VPLS OAM frames flow across a different path than the one used + by VPLS frames/packets, accurate measurement and/or determination of + service state may not be made. Therefore, data path, i.e., the one + being taken by VPLS frames/packets, must be used for the VPLS OAM. + + (R6) VPLS OAM frames MUST be forwarded along the same path (i.e., + links and nodes) as the VPLS frames. + + + + + + +Sajassi & Mohan Informational [Page 26] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +7.8. Scalability + + 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 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 is supported by the device. + +7.9. Extensibility + + Extensibility is intended to allow introduction of additional OAM + functionality in the future such that backward compatibility can be + maintained when interoperating with older version devices. In such a + case, VPLS OAM with reduced functionality should still be possible. + Further, VPLS 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 data frames/packets. + + (R8a) VPLS OAM MUST be extensible such that new functionality and + information elements related to this 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 belonging to an OAM domain originate and terminate + within that OAM domain. Security implies that an OAM domain must be + capable of filtering OAM frames. The filtering is such that the OAM + frames are prevented from leaking outside their domain. Also, OAM + frames from outside the OAM domains should be either discarded (when + such OAM frames belong to the same level or to a 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 + 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. + + + + + + +Sajassi & Mohan Informational [Page 27] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + (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/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. + + (R10a) VPLS OAM MUST be independent of the underlying + transport/network technologies and 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 allow fault notifications from transport/network layer(s) to be + sent to the VPLS layer. + +7.12. Application Independence + + VPLS itself may be used to carry application frame/packets. The + application may use its own OAM; service OAM must not be dependent on + application OAM. As an example, a VPLS may be used to carry IP + traffic; however, VPLS OAM should not assume IP or rely on the use of + IP-level OAM functions. + + (R11a) VPLS OAM MUST be independent of the application technologies + and specific application OAM capabilities. + +8. VPWS OAM Requirements + + These requirements are applicable to VPWS PE. The performance + metrics used in requirements are based on [MEF10.1] and [RFC2544], + which are applicable to Ethernet services. + + 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, they 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. + + + + + + +Sajassi & Mohan Informational [Page 28] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +8.1. Discovery + + Discovery allows a VPWS-aware device to learn about other devices + that support the same VPWS instance within a given domain. Discovery + also allows a VPWS-aware device to learn sufficient information + (e.g., IP addresses, MAC addresses, etc.) from other VPWS-aware + devices such that OAM frames can be exchanged among the VPWS-aware + devices. + + (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 is realized by exchanging service frames/packets between devices + that support the same VPWS instance. To allow the exchange of + service frames, connectivity between these service-aware devices is + required. + +8.2.1. Connectivity Fault Detection + + To ensure service, proactive connectivity monitoring is required. + Connectivity monitoring facilitates connectivity fault detection. + + (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, localization of connectivity fault may be carried out. This + may amount to identifying the specific AC and/or PW that is resulting + in the VPWS connectivity fault. + + + + + +Sajassi & Mohan Informational [Page 29] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + (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. + + However, a single transport/network fault may cause multiple services + to fail simultaneously causing multiple service alarms. 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. + + For example, if an AC fails, both the local CE and the local PE, + which are connected via the 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 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 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 are + lost during transit between the VPWS-aware devices. To determine if + a VPWS is degraded due to frame/packet loss, measurement of + frame/packet loss is required. + + (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 may be sensitive to delay experienced by the VPWS + frames/packets during transit between the VPWS-aware devices. To + determine if a VPWS is degraded due to frame/packet delay, + measurement of frame/packet delay is required. + + + +Sajassi & Mohan Informational [Page 30] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + VPWS frame/packet delay measurement can be of two types: + + 1) 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 the two + devices in question. + + 2) Two-way delay or round-trip delay does not require clock + synchronization between the 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 + 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 + + A VPWS may be sensitive to delay variation experienced by the VPWS + frames/packets during transit between the VPWS-aware devices. To + determine if a VPWS 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 + delay variation between two VPWS-aware devices that support the same + VPWS instance within a given OAM domain. + +8.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). + + Entry and exit conditions may be defined for unavailable state. + Availability itself may be defined in context of service type. + + Since availability measurement may be associated with connectivity, + frame/packet loss, frame/packet delay, and frame/packet delay + variation measurements, no additional requirements are specified + currently. + + + + +Sajassi & Mohan Informational [Page 31] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +8.7. Data Path Forwarding + + If the VPWS OAM frames flow across a different path than the one used + by VPWS 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 frames/packets, must be used for the VPWS OAM. + + (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 + + 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 instances, e.g., premium VPWS instance, and may not be used for + 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 intended to allow introduction of additional OAM + functionality in the future such that backward compatibility can be + maintained when interoperating with older version devices. In such a + case, VPWS OAM with reduced functionality should still be possible. + Further, VPWS 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 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 + + VPWS OAM frames belonging to an OAM domain originate and terminate + within that OAM domain. Security implies that an OAM domain must be + capable of filtering OAM frames. The filtering is such that the VPWS + OAM frames are prevented from leaking outside their domain. Also, + + + +Sajassi & Mohan Informational [Page 32] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + VPWS OAM frames from outside the OAM domains should be either + discarded (when such OAM frames belong to the same level or to a + 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 + 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/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. + + (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 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 may be used to 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 + specific application OAM capabilities. + + + + + + + +Sajassi & Mohan Informational [Page 33] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +8.13. Prioritization + + VPWS could be composed of several data flows, each related to a given + usage/application with specific requirements in terms of connectivity + and/or performance. 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 indicated in [BRIDGE-INTEROP], VPLS OAM relies upon bidirectional + Ethernet links or (V)LAN segments and failure in one 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 shut down when only an entire + VPLS is acceptable or a subset of PWs should be shut down such that + the remaining PWs have full connectivity among them when 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 indicated in [BRIDGE-INTEROP], VPLS 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 fault detection and recovery time to prevent unnecessary + switch-over and temporary flooding/loop within the customer OAM + domain that is dual-homed to the provider OAM domain. + + + + + +Sajassi & Mohan Informational [Page 34] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + (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. However, + a single (V)LAN emulation fault may result in CE devices or U-PE + devices detecting a connectivity fault in VPLS 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 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 highlights how the different OAM mechanisms can be + applied as per the OAM framework for different L2VPN services. + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 35] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +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 MIPs + + Among the different MEs identified in Figure 5 for VPLS OAM in the + customer OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM + mechanisms can be applied to meet the various requirements identified + in Section 7. The mechanisms can be applied across (C) in Figure 10 + MEs. + + Similarly, inside the service provider OAM domain, [IEEE802.1ag] and + [Y.1731] Ethernet OAM mechanisms can be applied across (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 + + + +Sajassi & Mohan Informational [Page 36] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + 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 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 MEs in (E) 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 (F) MEs for additional + monitoring or as an alternative to monitoring across (E) MEs. + +11. Security Considerations + + This specification assumes that L2VPN components within the OAM + domain are mutually trusted. Based on that assumption, + confidentiality issues are fully addressed by filtering to prevent + OAM frames from leaking outside their designated OAM domain. + Similarly, authentication issues are addressed by preventing OAM + frames generated outside a given OAM domain from entering the domain + in question. Requirements to prevent OAM messages from leaking + outside an OAM domain and for OAM domains to be transparent to OAM + frames from higher OAM domains are specified in Sections 7.10 and + 8.10. + + For additional levels of security, solutions may be required to + encrypt and/or authenticate OAM frames inside an OAM domain. + However, these solutions are out of the scope of this document. + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 37] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +12. Contributors + + In addition to the authors listed above, the following individuals + also contributed to this document. + + 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 would like to thank Deborah Brungard, Vasile Radoaca, Lei + Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their + reviews and comments. + + The 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. + +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. + + + +Sajassi & Mohan Informational [Page 38] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + [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. + + + + +Sajassi & Mohan Informational [Page 39] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking + Methodology for Network Interconnect Devices", RFC + 2544, March 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi & Mohan Informational [Page 40] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + +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. + +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. + + |<--------------- 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 + + + +Sajassi & Mohan Informational [Page 41] + +RFC 6136 L2VPN OAM Requirements and Framework March 2011 + + + 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. + + |<--------------- 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 + + + + +Sajassi & Mohan Informational [Page 42] + |