idnits 2.17.1 draft-ietf-trill-oam-framework-04.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 date (December 5, 2013) is 3767 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) == Outdated reference: A later version (-02) exists of draft-tissa-trill-oam-fm-01 == Outdated reference: A later version (-04) exists of draft-mrw-trill-over-ip-03 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-10) exists of draft-perlman-trill-rbridge-multilevel-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Samer Salam 3 INTERNET-DRAFT Tissa Senevirathne 4 Intended Status: Informational Cisco 6 Sam Aldrin 7 Donald Eastlake 8 Huawei 10 Expires: June 8, 2014 December 5, 2013 12 TRILL OAM Framework 13 draft-ietf-trill-oam-framework-04 15 Abstract 17 This document specifies a reference framework for Operations, 18 Administration, and Maintenance (OAM) in TRILL networks. The focus of 19 the document is on the fault and performance management aspects of 20 TRILL OAM. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2 Relationship to Other OAM Work . . . . . . . . . . . . . . . 5 63 2. TRILL OAM Model . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1 OAM Layering . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1.1 Relationship to CFM . . . . . . . . . . . . . . . . . . 7 66 2.1.2 Relationship to BFD . . . . . . . . . . . . . . . . . . 8 67 2.1.3 Relationship to Link OAM . . . . . . . . . . . . . . . . 8 68 2.2 TRILL OAM in the RBridge Port Model . . . . . . . . . . . . 8 69 2.3 Network, Service and Flow OAM . . . . . . . . . . . . . . . 10 70 2.4 Maintenance Domains . . . . . . . . . . . . . . . . . . . . 11 71 2.5 Maintenance Entity and Maintenance Entity Group . . . . . . 12 72 2.6 MEPs and MIPs . . . . . . . . . . . . . . . . . . . . . . . 12 73 2.7 Maintenance Point Addressing . . . . . . . . . . . . . . . . 14 74 3. OAM Frame Format . . . . . . . . . . . . . . . . . . . . . . . 15 75 3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 3.2 Determination of Flow Entropy . . . . . . . . . . . . . . . 17 77 3.2.1 Address Learning and Flow Entropy . . . . . . . . . . . 17 78 3.3 OAM Message Channel . . . . . . . . . . . . . . . . . . . . 18 79 3.4 Identification of OAM Messages . . . . . . . . . . . . . . . 18 80 4. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 18 81 4.1 Proactive Fault Management Functions . . . . . . . . . . . . 18 82 4.1.1 Fault Detection (Continuity Check) . . . . . . . . . . . 19 83 4.1.2 Defect Indication . . . . . . . . . . . . . . . . . . . 19 84 4.1.2.1 Forward Defect Indication . . . . . . . . . . . . . 19 85 4.1.2.2 Reverse Defect Indication (RDI) . . . . . . . . . . 20 86 4.2 On-Demand Fault Management Functions . . . . . . . . . . . . 20 87 4.2.1 Connectivity Verification . . . . . . . . . . . . . . . 20 88 4.2.1.1 Unicast . . . . . . . . . . . . . . . . . . . . . . 21 89 4.2.1.2 Multicast . . . . . . . . . . . . . . . . . . . . . 21 90 4.2.2 Fault Isolation . . . . . . . . . . . . . . . . . . . . 22 91 5. Performance Monitoring . . . . . . . . . . . . . . . . . . . . 22 92 5.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.2 Packet Delay . . . . . . . . . . . . . . . . . . . . . . . . 23 94 6. Operational and Manageability Considerations . . . . . . . . . 24 95 6.1 TRILL OAM Configuration . . . . . . . . . . . . . . . . . . 24 96 6.1.1 Maintenance Domain Parameters . . . . . . . . . . . . . 24 97 6.1.2 Maintenance Association Parameters . . . . . . . . . . . 24 98 6.1.3 Maintenance Endpoint Parameters . . . . . . . . . . . . 25 99 6.1.4 Continuity Check Parameters (applicable per MA) . . . . 25 100 6.1.5 Connectivity Verification Parameters (applicable per 101 operation) . . . . . . . . . . . . . . . . . . . . . . . 26 102 6.1.6 Fault Isolation Parameters (applicable per operation) . 26 103 6.1.7 Packet Loss Monitoring . . . . . . . . . . . . . . . . . 27 104 6.1.8 Packet Delay Monitoring . . . . . . . . . . . . . . . . 28 105 6.2 TRILL OAM Notifications . . . . . . . . . . . . . . . . . . 28 106 6.3 Collecting Performance Monitoring Metrics . . . . . . . . . 29 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 30 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 30 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 10.1 Normative References . . . . . . . . . . . . . . . . . . . 30 112 10.2 Informative References . . . . . . . . . . . . . . . . . . 31 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 115 1. Introduction 117 This document specifies a reference framework for Operations, 118 Administration, and Maintenance (OAM, [RFC6291]) in TRILL 119 (Transparent Interconnection of Lots of Links) networks. 121 TRILL [RFC6325] specifies a protocol for shortest-path frame routing 122 in multi-hop networks with arbitrary topologies and link 123 technologies, using the IS-IS routing protocol. TRILL capable devices 124 are referred to as TRILL Switches or RBridges (Routing Bridges). 125 RBridges provide an optimized and transparent Layer 2 delivery 126 service for Ethernet unicast and multicast traffic. Some 127 characteristics of a TRILL network that are different from IEEE 802.1 128 bridging are the following: 130 - TRILL networks support arbitrary link technology between TRILL 131 switches. Hence, a TRILL switch port may not have a 48-bit MAC 132 Address [802] but might, for example, have an IP address as an 133 identifier [TRILL-IP] or no unique identifier (PPP [RFC6361]). 135 - TRILL networks do not enforce congruence of unicast and multicast 136 paths between a given pair of RBridges. 138 - TRILL networks do not impose symmetry of the forward and reverse 139 paths between a given pair of RBridges. 141 - TRILL switches terminate spanning tree protocols instead of 142 propagating them. 144 In this document, we refer to the term OAM as defined in [RFC6291]. 145 The Operations aspect involves finding problems that prevent proper 146 functioning of the network. It also includes monitoring of the 147 network to identify potential problems before they occur. 148 Administration involves keeping track of network resources. 149 Maintenance activities are focused on facilitating repairs and 150 upgrades as well as corrective and preventive measures. [ISO/IEC 151 7498-4] defines 5 functional areas in the OSI model for network 152 management, commonly referred to as FCAPS: 154 -Fault Management 155 -Configuration Management 156 -Accounting Management 157 -Performance Management 158 -Security Management 160 The focus of this document is on the first and fourth functional 161 aspects, Fault Management and Performance Management, in TRILL 162 networks. These primarily map to the "Operations" and "Maintenance" 163 part of OAM. 165 This draft provides a generic framework for a comprehensive solution 166 that meets the requirements outlined in [RFC6905]. However, specific 167 mechanisms to address these requirements are considered to be outside 168 the scope of this document. Furthermore, another document will 169 specify the optional reporting of errors in TRILL user traffic, such 170 as the use of a reserved or unknown egress nickname, etc. 172 1.1 Terminology 174 Definitions of many OAM terms can be found in [draft-ietf-mpls-tp- 175 rosetta-stone]. 177 The following acronyms are used in this document: 179 BFD - Bidirectional Forwarding Detection [RFC5880] 180 CFM - Connectivity Fault Management [802.1Q] 181 ECMP - Equal Cost Multi-Path 182 FGL - Fine Grained Label(ing) [TRILL-FGL] 183 IEEE - Institute for Electrical and Electronic Engineers 184 IP - Internet Protocol, includes both IPv4 and IPv6 185 LAN - Local Area Network 186 MAC - Media Access Control [802] 187 MA - Maintenance Association 188 ME - Maintenance Entity 189 MEP - Maintenance End Point 190 MIP - Maintenance Intermediate Point 191 MP - Maintenance Point (MEP or MIP) 192 OAM - Operations, Administration, and Maintenance [RFC6291] 193 PPP - Point-to-Point Protocol [RFC1661] 194 RBridge - Routing Bridge, a device implementing TRILL [RFC6325] 195 RDI - Reverse Defect Indication 196 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 197 TRILL Switch - an alternate name for an RBridge 198 VLAN - Virtual LAN [802.1Q] 200 1.2 Relationship to Other OAM Work 202 OAM is a technology area where a wealth of prior art exists. This 203 document leverages concepts and draws upon elements defined and/or 204 used in the following documents: 206 [RFC6905] defines the requirements for TRILL OAM that serve as the 207 basis for this framework. It also defines terminology that is used 208 extensively in this document. 210 [802.1Q] specifies the Connectivity Fault Management (CFM) protocol, 211 which defines the concepts of Maintenance Domains, Maintenance End 212 Points, and Maintenance Intermediate Points. 214 [Y.1731] extends Connectivity Fault Management in the following 215 areas: it defines fault notification and alarm suppression functions 216 for Ethernet. It also specifies mechanisms for Ethernet performance 217 management, including loss, delay, jitter, and throughput 218 measurement. 220 [TRILL-BFD] defines a TRILL encapsulation for BFD that enables the 221 use of the latter for network fast failure detection. 223 [RFC5860] and [RFC6371] specify requirements and a framework for OAM 224 in MPLS based networks. 226 2. TRILL OAM Model 228 2.1 OAM Layering 230 In the TRILL architecture, the TRILL layer is independent of the 231 underlying Link Layer technology. Therefore, it is possible to run 232 TRILL over any transport layer capable of carrying TRILL packets such 233 as Ethernet [RFC6325], PPP [RFC6361], or IP [TRILL-IP]. Furthermore, 234 TRILL provides a virtual Ethernet connectivity service that is 235 transparent to higher layer entities (Layer 3 and above). This strict 236 layering is observed by TRILL OAM. 238 Of particular interest is the layering of TRILL OAM with respect to: 240 - BFD, which is typically used for fast failure detection. 242 - Ethernet CFM [802.1Q] on paths from an external device, over a 243 TRILL campus, to another external device, especially since TRILL 244 switches are likely to be deployed where existing 802.1 bridges can 245 be such external devices. 247 - Link OAM, on links interior to a TRILL campus, which is link 248 technology specific. 250 Consider the example network depicted in Figure 1 below, where a 251 TRILL network is interconnected via Ethernet links: 253 LAN LAN 254 +---+ +---+ ====== +---+ ============= +---+ 255 +--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+ 256 |B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5| 257 +--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+ 258 +---+ +---+ ====== +---+ ============= +---+ 260 a. Ethernet CFM (Client Layer) on path over the TRILL campus 261 >---o------------------------------------------------o---< 263 b. TRILL OAM (Network Layer) 264 >------o-----------o---------------------< 266 c. Ethernet CFM (Transport Layer) on interior Ethernet LANs 267 >---o--o---< >---o--o---o--o---< 269 d. BFD (Media Independent Link Layer) 270 #---# #----------# #-----------------# 272 e. Link OAM (Media Dependent Link Layer) 273 *---* *---* *---* *---* *---* *---* *---* *---* 275 Legend: >, < MEP o MIP # BFD Endpoint * Link OAM Endpoint 277 Figure 1: OAM Layering in TRILL 279 Where Bn and RBn (n= 1,2,3, ...) denote IEEE 802.1Q bridges and TRILL 280 RBridges, respectively. 282 2.1.1 Relationship to CFM 284 In the context of a TRILL network, CFM can be used as either a client 285 layer OAM or a transport layer OAM mechanism. 287 When acting as a client layer OAM (see Figure 1a), CFM provides fault 288 management capabilities for the user, on an end-to-end basis over the 289 TRILL network. Edge ports of the TRILL network may be visible to CFM 290 operations through the optional presence of a CFM Maintenance 291 Intermediate Point (MIP) in the TRILL switches edge Ethernet ports. 293 When acting as a transport layer OAM (see Figure 1c), CFM provides 294 fault management functions for the IEEE 802.1Q bridged LANs that may 295 interconnect RBridges. Such bridged LANs can be used as TRILL level 296 links between RBridges. RBridges directly connected to the 297 intervening 802.1Q bridges may host CFM Down Maintenance End Points 298 (MEPs). 300 2.1.2 Relationship to BFD 302 One-hop BFD (see Figure 1d) runs between adjacent RBridges and 303 provides fast link as well as node failure detection capability 304 [TRILL-BFD]. Note that TRILL BFD also provides some testing of the 305 TRILL protocol stack and thus sits a layer above Link OAM, which is 306 media specific. BFD's fast failure detection helps support rapid 307 convergence in TRILL networks. The requirements for BFD are different 308 from those of the TRILL OAM mechanisms that are the prime focus of 309 this document. Furthermore, BFD does not use the frame format 310 described in section 3.1. 312 TRILL BFD differs from TRILL OAM in two significant ways: 314 1. A TRILL BFD transmitter is always bound to a specific TRILL output 315 port. 317 2. TRILL BFD messages can be transmitted by the originator out a port 318 to a neighbor RBridge when the adjacency is in the Detect or Two-Way 319 states as well as when the adjacency is in the Report (Up) state 320 [RFC6327]. 322 In contrast, TRILL OAM messages are typically transmitted by 323 appearing to have been received on a TRILL input port (refer to 324 Section 2.2 for details). In that case, the output ports on which 325 TRILL OAM message are sent are determined by the TRILL routing 326 function. The TRILL routing function will only send on links that are 327 in the Report state and have been incorporated into the local view of 328 the campus topology. 330 2.1.3 Relationship to Link OAM 332 Link OAM (see Figure 1e) depends on the nature of the technology used 333 in the links interconnecting RBridges. For example, for Ethernet 334 links, [802.3] Clause 57 OAM may be used. 336 2.2 TRILL OAM in the RBridge Port Model 338 TRILL OAM processing can be represented as a layer situated between 339 the port's TRILL encapsulation/de-capsulation function and the TRILL 340 Forwarding Engine function, on any RBridge port. TRILL OAM requires 341 services of the RBridge forwarding engine and utilizes information 342 from the IS-IS control plane. Figure 2 below depicts TRILL OAM 343 processing in the context of the RBridge port model defined in 345 [RFC6325]. In this figure, double lines represent flow of both frames 346 and information. 348 This figure shows a conceptual model. It is to be understood that 349 implementations need not mirror this exact model as long as the 350 intended OAM requirements and functionality are preserved. 352 +-----------------------------------------------+---- 353 | (Flow of OAM Messages) RBridge 354 | +----------------------+ 355 | |+-------------------+|| Forwarding Engine, 356 | || || IS-IS, Etc. 357 | || || Processing of 358 | V V TRILL packets 359 +---------------------------------------------+----- 360 || || ...other ports 361 +------------+ +------------+ 362 UP MEP /\ | TRILL OAM | | TRILL OAM | /\ UP MEP 363 MIP () | Layer | | Layer | () MIP 364 DOWN MEP \/ +------------+ +------------+ \/ DOWN MEP 365 | TRILL | | TRILL | 366 | Encap/Decap| | Encap/Decap| 367 +------------+ +------------+ 368 |End Station | |End Station | 369 |VLAN & | |VLAN & | 370 |Priority | |Priority | 371 |Processing | |Processing | 372 +------------+ +------------+ <-- ISS 373 |802.1/802.3 | |802.1/802.3 | 374 |Low Level | |Low Level | 375 |Control | |Control | 376 |Frame | |Frame | 377 |Processing, | |Processing, | 378 |Port/Link | |Port/Link | 379 |Control | |Control | 380 |Logic | |Logic | 381 +------------+ +------------+ 382 | 802.3PHY | | 802.3PHY | 383 |(Physical | |(Physical | 384 | interface) | | interface) | 385 +------------+ +------------+ 386 || || 387 Link Link 389 Figure 2: TRILL OAM in RBridge Port Model 391 Note that the terms "MEP" and "MIP" in the above figure are explained 392 in detail in section 2.6 below. 394 2.3 Network, Service and Flow OAM 396 OAM functions in a TRILL network can be conducted at different 397 granularity. This gives rise to 'Network', 'Service' and 'Flow' OAM, 398 listed in order of finer granularity. 400 Network OAM mechanisms provide fault and performance management 401 functions in the context of a 'test' VLAN or fine-grained label 402 [TRILL-FGL]. The test VLAN can be thought of as a management or 403 diagnostics VLAN that extends to all RBridges in a TRILL network. In 404 order to account for multipathing, Network OAM functions also make 405 use of test flows (both unicast and multicast) to provide coverage of 406 the various paths in the network. 408 Service OAM mechanisms provide fault and performance management 409 functions in the context of the actual VLAN or fine-grained label set 410 for which end station service is enabled. Test flows are used here, 411 as well, to provide coverage in the case of multipathing. 413 Flow OAM mechanisms provide the most fine grained fault and 414 performance management capabilities, where OAM functions are 415 performed in the context of end station flows within VLANs or fine- 416 grained labels. While Flow OAM provides the most granular control, it 417 clearly poses scalability challenges if attempted on large numbers of 418 flows. 420 2.4 Maintenance Domains 422 The concept of Maintenance Domains, or OAM Domains, is well known in 423 the industry. IEEE [802.1Q] defines the notion of a Maintenance 424 Domain as a collection of devices (for example, network elements) 425 that are grouped for administrative and/or management purposes. 426 Maintenance domains usually delineate trust relationships, varying 427 addressing schemes, network infrastructure capabilities, etc. 429 When mapped to TRILL, a Maintenance Domain is defined as a collection 430 of RBridges in a network for which connectivity faults and 431 performance degradation are to be managed by a single operator. All 432 RBridges in a given Maintenance Domain are, by definition, managed by 433 a single entity (for example, an enterprise or a data center 434 operator, etc.). [RFC6325] defines the operation of TRILL in a single 435 IS-IS area, with the assumption that a single operator manages the 436 network. In this context, a single (default) Maintenance Domain is 437 sufficient for TRILL OAM. 439 However, when considering scenarios where different TRILL networks 440 need to be interconnected, for example, as discussed in [TRILL-ML], 441 then the introduction of multiple Maintenance Domains, and 442 Maintenance Domain hierarchies becomes useful to map and enforce 443 administrative boundaries. When considering multi-domain scenarios, 444 the following rules must be followed: TRILL OAM domains must not 445 partially intersect, but must either be disjoint or nest to form a 446 hierarchy (that is, a higher Maintenance Domain may completely 447 enclose a lower Domain). A Maintenance Domain is typically identified 448 by a Domain Name and a Maintenance Level (a numeric identifier). If 449 two domains are nested, the encompassing domain must be assigned a 450 higher Maintenance Level number than the enclosed domain. For this 451 reason, the encompassing domain is commonly referred to as the 452 'higher' domain, and the enclosed domain is referred to as the 453 'lower' domain. OAM functions in the lower domain are completely 454 transparent to the higher domain. Furthermore, OAM functions in the 455 higher domain only have visibility to the boundary of the lower 456 domain (for example, an attempt to trace the path in the higher 457 domain will depict the entire lower domain as a single-hop between 458 the RBridges that constitute the boundary of that lower domain). By 459 the same token, OAM functions in the higher domain are transparent to 460 RBridges that are internal to the lower domain. The hierarchical 461 nesting of domains is established through operator configuration of 462 the RBridges. 464 +-------------------+ +---------------+ +-------------------+ 465 | | | TRILL | | | 466 | Site 1 +----+Interconnect +----+ Site 2 | 467 | TRILL | RB | Network | RB | TRILL | 468 | (Level 1) +----+ (Level 2) +----+ (Level 1) | 469 | | | | | | 470 +-------------------+ +---------------+ +-------------------+ 472 <------------------------End-to-End Domain--------------------> 474 <----Site Domain----> <--Interconnect --> <----Site Domain----> 475 Domain 477 Figure 3: TRILL OAM Maintenance Domains 479 2.5 Maintenance Entity and Maintenance Entity Group 481 TRILL OAM functions are performed in the context of logical endpoint 482 pairs referred to as Maintenance Entities (ME). A Maintenance Entity 483 defines a relationship between two points in a TRILL network where 484 OAM functions (for example, monitoring operations) are applied. The 485 two points that define a Maintenance Entity are known as Maintenance 486 End Points (MEPs) - see section 2.6 below. The set of Maintenance End 487 Points that belong to the same Maintenance Domain are referred to as 488 a Maintenance Association (MA). On the network path in between MEPs, 489 there can be zero or more intermediate points, called Maintenance 490 Intermediate Points (MIPs). MEPs can be part of more than one ME in 491 a given MA. 493 2.6 MEPs and MIPs 494 OAM capabilities on RBridges can be defined in terms of logical 495 groupings of functions that can be categorized into two functional 496 objects: Maintenance End Points (MEPs) and Maintenance Intermediate 497 Points (MIPs). The two are collectively referred to as Maintenance 498 Points (MPs). 500 MEPs are the active components of TRILL OAM: MEPs source TRILL OAM 501 messages periodically or on-demand based on operator configuration 502 actions. Furthermore, MEPs ensure that TRILL OAM messages do not leak 503 outside a given Maintenance Domain, for example, out of the TRILL 504 network and into end stations. MIPs, on the other hand, are internal 505 to a Maintenance Domain. They are the more passive components of 506 TRILL OAM, primarily responsible for forwarding TRILL OAM messages 507 and selectively responding to a subset of these messages. 509 The following figure shows the MEP and MIP placement for the 510 Maintenance Domains depicted in Figure 3 above. 512 TRILL Site 1 Interconnect TRILL Site 2 513 +-----------------+ +------------------+ +-----------------+ 514 | | | | | | 515 | +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | 516 | |RB1|--|RB2|--|RB3|--|RB4|--|RB5|--|RB6|--|RB7|--|RB8| | 517 | +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | 518 | | | | | | 519 +-----------------+ +------------------+ +-----------------+ 521 523 525 Legend E: MEP I: MIP 527 Figure 4: MEPs and MIPs 529 A single RBridge may host multiple MEPs of different technologies, 530 for example, TRILL OAM MEP(s) and [802.1Q] MEP(s). This does not mean 531 that the protocol operation is necessarily consolidated into a single 532 functional entity on those ports. The protocol functions for each MEP 533 remain independent and reside in different shims in the RBridge Port 534 model of Figure 2: the TRILL OAM MEP resides in the "TRILL OAM 535 Processing" block whereas a CFM MEP resides in the "End Station VLAN 536 & Priority Processing" block. 538 In the model of Section 2.2, a single MEP and/or MIP per MA can be 539 instantiated per RBridge port. A MEP is further qualified with an 540 administratively set direction (UP or DOWN), as follows: 542 - An UP MEP sends and receives OAM messages through the RBridge 543 Forwarding Engine. This means that an UP MEP effectively communicates 544 with MEPs on other RBridges through TRILL interfaces other than the 545 one that the MEP is configured on. 547 - A DOWN MEP sends and receives OAM messages through the link 548 connected to the interface on which the MEP is configured. 550 In order to support TRILL OAM functions on sections, as described in 551 [RFC6905], while maintaining the simplicity of a single TRILL OAM 552 Maintenance Domain, the TRILL OAM Layer may be implemented on a 553 virtual port with no physical layer (Null PHY). In this case, the 554 Down MEP function is not supported, since the virtual port does not 555 attach to a link; as such, a Down MEP on a virtual port would not be 556 capable of sending or receiving OAM messages. 558 A TRILL OAM solution that conforms to this framework: 560 - must support the MIP function on TRILL ports (to 561 support fault isolation) 562 - must support the UP MEP function on a TRILL virtual port (to 563 support OAM functions on Sections, as defined in [RFC6905]) 564 - may support the UP MEP function on TRILL ports 565 - may support the DOWN MEP function on TRILL ports 567 2.7 Maintenance Point Addressing 569 TRILL OAM functions must provide the capability to address a specific 570 Maintenance Point or a set of one or more Maintenance Points in a MA. 571 To that end, RBridges need to recognize two sets of addresses: 573 - Individual MP addresses 575 - Group MP Addresses 577 TRILL OAM will support the Shared MP address model, where all MPs on 578 an RBridge share the same Individual MP address. In other words, 579 TRILL OAM messages can be addressed to a specific RBridge but not to 580 a specific port on an RBridge. 582 One cannot discern, from observing the external behavior of an 583 RBridge, whether TRILL OAM messages are actually delivered to a 584 certain MP or another entity within the RBridge. The Shared MP 585 address model takes advantage of this fact by allowing MPs in 586 different RBridge ports to share the same Individual MP address. The 587 MPs may still be implemented as residing on different RBridge ports 588 and for the most part, they have distinct identities. 590 The Group MP addresses enable the OAM mechanism to reach all the MPs 591 in a given MA. Certain OAM functions, for example, pruned tree 592 verification, require addressing a subset of the MPs in a MA. Group 593 MP addresses are not defined for such subsets. Rather, the OAM 594 function in question must use the Group MP addresses combined with an 595 indication of the scope of the MP subset encoded in the OAM Message 596 Channel. This prevents an unwieldy set of responses to Group MP 597 addresses. 599 3. OAM Frame Format 601 3.1 Motivation 603 In order for TRILL OAM messages to accurately test the data-path, 604 these messages must be transparent to transit RBridges. That is, a 605 TRILL OAM message must be indistinguishable from a TRILL data packet 606 through normal transit RBridge processing. Only the target RBridge, 607 which needs to process the message, should identify and trap the 608 packet as a control message through normal processing. Additionally 609 methods must be provided to prevent OAM packets from being 610 transmitted out as native frames. 612 The TRILL OAM packet format defined below provides the necessary 613 flexibility to exercise the data path as closely as possible to 614 actual data packets. 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | | 618 . Link Header . Variable 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Initial 8 byte fixed part of | 622 + TRILL Header + 8 bytes 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | TRILL Header Extensions | 626 . (if any) . Variable 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 629 | DA / SA | \ 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 631 | Data Label | | Flow Entropy 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Fixed Size 633 . . | 634 . . / 635 | | / 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 637 | OAM EtherType | 2 bytes 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | | 640 . OAM Message Channel . Variable 641 . . 642 | | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 . Link Trailer . Variable 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Figure 5: OAM Frame Format 651 The TRILL Header and the Link Header and Trailer need to be as 652 similar as practical to the Link Header/Trailer and TRILL Header of 653 the normal TRILL data packet corresponding to the traffic that OAM is 654 testing. 656 The OAM EtherType demarcates the boundary between the Flow Entropy 657 and the OAM Message Channel. The OAM EtherType is expected at a 658 deterministic offset from the TRILL Header, thereby allowing 659 applications to clearly identify the beginning of the OAM Message 660 Channel. Additionally, it facilitates the use of the same OAM frame 661 structure by different Ethernet technologies. 663 The Link Trailer is usually a checksum, such as the Ethernet Frame 664 Check Sequence, which is examined at a low level very early in the 665 frame input process and automatically generated as part of the low 666 level frame output process. If the checksum fails, the frame is 667 normally discarded with no higher level processing. 669 3.2 Determination of Flow Entropy 671 The Flow Entropy is a fixed length field that is populated with 672 either real packet data or synthetic data that mimics the intended 673 flow. It always start with a destination and source MAC address area 674 followed by a Data Label area (either a VLAN or fine grain label). 676 For a Layer 2 flow (that is, non-IP) the Flow Entropy must specify 677 the desired Ethernet header, including the MAC destination and source 678 addresses as well as a VLAN tag or fine grain label. 680 For a Layer 3 flow, the Flow Entropy must specify the desired 681 Ethernet header, the IP header and UDP or TCP header fields, although 682 the Ethernet layer header fields are also still present. 684 Not all fields in the Flow Entropy field need to be identical to the 685 data flow that the OAM message is mimicking. The only requirement is 686 for the selected flow entropy to follow the same path as the data 687 flow that it is mimicking. In other words, the selected flow entropy 688 must result in the same ECMP selection or multicast pruning behavior 689 or other applicable forwarding paradigm. 691 When performing diagnostics on user flows, the OAM mechanisms must 692 allow the network operator to configure the flow entropy parameters 693 (for example, Layer 2 and/or 3) on the RBridge from which the 694 diagnostic operations are to be triggered. 696 When running OAM functions over Test Flows, the TRILL OAM may provide 697 a mechanism for discovering the flow entropy parameters by querying 698 the RBridges dynamically, or allow the network operator to configure 699 the flow entropy parameters. 701 3.2.1 Address Learning and Flow Entropy 703 Edge TRILL switches, like traditional 802.1 bridges, are required to 704 learn MAC address associations. Learning is accomplished either by 705 snooping data packets or through other methods. The flow entropy 706 field of TRILL OAM messages mimics real packets and may impact the 707 address learning process of the TRILL data plane. TRILL OAM is 708 required to provide methods to prevent any learning of addresses from 709 the flow entropy field of OAM messages that would interfere with 710 normal TRILL operation. This can be done, for example, by 711 suppressing/preventing MAC address learning from OAM messages. 713 3.3 OAM Message Channel 715 The OAM Message Channel provides methods to communicate OAM specific 716 details between RBridges. [802.1Q] CFM and [RFC4379] have implemented 717 OAM message channels. It is desirable to select an appropriate 718 technology and re-use it, instead of redesigning yet another OAM 719 channel. TRILL is a transport layer that carries Ethernet frames, so 720 the TRILL OAM model specified earlier is based on the [802.1Q] CFM 721 model. The use of [802.1Q] CFM encoding format for the OAM Message 722 channel is one possible choice. [TRILL-OAM] presents a proposal on 723 the use of [802.1Q] CFM payload as the OAM message channel. 725 3.4 Identification of OAM Messages 727 RBridges must be able to identify OAM messages that are destined to 728 them, either individually or as a group, so as to properly process 729 those messages. 731 TRILL, as defined in [RFC6325], does not specify a method to identify 732 OAM messages. The most reliable method to identify these messages, 733 without imposing restrictions on the Flow Entropy field, involves 734 modifying the definition of the TRILL header to include an "Alert" 735 flag. This flag signals that the contents of the TRILL packet is a 736 control message as opposed to user data. The use of such a flag would 737 not be limited to TRILL OAM, and may be leveraged by any other TRILL 738 control protocol that require in-band behavior. The TRILL header 739 currently has two reserved bits that are unused. One of those bits 740 may be used as the Alert flag. In order to guarantee accurate in-band 741 forwarding behavior, RBridges must not use the Alert flag in ECMP 742 hashing decisions. Furthermore, to ensure that this flag remains 743 protocol agnostic, TRILL OAM mechanisms must not rely solely on the 744 Alert flag to identify OAM messages. Rather, these solutions must 745 identify OAM messages based on the combination of the Alert flag and 746 the OAM EtherType. 748 Since the above mechanism requires modification of the TRILL header, 749 it is not backward compatible. TRILL OAM solutions should provide 750 alternate methods to identify OAM messages that work on existing 751 RBridge implementations, thereby providing backwards compatibility. 753 4. Fault Management 755 Section 4.1 below discusses proactive fault management and Section 756 4.2 discusses on-demand fault management. 758 4.1 Proactive Fault Management Functions 759 Proactive fault management functions are configured by the network 760 operator to run periodically without a time bound, or are configured 761 to trigger certain actions upon the occurrence of specific events. 763 4.1.1 Fault Detection (Continuity Check) 765 Proactive fault detection is performed by periodically monitoring the 766 reachability between service endpoints, that is, MEPs in a given MA, 767 through the exchange of Continuity Check messages. The reachability 768 between any two arbitrary MEP may be monitored for a specified path, 769 all paths or any representative path. The fact that TRILL networks do 770 not enforce congruence between unicast and multicast paths means that 771 the proactive fault detection mechanism must provide procedures to 772 monitor the unicast paths independently of the multicast paths. 773 Furthermore, where the network has ECMP, the proactive fault 774 detection mechanism must be capable of exercising the equal-cost 775 paths individually. 777 The set of MEPs exchanging Continuity Check messages in a given 778 domain and for a specific monitored entity (flow, network or service) 779 must use the same transmission period. As long as the fault detection 780 mechanism involves MEPs transmitting periodic heartbeat messages 781 independently, then this OAM procedure is not affected by the lack of 782 forward/reverse path symmetry in TRILL. 784 The proactive fault detection function must detect the following 785 types of defects: 787 - Loss of continuity to one or more remote MEPs 788 - Unexpected connectivity between isolated VLANs or 789 fine-grained labels (mismerge) 790 - Unexpected connectivity to one or more remote MEPs 791 - Mismatch of the Continuity Check transmission period between MEPs 793 4.1.2 Defect Indication 795 TRILL OAM must support event-driven defect indication upon the 796 detection of a connectivity defect. Defect indications can be 797 categorized into two types: 799 4.1.2.1 Forward Defect Indication 801 This is used to signal a failure that is detected by a lower layer 802 OAM mechanism. Forward Defect indication is transmitted away from the 803 direction of the failure. For example, consider a simple network 804 comprising of four RBridges connected in series: RB1, RB2, RB3 and 805 RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 806 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a 807 forward defect indication towards RB1 while RB3 sends a forward 808 defect indication towards RB4. 810 Forward defect indication may be used for alarm suppression and/or 811 for purpose of inter-working with other layer OAM protocols. Alarm 812 suppression is useful when a transport/network level fault translates 813 to multiple service or flow level faults. In such a scenario, it is 814 enough to alert a network management station (NMS) of the single 815 transport/network level fault in lieu of flooding that NMS with a 816 multitude of Service or Flow granularity alarms. 818 4.1.2.2 Reverse Defect Indication (RDI) 820 RDI is used to signal that the advertising MEP has detected a loss of 821 continuity defect. RDI is transmitted in the direction of the 822 failure. For example, consider the same series network of the 823 previous section (4.1.2.1). If RB1 detects that is has lost 824 connectivity to RB4 because it is no longer receiving Continuity 825 Check messages from the MEP on RB4, then RB1 can transmit an RDI 826 towards RB4 to inform the latter of the failure. If the failure is 827 unidirectional (it is affecting the direction from RB4 to RB1), then 828 the RDI enables RB4 to become aware of the unidirectional 829 connectivity anomaly. 831 In the presence of equal-cost paths between MEPs, RDI must be able to 832 identify on which equal-cost path the failure was detected. 834 RDI allows single-sided management, where the network operator can 835 examine the state of a single MEP and deduce the overall health of a 836 monitored entity (network, flow or service). 838 4.2 On-Demand Fault Management Functions 840 On-demand fault management functions are initiated manually by the 841 network operator either as a one-time occurrence or as an action/test 842 that continues for a time bound period. These functions enable the 843 operator to run diagnostics to investigate a defect condition. 845 4.2.1 Connectivity Verification 847 As specified in [RFC6905], TRILL OAM must support on-demand 848 connectivity verification for unicast and multicast. The connectivity 849 verification mechanism must provide a means for specifying and 850 carrying in the messages: 852 - variable length payload/padding to test MTU related connectivity 853 problems. 855 - test message formats as defined in [RFC2544]. 857 4.2.1.1 Unicast 859 Unicast connectivity verification operation must be initiated from a 860 MEP and may target either a MIP or another MEP. For unicast, 861 connectivity verification can be performed at either Network or Flow 862 granularity. 864 Connectivity verification at the Network granularity tests 865 connectivity between a MEP on a source RBridge and a MIP or MEP on a 866 target RBridge over a test VLAN or fine grain label and for a test 867 flow. The operator must supply the source and target RBridges for the 868 operation, and the test VLAN/flow information uses pre-set values or 869 defaults. 871 Connectivity verification at the Flow granularity tests connectivity 872 between a MEP on a source RBridge and a MIP or MEP on a target 873 RBridge over an operator specified VLAN or fine grain label with 874 operator specified flow parameters. 876 The above functions must be supported on sections, as defined in 877 [RFC6905]. When connectivity verification is triggered over a 878 section, and the initiating MEP does not coincide with the edge 879 (ingress) RBridge, the MEP must use the edge RBridge nickname instead 880 of the local RBridge nickname on the associated connectivity 881 verification messages. The operator must supply the edge RBridge 882 nickname as part of the operation parameters. 884 4.2.1.2 Multicast 886 For multicast, the connectivity verification function tests all 887 branches and leaf nodes of a multi-destination distribution tree for 888 reachability. This function should include mechanisms to prevent 889 reply storms from overwhelming the initiating RBridge. This may be 890 done, for example, by staggering the replies through the introduction 891 of a random delay timer, with a preset upper bound, on the responding 892 RBridge ([802.1Q] CFM uses similar mechanisms for Linktrace Reply 893 messages to mitigate the load on the originating MEP). The upper 894 bound on the timer value should be selected by the OAM solution to be 895 long enough to accommodate large distribution trees, while allowing 896 the connectivity verification operation to conclude within a 897 reasonable time. To further prevent reply storms, connectivity 898 verification operation is initiated from a MEP and must target MEPs 899 only. MIPs are transparent to multicast connectivity verification. 901 Per [RFC6905], multicast connectivity verification must provide the 902 following granularity of operation: 904 A. Un-pruned Tree 906 - Connectivity verification for un-pruned multi-destination 907 distribution tree. The operator in this case supplies the tree 908 identifier (root nickname) and campus wide diagnostic VLAN or fine 909 grain label. 911 B. Pruned Tree 913 - Connectivity verification for a VLAN or fine-grain label in a given 914 multi-destination distribution tree. The operator in this case 915 supplies the tree identifier and VLAN or fine grain label. 917 - Connectivity verification for an IP multicast group in a given 918 multi-destination distribution tree. The operator in this case 919 supplies: the tree identifier, VLAN or fine grain label and IP (S,G) 920 or (*,G). 922 4.2.2 Fault Isolation 924 TRILL OAM must support an on-demand connectivity fault localization 925 function. This is the capability to trace the path of a Flow on a 926 hop-by-hop (RBridge by RBridge) basis to isolate failures. This 927 involves the capability to narrow down the locality of a fault to a 928 particular port, link or node. The characteristic of forward/reverse 929 path asymmetry, in TRILL, renders fault isolation into a direction- 930 sensitive operation. That is, given two RBridges A and B, 931 localization of connectivity faults between them requires running 932 fault isolation procedures from RBridge A to RBridge B as well as 933 from RBridge B to RBridge A. Generally speaking, single-sided fault 934 isolation is not possible in TRILL OAM. 936 Furthermore, TRILL OAM should support fault isolation over 937 distribution trees for both un-pruned as well as pruned trees. The 938 former allows the tracing of all active branches of a tree, whereas 939 the latter allows tracing of the active subset of branches associated 940 with a given Flow. 942 5. Performance Monitoring 944 Performance Monitoring functions are optional in TRILL OAM, per 945 [RFC6905]. These functions can be performed both proactively and on- 946 demand. Proactive management involves a scheduling function, where 947 the performance monitoring probes can be triggered on a recurring 948 basis. Since the basic performance monitoring functions involved are 949 the same, we make no distinction between proactive and on-demand 950 functions in this section. 952 5.1 Packet Loss 954 Given that TRILL provides inherent support for multipoint-to- 955 multipoint connectivity, then packet loss cannot be accurately 956 measured by means of counting user data packets. This is because user 957 packets can be delivered to more RBridges or more ports than are 958 necessary (for example, due to broadcast, un-pruned multicast or 959 unknown unicast flooding). As such, a statistical means of 960 approximating packet loss rate is required. This can be achieved by 961 sending "synthetic" (TRILL OAM) packets that are counted only by 962 those ports (MEPs) that are required to receive them. This provides a 963 statistical approximation of the number of data frames lost, even 964 with multipoint-to-multipoint connectivity. TRILL OAM mechanisms for 965 synthetic packet loss measurement should follow the statistical 966 considerations specified in [MEF35], especially with regards to the 967 volume/frequency of synthetic traffic generation and associated 968 impact on packet loss count accuracy. 970 Packet loss probes must be initiated from a MEP and must target a 971 MEP. This function should be supported on sections, as defined in 972 [RFC6905]. When packet loss is measured over a section, and the 973 initiating MEP does not coincide with the edge (ingress) RBridge, the 974 MEP must use the edge RBridge nickname instead of the local RBridge 975 nickname on the associated loss measurement messages. The user must 976 supply the edge RBridge nickname as part of the operation parameters. 978 TRILL OAM mechanisms should support one-way and two-way packet loss 979 monitoring. In one-way monitoring, a source RBridge triggers packet 980 loss monitoring messages to a target RBridge, and the latter is 981 responsible for calculating the loss in the direction from the source 982 RBridge towards the target RBridge. In two-way monitoring, a source 983 RBridge triggers packet loss monitoring messages to a target RBridge, 984 and the latter replies to the source with response messages. The 985 source RBridge can then monitor packet loss in both directions 986 (source to target and target to source). 988 5.2 Packet Delay 990 Packet delay is measured by inserting time-stamps in TRILL OAM 991 packets. In order to ensure high accuracy of measurement, TRILL OAM 992 must specify the time-stamp location at fixed offsets within the OAM 993 packet in order to facilitate hardware-based time-stamping. Hardware 994 implementations must implement the time-stamping function as close to 995 the wire as practical in order to maintain high accuracy. 997 TRILL OAM mechanisms should support one-way and two-way packet delay 998 monitoring. In one-way monitoring, a source RBridge triggers packet 999 delay-monitoring messages to a target RBridge, and the latter is 1000 responsible for calculating the delay in the direction from the 1001 source RBridge towards the target RBridge. This requires 1002 synchronization of the clocks between the two RBridges. In two-way 1003 monitoring, a source RBridge triggers packet delay monitoring 1004 messages to a target RBridge, and the latter replies to the source 1005 with response messages. The source RBridge can then monitor packet 1006 delay in both directions (source to target and target to source) as 1007 well as the cumulative round-trip delay. In this case as well, 1008 monitoring the delay in a single direction requires clock 1009 synchronization between the two RBridges. Whereas monitoring the 1010 round-trip delay does not require clock synchronization. Mechanisms 1011 for clock synchronization between RBridges are outside the scope of 1012 this document. 1014 6. Operational and Manageability Considerations 1016 6.1 TRILL OAM Configuration 1018 RBridges may be configured to enable TRILL OAM functions via the 1019 device Command Line Interface (CLI) or through one of the defined 1020 management protocols, such as SNMP [RFC3410] or NETCONF [RFC6241]. 1022 In order to maintain the plug-and-play characteristics of TRILL, the 1023 number of parameters that need to be configured on RBridges, in order 1024 to activate TRILL OAM, should be kept to a minimum. To that end, 1025 TRILL OAM mechanisms should rely on default values and auto-discovery 1026 mechanisms (for example, leveraging IS-IS) where applicable. The 1027 following is a non-exhaustive list of configuration parameters that 1028 apply to TRILL OAM. 1030 6.1.1 Maintenance Domain Parameters 1032 - Maintenance Domain Name 1033 An alphanumeric name for the Maintenance Domain. This is an IETF 1034 [RFC2579] DisplayString, with the exception that character codes 0- 1035 31 (decimal) are not used. The recommended default value is the 1036 character string "DEFAULT". 1038 - Maintenance Domain Level 1039 An integer in the range 0 to 7 indicating the Level at which the 1040 Maintenance Domain is to be created. Default value is 0. 1042 6.1.2 Maintenance Association Parameters 1044 - MA Name 1045 An alphanumeric name that uniquely identifies the Maintenance 1046 Association. This is an IETF [RFC2579] DisplayString, with the 1047 exception that character codes 0-31 (decimal) are not used. The 1048 recommended default value is a character string set to the value of 1049 the VLAN or fine grain label as "vl" or "fgl" concatenated with the 1050 VLAN ID or FGL ID as an unsigned decimal integer. 1052 - List of MEP Identifiers 1053 A list of the identifiers of the MEPs that belong to the MA. This 1054 is optional, and required only if the operator wants to detect 1055 missing MEPs as part of the Continuity Check function. 1057 6.1.3 Maintenance Endpoint Parameters 1059 - MEP Identifier 1060 An integer, unique over a given Maintenance Association, 1061 identifying a specific MEP. [802.1Q] CFM limits this to the range 1 1062 to 8191. This document recommends expanding the range from 1 to 1063 65535 so that the RBridge Nickname can be used as a default value. 1064 This will help keep TRILL OAM low-touch in terms of configuration 1065 overhead. 1067 - Direction 1068 Indicates whether this is an UP MEP or DOWN MEP. 1070 - Associated Interface 1071 Specifies the interface on which the MEP is configured. 1073 - MA context 1074 Specifies the Maintenance Association to which the MEP belongs. 1076 6.1.4 Continuity Check Parameters (applicable per MA) 1078 - Transmission interval 1079 Indicates the interval at which Continuity Check messages are sent 1080 by a MEP. 1082 - Loss threshold 1083 Indicates the number of consecutive Continuity Check messages that 1084 a MEP must not receive from any one of the other MEPs in its MA 1085 before indicating either a MEP failure or a network failure. 1086 Recommended default value is 3. 1088 - VLAN, Fine grain label and Flow parameters 1089 The VLAN or fine grain label and flow parameters to be used in the 1090 Continuity Check messages. 1092 - Hop Count 1093 The Hop Count to be used in the Continuity Check messages. 1095 6.1.5 Connectivity Verification Parameters (applicable per operation) 1097 - MA context 1098 Specifies the Maintenance Association in which the Connectivity 1099 Verification operation is to be performed. 1101 - Target RBridge Nickname (unicast), Tree Identifier (Multicast) and 1102 IP multicast group 1103 For unicast, the Nickname of the RBridge that is the target of the 1104 Connectivity Verification operation. For multicast, the target Tree 1105 Identifier for un-pruned tree verification or the Tree Identifier 1106 and IP multicast group (S, G) or (*, G) for pruned tree 1107 verification. 1109 - VLAN, Fine grain label and Flow parameters 1110 The VLAN or fine grain label and flow parameters to be used in the 1111 Connectivity Verification message. 1113 - Operation timeout value 1114 The timeout on the initiating MEP before the Connectivity 1115 Verification operation is declared to have failed. The recommended 1116 default value is 5 seconds. 1118 - Repeat Count 1119 The number of Connectivity Verification messages that must be 1120 transmitted per operation. The recommended default value is 1. 1122 - Hop Count 1123 The Hop Count to be used in the Connectivity Verification messages. 1125 - Reply Mode 1126 Indicates whether the response to the Connectivity Verification 1127 operation should be sent in-band or out-of-band. 1129 - Scope List (Multicast) 1130 List of MEP Identifiers that must respond to the message. 1132 6.1.6 Fault Isolation Parameters (applicable per operation) 1134 - MA context 1135 Specifies the Maintenance Association in which the Fault Isolation 1136 operation is to be performed. 1138 - Target RBridge Nickname (unicast), Tree Identifier (Multicast) and 1139 IP multicast group 1140 For unicast, the Nickname of the RBridge that is the target of the 1141 Fault Isolation operation. For multicast, the target Tree 1142 Identifier for un-pruned tree tracing or the Tree Identifier and IP 1143 multicast group (S, G) or (*, G) for pruned tree tracing. 1145 - VLAN, Fine grain label and Flow parameters 1146 The VLAN or fine grain label and flow parameters to be used in the 1147 Fault Isolation messages. 1149 - Operation timeout value 1150 The timeout on the initiating MEP before the Fault Isolation 1151 operation is declared to have failed. The recommended default value 1152 is 5 seconds. 1154 - Hop Count 1155 The Hop Count to be used in the Fault Isolation messages. 1157 - Reply Mode 1158 Indicates whether the response to the Fault Isolation operation 1159 should be sent in-band or out-of-band. 1161 - Scope List (Multicast) 1162 List of MEP Identifiers that must respond to the message. 1164 6.1.7 Packet Loss Monitoring 1166 - MA context 1167 Specifies the Maintenance Association in which the Packet Loss 1168 Monitoring operation is to be performed. 1170 - Target RBridge Nickname 1171 The Nickname of the RBridge that is the target of the Packet Loss 1172 Monitoring operation. 1174 - VLAN, Fine grain label and Flow parameters 1175 The VLAN or fine grain label and flow parameters to be used in the 1176 Packet Loss monitoring messages. 1178 - Transmission Rate 1179 The transmission rate at which the Packet Loss monitoring messages 1180 are to be sent. 1182 - Monitoring Interval 1183 The total duration of time for which a single Packet Loss 1184 monitoring probe is to continue. 1186 - Repeat Count 1187 The number of probe operations to be performed. For on-demand 1188 monitoring, this is typically set to 1. For proactive monitoring 1189 this may be set to allow for infinite monitoring. 1191 - Hop Count 1192 The Hop Count to be used in the Packet Loss monitoring messages. 1194 - Mode 1195 Indicates whether one-way or two-way loss measurement is required. 1197 6.1.8 Packet Delay Monitoring 1199 - MA context 1200 Specifies the Maintenance Association in which the Packet Delay 1201 monitoring operation is to be performed 1203 - Target RBridge Nickname 1204 The Nickname of the RBridge that is the target of the Packet Delay 1205 monitoring operation. 1207 - VLAN, Fine grain label and Flow parameters 1208 The VLAN or fine grain label and flow parameters to be used in the 1209 Packet Delay monitoring messages. 1211 - Transmission Rate 1212 The transmission rate at which the Packet Delay monitoring messages 1213 are to be sent. 1215 - Monitoring Interval 1216 The total duration of time for which a single Packet Delay 1217 monitoring probe is to continue. 1219 - Repeat Count 1220 The number of probe operations to be performed. For on-demand 1221 monitoring, this is typically set to 1. For proactive monitoring 1222 this may be set to allow for infinite monitoring. 1224 - Hop Count 1225 The Hop Count to be used in the Packet Delay monitoring messages. 1227 - Mode 1228 Indicates whether one-way or two-way delay measurement is required. 1230 6.2 TRILL OAM Notifications 1232 TRILL OAM mechanisms should trigger notifications to alert operators 1233 to certain conditions. Such conditions include but are not limited 1234 to: 1236 - Faults detected by proactive mechanisms. 1237 - Reception of event-driven defect indications. 1238 - Logged security incidents pertaining to the OAM message channel. 1240 - Protocol errors (for example, as caused by mis-configuration). 1242 Notifications generated by TRILL OAM mechanisms may be via SNMP, 1243 Syslog messages [RFC5424] or any other standard management protocol 1244 that supports asynchronous notifications. 1246 6.3 Collecting Performance Monitoring Metrics 1248 When performing the optional TRILL OAM Performance Monitoring 1249 functions, two RBridge designations are involved: a source RBridge 1250 and a target RBridge. The source RBridge is the one from which the 1251 Performance Monitoring probe is initiated, and the target RBridge is 1252 the destination of the probe. The goal being to monitor performance 1253 characteristics between the two RBridges. The RBridge from which the 1254 network operator can extract the results of the probe (the 1255 Performance Monitoring metrics) depends on whether one-way or two-way 1256 performance monitoring functions are performed: 1258 In the case of one-way performance monitoring functions, the metrics 1259 will be available at the target RBridge. 1261 In the case of two-way performance monitoring functions, all the 1262 metrics will be available at the source RBridge, and a subset will be 1263 available at the target RBridge. More specifically, metrics in the 1264 direction from source to target as well as the direction from target 1265 to source will be available at the source RBridge. Whereas, metrics 1266 in the direction from source to target will be available at the 1267 target RBridge. 1269 7. Security Considerations 1271 TRILL OAM must provide mechanisms for: 1273 - Preventing denial of service attacks caused by exploitation of 1274 the OAM message channel, where a rogue device may overload the 1275 RBridges and the network with OAM messages. This could lead to 1276 interruption of the OAM services and in the extreme case disrupt 1277 network connectivity. Mechanisms such as control-plane policing 1278 combined with shaping or rate limiting of OAM messaging can be 1279 employed to mitigate this. 1281 - Optionally authenticate at communicating endpoints (MEPs and 1282 MIPs) that an OAM message has originated at an appropriate 1283 communicating endpoint. 1285 - Preventing TRILL OAM packets from leaking outside of the TRILL 1286 network or outside their corresponding Maintenance Domain. This can 1287 be done by having MEPs implement a filtering function based on the 1288 Maintenance Level associated with received OAM packets. 1290 For general TRILL Security Considerations, see [RFC6325]. 1292 8. IANA Considerations 1294 This document requires no IANA Actions. 1296 9. Acknowledgments 1298 We thank Gayle Noble, Dan Romascanu, Olen Stokes, Susan Hares, Ali 1299 Karimi and Prabhu Raj for their thorough review of this work and 1300 their comments. 1302 10. References 1304 10.1 Normative References 1306 [RFC6905] Senevirathne, et al., "Requirements for Operations, 1307 Administration, and Maintenance (OAM) in Transparent 1308 Interconnection of Lots of Links (TRILL)", RFC 6905, March 1309 2013. 1311 [RFC6325] Perlman, et al., "Routing Bridges (RBridges): Base 1312 Protocol Specification", RFC 6325, July 2011. 1314 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1315 Network Interconnect Devices", RFC 2544, March 1999. 1317 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1318 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 1319 58, RFC 2579, April 1999. 1321 [RFC6291] Andersson et al., BCP 161 "Guidelines for the Use of the 1322 "OAM" Acronym in the IETF", June 2011. 1324 [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and 1325 V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 1326 6327, July 2011. 1328 [TRILL-FGL] D. Eastlake et al., "TRILL Fine-Grained Labeling", draft- 1329 ietf-trill-fine-labeling, work in progress. 1331 [802.1Q] "IEEE Standard for Local and metropolitan area networks - 1332 Media Access Control (MAC) Bridges and Virtual Bridge 1333 Local Area Networks", IEEE Std 802.1Q-2011, 31 August 1334 2011. 1336 [802] "IEEE Standard for Local and Metropolitan Area Networks - 1337 Overview and Architecture", IEEE Std 802-2001, 8 March 1338 2002. 1340 10.2 Informative References 1342 [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and 1343 mechanisms for Ethernet based networks", February 2008. 1345 [ISO/IEC 7498-4] "Information processing systems -- Open Systems 1346 Interconnection -- Basic Reference Model -- Part 4: 1347 Management framework", ISO/IEC, 1989. 1349 [draft-ietf-mpls-tp-rosetta-stone] van Helvoort et al., "A Thesaurus 1350 for the Terminology used in Multiprotocol Label Switching 1351 Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's 1352 Transport Network Recommendations", draft-ietf-mpls-tp- 1353 rosetta-stone-13, work in progress, October 2013. 1355 [TRILL-BFD] V. Manral, et al., "TRILL (Transparent Interconnection of 1356 Lots of Links): Bidirectional Forwarding Detection (BFD) 1357 Support", draft-ietf-trill-rbridge-bfd-07, work in 1358 progress, July 2012. 1360 [TRILL-OAM] T. Senevirathne, et al., "TRILL Fault Management", draft- 1361 tissa-trill-oam-fm-01, work in progress, February 2013. 1363 [TRILL-IP] M. Wasserman, et al., "Transparent Interconnection of Lots 1364 of Links (TRILL) over IP", draft-mrw-trill-over-ip-03, 1365 work in progress, October 2013. 1367 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 1368 51, RFC 1661, July 1994. 1370 [RFC6361] Carlson & Eastlake, "PPP Transparent Interconnection of 1371 Lots of Links (TRILL) Protocol Control Protocol", RFC 1372 6361, August 2011. 1374 [RFC5880] Katz & Ward, "Bidirectional Forwarding Detection (BFD)", 1375 RFC 5880, June 2010. 1377 [RFC4379] Kompella & Swallow, "Detecting Multi-Protocol Label 1378 Switched (MPLS) Data Plane Failures", RFC 4379, February 1379 2006. 1381 [RFC5860] Vigoureux, et al., "Requirements for Operations, 1382 Administration, and Maintenance (OAM) in MPLS Transport 1383 Networks", RFC 5860, May 2010. 1385 [RFC6371] Busi & Allan, "Operations, Administration, and Maintenance 1386 Framework for MPLS-Based Transport Networks", RFC 6371, 1387 September 2011. 1389 [TRILL-ML] Perlman, et al., "Alternatives for Multilevel TRILL", 1390 draft-perlman-trill-rbridge-multilevel-06, work in 1391 progress, July 2013. 1393 [RFC3410] Case, et al., "Introduction and Applicability Statements 1394 for Internet-Standard Management Framework", RFC 3410, 1395 December 2002. 1397 [RFC6241] Enns, et al., "Network Configuration Protocol (NETCONF)", 1398 RFC 6241, June 2011. 1400 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1402 [MEF35] "MEF 35 - Service OAM Performance Monitoring Implementation 1403 Agreement", Metro Ethernet Forum, April 2012. 1405 Authors' Addresses 1407 Samer Salam 1408 Cisco 1409 595 Burrard Street, Suite 2123 1410 Vancouver, BC V7X 1J1, Canada 1411 Email: ssalam@cisco.com 1413 Tissa Senevirathne 1414 Cisco 1415 375 East Tasman Drive 1416 San Jose, CA 95134, USA 1417 Email: tsenevir@cisco.com 1419 Sam Aldrin 1420 Huawei Technologies 1421 2330 Central Expressway 1422 Santa Clara, CA 95050, USA 1423 Email: sam.aldrin@gmail.com 1425 Donald Eastlake 1426 Huawei Technologies 1427 155 Beaver Street 1428 Milford, MA 01757, USA 1429 Tel: 1-508-333-2270 1430 Email: d3e3e3@gmail.com