idnits 2.17.1 draft-ietf-l2vpn-oam-req-frmk-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-l2vpn-vpls-bridge-interop-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft A. Sajassi (Editor) 3 L2VPN Working Group Cisco 4 Category: Informational 5 D. Mohan (Editor) 7 Expires: April 24, 2011 October 24, 2010 9 L2VPN OAM Requirements and Framework 10 draft-ietf-l2vpn-oam-req-frmk-11.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright and License Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Abstract 62 This draft provides framework and requirements for Layer 2 Virtual 63 Private Networks (L2VPN) Operation, Administration and Maintenance 64 (OAM). The OAM framework is intended to provide OAM layering across 65 L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) 66 tunnels. The requirements are intended to identify OAM requirement 67 for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if 68 L2VPN services OAM requirements impose specific requirements on PW 69 OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements 70 are also identified. 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119. 78 When these key words are used in consideration of RFC 2119, these 79 key words are used in capitalized form as indicated above. 81 Table of Contents 83 Conventions used in this document.................................. 2 84 1. Introduction.................................................... 4 85 1.1 Relationship with Other OAM Work............................... 5 86 1.2 Terminology.................................................... 6 87 2. L2VPN Services & Networks....................................... 6 88 3. L2VPN OAM Framework............................................. 7 89 3.1. OAM Layering.................................................. 7 90 3.2. OAM Domains................................................... 8 91 3.3. MEPs and MIPs................................................. 9 92 3.4. MEP and MIP Identifiers...................................... 10 93 4. OAM Framework for VPLS......................................... 10 94 4.1. VPLS as Service/Network...................................... 10 95 4.1.1. VPLS as Bridged LAN Service................................ 10 96 4.1.2. VPLS as a Network.......................................... 11 97 4.1.3. VPLS as (V)LAN Emulation................................... 11 98 4.2. VPLS OAM..................................................... 11 99 4.2.1. VPLS OAM Layering.......................................... 12 100 4.2.2. VPLS OAM Domains........................................... 13 101 4.2.3. VPLS MEPs & MIPs........................................... 13 102 4.2.4. VPLS MEP and MIP Identifiers............................... 14 103 5. OAM Framework for VPWS......................................... 14 104 5.1. VPWS as Service.............................................. 15 105 5.2. VPWS OAM..................................................... 15 106 5.2.1. VPWS OAM Layering.......................................... 16 107 5.2.2. VPWS OAM Domains........................................... 16 108 5.2.3. VPWS MEPs & MIPs........................................... 18 109 5.2.4. VPWS MEP and MIP Identifiers............................... 20 110 6. VPLS Service OAM Requirements.................................. 20 111 6.1. Discovery.................................................... 20 112 6.2. Connectivity Fault Management................................ 20 113 6.2.1. Connectivity Fault Detection............................... 21 114 6.2.2. Connectivity Fault Verification............................ 21 115 6.2.3. Connectivity Fault Localization............................ 21 116 6.2.4. Connectivity Fault Notification and Alarm Suppression...... 21 117 6.3. Frame Loss................................................... 21 118 6.4. Frame Delay.................................................. 22 119 6.5. Frame Delay Variation........................................ 22 120 6.6. Availability................................................. 22 121 6.7. Data Path Forwarding......................................... 23 122 6.8. Scalability.................................................. 23 123 6.9. Extensibility................................................ 23 124 6.10. Security.................................................... 24 125 6.11. Transport Independence...................................... 24 126 6.12. Application Independence.................................... 24 127 7. VPWS OAM Requirements.......................................... 25 128 7.1. Discovery.................................................... 25 129 7.2. Connectivity Fault Management................................ 25 130 7.2.1. Connectivity Fault Detection............................... 25 131 7.2.2. Connectivity Fault Verification............................ 26 132 7.2.3. Connectivity Fault Localization............................ 26 133 7.2.4. Connectivity Fault Notification and Alarm Suppression...... 26 134 7.3. Frame Loss................................................... 27 135 7.4. Frame Delay.................................................. 27 136 7.5. Frame Delay Variation........................................ 27 137 7.6. Availability................................................. 28 138 7.7. Data Path Forwarding......................................... 28 139 7.8. Scalability.................................................. 28 140 7.9. Extensibility................................................ 28 141 7.10. Security.................................................... 29 142 7.11. Transport Independence...................................... 29 143 7.12. Application Independence.................................... 30 144 7.13. Prioritization.............................................. 30 145 8. VPLS (V)LAN Emulation OAM Requirements......................... 30 146 8.1. Partial-mesh of PWs.......................................... 30 147 8.2. PW Fault Recovery............................................ 31 148 8.3. Connectivity Fault Notification and Alarm Suppression........ 31 149 9. OAM Operational Scenarios...................................... 31 150 9.1. VPLS OAM Operational Scenarios............................... 31 151 10. Acknowledgments............................................... 33 152 12. IANA Considerations........................................... 33 153 11. Security Considerations....................................... 33 154 13. References.................................................... 33 155 13.1 Normative References......................................... 33 156 13.2 Informative References....................................... 34 157 A1. Appendix 1 - Alternate Management Models...................... 34 158 A1.1. Alternate Model 1 (Minimal OAM)............................. 34 159 A1.2. Alternate Model 2 (Segment OAM Interworking)................ 35 160 Authors' Addresses................................................ 36 162 1. Introduction 164 This draft provides framework and requirements for Layer 2 Virtual 165 Private Networks (L2VPN) Operation, Administration and Maintenance 166 (OAM). 168 The scope of OAM for any service and/or transport/network 169 infrastructure technologies can be very broad in nature. OSI has 170 defined the following five generic functional areas commonly 171 abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b) 172 Performance Management, c) Configuration Management, d) Accounting 173 Management, and e) Security Management. 175 This draft focuses on the Fault and Performance Management aspects. 176 Other functional aspects of FCAPS are for further study. 178 Fault Management can typically be viewed in terms of the following 179 categories: 180 - Fault Detection 181 - Fault Verification 182 - Fault Isolation 183 - Fault Notification & Alarm Suppression 184 - Fault Recovery 186 Fault Detection deals with mechanism(s) that can detect both hard 187 failures, such as link and device failures, and soft failures, such 188 as software failure, memory corruption, mis-configuration, etc. 189 Typically a lightweight protocol is desirable to detect the fault 190 and thus it would be prudent to verify the fault via Fault 191 Verification mechanism before taking additional steps in isolating 192 the fault. After verifying that a fault has occurred along the data 193 path, it is important to be able to isolate the fault to the level 194 of a given device or link. Therefore, a Fault Isolation mechanism is 195 needed in Fault Management. Fault Notification mechanism can be used 196 in conjunction with Fault Detection mechanism to notify the devices 197 upstream and downstream to the fault detection point. For example, 198 when there is a client/server relationship between two layered 199 networks, Fault Detection at the server layer may result in the 200 following Fault Notifications: 201 - sending a forward Fault Notification from server layer to the 202 client layer network(s) using the Fault Notification format 203 appropriate to the client layer 204 - sending a backward Fault Notification at server layer, if 205 applicable, in the reverse direction 206 - sending a backward Fault Notification at client layer, if 207 applicable, in the reverse direction 209 Finally, Fault Recovery deals with recovering from the detected 210 failure by switching to an alternate available data path using 211 alternate devices or links (e.g., device redundancy or link 212 redundancy). 214 Performance Management deals with mechanism(s) that allow 215 determining and measuring the performance of network/services under 216 consideration. Performance Management can be used to verify the 217 compliance to both the service and network level metric 218 objectives/specifications. Performance Management typically consists 219 of measurement of performance metrics e.g. Frame Loss, Frame Delay, 220 Frame Delay Variation (aka Jitter) etc. across managed entities when 221 the managed entities are in available state. Performance Management 222 is suspended across unavailable managed entities. 224 [L2VPN-FRWK] specifies three different types of Layer 2 VPN 225 services. These are VPWS, VPLS and IPLS. 227 This document provides a reference model for OAM as it relates to 228 L2VPN services and their associated Pseudo Wires (PWs) and Public 229 Switched Network (PSN) tunnels. OAM requirement for L2VPN services 230 (e.g. VPLS and VPWS) are also identified. Furthermore, if L2VPN 231 services OAM requirements impose requirements for PW and/or PSN OAM, 232 those specific PW and/or PSN OAM requirements are also identified. 234 1.1 Relationship with Other OAM Work 236 This document leverages protocols, mechanisms and concepts defined 237 as part of other OAM work. More specifically: 239 IEEE Std. 802.1ag-2007 [IEEE 802.1ag] specifies the Ethernet 240 Connectivity Fault Management protocol, which defines the concepts 241 of Maintenance Domains, Maintenance End-Points and Maintenance 242 Intermediate Points. This standard also defines mechanisms and 243 procedures for proactive fault detection (Continuity Check), fault 244 notification (Remote Defect Indication - RDI), fault verification 245 (Loopback) and fault isolation (LinkTrace) in Ethernet networks. 247 ITU-T Std. Y.1731 [Y.1731] builds upon and extends IEEE 802.1ag in 248 the following areas: it defines fault notification and alarm 249 suppression functions for Ethernet (via Alarm Indication Signal - 250 AIS). It also specifies messages and procedures for Ethernet 251 performance management, including loss, delay, jitter and throughput 252 measurement. 254 1.2 Terminology 256 This document introduces and uses the following terms. Further, this 257 document also uses the terms defined in [L2VPN-FRWK] and [L2VPN- 258 TERM]. 260 AIS Alarm Indication Signal 261 FM Fault Management 262 IPLS IP-only LAN Service 263 ME Maintenance Entity which is defined in a given OAM 264 domain and represents an entity requiring monitoring 265 MEG Maintenance Entity Group which represents MEs belonging 266 to the same service instance. MEG is also called as 267 Maintenance Association (MA). 268 MEP Maintenance End Point is responsible for origination 269 and termination of OAM frames for a given MEG 270 MIP Maintenance Intermediate Point is located between peer 271 MEPs and can process OAM frames but does not initiate 272 or terminate them 273 OAM Domain OAM Domain represents a region over which OAM frames 274 can operate unobstructed 275 PM Performance Management 276 RDI Remote Defect Indication 277 SLA Service Level Agreement 278 STP Spanning Tree Protocols 279 VPLS Virtual Private LAN Service 280 VPWS Virtual Private Wire Service 282 2. L2VPN Services & Networks 284 As described in [L2VPN-REQ], following Figure 1 shows a L2VPN 285 reference model. L2VPN A represents a point-to-point service while 286 L2VPN B represents a bridged service. 288 +-----+ +-----+ 289 + CE1 +--+ +--| CE2 | 290 +-----+ | ..................... | +-----+ 291 L2VPN A | +----+ +----+ | L2VPN A 292 +--| PE |-- Service --| PE |--+ 293 +----+ Provider +----+ 294 / . Backbone . \ --------_ 295 +-----+ / . | . \ / \ +-----+ 296 + CE4 +--+ . | . +-\ Access \--| CE5 | 297 +-----+ . +----+ . | Network | +-----+ 298 L2VPN B ........| PE |....... \ / L2VPN B 299 +----+ ^ ------- 300 | | logical 301 | | switching 302 +-----+ | instance 303 | CE3 | 304 +-----+ 305 L2VPN B 307 Figure 1: L2VPN Reference Model 309 [L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a 310 point-to-point service where CEs are presented with point-to-point 311 virtual circuits. VPLS is a bridged LAN service provided to a set of 312 CEs that are members of a VPN. CEs that are members of the same 313 service instance communicate with each other as if they are 314 connected via a bridged LAN. IPLS is a special VPLS which is used to 315 carry only IP service packets. 317 [L2VPN-REQ] assumes the availability of runtime monitoring protocols 318 while defining requirements for management interfaces. This draft 319 specifies the requirements and framework for operations, 320 administration and maintenance (OAM) protocols between network 321 devices. 323 3. L2VPN OAM Framework 324 3.1. OAM Layering 326 The point-to-point or bridged LAN functionality is emulated by a 327 network of PEs to which the CEs are connected. This network of PEs 328 can belong to a single network operator or can span across multiple 329 network operators. Furthermore, it can belong to a single service 330 provider or can span across multiple service providers. A service 331 provider is responsible for providing L2VPN services to its 332 customers; whereas, a network operator (aka facility provider) 333 provides the necessary facilities to the service provider(s) in 334 support of their services. A network operator and a service 335 provider can be part of same administrative organization or they can 336 be different administrative organizations. 338 Different layers involved in realizing L2VPNs include service layer 339 and network layers. Network layers can be iterative. In context of 340 L2VPNs, the service layers consists of VPLS, VPWS (e.g. Ethernet, 341 ATM, FR, HDLC, SONET, etc. point-to-point emulation), and IPLS. 342 Similarly in context of L2VPNs, network layers consist of MPLS/IP 343 networks. The MPLS/IP networks can consist of networks links 344 realized by different technologies e.g. SONET, Ethernet, ATM etc. 346 Each layer is responsible for its own OAM. This document provides 347 the OAM framework and requirements for L2VPN services and networks. 349 3.2. OAM Domains 351 When discussing OAM tools for L2VPNs it is important to provide OAM 352 capabilities and functionality over each domain that a service 353 provider or a network operator is responsible for. For these 354 reasons, it is also important that OAM frames are not allowed to 355 enter/exit other domains. We define an OAM domain as a network 356 region over which OAM frames operate unobstructed as explained 357 below. 359 At the edge of an OAM domain, filtering constructs should prevent 360 OAM frames from exiting and entering that domain. OAM domains can be 361 nested but not overlapped. In other words, if there is a hierarchy 362 of the OAM domains, the OAM frames of a higher-level domain pass 363 transparently through the lower-level domains but the OAM frames of 364 a lower-level domain get blocked/filtered at the edge of that 365 domain. 367 In order to facilitate the processing of OAM frames, each OAM domain 368 can be associated with a level at which it operates. Higher level 369 OAM domains can contain lower level OAM domains but the converse is 370 not true. It may be noted that the higher level domain does not 371 necessarily mean a higher numerical value of the level encoding in 372 the OAM frame. 374 A PE can be part of several OAM domains with each interface 375 belonging to the same or a different OAM domain. A PE shall block 376 outgoing OAM frames and filter out incoming OAM frames whose domain 377 level is lower or same to the one configured on that interface and 378 pass through the OAM frames whose domain level is higher than the 379 one configured on that interface. 381 Generically, L2VPNs can be viewed as consisting of customer OAM 382 domain, service provider OAM domain, and network operator OAM domain 383 as depicted in Figure 2. 385 --- --- 386 / \ ------ ------- ----- / \ 387 | CE-- / \ / \ / \ --CE | 388 \ / \ / \ / \ / \ / \ / 389 --- --PE P P PE-- --- 390 \ / \ / \ / 391 \ / \ / \ / 392 ------ ------- ----- 394 Customer OAM Domain 395 |<-------------------------------------------->| 397 Service Provider OAM Domain 398 |<------------------------------>| 400 Operator Operator Operator 401 |<-------->|<--------->|<------->| 402 OAM Domain OAM Domain OAM Domain 404 Figure 2: OAM Domains 406 The OAM Domains can be categorized as: 408 8 Hierarchical OAM Domains: Hierarchical OAM Domains result from 409 OAM Layering and imply a contractual agreement among the OAM 410 Domain ownerships. In the above example, Customer OAM Domain, 411 Service Provider OAM Domain and Operator OAM Domains are 412 hierarchical. 413 8 Adjacent OAM Domains: Adjacent OAM Domains are typically 414 independent of each other and do not have any relationship 415 among them. In the above example, the different Operator OAM 416 Domains are independent of each other. 418 3.3. MEPs and MIPs 420 Maintenance End Points (MEPs) are responsible for origination and 421 termination of OAM frames. MEPs are located at the edge of their 422 corresponding OAM domains. Maintenance Intermediate Points (MIPs) 423 are located within their corresponding OAM domains and they normally 424 pass OAM frames but never initiate them. Since MEPs are located at 425 the edge of their OAM domains, they are responsible for filtering 426 outbound OAM frames from leaving the OAM domain or inbound OAM 427 frames from entering the OAM domain. 429 An OAM frame is generally associated with a Maintenance Entity (ME) 430 or a Maintenance Entity Group (MEG), where a MEG consists of a set 431 of MEs associated with the same service instance. A ME is a point- 432 to-point association between a pair of MEPs and represents a 433 monitored entity. For example, in a VPLS service which involves n 434 CEs, all the MEs associated with the VPLS service in the customer 435 OAM domain (i.e. from CE to CE) can be considered to be part of a 436 VPLS MEG, where the n-point MEG consists of a maximum of n(n-1)/2 437 MEs. MEPs and MIPs correspond to a PE or more specifically to an 438 interface of a PE. For example, an OAM frame can be said to 439 originate from an ingress PE or more specifically an ingress 440 interface of that PE. A MEP on a PE receives messages from n-1 other 441 MEPs (some of them may reside on the same PE) for a given MEG. 443 In Hierarchical OAM Domains, a MEP of lower-level OAM domain can 444 correspond to a MIP or a MEP of a higher-level OAM domain. 445 Furthermore, the MIPs of a lower-level OAM domain are always 446 transparent to the higher-level OAM domain (e.g., OAM frames of a 447 higher-level OAM domain are not seen by MIPs of a lower-level OAM 448 domain and get passed through them transparently). Further, the MEs 449 (or MEGs) are hierarchically organized in hierarchical OAM domains. 450 For example, in a VPWS service, the VPWS ME in Customer OAM domain 451 can coincide with the Attachment Circuit (AC) ME, PW ME and another 452 AC ME in Service Provider OAM Domain. Similarly, the PW ME can 453 coincide with different ME in Operator OAM Domains. 455 3.4. MEP and MIP Identifiers 457 As mentioned previously, OAM at each layer should be independent of 458 other layers e.g. service layer OAM should be independent of 459 underlying transport layer. MEPs and MIPs at each layer should be 460 identified with layer specific identifiers. 462 4. OAM Framework for VPLS 464 Virtual Private LAN Service (VPLS) is used in different contexts. In 465 general, VPLS is used in the following contexts: a) as a bridged LAN 466 service over networks, some of which are MPLS/IP, b) as an MPLS/IP 467 network supporting these bridged LAN services, and c) as (V)LAN 468 emulation. 470 4.1. VPLS as Service/Network 472 4.1.1. VPLS as Bridged LAN Service 474 The most common definition for VPLS is for bridged LAN service over 475 an MPLS/IP network. The service coverage is considered end-to-end 476 from UNI to UNI (or AC to AC) among the CE devices and it provides a 477 virtual LAN service to the attached CEs belonging to that service 478 instance. The reason it is called bridged LAN service is because the 479 VPLS-capable PE providing this end-to-end virtual LAN service is 480 performing bridging functions (either full or a subset) as described 481 in the [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN- 482 REQ], includes both bridge module and LAN emulation module (as 483 specified in [L2VPN-FRWK]). 485 A VPLS service instance is also analogous to a VLAN provided by IEEE 486 802.1Q networks since each VLAN provides a Virtual LAN service to 487 its MAC users. Therefore, when a part of the service provider 488 network is Ethernet based (such as H-VPLS with QinQ access network), 489 there is a one-to-one correspondence between a VPLS service instance 490 and its corresponding provider VLAN in the service provider Ethernet 491 network. To check the end-to-end service integrity, the OAM 492 mechanism needs to cover the end-to-end VPLS service as defined in 493 [L2VPN-REQ] which is from AC to AC including bridge module, VPLS 494 forwarder, and the associated PWs for this service. This draft 495 specifies the framework and requirements for such OAM mechanism. 497 4.1.2. VPLS as a Network 499 Sometimes VPLS is also used to refer to the underlying network that 500 supports bridged LAN services. This network can be an end-to-end 501 MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid 502 network consisting of MPLS/IP core and Ethernet access network as in 503 H-VPLS with QinQ access. In either case, the network consists of a 504 set of VPLS-capable PE devices capable of performing bridging 505 functions (either full or a subset). These VPLS-capable PE devices 506 can be arranged in a certain topology such as hierarchical topology 507 (H-VPLS) or distributed topology (D-VPLS) or some other topologies 508 such as multi-tier or star topologies. To check the network 509 integrity regardless of the network topology, network-level OAM 510 mechanisms (such as OAM for MPLS/IP networks) are needed. The 511 discussion of network-level OAM is outside of the scope of this 512 draft. 514 4.1.3. VPLS as (V)LAN Emulation 516 Sometimes VPLS also refers to (V)LAN emulation. In such context, 517 VPLS only refers to the full mesh of PWs with split horizon that 518 emulates a LAN segment over MPLS/IP network for a given service 519 instance and its associated VPLS forwarder. Since the emulated LAN 520 segment is presented as a Virtual LAN (VLAN) to the bridge module of 521 a VPLS-capable PE, the emulated segment is also referred to as an 522 emulated VLAN. The OAM mechanisms in this context refer primarily to 523 integrity check of VPLS forwarders and its associated full-mesh of 524 PWs and the ability to detect and notify a partial mesh failure. 525 This draft also covers the OAM framework and requirements for such 526 OAM mechanism. 528 4.2. VPLS OAM 530 When discussing the OAM mechanisms for VPLS, it is important to 531 consider that the end-to-end service can span across different types 532 of L2VPN networks. As an example, in case of [VPLS-LDP], the access 533 network on one side can be bridged network e.g. [IEEE 802.1ad], as 534 described in section 11 of [VPLS-LDP]. The access network can also 535 be a [IEEE 802.1ah] based bridged network. The access network on 536 other side can be MPLS based as described in section 10 of [VPLS- 537 LDP]; and the core network connecting them can be IP, MPLS, ATM, or 538 SONET. Similarly, the VPLS service instance can span across [VPLS- 539 BGP], and distributed VPLS as described in [L2VPN-SIG]. 541 Therefore, it is important that the OAM mechanisms can be applied to 542 all these network types. Each such network may be associated with a 543 separate administrative domain and also multiple such networks may 544 be associated with a single administrative domain. It is important 545 to ensure that the OAM mechanisms are independent of the underlying 546 transport mechanisms and solely rely on VPLS service, i.e. the 547 transparency of OAM mechanisms must be ensured over underlying 548 transport technologies such as MPLS, IP, etc. 550 This proposal is aligned with the discussions in other standard 551 bodies and groups such as ITU-T Q.5/13, IEEE 802.1, and MEF which 552 address Ethernet network and service OAM. 554 4.2.1. VPLS OAM Layering 556 Figure 3 shows an example of a VPLS service (with two CE belonging 557 to customer A) across a service provider network marked by UPE and 558 NPE devices. More CE devices belonging to the same Customer A can be 559 connected across different customer sites. Service provider network 560 is segmented into core network and two types of access network. 561 Figure 3(A) shows the bridged access network represented by its 562 bridge components marked B, and the MPLS access and core network 563 represented by MPLS components marked P. Figure 3(B) shows the 564 service/network view at the Ethernet MAC layer marked by E. 566 --- --- 567 / \ ------ ------- ---- / \ 568 | A CE-- / \ / \ / \ --CE A | 569 \ / \ / \ / \ / \ / \ / 570 --- --UPE NPE NPE UPE-- --- 571 \ / \ / \ / 572 \ / \ / \ / 573 ------ ------- ---- 575 (A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE 577 (B) E------E---E--E---E------------E----------E-----E 579 Figure 3: VPLS specific device view 581 As shown in Figure 3(B), only the devices with Ethernet 582 functionality are visible to OAM mechanisms operating at Ethernet 583 MAC layer and the P devices are invisible. Therefore, the OAM along 584 the path of P devices (e.g., between two PEs) is covered by 585 transport layer and it is outside the scope of this document. 587 However, VPLS services may impose some specific requirements on PSN 588 OAM. This document aims to identify such requirements. 590 4.2.2. VPLS OAM Domains 592 As described in the previous section, a VPLS service for a given 593 customer can span across one or more service providers and network 594 operators. Figure 4 depicts three OAM domains: (A) customer domain 595 which is among the CEs of a given customer, (B) service provider 596 domain which is among the edge PEs of the given service provider, 597 and (C) network operator domain which is among the PEs of a given 598 operator. 600 --- --- 601 / \ ------ ------- ---- / \ 602 | CE-- / \ / \ / \ --CE | 603 \ / \ / \ / \ / \ / \ / 604 --- --UPE NPE NPE UPE-- --- 605 \ / \ / \ / 606 \ / \ / \ / 607 ------ ------- ---- 609 Customer OAM Domain 610 (A) |<----------------------------------------------->| 612 Provider OAM Domain 613 (B) |<---------------------------------->| 615 Operator Operator Operator 616 (C) |<--------->|<---------->|<-------->| 617 OAM Domain OAM Domain OAM Domain 619 Figure 4: VPLS OAM Domains 621 4.2.3. VPLS MEPs & MIPs 623 As shown in Figure 5, (C) represents those MEPs and MIPs that are 624 visible within the customer domain. The MIP associated with (C) are 625 expected to be implemented in the bridge module/VPLS forwarder of a 626 PE device, as per the [L2VPN-FRWK]. (D) represents the MEPs and MIPs 627 visible within the service provider domain. These MEPs and MIPs are 628 expected to be implemented in the bridge module/VPLS forwarder of a 629 PE device, as per the [L2VPN-FRWK]. (E) represents the MEPs and MIPs 630 visible within each operator domain where MIPs only exist in an 631 Ethernet access network (e.g., an MPLS access network doesn't have 632 MIPs at the operator level). Further, (F) represents the MEPs and 633 MIPs corresponding to the MPLS layer and may apply MPLS based 634 mechanisms. The MPLS layer shown in Figure 5 is just an example and 635 specific OAM mechanisms are outside the scope of this document. 637 --- --- 638 / \ ------ ------- ---- / \ 639 | A CE-- / \ / \ / \ --CE A | 640 \ / \ / \ / \ / \ / \ / 641 --- --UPE NPE NPE UPE-- --- 642 \ / \ / \ / 643 \ / \ / \ / 644 ------ ------- ---- 646 (A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE 647 (B) E------E---E------E------------E----------E-----E 649 Customer OAM domain 650 (C) MEP---MIP--------------------------------MIP---MEP 652 Provider OAM domain 653 (D) MEP--------MIP-----------MIP-------MEP 655 Operator Operator Operator 656 (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP 657 OAM domain OAM domain OAM domain 659 MPLS OAM MPLS OAM 660 (F) MEP--MIP--MEP|MEP-MIP-MEP 661 domain domain 663 Figure 5: VPLS OAM Domains, MEPs & MIPs 665 4.2.4. VPLS MEP and MIP Identifiers 667 In VPLS, for Ethernet MAC layer, the MEPs and MIPs should be 668 identified with their Ethernet MAC addresses. As described in [VPLS- 669 LDP], VPLS instance can be identified in an Ethernet domain (e.g., 670 802.1ad domain) using VLAN tag (service tag) while in an MPLS/IP 671 network, PW-ids are used. Both PW-ids and VLAN tags for a given VPLS 672 instance are associated with a Service Identifier (e.g., VPN 673 identifier). MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids, 674 must be unique within their corresponding Service Identifiers within 675 the OAM domains. 677 For Ethernet services, e.g. VPLS, Ethernet frames are used for OAM 678 frames and the source MAC address of the OAM frames represent the 679 source MEP in that domain. For unicast Ethernet OAM frames, the 680 destination MAC address represents the destination MEP in that 681 domain. For multicast Ethernet OAM frames, the destination MAC 682 addresses corresponds to all MEPs in that domain. 684 5. OAM Framework for VPWS 686 Figure 6 shows the VPWS reference model. VPWS is a point-to-point 687 service where CEs are presented with point-to-point virtual 688 circuits. VPWS is realized by combining a pair of Attachment 689 Circuits between the CEs and PEs and a PW between PEs. 691 |<------------- VPWS1 ------------>| 692 | | 693 | +----+ +----+ | 694 +----+ | |==================| | +----+ 695 | |---AC11---| |.......PW1........| |--AC12----| | 696 | CE1| |PE1 | | PE2| |CE2 | 697 | |---AC21---| |.......PW2........| |--AC22----| | 698 +----+ | |==================| | +----+ 699 | +----+ PSN Tunnel +----+ | 700 | | 701 |<------------- VPWS2 ------------>| 703 Figure 6: VPWS Reference Model 705 5.1. VPWS as Service 707 VPWS service can be categorized as: 708 8 VPWS with homogeneous ACs (where both ACs are same type) 709 8 VPWS with heterogeneous ACs (where the ACs are of different 710 Layer-2 encapsulation) 712 Further, the VPWS can itself be classified as: 713 8 Homogeneous VPWS (when two ACs and PW are of the same type) 714 8 Heterogeneous VPWS (when at least one AC or PW is different 715 type than the others) 717 Based on the above classifications, the heterogeneous VPWS may have 718 either homogeneous or heterogeneous ACs. On the other hand, 719 homogeneous VPWS can have only homogeneous ACs. 721 5.2. VPWS OAM 723 When discussing the OAM mechanisms for VPWS, it is important to 724 consider that the end-to-end service can span across different types 725 of networks. As an example, the access network between CE and PE on 726 one side can be Ethernet bridged network, ATM network, etc. In 727 common scenarios, it could simply be a point-to-point interface such 728 as Ethernet PHY. The core network connecting PEs can be IP, MPLS, 729 etc. 731 Therefore, it is important that the OAM mechanisms can be applied to 732 different network types some of which are mentioned above. Each such 733 network may be associated with a separate administrative domain and 734 also multiple such networks may be associated with a single 735 administrative domain. 737 5.2.1. VPWS OAM Layering 739 Figure 7 shows an example of a VPWS service (with two CE devices 740 belonging to customer A) across a service provider network marked by 741 PE devices. Service provider network can be considered to be 742 segmented into a core network and two types of access network. 744 In the most general case, a PE can be client service aware when it 745 processes client service PDUs and is responsible for encapsulating 746 and de-encapsulating client service PDUs onto PWs and ACs. This is 747 particularly relevant for homogeneous VPWS. The service specific 748 device view for such a deployment is highlighted by Figure 7(A) for 749 these are the devices that are expected to be involved in end-to-end 750 VPWS OAM. 752 In other instances, a PE can be client service unaware when it does 753 not process native service PDUs but instead encapsulates access 754 technology PDUs over PWs. This may be relevant for VPWS with 755 heterogeneous ACs. For example, if the service is Ethernet VPWS 756 which is offered across an ATM AC, ATM PW and Ethernet AC. In this 757 case, the PE which is attached to ATM AC and ATM PW may be 758 transparent to the client Ethernet service PDUs. On the other hand, 759 the PE which is attached to ATM PW and Ethernet AC is expected to be 760 client Ethernet service aware. The service specific device view for 761 such a deployment is highlighted by Figure 7(B) for these are the 762 devices that are expected to be involved in end-to-end VPWS OAM, 763 where PE1 is expected to be client service unaware. 765 |<--------------- VPWS -------------->| 766 | | 767 | +----+ +----+ | 768 +----+ | |==================| | +----+ 769 | |---AC1----|............PW..............|--AC2-----| | 770 | CE1| |PE1 | | PE2| |CE2 | 771 +----+ | |==================| | +----+ 772 +----+ PSN Tunnel +----+ 774 access core access 775 |<---------->|<---------------------->|<------------>| 777 (A).CE----------PE-----------------------PE-------------CE 779 (B).CE-----------------------------------PE-------------CE 781 Figure 7: VPWS specific device view 783 5.2.2. VPWS OAM Domains 784 As described in the previous section, a VPWS service for a given 785 customer can span across one or more network operators. 787 Figure 8a and 8b depicts three OAM domains: (A) customer domain 788 which is among the CEs of a given customer, (B) service provider 789 domain which depends on the management model, and (C) network 790 operator domain which is among the PEs of a given operator and could 791 also be present in the access network if the ACs are provided by a 792 different network operator. The core network operator may be 793 responsible for managing the PSN Tunnel in these examples. 795 For the first management model, as shown in Figure 8a, the CEs are 796 expected to be managed by the customer and the customer is 797 responsible for running end-to-end service OAM, if needed. The 798 service provider is responsible for monitoring the PW ME and the 799 monitoring of the AC is the shared responsibility of the customer 800 and the service provider. In most simple cases, when the AC is 801 realized across a physical interface that connects the CE to PE, the 802 monitoring requirements across the AC ME are minimal. 804 |<--------------- VPWS -------------->| 805 | | 806 | +----+ +----+ | 807 +----+ | |==================| | +----+ 808 | |---AC1----|............PW..............|--AC2-----| | 809 | CE1| |PE1 | | PE2| |CE2 | 810 +----+ | |==================| | +----+ 811 +----+ PSN Tunnel +----+ 813 Customer OAM Domain 814 (A).|<------------------------------------------------->| 816 Service Provider OAM Domain 817 (B) |<--------------------------->| 819 Operator OAM Domain 820 (C) |<---------------->| 822 Figure 8a: VPWS OAM Domains - Management Model 1 824 Figure 8b highlights another management model, where the CEs are 825 managed by the Service Provider and where CEs and PEs are connected 826 via an access network. The access network between the CEs and PEs 827 may or may not be provided by a distinct network operator. In this 828 model, the VPWS service ME spans between the CEs in the Service 829 Provider OAM Domain, as shown by Figure 8b(B). The Service Provider 830 OAM Domain may additionally monitor the AC MEs and PW MEs 831 individually, as shown by Figure 8b(C). The network operators may be 832 responsible for managing the access service MEs (e.g. access 833 tunnels) and core PSN Tunnel MEs, as shown by Figure 8b(D). The 834 distinction between Figure 8b-(C) and 8(b)-D) is that in (C), MEs 835 have MEPs at CEs and at PEs, and have no MIPs. While in (D) MEs have 836 MEPs at CEs and at PEs and furthermore, MIPs may be present in 837 between the MEPs; thereby, providing visibility of the network to 838 the operator. 840 |<--------------- VPWS -------------->| 841 | | 842 | +----+ +----+ | 843 +----+ | |==================| | +----+ 844 | |---AC1----|............PW..............|--AC2-----| | 845 | CE1| |PE1 | | PE2| |CE2 | 846 +----+ | |==================| | +----+ 847 +----+ PSN Tunnel +----+ 849 Customer OAM Domain 850 (A) |<-------------------------------------------------->| 852 Service Provider (SP) OAM Domain 853 (B) |<------------------------------------------------>| 855 SP OAM SP OAM SP OAM 856 (C) |<--------->|<----------------------->|<---------->| 857 Domain Domain Domain 859 Operator Operator Operator 860 (D) |<--------->|<----------------------->|<---------->| 861 OAM Domain OAM Domain OAM Domain 863 Figure 8b: VPWS OAM Domains - Management Model 2 865 Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where 866 multiple operator domains may occur between the U-PE devices, VPWS 867 OAM domain in Figure 8a and 8b highlight a single Operator domain 868 between PE devices. This is since unlike the distributed VPLS PE 869 case (H-VPLS) where VPLS service aware U-PEs and N-PEs may be used 870 to realize a distributed PE, the VPWS has no such distributed PE 871 model. If the PSN involves multiple Operator domains, resulting in a 872 Multi-segment PW [Ms-PW Arch], VPWS OAM Domains remain unchanged 873 since S-PEs are typically not aware of native service. 875 5.2.3. VPWS MEPs & MIPs 877 The location of MEPs and MIPs can be based upon the management model 878 used in the VPWS scenarios. The interest remains in being able to 879 monitor end-to-end service and also support segment monitoring in 880 the network to allow isolation of faults to specific areas within 881 the network. 883 The end-to-end service monitoring is provided by end-to-end ME and 884 additional segment OAM monitoring is provided by segment MEs, all in 885 the Service Provider OAM Domain. The end-to-end MEs and segment MEs 886 are hierarchically organized as mentioned earlier for hierarchical 887 OAM domains. This is shown in Figure 8b (B) and (C). 889 The CE interfaces support MEPs at the end-to-end Service Provider 890 OAM level for VPWS as an end-to-end service as shown in Figure 9 891 (B1) and (B2). In addition, PE interfaces may support MIPs at end- 892 to-end Service Provider OAM level when PEs are client service aware, 893 as shown in Figure 9 (B2). As an example, if one considers an end- 894 to-end Ethernet line service offered to a subscriber between CE1 and 895 CE2 which is realized via ATM type AC1 and AC2 and PW which 896 encapsulates ATM over MPLS, the PEs can be considered as Ethernet 897 service unaware, and therefore cannot support any Ethernet MIPs. 898 Figure 9 (B1) represents this particular situation. Of course, 899 another view of the end-to-end service can be ATM, in which case PE1 900 and PE2 can be considered to be service aware, and therefore support 901 ATM MIPs. Figure 9 (B2) represents this particular situation. 903 In addition, CEs and PE interfaces support MEPs at a segment (lower 904 level) Service Provider OAM level for AC and PW MEs and no MIPs are 905 involved at this segment Service Provider OAM Level, as shown in 906 Figure 9 (C). Operators may also run segment OAM by having MEPs at 907 Network Operator OAM level, as shown in Figure 9 (D). 909 The advantage of having layered OAM is that end-to-end and segment 910 OAM can be carried out in an independent manner. It is also possible 911 to carry out some optimizations, e.g. when proactive segment OAM 912 monitoring is performed, proactive end-to-end monitoring may not be 913 needed since client layer end-to-end ME could simply use fault 914 notifications from the server layer segment MEs. 916 Although many different OAM layers are possible, as shown in Figure 917 9, not all may be realized. For example, Figure (B2) and (D) may be 918 adequate in some cases. 920 |<--------------- VPWS -------------->| 921 | | 922 | +----+ +----+ | 923 +----+ | |==================| | +----+ 924 | |---AC1----|............PW..............|--AC2-----| | 925 | CE1| |PE1 | | PE2| |CE2 | 926 +----+ | |==================| | +----+ 927 +----+ PSN Tunnel +----+ 929 (B1) MEP-----------------------------------------------MEP 930 (B2) MEP----------MIP---------------------MIP----------MEP 931 (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP 932 (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP 933 Figure 9: VPWS MEPs & MIPs 935 5.2.4. VPWS MEP and MIP Identifiers 937 In VPWS, the MEPs and MIPs should be identified with their native 938 addressing schemes. MEPs and MIPs Identifiers, i.e. MEP Ids and MIP 939 Ids, must be unique within their corresponding OAM domains and must 940 also be unique to the VPWS service instance. 942 6. VPLS Service OAM Requirements 944 These requirements are applicable to VPLS PE offering VPLS as an 945 Ethernet Bridged LAN service, as described in Section 4.1.1. 946 Further, the performance metrics used in requirements are based on 947 [MEF10.1] and [RFC2544]. 949 It is noted that OAM solutions that meet the following requirements 950 may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, 951 etc. however must not break these existing OAM mechanisms. If 952 extensions are required to existing OAM mechanisms, these should be 953 coordinated with relevant groups responsible for these OAM 954 mechanisms. 956 6.1. Discovery 958 Discovery allows a VPLS service aware device to learn about other 959 devices that support the same VPLS service instance within a given 960 domain. 962 Discovery also allows a VPLS service aware device to learn 963 sufficient information (e.g. IP addresses, MAC addressed etc.) from 964 other VPLS service aware devices such that VPLS OAM frames can be 965 exchanged among the service aware devices. 967 (R1) VPLS OAM MUST allow a VPLS service aware device to discover 968 other devices that share the same VPLS service instance(s) within a 969 given OAM domain. 971 6.2. Connectivity Fault Management 973 VPLS service is realized by exchanging service frames/packets 974 between devices that support the same VPLS service instance. To 975 allow the exchange of service frames, connectivity between these 976 service aware devices is required. 978 6.2.1. Connectivity Fault Detection 980 To ensure service, pro-active connectivity monitoring is required. 981 Connectivity monitoring facilitates connectivity fault detection. 983 (R2a) VPLS OAM MUST allow pro-active connectivity monitoring between 984 two VPLS service aware devices that support the same VPLS service 985 instance within a given OAM domain. 987 6.2.2. Connectivity Fault Verification 989 Once a connectivity fault is detected, connectivity fault 990 verification may be performed. 992 (R2b) VPLS OAM MUST allow connectivity fault verification between 993 two VPLS service aware devices that support the same VPLS service 994 instance within a given OAM domain. 996 6.2.3. Connectivity Fault Localization 998 Further, localization of connectivity fault may be carried out. 1000 (R2c) VPLS OAM MUST allow connectivity fault localization between 1001 two VPLS service aware devices that support the same VPLS service 1002 instance within a given OAM domain. 1004 6.2.4. Connectivity Fault Notification and Alarm Suppression 1006 Typically, when connectivity fault is detected and optionally 1007 verified, VPLS service device may notify the NMS (Network Management 1008 System) via alarms. 1010 However, a single transport/network fault may cause multiple 1011 services to fail simultaneously causing multiple service alarms. 1012 Therefore, VPLS OAM must allow service level fault notification to 1013 be triggered at the client layer as a result of transport/network 1014 faults in the service layer. This fault notification should be used 1015 for the suppression of service level alarms at the client layer. 1017 (R2d) VPLS OAM MUST support fault notification to be triggered as a 1018 result of transport/network faults. This fault notification SHOULD 1019 be used for the suppression of redundant service level alarms. 1021 6.3. Frame Loss 1023 A VPLS service may be considered degraded if service-layer 1024 frames/packets are lost during transit between the VPLS service 1025 aware devices. To determine if a VPLS service is degraded due to 1026 frame/packet loss, measurement of frame/packet loss is required. 1028 (R3) VPLS OAM MUST support measurement of per-service frame/packet 1029 loss between two VPLS service aware devices that support the same 1030 VPLS service instance within a given OAM domain. 1032 6.4. Frame Delay 1034 A VPLS service may be sensitive to delay experienced by the VPLS 1035 frames/packets during transit between the VPLS service aware 1036 devices. To determine if a VPLS service is degraded due to 1037 frame/packet delay, measurement of frame/packet delay is required. 1039 VPLS frame/packet delay measurement can be of two types: 1041 One-way delay 1042 One-way delay is used to characterize certain applications like 1043 multicast and broadcast applications. The measurement for one-way 1044 delay usually requires clock synchronization between two devices in 1045 question. 1047 Two-way delay 1048 Two-way delay or round-trip delay does not require clock 1049 synchronization between two devices involved in measurement and is 1050 usually sufficient to determine the frame/packet delay being 1051 experienced. 1053 (R4a) VPLS OAM MUST support measurement of per-service two-way 1054 frame/packet delay between two VPLS service aware devices that 1055 support the same VPLS service instance within a given OAM domain. 1057 (R4b) VPLS OAM SHOULD support measurement of per-service one-way 1058 frame/packet delay between two VPLS service aware devices that 1059 support the same VPLS service instance within a given OAM domain. 1061 6.5. Frame Delay Variation 1063 A VPLS service may be sensitive to delay variation experienced by 1064 the VPLS frames/packets during transit between the VPLS service 1065 aware devices. To determine if a VPLS service is degraded due to 1066 frame/packet delay variation, measurement of frame/packet delay 1067 variation is required. For frame/packet delay variation 1068 measurements, one-way mechanisms are considered to be sufficient. 1070 (R5) VPLS OAM MUST support measurement of per-service frame/packet 1071 delay variation between two VPLS service aware devices that support 1072 the same VPLS service instance within a given OAM domain. 1074 6.6. Availability 1075 A service may be considered unavailable if the service 1076 frames/packets do not reach their intended destination (e.g. 1077 connectivity is down or frame/packet loss is occurring) or the 1078 service is degraded (e.g. frame/packet delay and/or delay variation 1079 threshold is exceeded). 1081 Entry and exit conditions may be defined for unavailable state. 1082 Availability itself may be defined in context of service type. 1084 Since availability measurement may be associated with connectivity, 1085 frame/packet loss, frame/packet delay and frame/packet delay 1086 variation measurements, no additional requirements are specified 1087 currently. 1089 6.7. Data Path Forwarding 1091 If the VPLS OAM frames flow across a different path than the one 1092 used by VPLS service frames/packets, accurate measurement and/or 1093 determination of service state may not be made. Therefore data path, 1094 i.e. the one being taken by VPLS service frames/packets, must be 1095 used for the VPLS OAM. 1097 (R6) VPLS OAM frames MUST be forwarded along the same path (i.e. 1098 links and nodes) as the VPLS service/data frames. 1100 6.8. Scalability 1102 Mechanisms developed for VPLS OAM need to be such that per-service 1103 OAM can be supported even though the OAM may only be used for 1104 limited VPLS service instances, e.g. premium VPLS service instances, 1105 and may not be used for best-effort VPLS services. 1107 (R7) VPLS OAM MUST be scalable such that a service aware device can 1108 support OAM for each VPLS service that is supported by the device. 1110 6.9. Extensibility 1112 Extensibility is intended to allow introduction of additional OAM 1113 functionality in future such that backward compatibility can be 1114 maintained when interoperating with older version devices. In such a 1115 case, VPLS OAM with reduced functionality should still be possible. 1116 Further, VPLS Service OAM should be defined such that OAM incapable 1117 devices in the middle of the OAM domain should be able to forward 1118 the VPLS OAM frames similar to the regular VPLS service/data 1119 frames/packets. 1121 (R8a) VPLS OAM MUST be extensible such that new functionality and 1122 information elements related to this functionality can be introduced 1123 in future. 1125 (R8b) VPLS OAM MUST be defined such that devices not supporting the 1126 OAM are able to forward the OAM frames in a similar fashion as the 1127 regular VPLS service/data frames/packets. 1129 6.10. Security 1131 VPLS OAM frames belonging to an OAM domain originate and terminate 1132 within that OAM domain. Security implies that an OAM domain must be 1133 capable of filtering OAM frames. The filtering is such that the OAM 1134 frames are prevented from leaking outside their domain. Also, OAM 1135 frames from outside the OAM domains should be either discarded (when 1136 such OAM frames belong to same or lower-level OAM domain) or 1137 transparently passed (when such OAM frames belong to a higher-level 1138 OAM domain). 1140 (R9a) VPLS OAM frames MUST be prevented from leaking outside their 1141 OAM domain. 1143 (R9b) VPLS OAM frames from outside an OAM domain MUST be prevented 1144 from entering the OAM domain when such OAM frames belong to the same 1145 level or lower-level OAM domain. 1147 (R9c) VPLS OAM frames from outside an OAM domain MUST be transported 1148 transparently inside the OAM domain when such OAM frames belong to 1149 the higher-level OAM domain. 1151 6.11. Transport Independence 1153 VPLS service frame/packets delivery is carried out across transport 1154 infrastructure, also called network infrastructure. Though specific 1155 transport/network technologies may provide their own OAM 1156 capabilities, VPLS OAM must be independently supported as many 1157 different transport/network technologies can be used to carry 1158 service frame/packets. 1160 (R10a) VPLS OAM MUST be independent of the underlying 1161 transport/network technologies and specific transport/network OAM 1162 capabilities. 1164 (R10b) VPLS OAM MAY allow adaptation/interworking with specific 1165 transport/network OAM functions. For example, this would be useful 1166 to allow Fault Notifications from transport/network layer(s) to be 1167 sent to the VPLS service layer. 1169 6.12. Application Independence 1171 VPLS service itself may be used to carry application frame/packets. 1172 The application may use its own OAM; service OAM must not be 1173 dependent on application OAM. As an example, a VPLS service may be 1174 used to carry IP traffic; however, VPLS OAM should not assume IP or 1175 rely on the use of IP level OAM functions. 1177 (R11a) VPLS OAM MUST be independent of the application technologies 1178 and specific application OAM capabilities. 1180 7. VPWS OAM Requirements 1182 These requirements are applicable to VPWS PE. The performance 1183 metrics used in requirements are based on [MEF10.1] and [RFC2544], 1184 which are applicable to Ethernet Services. 1186 It is noted that OAM solutions that meet the following requirements 1187 may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, 1188 etc. however must not break these existing OAM mechanisms. If 1189 extensions are required to existing OAM mechanisms, these should be 1190 coordinated with relevant groups responsible for these OAM 1191 mechanisms. 1193 7.1. Discovery 1195 Discovery allows a VPWS service aware device to learn about other 1196 devices that support the same VPWS service instance within a given 1197 domain. Discovery also allows a VPWS service aware device to learn 1198 sufficient information (e.g. IP addresses, MAC addresses etc.) from 1199 other VPWS service aware devices such that OAM frames can be 1200 exchanged among the VPWS service aware devices. 1202 (R12) VPWS OAM MUST allow a VPWS service aware device to discover 1203 other devices that share the same VPWS service instance(s) within a 1204 given OAM domain. 1206 7.2. Connectivity Fault Management 1208 VPWS Service is realized by exchanging service frames/packets 1209 between devices that support the same VPWS service instance. To 1210 allow the exchange of service frames, connectivity between these 1211 service aware devices is required. 1213 7.2.1. Connectivity Fault Detection 1215 To ensure service, pro-active connectivity monitoring is required. 1216 Connectivity monitoring facilitates connectivity fault detection. 1218 (R13a) VPWS OAM MUST allow pro-active connectivity monitoring 1219 between two VPWS service aware devices that support the same VPWS 1220 service instance within a given OAM domain. 1222 (R13b) VPWS OAM mechanism SHOULD allow detection of misbranching or 1223 misconnections. 1225 7.2.2. Connectivity Fault Verification 1227 Once a connectivity fault is detected, connectivity fault 1228 verification may be performed. 1230 (R13c) VPWS OAM MUST allow connectivity fault verification between 1231 two VPWS service aware devices that support the same VPWS service 1232 instance within a given OAM domain. 1234 7.2.3. Connectivity Fault Localization 1236 Further, localization of connectivity fault may be carried out. This 1237 may amount to identifying the specific AC and/or PW that is 1238 resulting in the VPWS connectivity fault. 1240 (R13d) VPWS OAM MUST allow connectivity fault localization between 1241 two VPWS service aware devices that support the same VPWS service 1242 instance within a given OAM domain. 1244 7.2.4. Connectivity Fault Notification and Alarm Suppression 1246 Typically, when connectivity fault is detected and optionally 1247 verified, service device may notify the NMS (Network Management 1248 System) via alarms. 1250 However, a single transport/network fault may cause multiple 1251 services to fail simultaneously causing multiple service alarms. 1252 Therefore, OAM must allow service level fault notification to be 1253 triggered at the client layer as a result of transport/network 1254 faults in the service layer. This fault notification should be used 1255 for the suppression of service level alarms at the client layer. 1257 For example, if an AC fails, both local CE and local PE which are 1258 connected via AC may detect the connectivity failure. The local CE 1259 must notify the remote CE about the failure while the local PE must 1260 notify the remote PE about the failure. 1262 (R13e) VPWS OAM MUST MUST support fault notification to be triggered 1263 as a result of transport/network faults. This fault notification 1264 SHOULD be used for the suppression of redundant service level 1265 alarms. 1267 (R13f) VPWS OAM SHOULD support fault notification in backward 1268 direction, to be triggered as a result of transport/network faults. 1269 This fault notification SHOULD be used for the suppression of 1270 redundant service level alarms. 1272 7.3. Frame Loss 1274 A VPWS service may be considered degraded if service-layer 1275 frames/packets are lost during transit between the VPWS service 1276 aware devices. To determine if a VPWS service is degraded due to 1277 frame/packet loss, measurement of frame/packet loss is required. 1279 (R14) VPWS OAM MUST support measurement of per-service frame/packet 1280 loss between two VPWS service aware devices that support the same 1281 VPWS service instance within a given OAM domain. 1283 7.4. Frame Delay 1285 A VPWS service may be sensitive to delay experienced by the VPWS 1286 service frames/packets during transit between the VPWS service aware 1287 devices. To determine if a VPWS service is degraded due to 1288 frame/packet delay, measurement of frame/packet delay is required. 1290 VPWS frame/packet delay measurement can be of two types: 1291 - One-way delay 1292 One-way delay is used to characterize certain applications like 1293 multicast and broadcast applications. The measurement for one-way 1294 delay usually requires clock synchronization between two devices in 1295 question. 1296 - Two-way delay 1297 Two-way delay or round-trip delay does not require clock 1298 synchronization between two devices involved in measurement and is 1299 usually sufficient to determine the frame/packet delay being 1300 experienced. 1302 (R15a) VPWS OAM MUST support measurement of per-service two-way 1303 frame/packet delay between two VPWS service aware devices that 1304 support the same VPWS service instance within a given OAM domain. 1306 (R15b) VPWS OAM SHOULD support measurement of per-service one-way 1307 frame/packet delay between two VPWS service aware devices that 1308 support the same VPWS service instance within a given OAM domain. 1310 7.5. Frame Delay Variation 1312 A VPWS service may be sensitive to delay variation experienced by 1313 the VPWS frames/packets during transit between the VPWS service 1314 aware devices. To determine if a VPWS service is degraded due to 1315 frame/packet delay variation, measurement of frame/packet delay 1316 variation is required. For frame/packet delay variation 1317 measurements, one-way mechanisms are considered to be sufficient. 1319 (R16) VPWS OAM MUST support measurement of per-service frame/packet 1320 delay variation between two VPWS service aware devices that support 1321 the same VPWS service instance within a given OAM domain. 1323 7.6. Availability 1325 A service may be considered unavailable if the service 1326 frames/packets do not reach their intended destination (e.g. 1327 connectivity is down or frame/packet loss is occurring) or the 1328 service is degraded (e.g. frame/packet delay and/or delay variation 1329 threshold is exceeded). 1331 Entry and exit conditions may be defined for unavailable state. 1332 Availability itself may be defined in context of service type. 1333 Since availability measurement may be associated with connectivity, 1334 frame/packet loss, frame/packet delay and frame/packet delay 1335 variation measurements, no additional requirements are specified 1336 currently. 1338 7.7. Data Path Forwarding 1340 If the VPWS OAM frames flow across a different path than the one 1341 used by VPWS service frames/packets, accurate measurement and/or 1342 determination of service state may not be made. Therefore data path, 1343 i.e. the one being taken by VPWS service frames/packets, must be 1344 used for the VPWS OAM. 1346 (R17a) VPWS OAM frames MUST be forwarded along the same path as the 1347 VPWS service/data frames. 1349 (R17b) VPWS OAM MUST be forwarded using the transfer plane (data 1350 plane) as regular VPWS service/data frames/packets and must not rely 1351 on control plane messages. 1353 7.8. Scalability 1355 Mechanisms developed for VPWS OAM need to be such that per-service 1356 OAM can be supported even though the OAM may only be used for 1357 limited VPWS service instances, e.g. premium VPWS service instance, 1358 and may not be used for best-effort services. 1360 (R18) VPWS OAM MUST be scalable such that a service aware device can 1361 support OAM for each VPWS service that is supported by the device. 1363 7.9. Extensibility 1365 Extensibility is intended to allow introduction of additional OAM 1366 functionality in future such that backward compatibility can be 1367 maintained when interoperating with older version devices. In such a 1368 case, VPWS service OAM with reduced functionality should still be 1369 possible. Further, VPWS service OAM should be such that OAM 1370 incapable devices in the middle of the OAM domain should be able to 1371 forward the VPWS OAM frames similar to the regular VPWS service/data 1372 frames/packets. 1374 (R19a) VPWS OAM MUST be extensible such that new functionality and 1375 information elements related to this functionality can be introduced 1376 in future. 1378 (R19b) VPWS OAM MUST be defined such that devices not supporting the 1379 OAM are able to forward the VPWS OAM frames in a similar fashion as 1380 the regular VPWS service/data frames/packets. 1382 7.10. Security 1384 VPWS OAM frames belonging to an OAM domain originate and terminate 1385 within that OAM domain. Security implies that an OAM domain must be 1386 capable of filtering OAM frames. The filtering is such that the VPWS 1387 OAM frames are prevented from leaking outside their domain. Also, 1388 VPWS OAM frames from outside the OAM domains should be either 1389 discarded (when such OAM frames belong to same or lower-level OAM 1390 domain) or transparently passed (when such OAM frames belong to a 1391 higher-level OAM domain). 1393 (R20a) VPWS OAM frames MUST be prevented from leaking outside their 1394 OAM domain. 1396 (R20b) VPWS OAM frames from outside an OAM domain MUST be prevented 1397 from entering the OAM domain when such OAM frames belong to the same 1398 level or lower-level OAM domain. 1400 (R20c) VPWS OAM frames from outside an OAM domain MUST be 1401 transported transparently inside the OAM domain when such OAM frames 1402 belong to the higher-level OAM domain. 1404 7.11. Transport Independence 1406 VPWS service frame/packets delivery is carried out across transport 1407 infrastructure, also called network infrastructure. Though specific 1408 transport/network technologies may provide their own OAM 1409 capabilities, VPWS OAM must be independently supported as many 1410 different transport/network technologies can be used to carry 1411 service frame/packets. 1413 (R21a) VPWS OAM MUST be independent of the underlying 1414 transport/network technologies and specific transport/network OAM 1415 capabilities. 1417 (R21b) VPWS OAM MAY allow adaptation/interworking with specific 1418 transport/network OAM functions. For example, this would be useful 1419 to allow Fault Notifications from transport/network layer(s) to be 1420 sent to the VPWS service layer. 1422 7.12. Application Independence 1424 VPWS service itself may be used to carry application frame/packets. 1425 The application may use its own OAM; VPWS OAM must not be dependent 1426 on application OAM. As an example, a VPWS service may be used to 1427 carry IP traffic; however, VPWS OAM should not assume IP or rely on 1428 the use of IP level OAM functions. 1430 (R22a) OAM MUST be independent of the application technologies and 1431 specific application OAM capabilities. 1433 7.13. Prioritization 1435 VPWS service could be composed of several data flows each related to 1436 a given usage/application with specific requirements in term of 1437 connectivity and/or performances. Dedicated VPWS OAM should be 1438 applicable to these flows. 1440 (R23) VPWS OAM SHOULD support configurable prioritization for OAM 1441 packet/frames to be compatible with associated VPWS service 1442 packets/frames. 1444 8. VPLS (V)LAN Emulation OAM Requirements 1446 8.1. Partial-mesh of PWs 1448 As indicated in [BRIDGE-INTEROP], VPLS service OAM relies upon 1449 bidirectional Ethernet links or (V)LAN segments and failure in one 1450 direction or link results in failure of the whole link or (V)LAN 1451 segment. Therefore, when partial-mesh failure occurs in (V)LAN 1452 emulation, either the entire PW mesh should be shutdown when only an 1453 entire VPLS service is acceptable or a subset of PWs should be 1454 shutdown such that the remaining PWs have full connectivity among 1455 them, when partial VPLS service is acceptable. 1457 (R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow 1458 detection of partial-mesh failure condition. 1460 (R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the 1461 entire mesh of PWs to be shutdown upon detection of a partial-mesh 1462 failure condition. 1464 (R13c) PW OAM for PWs related to a (V)LAN emulation MUST allow the 1465 subset of PWs to be shutdown upon detection of a partial-mesh 1466 failure condition in a manner such that full mesh is present across 1467 the remaining subset. 1469 Note: Shutdown action in R13b and R13c may not necessarily involve 1470 withdrawal of labels etc. 1472 8.2. PW Fault Recovery 1474 As indicated in [BRIDGE-INTEROP], VPLS service OAM fault detection 1475 and recovery relies upon (V)LAN emulation recovery such that fault 1476 detection and recovery time in (V)LAN emulation should be less than 1477 the VPLS service fault detection and recovery time to prevent 1478 unnecessary switch-over and temporary flooding/loop within customer 1479 OAM domain that is dual-homed to provider OAM domain. 1481 (R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a 1482 fault detection time in the provider OAM domain faster than the VPLS 1483 fault detection time in the customer OAM domain. 1485 (R14b) PW OAM for PWs related to a (V)LAN emulation MUST support a 1486 fault recovery time in the provider OAM domain faster than the VPLS 1487 fault recovery time in the customer OAM domain. 1489 8.3. Connectivity Fault Notification and Alarm Suppression 1491 When connectivity fault is detected in (V)LAN emulation, PE devices 1492 may notify the NMS (Network Management System) via alarms. However, 1493 a single (V)LAN emulation fault may result in CE devices or U-PE 1494 devices detecting connectivity fault in VPLS service and therefore 1495 also notifying the NMS. To prevent multiple alarms for the same 1496 fault, (V)LAN emulation OAM must provide alarm suppression 1497 capability in the VPLS service OAM. 1499 (R15) PW OAM for PWs related to a (V)LAN emulation MUST support 1500 interworking with VPLS service OAM to trigger fault notification and 1501 allow alarm suppression in the VPLS service upon fault detection in 1502 (V)LAN emulation. 1504 9. OAM Operational Scenarios 1506 This section highlights how the different OAM mechanisms can be 1507 applied as per the OAM framework for different L2VPN services. 1509 9.1. VPLS OAM Operational Scenarios 1510 --- --- 1511 / \ ------ ------- ---- / \ 1512 | A CE-- / \ / \ / \ --CE A | 1513 \ / \ / \ / \ / \ / \ / 1514 --- --UPE NPE NPE UPE-- --- 1515 \ / \ / \ / 1516 \ / \ / \ / 1517 ------ ------- ---- 1518 Customer OAM domain 1519 (C) MEP---MIP--------------------------------MIP---MEP 1521 Service Provider(SP) OAM domain 1522 (D) MEP--------MIP-----------MIP-------MEP 1524 SP OAM SP OAM SP OAM 1525 (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP 1526 domain domain domain 1528 Operator Operator Operator 1529 (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP 1530 OAM domain OAM domain OAM domain 1532 MPLS OAM MPLS OAM 1533 (F) MEP--MIP-----MEP--MIP--MEP 1534 domain domain 1536 Figure 10: VPLS OAM Domains, MEPs & MIPs 1538 Among the different MEs identified in Figure 5, for VPLS OAM in 1539 Customer OAM domain, [IEEE 802.1ag] and [Y.1731] Ethernet OAM 1540 mechanisms can be applied, to meet various requirements identified 1541 in Section 6. The mechanisms can be applied across Figure 10 (C) 1542 MEs. 1544 Similarly, inside the Service Provider OAM domain, [IEEE 802.1ag] 1545 and [Y.1731] Ethernet OAM mechanisms can be applied across Figure 10 1546 (D) MEs to meet functional requirements identified in Section 6. 1548 It may be noted that in the interim, when [IEEE 802.1ag] and 1549 [Y.1731] capabilities are not available across the PE devices, the 1550 fault management option using segment OAM introduced in Section 1551 5.2.3 can be applied, with the limitations cited below. In this 1552 option, the Service Provider can run segment OAM across the Figure 1553 10 (D1) MEs. The OAM mechanisms across the Figure 10 (D1) MEs can be 1554 non-Ethernet e.g. VCCV, or BFD when network technology is MPLS. The 1555 Service Provider can monitor each sub-network segment ME using the 1556 native technology OAM and by performing interworking across the 1557 segment MEs, attempt to realize end-to-end monitoring between a pair 1558 of VPLS end-points. However, such mechanisms do not fully utilize 1559 the data plane forwarding as experienced by native (i.e. Ethernet) 1560 service PDUs and therefore monitoring is severely limited in the 1561 sense that monitoring at Figure 10 (D1) and interworking across them 1562 could lead to an indication that the ME between VPLS end-points is 1563 functional while the customer may be experiencing end-to-end 1564 connectivity issues in the data plane. 1566 Inside the Network Operator OAM domain, [IEEE 802.1ag] and [Y.1731] 1567 Ethernet OAM mechanisms can also be applied across Figure 10 (E) MEs 1568 to meet functional requirements identified in Section 6. In 1569 addition, the network operator could decide to use native OAM 1570 mechanisms e.g. VCCV or BFD across Figure 10 (F) MEs for additional 1571 monitoring or as an alternative to monitoring across Figure 10 (E) 1572 MEs. 1574 10. Acknowledgments 1576 The authors would like to thank Deborah Brungard, Vasile Radoaca, 1577 Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their 1578 reviews and comments. 1580 Authors would also like to thank Shahram Davari, Norm Finn, Dave 1581 Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness, 1582 Malcolm Betts, Paul Bottorff, Hamid-ould Brahim, Lior Shabtay, and 1583 Dan Cauchy for their feedback. 1585 12. IANA Considerations 1587 This document has no actions for IANA. 1589 11. Security Considerations 1591 This document takes into account the security considerations and 1592 imposes requirements on solutions to prevent OAM messages from 1593 leaking outside an OAM domain and for OAM domains to be transparent 1594 to OAM frames from higher OAM domains, as specified in Section 6.10 1595 and 7.10. 1597 For additional levels of security, the solutions may be required to 1598 encrypt and/or authenticate OAM frames inside an OAM domain however 1599 solutions are out of the scope of this draft. 1601 13. References 1603 13.1 Normative References 1605 [IEEE 802.1ad] "IEEE Standard for Local and metropolitan area 1606 networks - virtual Bridged Local Area Networks, Amendment 4: 1607 Provider Bridges", 2005 1609 [IEEE 802.1ag] "IEEE Standard for Local and metropolitan area 1610 networks - virtual Bridged Local Area Networks, Amendment 5: 1611 Connectivity Fault Management", 2007 1613 [IEEE 802.1ah] "IEEE Standard for Local and metropolitan area 1614 networks - virtual Bridged Local Area Networks, Amendment 6: 1615 Provider Backbone Bridges", 2008 1617 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 1618 mechanisms for Ethernet based networks", February 2008 1620 [L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks 1621 (L2VPNs)", RFC 4664 1623 [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned 1624 Virtual Private Networks", RFC 4665 1626 [L2VPN-TERM] "Provider Provisioned Virtual Private Network (VPN) 1627 Terminology", RFC 4026 1629 [MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1, 2006 1631 [NM-Standards] "TMN Management Functions", M.3400, February 2000 1633 [VPLS-BGP] "Virtual Private LAN Service", RFC 4761, Jan 2007 1635 [VPLS-LDP] "Virtual Private LAN Services over MPLS", RFC 4762, Jan 1636 2007 1638 13.2 Informative References 1640 [BRIDGE-INTEROP] "VPLS Interoperability with CE Bridges", draft- 1641 ietf-l2vpn-vpls-bridge-interop-05.txt, Work in progress, March 2010 1643 [L2VPN-SIG] "Provisioning, Autodiscovery, and Signaling in L2VPNs", 1644 draft-ietf-l2vpn-signaling-08.txt, Work in progress, May 2006 1646 [MS-PW Arch] "An Architecture for Multi-segment Pseudowire Emulation 1647 Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-04.txt, Work in progress, 1648 June 2008 1650 [RFC2544] "Benchmarking Methodology for Network Interconnect 1651 Devices", RFC 2544, 1999 1653 A1. Appendix 1 - Alternate Management Models 1655 In consideration of the management models that can be deployed 1656 besides the hierarchical models elaborated in this document, this 1657 section highlights some alternate models that are not recommended 1658 due to their limitations, as pointed out below. These alternatives 1659 have been highlighted as potential interim models while the network 1660 equipments are upgraded to support full functionality and meet the 1661 requirements set forward by this document. 1663 A1.1. Alternate Model 1 (Minimal OAM) 1665 In this model, the end-to-end service monitoring is provided by 1666 applying CE to CE ME in the Service Provider OAM Domain. 1668 A MEP is located at each CE interface that is part of the VPWS 1669 service, as shown in Figure A1.1 (B). The network operators can 1670 carry out segment (e.g. PSN Tunnel ME, etc.) monitoring independent 1671 of the VPWS end-to-end service monitoring, as shown in Figure A1.1 1672 (D). 1674 The advantage of this option is that VPWS service monitoring is 1675 limited to CEs. The limitation of this option is that the 1676 localization of faults at the VPWS Service level. 1678 |<--------------- VPWS -------------->| 1679 | | 1680 | +----+ +----+ | 1681 +----+ | |==================| | +----+ 1682 | |---AC1----|............PW..............|--AC2-----| | 1683 | CE1| |PE1 | | PE2| |CE2 | 1684 +----+ | |==================| | +----+ 1685 +----+ PSN Tunnel +----+ 1687 (B) MEP-----------------------------------------------MEP 1688 (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP 1690 Figure A1.1: VPWS MEPs & MIPs - Minimal OAM 1692 A1.2. Alternate Model 2 (Segment OAM Interworking) 1694 In this model, the end-to-end service monitoring is provided by 1695 interworking OAM across each segment. Typical segments involved in 1696 this case include two AC MEs and PW ME, as shown in Figure A1.2 (C). 1697 These segments are expected in the Service Provider OAM Domain. An 1698 interworking function is required to transfer the OAM information 1699 flows across the OAM segments for the purposes of end-to-end 1700 monitoring. Depending on whether homogenous VPWS is deployed or 1701 heterogeneous VPWS is deployed, the interworking function could be 1702 straightforward or more involved. 1704 In this option, the CE and PE interfaces support MEPs for AC and PW 1705 MEs and no MIPs are involved at the Service Provider OAM Level, as 1706 shown in Figure A1.2 (C). The network operators may run segment OAM 1707 by having MEPs at Network Operator OAM level, as shown in Figure 1708 A1.2 (D). 1710 The limitations of this model are that it requires interworking 1711 across the OAM segments and does not conform to the OAM layering 1712 principles, where each OAM layer ought to be independent of the 1713 other. For end-to-end OAM determinations, the end-to-end service 1714 frame path is not necessarily exercised. Further, it requires 1715 interworking function implementation for all possible technologies 1716 across access and core that may be used to realize end-to-end 1717 services. 1719 |<--------------- VPWS -------------->| 1720 | | 1721 | +----+ +----+ | 1722 +----+ | |==================| | +----+ 1723 | |---AC1----|............PW..............|--AC2-----| | 1724 | CE1| |PE1 | | PE2| |CE2 | 1725 +----+ | |==================| | +----+ 1726 +----+ PSN Tunnel +----+ 1728 (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP 1729 (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP 1731 Figure A1.2: VPWS MEPs & MIPs - Segment OAM Interworking 1733 Authors' Addresses 1735 Ali Sajassi 1736 Cisco Systems, Inc. 1737 170 West Tasman Drive 1738 San Jose, CA 95134 1739 Email: sajassi@cisco.com 1741 Dinesh Mohan 1742 Nortel 1743 3500 Carling Ave 1744 Ottawa, ON K2H8E9 1745 Email: mohand@nortel.com 1747 Simon Delord 1748 Uecomm 1749 658 Church St 1750 Richmond, VIC, 3121, Australia 1751 E-mail: sdelord@uecomm.com.au 1753 Philippe Niger 1754 France Telecom 1755 2 av. Pierre Marzin 1756 22300 LANNION, France 1757 E-mail: philippe.niger@francetelecom.com 1759 Samer Salam 1760 Cisco Systems, Inc. 1761 170 West Tasman Drive 1762 San Jose, CA 95134 1763 Email: ssalam@cisco.com