idnits 2.17.1 draft-ietf-l2vpn-oam-req-frmk-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1711. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T Y.1731' is mentioned on line 1497, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-l2vpn-vpls-bridge-interop-02 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Mohan (Editor), Nortel 3 L2VPN Working Group A. Sajassi (Editor), Cisco 4 Intended status: Informational 5 Date Created: July 14, 2008 6 Expiration Date: January 14, 2009 8 L2VPN OAM Requirements and Framework 9 draft-ietf-l2vpn-oam-req-frmk-10.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire in January 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This draft provides framework and requirements for Layer 2 Virtual 43 Private Networks (L2VPN) Operation, Administration and Maintenance 44 (OAM). The OAM framework is intended to provide OAM layering across 45 L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) 46 tunnels. The requirements are intended to identify OAM requirement 47 for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if 48 L2VPN services OAM requirements impose specific requirements on PW 49 OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements 50 are also identified. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 When these key words are used in consideration of RFC 2119, these 59 key words are used in capitalized form as indicated above. 61 Table of Contents 63 Status of this Memo................................................1 64 Abstract...........................................................1 65 Conventions used in this document..................................2 66 1. Introduction....................................................4 67 1.1 Terminology....................................................5 68 2. L2VPN Services & Networks.......................................6 69 3. L2VPN OAM Framework.............................................7 70 3.1. OAM Layering..................................................7 71 3.2. OAM Domains...................................................8 72 3.3. MEPs and MIPs.................................................9 73 3.4. MEP and MIP Identifiers......................................10 74 4. OAM Framework for VPLS.........................................10 75 4.1. VPLS as Service/Network......................................10 76 4.1.1. VPLS as Bridged LAN Service................................10 77 4.1.2. VPLS as a Network..........................................11 78 4.1.3. VPLS as (V)LAN Emulation...................................11 79 4.2. VPLS OAM.....................................................11 80 4.2.1. VPLS OAM Layering..........................................12 81 4.2.2. VPLS OAM Domains...........................................13 82 4.2.3. VPLS MEPs & MIPs...........................................13 83 4.2.4. VPLS MEP and MIP Identifiers...............................14 84 5. OAM Framework for VPWS.........................................14 85 5.1. VPWS as Service..............................................15 86 5.2. VPWS OAM.....................................................15 87 5.2.1. VPWS OAM Layering..........................................16 88 5.2.2. VPWS OAM Domains...........................................16 89 5.2.3. VPWS MEPs & MIPs...........................................18 90 5.2.4. VPWS MEP and MIP Identifiers...............................20 91 6. VPLS Service OAM Requirements..................................20 92 6.1. Discovery....................................................20 93 6.2. Connectivity Fault Management................................20 94 6.2.1. Connectivity Fault Detection...............................20 95 6.2.2. Connectivity Fault Verification............................21 96 6.2.3. Connectivity Fault Localization............................21 97 6.2.4. Connectivity Fault Alarm...................................21 98 6.3. Frame Loss...................................................21 99 6.4. Frame Delay..................................................22 100 6.5. Frame Delay Variation........................................22 101 6.6. Availability.................................................22 102 6.7. Data Path Forwarding.........................................23 103 6.8. Scalability..................................................23 104 6.9. Extensibility................................................23 105 6.10. Security....................................................24 106 6.11. Transport Independence......................................24 107 6.12. Application Independence....................................24 108 7. VPWS OAM Requirements..........................................25 109 7.1. Discovery....................................................25 110 7.2. Connectivity Fault Management................................25 111 7.2.1. Connectivity Fault Detection...............................25 112 7.2.2. Connectivity Fault Verification............................25 113 7.2.3. Connectivity Fault Localization............................26 114 7.2.4. Connectivity Fault Alarm...................................26 115 7.3. Frame Loss...................................................26 116 7.4. Frame Delay..................................................27 117 7.5. Frame Delay Variation........................................27 118 7.6. Availability.................................................27 119 7.7. Data Path Forwarding.........................................28 120 7.8. Scalability..................................................28 121 7.9. Extensibility................................................28 122 7.10. Security....................................................29 123 7.11. Transport Independence......................................29 124 7.12. Application Independence....................................29 125 7.13. Prioritization..............................................30 126 8. VPLS (V)LAN Emulation OAM Requirements.........................30 127 8.1. Partial-mesh of PWs..........................................30 128 8.2. PW Fault Recovery............................................30 129 8.3. Connectivity Fault Notification..............................31 130 9. OAM Operational Scenarios......................................31 131 9.1. VPLS OAM Operational Scenarios...............................31 132 10. Acknowledgments...............................................32 133 12. IANA Considerations...........................................33 134 11. Security Considerations.......................................33 135 13. References....................................................33 136 13.1 Normative References.........................................33 137 13.2 Informative References.......................................34 138 A1. Appendix 1 - Alternate Management Models......................34 139 A1.1. Alternate Model 1 (Minimal OAM).............................34 140 A1.2. Alternate Model 2 (Segment OAM Interworking)................35 141 Intellectual Property Statement...................................36 142 Authors' Addresses................................................36 143 Full Copyright Statement..........................................37 145 1. Introduction 147 This draft provides framework and requirements for Layer 2 Virtual 148 Private Networks (L2VPN) Operation, Administration and Maintenance 149 (OAM). 151 The scope of OAM for any service and/or transport/network 152 infrastructure technologies can be very broad in nature. OSI has 153 defined the following five generic functional areas commonly 154 abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b) 155 Performance Management, c) Configuration Management, d) Accounting 156 Management, and e) Security Management. 158 This draft focuses on the Fault and Performance Management aspects. 159 Other functional aspects of FCAPS are for further study. 161 Fault Management can typically be viewed in terms of the following 162 categories: 163 - Fault Detection 164 - Fault Verification 165 - Fault Isolation 166 - Fault Notification 167 - Fault Recovery 169 Fault Detection deals with mechanism(s) that can detect both hard 170 failures, such as link and device failures, and soft failures, such 171 as software failure, memory corruption, mis-configuration, etc. 172 Typically a lightweight protocol is desirable to detect the fault 173 and thus it would be prudent to verify the fault via Fault 174 Verification mechanism before taking additional steps in isolating 175 the fault. After verifying that a fault has occurred along the data 176 path, it is important to be able to isolate the fault to the level 177 of a given device or link. Therefore, a Fault Isolation mechanism is 178 needed in Fault Management. Fault Notification mechanism can be used 179 in conjunction with Fault Detection mechanism to notify the devices 180 upstream and downstream to the fault detection point. For example, 181 when there is a client/server relationship between two layered 182 networks, Fault Detection at the server layer may result in the 183 following Fault Notifications: 184 - sending a forward Fault Notification from server layer to the 185 client layer network(s) using the Fault Notification format 186 appropriate to the client layer 188 - sending a backward Fault Notification at server layer, if 189 applicable, in the reverse direction 190 - sending a backward Fault Notification at client layer, if 191 applicable, in the reverse direction 193 Finally, Fault Recovery deals with recovering from the detected 194 failure by switching to an alternate available data path using 195 alternate devices or links (e.g., device redundancy or link 196 redundancy). 198 Performance Management deals with mechanism(s) that allow 199 determining and measuring the performance of network/services under 200 consideration. Performance Management can be used to verify the 201 compliance to both the service and network level metric 202 objectives/specifications. Performance Management typically consists 203 of measurement of performance metrics e.g. Frame Loss, Frame Delay, 204 Frame Delay Variation (aka Jitter) etc. across managed entities when 205 the managed entities are in available state. Performance Management 206 is suspended across unavailable managed entities. 208 [L2VPN-FRWK] specifies three different types of Layer 2 VPN 209 services. These are VPWS, VPLS and IPLS. 211 This document provides a reference model for OAM as it relates to 212 L2VPN services and their associated Pseudo Wires (PWs) and Public 213 Switched Network (PSN) tunnels. OAM requirement for L2VPN services 214 (e.g. VPLS and VPWS) are also identified. Furthermore, if L2VPN 215 services OAM requirements impose requirements for PW and/or PSN OAM, 216 those specific PW and/or PSN OAM requirements are also identified. 218 1.1 Terminology 220 This document introduces and uses the following terms. Further, this 221 document also uses the terms defined in [L2VPN-FRWK] and [L2VPN- 222 TERM]. 224 AIS Alarm Indication Signal 225 FM Fault Management 226 IPLS IP-only LAN Service 227 ME Maintenance Entity which is defined in a given OAM 228 domain and represents an entity requiring monitoring 229 MEG Maintenance Entity Group which represents MEs belonging 230 to the same service instance. MEG is also called as 231 Maintenance Association (MA). 232 MEP Maintenance End Point is responsible for origination 233 and termination of OAM frames for a given MEG 234 MIP Maintenance Intermediate Point is located between peer 235 MEPs and can process OAM frames but does not initiate 236 or terminate them 237 OAM Domain OAM Domain represents a region over which OAM frames 238 can operate unobstructed 239 PM Performance Management 240 RDI Remote Defect Indication 241 SLA Service Level Agreement 242 STP Spanning Tree Protocols 243 VPLS Virtual Private LAN Service 244 VPWS Virtual Private Wire Service 246 2. L2VPN Services & Networks 248 As described in [L2VPN-REQ], following Figure 1 shows a L2VPN 249 reference model. L2VPN A represents a point-to-point service while 250 L2VPN B represents a bridged service. 252 +-----+ +-----+ 253 + CE1 +--+ +--| CE2 | 254 +-----+ | ..................... | +-----+ 255 L2VPN A | +----+ +----+ | L2VPN A 256 +--| PE |-- Service --| PE |--+ 257 +----+ Provider +----+ 258 / . Backbone . \ --------_ 259 +-----+ / . | . \ / \ +-----+ 260 + CE4 +--+ . | . +-\ Access \--| CE5 | 261 +-----+ . +----+ . | Network | +-----+ 262 L2VPN B ........| PE |....... \ / L2VPN B 263 +----+ ^ ------- 264 | | logical 265 | | switching 266 +-----+ | instance 267 | CE3 | 268 +-----+ 269 L2VPN B 271 Figure 1: L2VPN Reference Model 273 [L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a 274 point-to-point service where CEs are presented with point-to-point 275 virtual circuits. VPLS is a bridged LAN service provided to a set of 276 CEs that are members of a VPN. CEs that are members of the same 277 service instance communicate with each other as if they are 278 connected via a bridged LAN. IPLS is a special VPLS which is used to 279 carry only IP service packets. 281 [L2VPN-REQ] assumes the availability of runtime monitoring protocols 282 while defining requirements for management interfaces. This draft 283 specifies the requirements and framework for operations, 284 administration and maintenance (OAM) protocols between network 285 devices. 287 3. L2VPN OAM Framework 288 3.1. OAM Layering 290 The point-to-point or bridged LAN functionality is emulated by a 291 network of PEs to which the CEs are connected. This network of PEs 292 can belong to a single network operator or can span across multiple 293 network operators. Furthermore, it can belong to a single service 294 provider or can span across multiple service providers. A service 295 provider is responsible for providing L2VPN services to its 296 customers; whereas, a network operator (aka facility provider) 297 provides the necessary facilities to the service provider(s) in 298 support of their services. A network operator and a service 299 provider can be part of same administrative organization or they can 300 be different administrative organizations. 302 Different layers involved in realizing L2VPNs include service layer 303 and network layers. Network layers can be iterative. In context of 304 L2VPNs, the service layers consists of VPLS, VPWS (e.g. Ethernet, 305 ATM, FR, HDLC, SONET, etc. point-to-point emulation), and IPLS. 306 Similarly in context of L2VPNs, network layers consist of MPLS/IP 307 networks. The MPLS/IP networks can consist of networks links 308 realized by different technologies e.g. SONET, Ethernet, ATM etc. 310 Each layer is responsible for its own OAM. This document provides 311 the OAM framework and requirements for L2VPN services and networks. 313 3.2. OAM Domains 315 When discussing OAM tools for L2VPNs it is important to provide OAM 316 capabilities and functionality over each domain that a service 317 provider or a network operator is responsible for. For these 318 reasons, it is also important that OAM frames are not allowed to 319 enter/exit other domains. We define an OAM domain as a network 320 region over which OAM frames operate unobstructed as explained 321 below. 323 At the edge of an OAM domain, filtering constructs should prevent 324 OAM frames from exiting and entering that domain. OAM domains can be 325 nested but not overlapped. In other words, if there is a hierarchy 326 of the OAM domains, the OAM frames of a higher-level domain pass 327 transparently through the lower-level domains but the OAM frames of 328 a lower-level domain get blocked/filtered at the edge of that 329 domain. 331 In order to facilitate the processing of OAM frames, each OAM domain 332 can be associated with a level at which it operates. Higher level 333 OAM domains can contain lower level OAM domains but the converse is 334 not true. It may be noted that the higher level domain does not 335 necessarily mean a higher numerical value of the level encoding in 336 the OAM frame. 338 A PE can be part of several OAM domains with each interface 339 belonging to the same or a different OAM domain. A PE shall block 340 outgoing OAM frames and filter out incoming OAM frames whose domain 341 level is lower or same to the one configured on that interface and 342 pass through the OAM frames whose domain level is higher than the 343 one configured on that interface. 345 Generically, L2VPNs can be viewed as consisting of customer OAM 346 domain, service provider OAM domain, and network operator OAM domain 347 as depicted in Figure 2. 349 --- --- 350 / \ ------ ------- ----- / \ 351 | CE-- / \ / \ / \ --CE | 352 \ / \ / \ / \ / \ / \ / 353 --- --PE P P PE-- --- 354 \ / \ / \ / 355 \ / \ / \ / 356 ------ ------- ----- 358 Customer OAM Domain 359 |<-------------------------------------------->| 361 Service Provider OAM Domain 362 |<------------------------------>| 364 Operator Operator Operator 365 |<-------->|<--------->|<------->| 366 OAM Domain OAM Domain OAM Domain 368 Figure 2: OAM Domains 370 The OAM Domains can be categorized as: 372 . Hierarchical OAM Domains: Hierarchical OAM Domains result from 373 OAM Layering and imply a contractual agreement among the OAM 374 Domain ownerships. In the above example, Customer OAM Domain, 375 Service Provider OAM Domain and Operator OAM Domains are 376 hierarchical. 377 . Adjacent OAM Domains: Adjacent OAM Domains are typically 378 independent of each other and do not have any relationship 379 among them. In the above example, the different Operator OAM 380 Domains are independent of each other. 382 3.3. MEPs and MIPs 384 Maintenance End Points (MEPs) are responsible for origination and 385 termination of OAM frames. MEPs are located at the edge of their 386 corresponding OAM domains. Maintenance Intermediate Points (MIPs) 387 are located within their corresponding OAM domains and they normally 388 pass OAM frames but never initiate them. Since MEPs are located at 389 the edge of their OAM domains, they are responsible for filtering 390 outbound OAM frames from leaving the OAM domain or inbound OAM 391 frames from entering the OAM domain. 393 An OAM frame is generally associated with a Maintenance Entity (ME) 394 or a Maintenance Entity Group (MEG), where a MEG consists of a set 395 of MEs associated with the same service instance. A ME is a point- 396 to-point association between a pair of MEPs and represents a 397 monitored entity. For example, in a VPLS service which involves n 398 CEs, all the MEs associated with the VPLS service in the customer 399 OAM domain (i.e. from CE to CE) can be considered to be part of a 400 VPLS MEG, where the n-point MEG consists of a maximum of n(n-1)/2 401 MEs. MEPs and MIPs correspond to a PE or more specifically to an 402 interface of a PE. For example, an OAM frame can be said to 403 originate from an ingress PE or more specifically an ingress 404 interface of that PE. A MEP on a PE receives messages from n-1 other 405 MEPs (some of them may reside on the same PE) for a given MEG. 407 In Hierarchical OAM Domains, a MEP of lower-level OAM domain can 408 correspond to a MIP or a MEP of a higher-level OAM domain. 409 Furthermore, the MIPs of a lower-level OAM domain are always 410 transparent to the higher-level OAM domain (e.g., OAM frames of a 411 higher-level OAM domain are not seen by MIPs of a lower-level OAM 412 domain and get passed through them transparently). Further, the MEs 413 (or MEGs) are hierarchically organized in hierarchical OAM domains. 414 For example, in a VPWS service, the VPWS ME in Customer OAM domain 415 can coincide with the Attachment Circuit (AC) ME, PW ME and another 416 AC ME in Service Provider OAM Domain. Similarly, the PW ME can 417 coincide with different ME in Operator OAM Domains. 419 3.4. MEP and MIP Identifiers 421 As mentioned previously, OAM at each layer should be independent of 422 other layers e.g. service layer OAM should be independent of 423 underlying transport layer. MEPs and MIPs at each layer should be 424 identified with layer specific identifiers. 426 4. OAM Framework for VPLS 428 Virtual Private LAN Service (VPLS) is used in different contexts. In 429 general, VPLS is used in the following contexts: a) as a bridged LAN 430 service over networks, some of which are MPLS/IP, b) as an MPLS/IP 431 network supporting these bridged LAN services, and c) as (V)LAN 432 emulation. 434 4.1. VPLS as Service/Network 436 4.1.1. VPLS as Bridged LAN Service 438 The most common definition for VPLS is for bridged LAN service over 439 an MPLS/IP network. The service coverage is considered end-to-end 440 from UNI to UNI (or AC to AC) among the CE devices and it provides a 441 virtual LAN service to the attached CEs belonging to that service 442 instance. The reason it is called bridged LAN service is because the 443 VPLS-capable PE providing this end-to-end virtual LAN service is 444 performing bridging functions (either full or a subset) as described 445 in the [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN- 446 REQ], includes both bridge module and LAN emulation module (as 447 specified in [L2VPN-FRWK]). 449 A VPLS service instance is also analogous to a VLAN provided by IEEE 450 802.1Q networks since each VLAN provides a Virtual LAN service to 451 its MAC users. Therefore, when a part of the service provider 452 network is Ethernet based (such as H-VPLS with QinQ access network), 453 there is a one-to-one correspondence between a VPLS service instance 454 and its corresponding provider VLAN in the service provider Ethernet 455 network. To check the end-to-end service integrity, the OAM 456 mechanism needs to cover the end-to-end VPLS service as defined in 457 [L2VPN-REQ] which is from AC to AC including bridge module, VPLS 458 forwarder, and the associated PWs for this service. This draft 459 specifies the framework and requirements for such OAM mechanism. 461 4.1.2. VPLS as a Network 463 Sometimes VPLS is also used to refer to the underlying network that 464 supports bridged LAN services. This network can be an end-to-end 465 MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid 466 network consisting of MPLS/IP core and Ethernet access network as in 467 H-VPLS with QinQ access. In either case, the network consists of a 468 set of VPLS-capable PE devices capable of performing bridging 469 functions (either full or a subset). These VPLS-capable PE devices 470 can be arranged in a certain topology such as hierarchical topology 471 (H-VPLS) or distributed topology (D-VPLS) or some other topologies 472 such as multi-tier or star topologies. To check the network 473 integrity regardless of the network topology, network-level OAM 474 mechanisms (such as OAM for MPLS/IP networks) are needed. The 475 discussion of network-level OAM is outside of the scope of this 476 draft. 478 4.1.3. VPLS as (V)LAN Emulation 480 Sometimes VPLS also refers to (V)LAN emulation. In such context, 481 VPLS only refers to the full mesh of PWs with split horizon that 482 emulates a LAN segment over MPLS/IP network for a given service 483 instance and its associated VPLS forwarder. Since the emulated LAN 484 segment is presented as a Virtual LAN (VLAN) to the bridge module of 485 a VPLS-capable PE, the emulated segment is also referred to as an 486 emulated VLAN. The OAM mechanisms in this context refer primarily to 487 integrity check of VPLS forwarders and its associated full-mesh of 488 PWs and the ability to detect and notify a partial mesh failure. 489 This draft also covers the OAM framework and requirements for such 490 OAM mechanism. 492 4.2. VPLS OAM 494 When discussing the OAM mechanisms for VPLS, it is important to 495 consider that the end-to-end service can span across different types 496 of L2VPN networks. As an example, in case of [VPLS-LDP], the access 497 network on one side can be bridged network e.g. [IEEE 802.1ad], as 498 described in section 11 of [VPLS-LDP]. The access network can also 499 be a [IEEE 802.1ah] based bridged network. The access network on 500 other side can be MPLS based as described in section 10 of [VPLS- 501 LDP]; and the core network connecting them can be IP, MPLS, ATM, or 502 SONET. Similarly, the VPLS service instance can span across [VPLS- 503 BGP], and distributed VPLS as described in [L2VPN-SIG]. 505 Therefore, it is important that the OAM mechanisms can be applied to 506 all these network types. Each such network may be associated with a 507 separate administrative domain and also multiple such networks may 508 be associated with a single administrative domain. It is important 509 to ensure that the OAM mechanisms are independent of the underlying 510 transport mechanisms and solely rely on VPLS service, i.e. the 511 transparency of OAM mechanisms must be ensured over underlying 512 transport technologies such as MPLS, IP, etc. 514 This proposal is aligned with the current discussions in other 515 standard bodies and groups such as ITU-T Q.5/13, IEEE 802.1, and MEF 516 which are addressing Ethernet network and service OAM. 518 4.2.1. VPLS OAM Layering 520 Figure 3 shows an example of a VPLS service (with two CE belonging 521 to customer A) across a service provider network marked by UPE and 522 NPE devices. More CE devices belonging to the same Customer A can be 523 connected across different sites of customer. Service provider 524 network is segmented into core network and two types of access 525 network. Figure 3(A) shows the bridged access network represented by 526 its bridge components marked B, and the MPLS access and core network 527 represented by MPLS components marked P. Figure 3(B) shows the 528 service/network view at the Ethernet MAC layer marked by E. 530 --- --- 531 / \ ------ ------- ---- / \ 532 | A CE-- / \ / \ / \ --CE A | 533 \ / \ / \ / \ / \ / \ / 534 --- --UPE NPE NPE UPE-- --- 535 \ / \ / \ / 536 \ / \ / \ / 537 ------ ------- ---- 539 (A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE 541 (B) E------E---E--E---E------------E----------E-----E 543 Figure 3: VPLS specific device view 545 As shown in Figure 3(B), only the devices with Ethernet 546 functionality are visible to OAM mechanisms operating at Ethernet 547 MAC layer and the P devices are invisible. Therefore, the OAM along 548 the path of P devices (e.g., between two PEs) is covered by 549 transport layer and it is outside the scope of this document. 551 However, VPLS services may impose some specific requirements on PSN 552 OAM. This document aims to identify such requirements. 554 4.2.2. VPLS OAM Domains 556 As described in the previous section, a VPLS service for a given 557 customer can span across one or more service providers and network 558 operators. Figure 4 depicts three OAM domains: (A) customer domain 559 which is among the CEs of a given customer, (B) service provider 560 domain which is among the edge PEs of the given service provider, 561 and (C) network operator domain which is among the PEs of a given 562 operator. 564 --- --- 565 / \ ------ ------- ---- / \ 566 | CE-- / \ / \ / \ --CE | 567 \ / \ / \ / \ / \ / \ / 568 --- --UPE NPE NPE UPE-- --- 569 \ / \ / \ / 570 \ / \ / \ / 571 ------ ------- ---- 573 Customer OAM Domain 574 (A) |<----------------------------------------------->| 576 Provider OAM Domain 577 (B) |<---------------------------------->| 579 Operator Operator Operator 580 (C) |<--------->|<---------->|<-------->| 581 OAM Domain OAM Domain OAM Domain 583 Figure 4: VPLS OAM Domains 585 4.2.3. VPLS MEPs & MIPs 587 As shown in Figure 5, (C) represents those MEPs and MIPs that are 588 visible within the customer domain. The MIP associated with (C) are 589 expected to be implemented in the bridge module/VPLS forwarder of a 590 PE device, as per the [L2VPN-FRWK]. (D) represents the MEPs and MIPs 591 visible within the service provider domain. These MEPs and MIPs are 592 expected to be implemented in the bridge module/VPLS forwarder of a 593 PE device, as per the [L2VPN-FRWK]. (E) represents the MEPs and MIPs 594 visible within each operator domain where MIPs only exist in an 595 Ethernet access network (e.g., an MPLS access network doesn't have 596 MIPs at the operator level). Further, (F) represents the MEPs and 597 MIPs corresponding to the MPLS layer and may apply MPLS based 598 mechanisms. The MPLS layer shown in Figure 5 is just an example and 599 specific OAM mechanisms are outside the scope of this document. 601 --- --- 602 / \ ------ ------- ---- / \ 603 | A CE-- / \ / \ / \ --CE A | 604 \ / \ / \ / \ / \ / \ / 605 --- --UPE NPE NPE UPE-- --- 606 \ / \ / \ / 607 \ / \ / \ / 608 ------ ------- ---- 610 (A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE 611 (B) E------E---E------E------------E----------E-----E 613 Customer OAM domain 614 (C) MEP---MIP--------------------------------MIP---MEP 616 Provider OAM domain 617 (D) MEP--------MIP-----------MIP-------MEP 619 Operator Operator Operator 620 (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP 621 OAM domain OAM domain OAM domain 623 MPLS OAM MPLS OAM 624 (F) MEP--MIP--MEP|MEP-MIP-MEP 625 domain domain 627 Figure 5: VPLS OAM Domains, MEPs & MIPs 629 4.2.4. VPLS MEP and MIP Identifiers 631 In VPLS, for Ethernet MAC layer, the MEPs and MIPs should be 632 identified with their Ethernet MAC addresses. As described in [VPLS- 633 LDP], VPLS instance can be identified in an Ethernet domain (e.g., 634 802.1ad domain) using VLAN tag (service tag) while in an MPLS/IP 635 network, PW-ids are used. Both PW-ids and VLAN tags for a given VPLS 636 instance are associated with a Service Identifier (e.g., VPN 637 identifier). MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids, 638 must be unique within their corresponding Service Identifiers within 639 the OAM domains. 641 For Ethernet services, e.g. VPLS, Ethernet frames are used for OAM 642 frames and the source MAC address of the OAM frames represent the 643 source MEP in that domain. For unicast Ethernet OAM frames, the 644 destination MAC address represents the destination MEP in that 645 domain. For multicast Ethernet OAM frames, the destination MAC 646 addresses corresponds to all MEPs in that domain. 648 5. OAM Framework for VPWS 650 Figure 6 shows the VPWS reference model. VPWS is a point-to-point 651 service where CEs are presented with point-to-point virtual 652 circuits. VPWS is realized by combining a pair of Attachment 653 Circuits between the CEs and PEs and a PW between PEs. 655 |<------------- VPWS1 ------------>| 656 | | 657 | +----+ +----+ | 658 +----+ | |==================| | +----+ 659 | |---AC11---| |.......PW1........| |--AC12----| | 660 | CE1| |PE1 | | PE2| |CE2 | 661 | |---AC21---| |.......PW2........| |--AC22----| | 662 +----+ | |==================| | +----+ 663 | +----+ PSN Tunnel +----+ | 664 | | 665 |<------------- VPWS2 ------------>| 667 Figure 6: VPWS Reference Model 669 5.1. VPWS as Service 671 VPWS service can be categorized as: 672 . VPWS with homogeneous ACs (where both ACs are same type) 673 . VPWS with heterogeneous ACs (where the ACs are of different 674 Layer-2 encapsulation) 676 Further, the VPWS can itself be classified as: 677 . Homogeneous VPWS (when two ACs and PW are of the same type) 678 . Heterogeneous VPWS (when at least one AC or PW is different 679 type than the others) 681 Based on the above classifications, the heterogeneous VPWS may have 682 either homogeneous or heterogeneous ACs. On the other hand, 683 homogeneous VPWS can have only homogeneous ACs. 685 5.2. VPWS OAM 687 When discussing the OAM mechanisms for VPWS, it is important to 688 consider that the end-to-end service can span across different types 689 of networks. As an example, the access network between CE and PE on 690 one side can be Ethernet bridged network, ATM network, etc. In 691 common scenarios, it could simply be a point-to-point interface such 692 as Ethernet PHY. The core network connecting PEs can be IP, MPLS, 693 etc. 695 Therefore, it is important that the OAM mechanisms can be applied to 696 different network types some of which are mentioned above. Each such 697 network may be associated with a separate administrative domain and 698 also multiple such networks may be associated with a single 699 administrative domain. 701 5.2.1. VPWS OAM Layering 703 Figure 7 shows an example of a VPWS service (with two CE devices 704 belonging to customer A) across a service provider network marked by 705 PE devices. Service provider network can be considered to be 706 segmented into a core network and two types of access network. 708 In the most general case, a PE can be client service aware when it 709 processes client service PDUs and is responsible for encapsulating 710 and de-encapsulating client service PDUs onto PWs and ACs. This is 711 particularly relevant for homogeneous VPWS. The service specific 712 device view for such a deployment is highlighted by Figure 7(A) for 713 these are the devices that are expected to be involved in end-to-end 714 VPWS OAM. 716 In other instances, a PE can be client service unaware when it does 717 not process native service PDUs but instead encapsulates access 718 technology PDUs over PWs. This may be relevant for VPWS with 719 heterogeneous ACs. For example, if the service is Ethernet VPWS 720 which is offered across an ATM AC, ATM PW and Ethernet AC. In this 721 case, the PE which is attached to ATM AC and ATM PW may be 722 transparent to the client Ethernet service PDUs. On the other hand, 723 the PE which is attached to ATM PW and Ethernet AC is expected to be 724 client Ethernet service aware. The service specific device view for 725 such a deployment is highlighted by Figure 7(B) for these are the 726 devices that are expected to be involved in end-to-end VPWS OAM, 727 where PE1 is expected to be client service unaware. 729 |<--------------- VPWS -------------->| 730 | | 731 | +----+ +----+ | 732 +----+ | |==================| | +----+ 733 | |---AC1----|............PW..............|--AC2-----| | 734 | CE1| |PE1 | | PE2| |CE2 | 735 +----+ | |==================| | +----+ 736 +----+ PSN Tunnel +----+ 738 access core access 739 |<---------->|<---------------------->|<------------>| 741 (A).CE----------PE-----------------------PE-------------CE 743 (B).CE-----------------------------------PE-------------CE 745 Figure 7: VPWS specific device view 747 5.2.2. VPWS OAM Domains 748 As described in the previous section, a VPWS service for a given 749 customer can span across one or more network operators. 751 Figure 8a and 8b depicts three OAM domains: (A) customer domain 752 which is among the CEs of a given customer, (B) service provider 753 domain which depends on the management model, and (C) network 754 operator domain which is among the PEs of a given operator and could 755 also be present in the access network if the ACs are provided by a 756 different network operator. The core network operator may be 757 responsible for managing the PSN Tunnel in these examples. 759 For the first management model, as shown in Figure 8a, the CEs are 760 expected to be managed by the customer and the customer is 761 responsible for running end-to-end service OAM, if needed. The 762 service provider is responsible for monitoring the PW ME and the 763 monitoring of the AC is the shared responsibility of the customer 764 and the service provider. In most simple cases, when the AC is 765 realized across a physical interface that connects the CE to PE, the 766 monitoring requirements across the AC ME are minimal. 768 |<--------------- VPWS -------------->| 769 | | 770 | +----+ +----+ | 771 +----+ | |==================| | +----+ 772 | |---AC1----|............PW..............|--AC2-----| | 773 | CE1| |PE1 | | PE2| |CE2 | 774 +----+ | |==================| | +----+ 775 +----+ PSN Tunnel +----+ 777 Customer OAM Domain 778 (A).|<------------------------------------------------->| 780 Service Provider OAM Domain 781 (B) |<--------------------------->| 783 Operator OAM Domain 784 (C) |<---------------->| 786 Figure 8a: VPWS OAM Domains - Management Model 1 788 Figure 8b highlights another management model, where the CEs are 789 managed by the Service Provider and where CEs and PEs are connected 790 via an access network. The access network between the CEs and PEs 791 may or may not be provided by a distinct network operator. In this 792 model, the VPWS service ME spans between the CEs in the Service 793 Provider OAM Domain, as shown by Figure 8b(B). The Service Provider 794 OAM Domain may additionally monitor the AC MEs and PW MEs 795 individually, as shown by Figure 8b(C). The network operators may be 796 responsible for managing the access service MEs (e.g. access 797 tunnels) and core PSN Tunnel MEs, as shown by Figure 8b(D). The 798 distinction between Figure 8b-(C) and 8(b)-D) is that in (C), MEs 799 have MEPs at CEs and at PEs, and have no MIPs. While in (D) MEs have 800 MEPs at CEs and at PEs and furthermore, MIPs may be present in 801 between the MEPs; thereby, providing visibility of the network to 802 the operator. 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 (SP) OAM Domain 817 (B) |<------------------------------------------------>| 819 SP OAM SP OAM SP OAM 820 (C) |<--------->|<----------------------->|<---------->| 821 Domain Domain Domain 823 Operator Operator Operator 824 (D) |<--------->|<----------------------->|<---------->| 825 OAM Domain OAM Domain OAM Domain 827 Figure 8b: VPWS OAM Domains - Management Model 2 829 Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where 830 multiple operator domains may occur between the U-PE devices, VPWS 831 OAM domain in Figure 8a and 8b highlight a single Operator domain 832 between PE devices. This is since unlike the distributed VPLS PE 833 case (H-VPLS) where VPLS service aware U-PEs and N-PEs may be used 834 to realize a distributed PE, the VPWS has no such distributed PE 835 model. If the PSN involves multiple Operator domains, resulting in a 836 Multi-segment PW [Ms-PW Arch], VPWS OAM Domains remain unchanged 837 since S-PEs are typically not aware of native service. 839 5.2.3. VPWS MEPs & MIPs 841 The location of MEPs and MIPs can be based upon the management model 842 used in the VPWS scenarios. The interest remains in being able to 843 monitor end-to-end service and also support segment monitoring in 844 the network to allow isolation of faults to specific areas within 845 the network. 847 The end-to-end service monitoring is provided by end-to-end ME and 848 additional segment OAM monitoring is provided by segment MEs, all in 849 the Service Provider OAM Domain. The end-to-end MEs and segment MEs 850 are hierarchically organized as mentioned earlier for hierarchical 851 OAM domains. This is shown in Figure 8b (B) and (C). 853 The CE interfaces support MEPs at the end-to-end Service Provider 854 OAM level for VPWS as an end-to-end service as shown in Figure 9 855 (B1) and (B2). In addition, PE interfaces may support MIPs at end- 856 to-end Service Provider OAM level when PEs are client service aware, 857 as shown in Figure 9 (B2). As an example, if one considers an end- 858 to-end Ethernet line service offered to a subscriber between CE1 and 859 CE2 which is realized via ATM type AC1 and AC2 and PW which 860 encapsulates ATM over MPLS, the PEs can be considered as Ethernet 861 service unaware, and therefore cannot support any Ethernet MIPs. 862 Figure 9 (B1) represents this particular situation. Of course, 863 another view of the end-to-end service can be ATM, in which case PE1 864 and PE2 can be considered to be service aware, and therefore support 865 ATM MIPs. Figure 9 (B2) represents this particular situation. 867 In addition, CEs and PE interfaces support MEPs at a segment (lower 868 level) Service Provider OAM level for AC and PW MEs and no MIPs are 869 involved at this segment Service Provider OAM Level, as shown in 870 Figure 9 (C). Operators may also run segment OAM by having MEPs at 871 Network Operator OAM level, as shown in Figure 9 (D). 873 The advantage of having layered OAM is that end-to-end and segment 874 OAM can be carried out in an independent manner. It is also possible 875 to carry out some optimizations, e.g. when proactive segment OAM 876 monitoring is performed, proactive end-to-end monitoring may not be 877 needed since client layer end-to-end ME could simply use fault 878 notifications from the server layer segment MEs. 880 Although many different OAM layers are possible, as shown in Figure 881 9, not all may be realized. For example, Figure (B2) and (D) may be 882 adequate in some cases. 884 |<--------------- VPWS -------------->| 885 | | 886 | +----+ +----+ | 887 +----+ | |==================| | +----+ 888 | |---AC1----|............PW..............|--AC2-----| | 889 | CE1| |PE1 | | PE2| |CE2 | 890 +----+ | |==================| | +----+ 891 +----+ PSN Tunnel +----+ 893 (B1) MEP-----------------------------------------------MEP 894 (B2) MEP----------MIP---------------------MIP----------MEP 895 (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP 896 (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP 897 Figure 9: VPWS MEPs & MIPs 899 5.2.4. VPWS MEP and MIP Identifiers 901 In VPWS, the MEPs and MIPs should be identified with their native 902 addressing schemes. MEPs and MIPs Identifiers, i.e. MEP Ids and MIP 903 Ids, must be unique within their corresponding OAM domains and must 904 also be unique to the VPWS service instance. 906 6. VPLS Service OAM Requirements 908 These requirements are applicable to VPLS PE offering VPLS as an 909 Ethernet Bridged LAN service, as described in Section 4.1.1. 910 Further, the performance metrics used in requirements are based on 911 [MEF10.1] and [RFC2544]. 913 It is noted that OAM solutions that meet the following requirements 914 may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc. 915 however must not break these existing OAM mechanisms. If extensions 916 are required to existing OAM mechanisms, these should be coordinated 917 with relevant groups responsible for these OAM mechanisms. 919 6.1. Discovery 921 Discovery allows a VPLS service aware device to learn about other 922 devices that support the same VPLS service instance within a given 923 domain. 925 Discovery also allows a VPLS service aware device to learn 926 sufficient information (e.g. IP addresses, MAC addressed etc.) from 927 other VPLS service aware devices such that VPLS OAM frames can be 928 exchanged among the service aware devices. 930 (R1) VPLS OAM MUST allow a VPLS service aware device to discover 931 other devices that share the same VPLS service instance(s) within a 932 given OAM domain. 934 6.2. Connectivity Fault Management 936 VPLS service is realized by exchanging service frames/packets 937 between devices that support the same VPLS service instance. To 938 allow the exchange of service frames, connectivity between these 939 service aware devices is required. 941 6.2.1. Connectivity Fault Detection 943 To ensure service, pro-active connectivity monitoring is required. 944 Connectivity monitoring facilitates connectivity fault detection. 946 (R2a) VPLS OAM MUST allow pro-active connectivity monitoring between 947 two VPLS service aware devices that support the same VPLS service 948 instance within a given OAM domain. 950 6.2.2. Connectivity Fault Verification 952 Once a connectivity fault is detected, connectivity fault 953 verification may be performed. 955 (R2b) VPLS OAM MUST allow connectivity fault verification between 956 two VPLS service aware devices that support the same VPLS service 957 instance within a given OAM domain. 959 6.2.3. Connectivity Fault Localization 961 Further, localization of connectivity fault may be carried out. 963 (R2c) VPLS OAM MUST allow connectivity fault localization between 964 two VPLS service aware devices that support the same VPLS service 965 instance within a given OAM domain. 967 6.2.4. Connectivity Fault Alarm 969 Typically, when connectivity fault is detected and optionally 970 verified, VPLS service device may notify the NMS (Network Management 971 System). 973 However, a single transport/network fault may cause multiple 974 services to fail simultaneously causing multiple connectivity 975 faults. Therefore, VPLS OAM must allow suppression of service 976 connectivity faults. 978 (R2d) VPLS OAM MUST allow forwarding of transport/network fault 979 indications to those VPLS service aware devices that support VPLS 980 service instances affected by the fault. 982 6.3. Frame Loss 984 A VPLS service may be considered degraded if service-layer 985 frames/packets are lost during transit between the VPLS service 986 aware devices. To determine if a VPLS service is degraded due to 987 frame/packet loss, measurement of frame/packet loss is required. 989 (R3) VPLS OAM MUST support measurement of per-service frame/packet 990 loss between two VPLS service aware devices that support the same 991 VPLS service instance within a given OAM domain. 993 6.4. Frame Delay 995 A VPLS service may be sensitive to delay experienced by the VPLS 996 frames/packets during transit between the VPLS service aware 997 devices. To determine if a VPLS service is degraded due to 998 frame/packet delay, measurement of frame/packet delay is required. 1000 VPLS frame/packet delay measurement can be of two types: 1002 One-way delay 1003 One-way delay is used to characterize certain applications like 1004 multicast and broadcast applications. The measurement for one-way 1005 delay usually requires clock synchronization between two devices in 1006 question. 1008 Two-way delay 1009 Two-way delay or round-trip delay does not require clock 1010 synchronization between two devices involved in measurement and is 1011 usually sufficient to determine the frame/packet delay being 1012 experienced. 1014 (R4a) VPLS OAM MUST support measurement of per-service two-way 1015 frame/packet delay between two VPLS service aware devices that 1016 support the same VPLS service instance within a given OAM domain. 1018 (R4b) VPLS OAM SHOULD support measurement of per-service one-way 1019 frame/packet delay between two VPLS service aware devices that 1020 support the same VPLS service instance within a given OAM domain. 1022 6.5. Frame Delay Variation 1024 A VPLS service may be sensitive to delay variation experienced by 1025 the VPLS frames/packets during transit between the VPLS service 1026 aware devices. To determine if a VPLS service is degraded due to 1027 frame/packet delay variation, measurement of frame/packet delay 1028 variation is required. For frame/packet delay variation 1029 measurements, one-way mechanisms are considered to be sufficient. 1031 (R5) VPLS OAM MUST support measurement of per-service frame/packet 1032 delay variation between two VPLS service aware devices that support 1033 the same VPLS service instance within a given OAM domain. 1035 6.6. Availability 1037 A service may be considered unavailable if the service 1038 frames/packets do not reach their intended destination (e.g. 1039 connectivity is down or frame/packet loss is occurring) or the 1040 service is degraded (e.g. frame/packet delay and/or delay variation 1041 threshold is exceeded). 1043 Entry and exit conditions may be defined for unavailable state. 1044 Availability itself may be defined in context of service type. 1046 Since availability measurement may be associated with connectivity, 1047 frame/packet loss, frame/packet delay and frame/packet delay 1048 variation measurements, no additional requirements are specified 1049 currently. 1051 6.7. Data Path Forwarding 1053 If the VPLS OAM frames flow across a different path than the one 1054 used by VPLS service frames/packets, accurate measurement and/or 1055 determination of service state may not be made. Therefore data path, 1056 i.e. the one being taken by VPLS service frames/packets, must be 1057 used for the VPLS OAM. 1059 (R6) VPLS OAM frames MUST be forwarded along the same path (i.e. 1060 links and nodes) as the VPLS service/data frames. 1062 6.8. Scalability 1064 Mechanisms developed for VPLS OAM need to be such that per-service 1065 OAM can be supported even though the OAM may only be used for 1066 limited VPLS service instances, e.g. premium VPLS service instances, 1067 and may not be used for best-effort VPLS services. 1069 (R7) VPLS OAM MUST be scalable such that a service aware device can 1070 support OAM for each VPLS service that is supported by the device. 1072 6.9. Extensibility 1074 Extensibility is intended to allow introduction of additional OAM 1075 functionality in future such that backward compatibility can be 1076 maintained when interoperating with older version devices. In such a 1077 case, VPLS OAM with reduced functionality should still be possible. 1078 Further, VPLS Service OAM should be defined such that OAM incapable 1079 devices in the middle of the OAM domain should be able to forward 1080 the VPLS OAM frames similar to the regular VPLS service/data 1081 frames/packets. 1083 (R8a) VPLS OAM MUST be extensible such that new functionality and 1084 information elements related to this functionality can be introduced 1085 in future. 1087 (R8b) VPLS OAM MUST be defined such that devices not supporting the 1088 OAM are able to forward the OAM frames in a similar fashion as the 1089 regular VPLS service/data frames/packets. 1091 6.10. Security 1093 VPLS OAM frames belonging to an OAM domain originate and terminate 1094 within that OAM domain. Security implies that an OAM domain must be 1095 capable of filtering OAM frames. The filtering is such that the OAM 1096 frames are prevented from leaking outside their domain. Also, OAM 1097 frames from outside the OAM domains should be either discarded (when 1098 such OAM frames belong to same or lower-level OAM domain) or 1099 transparently passed (when such OAM frames belong to a higher-level 1100 OAM domain). 1102 (R9a) VPLS OAM frames MUST be prevented from leaking outside their 1103 OAM domain. 1105 (R9b) VPLS OAM frames from outside an OAM domain MUST be prevented 1106 from entering the OAM domain when such OAM frames belong to the same 1107 level or lower-level OAM domain. 1109 (R9c) VPLS OAM frames from outside an OAM domain MUST be transported 1110 transparently inside the OAM domain when such OAM frames belong to 1111 the higher-level OAM domain. 1113 6.11. Transport Independence 1115 VPLS service frame/packets delivery is carried out across transport 1116 infrastructure, also called network infrastructure. Though specific 1117 transport/network technologies may provide their own OAM 1118 capabilities, VPLS OAM must be independently supported as many 1119 different transport/network technologies can be used to carry 1120 service frame/packets. 1122 (R10a) VPLS OAM MUST be independent of the underlying 1123 transport/network technologies and specific transport/network OAM 1124 capabilities. 1126 (R10b) VPLS OAM MAY allow adaptation/interworking with specific 1127 transport/network OAM functions. For example, this would be useful 1128 to allow Fault Notifications from transport/network layer(s) to be 1129 sent to the VPLS service layer. 1131 6.12. Application Independence 1133 VPLS service itself may be used to carry application frame/packets. 1134 The application may use its own OAM; service OAM must not be 1135 dependent on application OAM. As an example, a VPLS service may be 1136 used to carry IP traffic; however, VPLS OAM should not assume IP or 1137 rely on the use of IP level OAM functions. 1139 (R11a) VPLS OAM MUST be independent of the application technologies 1140 and specific application OAM capabilities. 1142 7. VPWS OAM Requirements 1144 These requirements are applicable to VPWS PE. The performance 1145 metrics used in requirements are based on [MEF10.1] and [RFC2544], 1146 which are applicable to Ethernet Services. 1148 It is noted that OAM solutions that meet the following requirements 1149 may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc. 1150 however must not break these existing OAM mechanisms. If extensions 1151 are required to existing OAM mechanisms, these should be coordinated 1152 with relevant groups responsible for these OAM mechanisms. 1154 7.1. Discovery 1156 Discovery allows a VPWS service aware device to learn about other 1157 devices that support the same VPWS service instance within a given 1158 domain. Discovery also allows a VPWS service aware device to learn 1159 sufficient information (e.g. IP addresses, MAC addresses etc.) from 1160 other VPWS service aware devices such that OAM frames can be 1161 exchanged among the VPWS service aware devices. 1163 (R12) VPWS OAM MUST allow a VPWS service aware device to discover 1164 other devices that share the same VPWS service instance(s) within a 1165 given OAM domain. 1167 7.2. Connectivity Fault Management 1169 VPWS Service is realized by exchanging service frames/packets 1170 between devices that support the same VPWS service instance. To 1171 allow the exchange of service frames, connectivity between these 1172 service aware devices is required. 1174 7.2.1. Connectivity Fault Detection 1176 To ensure service, pro-active connectivity monitoring is required. 1177 Connectivity monitoring facilitates connectivity fault detection. 1179 (R13a) VPWS OAM MUST allow pro-active connectivity monitoring 1180 between two VPWS service aware devices that support the same VPWS 1181 service instance within a given OAM domain. 1183 (R13b) VPWS OAM mechanism SHOULD allow detection of misbranching or 1184 misconnections. 1186 7.2.2. Connectivity Fault Verification 1188 Once a connectivity fault is detected, connectivity fault 1189 verification may be performed. 1191 (R13c) VPWS OAM MUST allow connectivity fault verification between 1192 two VPWS service aware devices that support the same VPWS service 1193 instance within a given OAM domain. 1195 7.2.3. Connectivity Fault Localization 1197 Further, localization of connectivity fault may be carried out. This 1198 may amount to identifying the specific AC and/or PW that is 1199 resulting in the VPWS connectivity fault. 1201 (R13d) VPWS OAM MUST allow connectivity fault localization between 1202 two VPWS service aware devices that support the same VPWS service 1203 instance within a given OAM domain. 1205 7.2.4. Connectivity Fault Alarm 1207 Typically, when connectivity fault is detected and optionally 1208 verified, service device may notify the NMS (Network Management 1209 System). 1211 However, a single transport/network fault may cause multiple 1212 services to fail simultaneously causing multiple connectivity 1213 faults. Therefore, OAM must allow fault notification to allow 1214 suppression of service connectivity fault alarms at client layer, 1215 resulting in only one true fault alarm at server layer where the 1216 fault is originally detected. 1218 For example, if an AC fails, both local CE and local PE which are 1219 connected via AC may detect the connectivity failure. The local CE 1220 must notify the remote CE about the failure while the local PE must 1221 notify the remote PE about the failure. 1223 (R13e) VPWS OAM MUST allow forwarding of transport/network fault 1224 indications to service aware devices that support VPWS service 1225 instances affected by the fault. 1227 (R13f) VPWS OAM SHOULD allow propagation of fault indications in 1228 backward direction between VPWS service aware devices that support 1229 the VPWS service instance affected by the fault. 1231 7.3. Frame Loss 1233 A VPWS service may be considered degraded if service-layer 1234 frames/packets are lost during transit between the VPWS service 1235 aware devices. To determine if a VPWS service is degraded due to 1236 frame/packet loss, measurement of frame/packet loss is required. 1238 (R14) VPWS OAM MUST support measurement of per-service frame/packet 1239 loss between two VPWS service aware devices that support the same 1240 VPWS service instance within a given OAM domain. 1242 7.4. Frame Delay 1244 A VPWS service may be sensitive to delay experienced by the VPWS 1245 service frames/packets during transit between the VPWS service aware 1246 devices. To determine if a VPWS service is degraded due to 1247 frame/packet delay, measurement of frame/packet delay is required. 1249 VPWS frame/packet delay measurement can be of two types: 1250 - One-way delay 1251 One-way delay is used to characterize certain applications like 1252 multicast and broadcast applications. The measurement for one-way 1253 delay usually requires clock synchronization between two devices in 1254 question. 1255 - Two-way delay 1256 Two-way delay or round-trip delay does not require clock 1257 synchronization between two devices involved in measurement and is 1258 usually sufficient to determine the frame/packet delay being 1259 experienced. 1261 (R15a) VPWS OAM MUST support measurement of per-service two-way 1262 frame/packet delay between two VPWS service aware devices that 1263 support the same VPWS service instance within a given OAM domain. 1265 (R15b) VPWS OAM SHOULD support measurement of per-service one-way 1266 frame/packet delay between two VPWS service aware devices that 1267 support the same VPWS service instance within a given OAM domain. 1269 7.5. Frame Delay Variation 1271 A VPWS service may be sensitive to delay variation experienced by 1272 the VPWS frames/packets during transit between the VPWS service 1273 aware devices. To determine if a VPWS service is degraded due to 1274 frame/packet delay variation, measurement of frame/packet delay 1275 variation is required. For frame/packet delay variation 1276 measurements, one-way mechanisms are considered to be sufficient. 1278 (R16) VPWS OAM MUST support measurement of per-service frame/packet 1279 delay variation between two VPWS service aware devices that support 1280 the same VPWS service instance within a given OAM domain. 1282 7.6. Availability 1284 A service may be considered unavailable if the service 1285 frames/packets do not reach their intended destination (e.g. 1286 connectivity is down or frame/packet loss is occurring) or the 1287 service is degraded (e.g. frame/packet delay and/or delay variation 1288 threshold is exceeded). 1290 Entry and exit conditions may be defined for unavailable state. 1291 Availability itself may be defined in context of service type. 1292 Since availability measurement may be associated with connectivity, 1293 frame/packet loss, frame/packet delay and frame/packet delay 1294 variation measurements, no additional requirements are specified 1295 currently. 1297 7.7. Data Path Forwarding 1299 If the VPWS OAM frames flow across a different path than the one 1300 used by VPWS service frames/packets, accurate measurement and/or 1301 determination of service state may not be made. Therefore data path, 1302 i.e. the one being taken by VPWS service frames/packets, must be 1303 used for the VPWS OAM. 1305 (R17a) VPWS OAM frames MUST be forwarded along the same path as the 1306 VPWS service/data frames. 1308 (R17b) VPWS OAM MUST be forwarded using the transfer plane (data 1309 plane) as regular VPWS service/data frames/packets and must not rely 1310 on control plane messages. 1312 7.8. Scalability 1314 Mechanisms developed for VPWS OAM need to be such that per-service 1315 OAM can be supported even though the OAM may only be used for 1316 limited VPWS service instances, e.g. premium VPWS service instance, 1317 and may not be used for best-effort services. 1319 (R18) VPWS OAM MUST be scalable such that a service aware device can 1320 support OAM for each VPWS service that is supported by the device. 1322 7.9. Extensibility 1324 Extensibility is intended to allow introduction of additional OAM 1325 functionality in future such that backward compatibility can be 1326 maintained when interoperating with older version devices. In such a 1327 case, VPWS service OAM with reduced functionality should still be 1328 possible. Further, VPWS service OAM should be such that OAM 1329 incapable devices in the middle of the OAM domain should be able to 1330 forward the VPWS OAM frames similar to the regular VPWS service/data 1331 frames/packets. 1333 (R19a) VPWS OAM MUST be extensible such that new functionality and 1334 information elements related to this functionality can be introduced 1335 in future. 1337 (R19b) VPWS OAM MUST be defined such that devices not supporting the 1338 OAM are able to forward the VPWS OAM frames in a similar fashion as 1339 the regular VPWS service/data frames/packets. 1341 7.10. Security 1343 VPWS OAM frames belonging to an OAM domain originate and terminate 1344 within that OAM domain. Security implies that an OAM domain must be 1345 capable of filtering OAM frames. The filtering is such that the VPWS 1346 OAM frames are prevented from leaking outside their domain. Also, 1347 VPWS OAM frames from outside the OAM domains should be either 1348 discarded (when such OAM frames belong to same or lower-level OAM 1349 domain) or transparently passed (when such OAM frames belong to a 1350 higher-level OAM domain). 1352 (R20a) VPWS OAM frames MUST be prevented from leaking outside their 1353 OAM domain. 1355 (R20b) VPWS OAM frames from outside an OAM domain MUST be prevented 1356 from entering the OAM domain when such OAM frames belong to the same 1357 level or lower-level OAM domain. 1359 (R20c) VPWS OAM frames from outside an OAM domain MUST be 1360 transported transparently inside the OAM domain when such OAM frames 1361 belong to the higher-level OAM domain. 1363 7.11. Transport Independence 1365 VPWS service frame/packets delivery is carried out across transport 1366 infrastructure, also called network infrastructure. Though specific 1367 transport/network technologies may provide their own OAM 1368 capabilities, VPWS OAM must be independently supported as many 1369 different transport/network technologies can be used to carry 1370 service frame/packets. 1372 (R21a) VPWS OAM MUST be independent of the underlying 1373 transport/network technologies and specific transport/network OAM 1374 capabilities. 1376 (R21b) VPWS OAM MAY allow adaptation/interworking with specific 1377 transport/network OAM functions. For example, this would be useful 1378 to allow Fault Notifications from transport/network layer(s) to be 1379 sent to the VPWS service layer. 1381 7.12. Application Independence 1383 VPWS service itself may be used to carry application frame/packets. 1384 The application may use its own OAM; VPWS OAM must not be dependent 1385 on application OAM. As an example, a VPWS service may be used to 1386 carry IP traffic; however, VPWS OAM should not assume IP or rely on 1387 the use of IP level OAM functions. 1389 (R22a) OAM MUST be independent of the application technologies and 1390 specific application OAM capabilities. 1392 7.13. Prioritization 1394 VPWS service could be composed of several data flows each related to 1395 a given usage/application with specific requirements in term of 1396 connectivity and/or performances. Dedicated VPWS OAM should be 1397 applicable to these flows. 1399 (R23) VPWS OAM SHOULD support configurable prioritization for OAM 1400 packet/frames to be compatible with associated VPWS service 1401 packets/frames. 1403 8. VPLS (V)LAN Emulation OAM Requirements 1405 8.1. Partial-mesh of PWs 1407 As indicated in [BRIDGE-INTEROP], VPLS service OAM relies upon 1408 bidirectional Ethernet links or (V)LAN segments and failure in one 1409 direction or link results in failure of the whole link or (V)LAN 1410 segment. Therefore, when partial-mesh failure occurs in (V)LAN 1411 emulation, either the entire PW mesh should be shutdown when only an 1412 entire VPLS service is acceptable or a subset of PWs should be 1413 shutdown such that the remaining PWs have full connectivity among 1414 them, when partial VPLS service is acceptable. 1416 (R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow 1417 detection of partial-mesh failure condition. 1419 (R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the 1420 entire mesh of PWs to be shutdown upon detection of a partial-mesh 1421 failure condition. 1423 (R13c) PW OAM for PWs related to a (V)LAN emulation MUST allow the 1424 subset of PWs to be shutdown upon detection of a partial-mesh 1425 failure condition in a manner such that full mesh is present across 1426 the remaining subset. 1428 Note: Shutdown action in R13b and R13c may not necessarily involve 1429 withdrawal of labels etc. 1431 8.2. PW Fault Recovery 1433 As indicated in [BRIDGE-INTEROP], VPLS service OAM fault detection 1434 and recovery relies upon (V)LAN emulation recovery such that fault 1435 detection and recovery time in (V)LAN emulation should be less than 1436 the VPLS service fault detection and recovery time to prevent 1437 unnecessary switch-over and temporary flooding/loop within customer 1438 OAM domain that is dual-homed to provider OAM domain. 1440 (R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a 1441 fault detection time in the provider OAM domain faster than the VPLS 1442 fault detection time in the customer OAM domain. 1444 (R14b) PW OAM for PWs related to a (V)LAN emulation MUST support a 1445 fault recovery time in the provider OAM domain faster than the VPLS 1446 fault recovery time in the customer OAM domain. 1448 8.3. Connectivity Fault Notification 1450 When connectivity fault is detected in (V)LAN emulation, PE devices 1451 may notify the NMS (Network Management System). However, a single 1452 (V)LAN emulation fault may result in CE devices or U-PE devices 1453 detecting connectivity fault in VPLS service and therefore also 1454 notifying the NMS. To prevent multiple notifications for the same 1455 fault, (V)LAN emulation OAM must provide alarm suppression 1456 capability in the VPLS service OAM. 1458 (R15) PW OAM for PWs related to a (V)LAN emulation MUST support 1459 interworking with VPLS service OAM to allow alarm suppression in the 1460 VPLS service upon fault detection in (V)LAN emulation. 1462 9. OAM Operational Scenarios 1464 This section highlights how the different OAM mechanisms can be 1465 applied as per the OAM framework for different L2VPN services. 1467 9.1. VPLS OAM Operational Scenarios 1468 --- --- 1469 / \ ------ ------- ---- / \ 1470 | A CE-- / \ / \ / \ --CE A | 1471 \ / \ / \ / \ / \ / \ / 1472 --- --UPE NPE NPE UPE-- --- 1473 \ / \ / \ / 1474 \ / \ / \ / 1475 ------ ------- ---- 1477 Customer OAM domain 1478 (C) MEP---MIP--------------------------------MIP---MEP 1480 Service Provider(SP) OAM domain 1481 (D) MEP--------MIP-----------MIP-------MEP 1483 SP OAM SP OAM SP OAM 1484 (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP 1485 domain domain domain 1486 Operator Operator Operator 1487 (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP 1488 OAM domain OAM domain OAM domain 1490 MPLS OAM MPLS OAM 1491 (F) MEP--MIP-----MEP--MIP--MEP 1492 domain domain 1494 Figure 10: VPLS OAM Domains, MEPs & MIPs 1496 Among the different MEs identified in Figure 5, for VPLS OAM in 1497 Customer OAM domain, [IEEE 802.1ag] and [ITU-T Y.1731] Ethernet OAM 1498 mechanisms can be applied, to meet various requirements identified 1499 in Section 6. The mechanisms can be applied across Figure 10 (C) 1500 MEs. 1502 Similarly, inside the Service Provider OAM domain, [IEEE 802.1ag] 1503 and [Y.1731] Ethernet OAM mechanisms can be applied across Figure 10 1504 (D) MEs to meet functional requirements identified in Section 6. 1506 It may be noted that in the interim, when [IEEE 802.1ag] and 1507 [Y.1731] capabilities are not available across the PE devices, the 1508 management option introduced in Section 5.2.3 can be applied, with 1509 the limitations cited below. In this option, the Service Provider 1510 can run segment OAM across the Figure 10 (D1) MEs. The OAM 1511 mechanisms across the Figure 10 (D1) MEs can be non-Ethernet e.g. 1512 VCCV, or BFD when network technology is MPLS. The Service Provider 1513 can monitor each sub-network segment ME using the native technology 1514 OAM and by performing interworking across the segment MEs, attempt 1515 to realize end-to-end monitoring between a pair of VPLS end-points. 1516 However, such mechanisms do not fully utilize the data plane 1517 forwarding as experienced by native (i.e. Ethernet) service PDUs and 1518 therefore monitoring is severely limited in the sense that 1519 monitoring at Figure 10 (D1) and interworking across them could lead 1520 to an indication that the ME between VPLS end-points is functional 1521 while the customer may be experiencing end-to-end connectivity 1522 issues in the data plane. 1524 Inside the Network Operator OAM domain, [IEEE 802.1ag] and [Y.1731] 1525 Ethernet OAM mechanisms can also be applied across Figure 10 (E) MEs 1526 to meet functional requirements identified in Section 6. In 1527 addition, the network operator could decide to use native OAM 1528 mechanisms e.g. VCCV or BFD across Figure 10 (F) MEs for additional 1529 monitoring or as an alternative to monitoring across Figure 10 (E) 1530 MEs. 1532 10. Acknowledgments 1534 The authors would like to thank Deborah Brungard, Vasile Radoaca, 1535 Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their 1536 reviews and comments. 1538 Authors would also like to thank Shahram Davari, Norm Finn, Dave 1539 Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness, 1540 Malcolm Betts, Paul Bottorff, Hamid-ould Brahim, Lior Shabtay, and 1541 Dan Cauchy for their feedback. 1543 12. IANA Considerations 1545 This document has no actions for IANA. 1547 11. Security Considerations 1549 This document takes into account the security considerations and 1550 imposes requirements on solutions to prevent OAM messages from 1551 leaking outside an OAM domain and for OAM domains to be transparent 1552 to OAM frames from higher OAM domains, as specified in Section 6.10 1553 and 7.10. 1555 For additional levels of security, the solutions may be required to 1556 encrypt and/or authenticate OAM frames inside an OAM domain however 1557 solutions are out of the scope of this draft. 1559 13. References 1561 13.1 Normative References 1563 [IEEE 802.1ad] "IEEE Standard for Local and metropolitan area 1564 networks - virtual Bridged Local Area Networks, Amendment 4: 1565 Provider Bridges", 2005 1567 [IEEE 802.1ag] "IEEE Standard for Local and metropolitan area 1568 networks - virtual Bridged Local Area Networks, Amendment 5: 1569 Connectivity Fault Management", 2007 1571 [IEEE 802.1ah] "IEEE Standard for Local and metropolitan area 1572 networks - virtual Bridged Local Area Networks, Amendment 6: 1573 Provider Backbone Bridges", 2008 1575 [L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks 1576 (L2VPNs)", RFC 4664 1578 [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned 1579 Virtual Private Networks", RFC 4665 1581 [L2VPN-TERM] "Provider Provisioned Virtual Private Network (VPN) 1582 Terminology", RFC 4026 1584 [MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1, 2006 1586 [NM-Standards] "TMN Management Functions", M.3400, February 2000 1587 [VPLS-BGP] "Virtual Private LAN Service", RFC 4761, Jan 2007 1589 [VPLS-LDP] "Virtual Private LAN Services over MPLS", RFC 4762, Jan 1590 2007 1592 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", 1593 ITU-T Y.1731, May 2006 1595 13.2 Informative References 1597 [BRIDGE-INTEROP] "VPLS Interoperability with CE Bridges", draft- 1598 ietf-l2vpn-vpls-bridge-interop-02.txt, Work in progress, November 1599 2007 1601 [L2VPN-SIG] "Provisioning, Autodiscovery, and Signaling in L2VPNs", 1602 [MS-PW Arch] "An Architecture for Multi-segment Pseudowire Emulation 1603 Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-04.txt, Work in progress, 1604 June 2008 1606 [RFC2544] "Benchmarking Methodology for Network Interconnect 1607 Devices", RFC 2544, 1999 1609 A1. Appendix 1 - Alternate Management Models 1611 In consideration of the management models that can be deployed 1612 besides the hierarchical models elaborated in this document, this 1613 section highlights some alternate models that are not recommended 1614 due to their limitations, as pointed out below. These alternatives 1615 have been highlighted as potential interim models while the network 1616 equipments are upgraded to support full functionality and meet the 1617 requirements set forward by this document. 1619 A1.1. Alternate Model 1 (Minimal OAM) 1621 In this model, the end-to-end service monitoring is provided by 1622 applying CE to CE ME in the Service Provider OAM Domain. 1624 A MEP is located at each CE interface that is part of the VPWS 1625 service, as shown in Figure A1.1 (B). The network operators can 1626 carry out segment (e.g. PSN Tunnel ME, etc.) monitoring independent 1627 of the VPWS end-to-end service monitoring, as shown in Figure A1.1 1628 (D). 1630 The advantage of this option is that VPWS service monitoring is 1631 limited to CEs. The limitation of this option is that the 1632 localization of faults at the VPWS Service level. 1634 |<--------------- VPWS -------------->| 1635 | | 1636 | +----+ +----+ | 1637 +----+ | |==================| | +----+ 1638 | |---AC1----|............PW..............|--AC2-----| | 1639 | CE1| |PE1 | | PE2| |CE2 | 1640 +----+ | |==================| | +----+ 1641 +----+ PSN Tunnel +----+ 1643 (B) MEP-----------------------------------------------MEP 1644 (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP 1646 Figure A1.1: VPWS MEPs & MIPs - Minimal OAM 1648 A1.2. Alternate Model 2 (Segment OAM Interworking) 1650 In this model, the end-to-end service monitoring is provided by 1651 interworking OAM across each segment. Typical segments involved in 1652 this case include two AC MEs and PW ME, as shown in Figure A1.2 (C). 1653 These segments are expected in the Service Provider OAM Domain. An 1654 interworking function is required to transfer the OAM information 1655 flows across the OAM segments for the purposes of end-to-end 1656 monitoring. Depending on whether homogenous VPWS is deployed or 1657 heterogeneous VPWS is deployed, the interworking function could be 1658 straightforward or more involved. 1660 In this option, the CE and PE interfaces support MEPs for AC and PW 1661 MEs and no MIPs are involved at the Service Provider OAM Level, as 1662 shown in Figure A1.2 (C). The network operators may run segment OAM 1663 by having MEPs at Network Operator OAM level, as shown in Figure 1664 A1.2 (D). 1666 The limitations of this model are that it requires interworking 1667 across the OAM segments and does not conform to the OAM layering 1668 principles, where each OAM layer ought to be independent of the 1669 other. For end-to-end OAM determinations, the end-to-end service 1670 frame path is not necessarily exercised. Further, it requires 1671 interworking function implementation for all possible technologies 1672 across access and core that may be used to realize end-to-end 1673 services. 1675 |<--------------- VPWS -------------->| 1676 | | 1677 | +----+ +----+ | 1678 +----+ | |==================| | +----+ 1679 | |---AC1----|............PW..............|--AC2-----| | 1680 | CE1| |PE1 | | PE2| |CE2 | 1681 +----+ | |==================| | +----+ 1682 +----+ PSN Tunnel +----+ 1684 (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP 1685 (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP 1687 Figure A1.2: VPWS MEPs & MIPs - Segment OAM Interworking 1689 Intellectual Property Statement 1691 The IETF takes no position regarding the validity or scope of any 1692 Intellectual Property Rights or other rights that might be claimed 1693 to pertain to the implementation or use of the technology described 1694 in this document or the extent to which any license under such 1695 rights might or might not be available; nor does it represent that 1696 it has made any independent effort to identify any such rights. 1697 Information on the procedures with respect to rights in RFC 1698 documents can be found in BCP 78 and BCP 79. 1700 Copies of IPR disclosures made to the IETF Secretariat and any 1701 assurances of licenses to be made available, or the result of an 1702 attempt made to obtain a general license or permission for the use 1703 of such proprietary rights by implementers or users of this 1704 specification can be obtained from the IETF on-line IPR repository 1705 at http://www.ietf.org/ipr. 1707 The IETF invites any interested party to bring to its attention any 1708 copyrights, patents or patent applications, or other proprietary 1709 rights that may cover technology that may be required to implement 1710 this standard. Please address the information to the IETF at ietf- 1711 ipr@ietf.org. 1713 Authors' Addresses 1715 Dinesh Mohan 1716 Nortel 1717 3500 Carling Ave 1718 Ottawa, ON K2H8E9 1719 Email: mohand@nortel.com 1721 Ali Sajassi 1722 Cisco Systems, Inc. 1724 170 West Tasman Drive 1725 San Jose, CA 95134 1726 Email: sajassi@cisco.com 1728 Simon Delord 1729 Uecomm 1730 658 Church St 1731 Richmond, VIC, 3121, Australia 1732 E-mail: sdelord@uecomm.com.au 1734 Philippe Niger 1735 France Telecom 1736 2 av. Pierre Marzin 1737 22300 LANNION, France 1738 E-mail: philippe.niger@francetelecom.com 1740 Full Copyright Statement 1742 Copyright (C) The IETF Trust (2008). 1744 This document is subject to the rights, licenses and restrictions 1745 contained in BCP 78, and except as set forth therein, the authors 1746 retain all their rights. 1748 This document and the information contained herein are provided on 1749 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1750 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1751 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1752 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1753 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1754 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1755 FOR A PARTICULAR PURPOSE.