idnits 2.17.1 draft-tissa-trill-oam-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Forward frames that have egress RBridge nickname equal to local RBridge nickname and EthType equal to Diagnostic Ethtype, to the Central Processing Unit (CPU). Such frames SHOULD NOT egress out of the RBridge. o The RBridge SHOULD not egress frames with Diagnostic Ethtype to non TRILL interfaces. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RFC 6325 section 3.6 explains handling of TRILL Hop-Count field. Accordingly, frames received with Hop-Count of zero (0) MUST not be forwarded. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Parameters specified herein SHOULD be utilized as default parameters. Parameters specified under the Fixed category MUST not be changed based on user specification and MUST be followed exactly as specified below. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 - VLAN non existent 1 - VLAN in suspended state 2 - Cross connect error 3 - Unknwon RBridge nickname 4 - Not AF 5 - MTU mismatch 6 - Interface not in forwarding state 7 - Service Tag non existent 8 - Service Tag in suspended state 9 - 0xFFFF - Reserved for future use and MUST not be used in transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Sub-code (2 octets) : identify the sub-error code. 0 - 0xFFFF - Reserved for future use and MUST not be used in transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Warning Code (2 octets) : Identify the Warning. Currently following Warnings are defined 0 - Inavlid RBridge nickname (RBridge nickname in the range 0xffco to 0xffff) 1 - Invalid VLAN (Reserved VLAN) 2 - AF VLAN list Mismatch 3 - 0xFFFF - Reserved for future use and MUST not be used in transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 - 0xFFFF - Reserved for future use and MUST not be used in transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 - 0xFFFF - Reserved for future use and MUST not be used in transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0 - 0xFFFF - Reserved for future use and MUST not be used in transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0. Success 1. ECMP does not exist 2. Unable to generate payload using the proposed seed 3. System overloaded try later 4. - 7 Reserved MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 6-255 : Reserved and MUST not be used == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Notification messages are generated either due to regular TRILL data frames or TRILL OAM frames. Implementation MUST not generate notification messages on notification messages. -- The document date (July 6, 2012) is 4310 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 792' is mentioned on line 219, but not defined == Missing Reference: 'RFC 4884' is mentioned on line 549, but not defined == Missing Reference: 'RFC 4379' is mentioned on line 700, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Missing Reference: 'RFC 1122' is mentioned on line 706, but not defined == Missing Reference: 'RFCtrill' is mentioned on line 4248, but not defined == Missing Reference: 'FNGRAIN' is mentioned on line 1894, but not defined == Missing Reference: 'RFC 2390' is mentioned on line 3174, but not defined == Missing Reference: 'RFC 826' is mentioned on line 3162, but not defined == Missing Reference: 'RFC 892' is mentioned on line 3173, but not defined ** Obsolete undefined reference: RFC 892 (Obsoleted by RFC 905) == Missing Reference: 'RFC 6325' is mentioned on line 3351, but not defined == Missing Reference: 'GenAPP' is mentioned on line 3883, but not defined == Unused Reference: 'RFC6326' is defined on line 4508, but no explicit reference was found in the text == Unused Reference: 'RFC6327' is defined on line 4511, but no explicit reference was found in the text == Unused Reference: 'RFC4379' is defined on line 4523, but no explicit reference was found in the text == Unused Reference: 'RFC826' is defined on line 4547, but no explicit reference was found in the text == Unused Reference: 'RFC2390' is defined on line 4550, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- No information found for draft-ietf-trill-channel - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TRILLCH' == Outdated reference: A later version (-02) exists of draft-ietf-trill-rbridge-oam-00 -- No information found for draft-shen-traceroute-ping-msg-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PINGEXT' == Outdated reference: A later version (-08) exists of draft-ietf-isis-mi-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 6 errors (**), 0 flaws (~~), 31 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft Dinesh G Dutt 3 Intended status: Standards Track CISCO 4 Vishwas Manral 5 HP Networking 6 Sam Aldrin 7 HuaWei 9 July 6, 2012 10 Expires: January 2013 12 ICMP based OAM Solution for TRILL 13 draft-tissa-trill-oam-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on December 6, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document presents a solution suite for TRILL data plane 56 monitoring and failure detection. Methods presented herein allow in- 57 cooperating IP payloads, exercising multi-paths, verifying multicast 58 trees, locating end stations, virtual segments and diagnosing 59 connectivity problems. ICMP protocol is proposed as framework for 60 error reporting. Document also presents network wide health 61 monitoring, distribution and reporting methods that are intended for 62 efficient troubleshooting. 64 Table of Contents 66 1. Introduction...................................................4 67 1.1. Motivation................................................6 68 1.2. Contributors..............................................7 69 2. Conventions used in this document..............................7 70 3. Protocol Architecture Overview.................................7 71 3.1. Overview of Tools.........................................8 72 3.2. TRILL Data Plane..........................................9 73 3.3. Monitoring...............................................10 74 3.4. Traffic Triggered Monitoring (TTM).......................10 75 3.5. Distribution.............................................10 76 3.6. ISIS.....................................................11 77 3.7. Reporting................................................11 78 4. Frame Format..................................................11 79 4.1. Encoding of Request message..............................12 80 4.2. Encoding of Response Message.............................13 81 4.3. Encoding of Notification Message.........................13 82 4.3.1. Pseudo IP Header....................................15 83 4.4. OAM Command Messages.....................................15 84 5. 127/8 in-band OAM IP address..................................16 85 5.1. IPv6 default in-band address.............................16 86 6. Identification of Diagnostic frames...........................17 87 6.1. Identification of Layer 2 Flow...........................17 88 6.2. Identification of IP Flows...............................17 89 6.3. Identification of Flows using Hop-Count Restrictions.....19 90 6.4. Identification of Multicast Flows........................20 91 6.4.1. Identification of overall tree verification frames..20 92 6.4.2. Identification of Layer 2 Multicast group verification 93 frames.....................................................21 94 6.4.3. Identification of IP Multicast group verification 95 frames.....................................................21 96 6.5. Default OAM flow Parameters..............................21 97 6.6. Validation of OAM Request and Response frames............22 98 7. ISIS Extensions...............................................23 99 8. ICMP multi part extensions....................................25 100 8.1. ICMP Echo Request and Response message extensions........25 101 8.2. C-Type Definitions.......................................26 102 9. Details of Diagnostic tools...................................57 103 9.1. Loopback Message.........................................57 104 9.1.1. Theory of Operation.................................58 105 9.1.1.1. Originator RBridge.............................58 106 9.1.1.2. Intermediate RBridge...........................59 107 9.1.1.3. Destination RBridge............................59 108 9.2. Loopback Message Hop-count method........................60 109 9.2.1. Identification of OAM frames........................60 110 9.2.2. Prevent leaking out from TRILL network..............60 111 9.3. Path Trace Message.......................................61 112 9.3.1. Theory of Operation.................................61 113 9.3.1.1. Originator RBridge.............................61 114 9.3.1.2. Intermediate RBridge...........................62 115 9.3.1.3. Destination RBridge............................63 116 9.4. Multicast Tree Verification (MTV) Message................63 117 9.4.1. Theory of Operation.................................64 118 9.4.1.1. Originator RBridge.............................64 119 9.4.1.2. Intermediate RBridge...........................65 120 9.4.1.3. In scope RBridges..............................66 121 9.5. MAC address discovery Message............................67 122 9.5.1. Theory of Operation.................................68 123 9.5.1.1. Originator RBridge.............................68 124 9.5.1.2. Receiving RBridges.............................69 125 9.6. Address-Binding Verification Message.....................71 126 9.6.1. Extension to ARP and invARP.........................72 127 9.6.1.1. Encoding ARP-invARP extensions.................74 128 9.7. End-Station Attachment Point Discovery...................76 129 9.8. DRB and AF Discovery.....................................77 130 9.8.1. Theory of Operation.................................78 131 9.8.1.1. Originator RBridge.............................78 132 9.8.1.2. Receiving RBridge..............................78 133 9.9. Diagnostic Payload Discovery for ECMP coverage...........80 134 9.9.1. Theory of Operations................................82 135 9.9.1.1. Receiving RBridge..............................83 136 9.10. Notification Messages...................................84 137 10. Monitoring and Reporting.....................................85 138 10.1. Data categories.........................................87 139 10.2. Advertising Policy......................................87 140 10.2.1. Multi Instance ISIS and Flooding Scope.............89 141 10.3. Summary Category........................................89 142 10.4. Detail Category.........................................91 143 10.5. Vendor Specific Category................................97 144 11. Traffic Triggered Monitoring (TTM)...........................98 145 11.1. TTM Policy.............................................100 146 11.2. TTM Commands...........................................102 147 11.3. Reverse Flow Monitoring (RFM)..........................103 148 12. Security Considerations.....................................103 149 13. IANA Considerations.........................................103 150 13.1. IANA considerations....................................103 151 13.1.1. ICMP Extensions...................................103 152 13.1.2. TRILL-OAM UDP port................................103 153 13.1.3. ARP Extensions....................................103 154 13.1.4. Well known Multicast MAC..........................104 155 13.2. IEEE Registration Authority Consideration..............104 156 14. References..................................................104 157 14.1. Normative References...................................104 158 14.2. Informative References.................................105 159 15. Acknowledgments.............................................105 160 Appendix A. Reports.............................................106 161 A.1. Sample Reports..........................................106 162 A.2. Summary Report..........................................106 163 A.3. Detail Report...........................................107 164 A.4. C-Type usage in messages................................108 165 Authors' Addresses..............................................109 167 1. Introduction 169 TRILL protocol has revolutionized how Layer 2 networks are being 170 built and used. Legacy Ethernet networks provide single path for 171 forwarding traffic and require all of the switches in the network to 172 learn end-station MAC addresses. TRILL, on the other hand utilize 173 multiple active links for forwarding thereby maximizing the overall 174 network bandwidth utilization. TRILL is simple plug-and-play 175 solution and does not require intermediate devices to learn MAC 176 addresses of end-stations. These powerful characteristics of TRILL 177 optimize performance and increase scaling limits. However, with that 178 comes increased difficulty in diagnosing connectivity problems and 179 locating end stations. 181 Network operators are used to troubleshooting legacy networks with 182 single paths. Legacy devices maintain forwarding database of all 183 end-station addresses in the Layer 2 network. Network administrators 184 can trace the path taken by specific MAC address by examining the 185 forwarding databases of devices. TRILL core switches, by design do 186 not maintain end-station address database. Hence, administrators may 187 not be able to trace a path taken by a specific MAC address by 188 tracing the forwarding databases. Additionally, a given device may 189 utilize multiple active paths to reach to a destination and may use 190 a completely different forwarding topology for multicast traffic 191 than it would use for unicast traffic. These challenges mandate the 192 presence of an effective tool set to monitor and diagnose data plane 193 failures in TRILL networks. These tools and protocols must stay as 194 close as possible to the forwarding paths taken by actual data. OAM 195 frames should not leak to end stations or out of the TRILL network 196 to legacy networks. 198 TRILL base protocol specification [RFC6325] does not specify 199 algorithm for selecting a path from a set of equal cost paths to 200 forward a given flow. The majority of traffic in the networks is IP 201 centric and most devices deploy some sort of hashing algorithm to 202 identify the forwarding path from set of equal cost paths for a 203 given flow. Thus, it is desirable to use IP address and TCP/UDP port 204 information as inputs to the ECMP selection hash function. Use of 205 such higher level information provides better distribution of flows 206 across multiple equal cost paths. This document, propose a framework 207 that allow specifying, various combinations of payloads including IP 208 payloads and actual payloads. 210 As TRILL based networks get deployed, during the transition period, 211 it may be required for TRILL RBridges to co-exist with legacy 212 networks. It is very helpful for the network operator if TRILL data 213 plane failure detection tools allow isolating problem to specific 214 legacy device or at least to the interface(s) that the downstream 215 legacy device is connected. Solutions presented in this document 216 facilitate identifying legacy devices or RBridge interfaces legacy 217 devices are connected to. 219 ICMP (Internet Control Message Protocol)[RFC 792] has been in use 220 for nearly three decades. ICMP multipart extensions [RFC4884], 221 propose methods to extend ICMP messages to include additional 222 information, without changing or inventing new ICMP message types. 223 In this document we utilize ICMP for reporting of errors. ICMP 224 multipart extensions will be utilized to define additional 225 information that is specific to TRILL. Additionally use of ICMP 226 allows sending error reports either in-band or out-of-band. Use of 227 out-of-band ICMP allows network operators to diagnose uni- 228 directional path failures easily. Also, the same ICMP infrastructure 229 can be utilized to generate unsolicited error notifications for 230 TRILL data plane failures, such as Destination unreachable, Time 231 Exceed (TTL expiry), Parameter Mismatch (MTU mismatch) etc.. 233 Availability of Network health information is a valuable starting 234 point for any failure detection process. In this document we present 235 the concept of network regions, monitoring of network regions and 236 distribution of network health. 238 Diagnostic tools are also commonly referred to as OAM (Operations, 239 Administration and Maintenance). In this document we use words 240 diagnostics and OAM interchangeably. Unless explicitly specified 241 both the words means the same. 243 1.1. Motivation 245 Currently published TRILL OAM solutions, [TRILLCH] and [TRILLOAM], 246 mainly focus on data plane encoding and individual tools. The 247 encoding methods presented in [TRILLCH] and [TRILLOAM], require 248 defining OAM channel that utilize a special EtherType. 249 Implementations that utilize ECMP selection algorithms based on 250 higher layer address information may require flexible OAM channel 251 that allow specifying different payloads including IP based 252 payloads. 254 Availability of network health information is important for 255 efficient isolation of network connectivity problems. Currently 256 there are neither standard sets of such data to be distributed nor 257 framework to distribute network health data. Lack of such leads to 258 cumbersome and time consuming troubleshooting of network 259 connectivity issues, especially in multi-vendor networks. 261 Device virtualization is an increasing trend in datacenters and 262 large enterprises. Physical servers may host multiple virtual 263 servers and these virtual servers may move from physical server to 264 physical server based on load balancing policies. As part of network 265 connectivity problem isolation, it is important to identify the 266 location of the virtual servers and RBridges they are connected to. 267 Currently, administrators are required to utilize multiple tools to 268 locate these virtual machines and connecting RBridges. 270 ICMP has been in use over three decades as the primary OAM tool of 271 IP infrastructure. It is highly desirable to utilize the framework 272 of existing infrastructure such as ICMP, thereby leveraging 273 knowledge, implementation and time to market. 275 TRILL networks can co-exist with multi access LAN networks at the 276 boundary of the TRILL network. TRILL protocol [RFC6325], introduced 277 Designated RBridge (DRB) and Appointed Forwarder (AF) concepts to 278 ensure loop free forwarding and load splitting at the boundary of 279 TRILL and multi access LAN networks. Discovery of DRB,AF and 280 associated VLANs are important for effective fault isolation at the 281 TRILL and multi access LAN boundary. Currently there are no known 282 tools available for the purpose. 284 In this document we propose a framework and solution suite that will 285 address the above. 287 1.2. Contributors 289 Many people contributed with ideas and comments. Among all, 290 following people made notable contributions to all parts of this 291 document and spend time reviewing, debating and commenting to ensure 292 this specification addressees the problem space. 294 Ian Cox, Ronak Desai, Satya Dillikar ,Rohit Watve, Ashok Ganesan and 295 Leonard Tracy. 297 2. Conventions used in this document 299 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 300 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 301 document are to be interpreted as described in RFC-2119 [RFC2119]. 303 In this document, these words will appear with that interpretation 304 only when in ALL CAPS. Lower case uses of these words are not to be 305 interpreted as carrying RFC-2119 significance. 307 3. Protocol Architecture Overview 309 Effective OAM solution is not only a set of tools but a wholesome 310 solution that covers all aspects of OAM, such as tools, monitoring, 311 reporting etc. Solution presented in this document contains multiple 312 subcomponents that cover various elements of the total solution. 313 There are six subcomponents in the proposed architecture. These 314 subcomponents collectively are called TRILL OAM Protocol. Here we 315 present an overview of the architecture of the solution and explain 316 the purpose of each of subcomponents and interaction between 317 different subcomponents. Subsequent sections cover details of each 318 of the subcomponents. 320 +--+ 321 | | +-------------+ +----------+ 322 | | | Reporting | | | 323 | | +-------------+ | | 324 | | ^ | ISIS | 325 |T | | | | 326 |R | +-------------+ | (GenApp) | 327 |I | | |<-->| | 328 |L | | Distribution| | | 329 |L | +-------------+ +----------+ 330 | | ^ 331 |O | | 332 |A | +-------------+ +----------+ 333 |M | | | | TTM | 334 | | | Monitoring |<-->| | 335 |P | +-------------+ +----------+ 336 |r | ^ ^ 337 |o | | | 338 |t | v V 339 |o | +------------+ +------------+ 340 |c | | | | Data Plane | 341 |o | | Tools |<-->| | 342 |l | +------------+ +------------+ 343 | | 344 +--+ 346 Figure 1 Architecture Overview 348 3.1. Overview of Tools 350 The Tools subcomponent consists of series of utilities to implement 351 various data plane monitoring and failure detections methods. 352 Individual tools are invoked directly by the user or by the 353 monitoring subcomponent. Individual tools allow, where applicable, 354 for callers to specify options such as ECMP coverage, destination 355 RBridge nickname, pay-load etc. Tools interface with the TRILL data 356 plane layer to send and receive OAM frames. At the time of writing 357 following tools are included as part of the tool set. 359 1. Loopback Message (Ping) 361 2. Path Trace Message (Trace route) 363 3. Multicast Tree Verification (mtv) 364 4. MAC discovery 366 5. Address Binding Verification 368 6. IP End-station Locator 370 7. DRB-AF discovery 372 8. Notification messages 374 9. OAM Command messages 376 Tools, based on the intended use, can be classified in to 3 broader 377 categories as below. 379 +--------------------+------------------------------+ 380 | Category | Tools | 381 +--------------------+------------------------------+ 382 | Fault Verification | Loop Back Message | 383 +--------------------+------------------------------+ 384 | Fault Isolation | Path Trace Message, | 385 | | Multicast Tree Verification | 386 +--------------------+------------------------------+ 387 | Auxiliary | MAC discovery | 388 | | Address Binding Verification | 389 | | IP End-station Locator | 390 | | DRB-AF Discovery | 391 | | Error Notification | 392 | | OAM command messages | 393 +--------------------+------------------------------+ 395 3.2. TRILL Data Plane 397 The TRILL data plane receives and transmits frames on behalf of the 398 tools subcomponent. As far as the encapsulation is concerned, TRILL 399 data plane layer treat these frames exactly as it would treat a 400 regular data frame. In fact one of the key design goals is to 401 maintain TRILL data plane diagnostic (OAM) frames as close as 402 possible to actual data frames. Additionally, implementation MUST 403 satisfy the following requirements: 405 1. OAM frames SHOULD NOT leak in to legacy Ethernet or to end 406 stations outside the TRILL cloud 408 2. RBridge MUST have ability to identify OAM (diagnostics) frames 409 intended for a destination RBridge. 411 3. RBridgeS SHOULD have ability to identify TRILL data OAM frames 412 that are not intended for itself and forward such frames 413 without assistance from the CPU. 415 We explain in Section 6 various methods available to identify 416 TRILL OAM (diagnostic) frames intended for the local RBridge and 417 satisfy above requirements. 419 3.3. Monitoring 421 The Monitoring subcomponent utilize the tools subcomponent to 422 monitor the TRILL data plane and proactively detect connectivity 423 faults, configuration errors (cross connect errors) etc. The 424 monitoring subcomponent provides options to specify frequency, 425 retransmission count, ECMP choice and all other applicable options 426 to the specific tool being used to implement the monitoring service. 427 Based on the configuration specified by the user, the monitoring 428 subcomponent periodically invokes the applicable tools. 429 Additionally, based on configuration, monitoring results are 430 propagated to the distribution subcomponent. Monitoring results are 431 always associated with a monitoring region. The monitoring region is 432 an administrative partition of the network such that it: 1. Maximize 433 the fault coverage, 2. Optimize network health data summarization. 434 More details of regions are discussed in Section 10. 436 The Monitoring subcomponent also interfaces with Traffic Triggered 437 Monitoring subcomponent. 439 3.4. Traffic Triggered Monitoring (TTM) 441 Traffic Triggered Monitoring facilitates monitoring and diagnose of 442 live data traffic. TTM subcomponent interfaces with the Data Plane 443 to install required TTM policies. Details of the TTM framework and 444 operations are presented in section 11. 446 3.5. Distribution 448 The distribution subcomponent has two primary inputs 450 o Data from the Monitoring Layer 452 o Data from other RBridges via ISIS GenApp 454 The distribution subcomponent performs the following functions: 456 o Advertising locally generated data 458 o Applying Advertising policies and re-advertising received data 460 o Maintaining the network health Database 462 Details of distribution layer and data handling are presented in 463 section 10. 465 3.6. ISIS 467 TRILL OAM protocol suite proposed in this document utilize ISIS to 468 distribute 470 OAM capability of individual RBridge 472 In-band OAM IP and MAC address 474 Above, OAM capability and In-band OAM address information are 475 advertised using ISIS MT-Protocol extensions.[section 7. ] 477 Network monitoring data are distributed using ISIS GenApp extension 478 methods specified in [GenApp]. Details of encoding and proposed TLV 479 definitions are defined in detail in section 7. 481 3.7. Reporting 483 The Reporting subcomponent allows users to define and use various 484 reports on network health. The Reporting subcomponent utilize data 485 available in the distribution subcomponent to generate requested 486 reports. Sample reports are listed in Appendix A. 488 4. Frame Format 490 TRILL data plane diagnostic (OAM) frames can be broadly classified 491 in to four types: request, response, notification and command 492 messages. Request messages are generated to measure TRILL data plane 493 characteristics, such as connectivity. Response messages are 494 generated by a RBridge in response to a request. Notifications are 495 unsolicited messages generated due to certain failures such as 496 unreachable destination. OAM command messages provide a generic 497 framework of communication between RBridges for OAM purposes. 498 Details of individual messages are covered in later sections. Here 499 we present frame encoding format for Request, Response and 500 Notification messages. 502 4.1. Encoding of Request message 504 +-------------------------------+ 505 | Outer Header | 506 +-------------------------------+ 507 | TRILL Header | 508 +-------------------------------+ --- 509 | L2 Header + EthType | ^ 510 +-------------------------------+ | Diagnostic 511 | IP Header (including TCP/UDP) | | payload 512 +-------------------------------+ | 513 | User defined data or | | 514 . padded to zero . | 515 | | v 516 +-------------------------------+ --- 517 | ICMP Header | 518 +-------------------------------+ 519 | Common ICMP Extension Header | 520 +-------------------------------+ 521 |ICMP extensions (optional) | 522 +-------------------------------+ 524 Figure 2 Encoding TRILL data plane diagnostic request message 526 The above diagram depicts encapsulation of TRILL data plane 527 diagnostic request frames. Encoded in the frame is the diagnostic 528 payload. The diagnostic payload is a flexible structure that allow 529 user to specify different kinds of payloads, including actual 530 payloads. Most hardware implementations use 531 IPDA:IPSA:DestPor:SrcPort based hash method to select ECMP paths for 532 IP frames. For non IP payloads, RBridges normally uses a Layer 2 MAC 533 DA and SA based hash for selecting an ECMP path. Flexible diagnostic 534 payload allow user to drive end to end ECMP selection based on 535 payload without needing additional hardware. Also, in terms of 536 forwarding, this keeps diagnostic frame as close as possible to data 537 frames. The length of the diagnostic payload must be deterministic. 538 We propose a fixed 128 byte size for the diagnostic payload section 539 of the OAM frame. This allows including IPv6 frames with multiple 540 802.1Q tags in to the diagnostic payload. The remaining bytes are 541 set to zero, if the specified frame is smaller than the 128 byte 542 fixed size. 544 ICMP header immediately follows the diagnostic payload. The ICMP 545 header is constructed as defined in [RFC792] and [PINGEXT]. 546 [PINGEXT] provide methods to extend ICMP echo request message to 547 include ICMP multi part extensions. 549 ICMP multi part extensions [RFC 4884] are defined to carry 550 additional information and are encoded after the ICMP 551 header.[section 8. ] 553 4.2. Encoding of Response Message 555 +-------------------------------+ 556 | TRILL Header or MAC Header | 557 +-------------------------------+ 558 | IP Header | ^ 559 +-------------------------------+ | 560 | ICMP Header | 561 +-------------------------------+ Response Message 562 | Common ICMP Extension Header | | 563 +-------------------------------+ | 564 | | | 565 | original frame | | 566 . (TRILL Header + . | 567 . diagnostic payload) . | 568 | | | 569 +-------------------------------+ | 570 |ICMP extensions | | 571 +-------------------------------+ v 573 Figure 3 Encoding of OAM response message 575 The above diagram depicts encoding of OAM response messages. If in- 576 band delivery is requested, the OAM response message MUST be encoded 577 as payload in a TRILL data frame. The ingress RBridge nickname MUST 578 be set to the RBridge nickname of the node generating the response. 579 Egress RBRidge nickname MUST be set to the ingress RBridge nickname 580 of the, original TRILL data frame that triggered this response. 582 Normal IP forwarding rules MUST be followed, if an out-of-band 583 response is requested. 585 4.3. Encoding of Notification Message 587 Notification messages are generated in response to an error 588 condition such as delivery failure due to incompatible MTU or 589 destination RBridge not in the forwarding table etc.. Out-of-band 590 responses are generally indicated by explicitly including the 591 indication to receive an out-of-band response in the TRILL OAM 592 request frame. Since notifications are generated proactively, the 593 originator RBridge may not have methods to identify the IP address 594 required to deliver an out-of-band response. Hence, in this document 595 we propose to deliver Notification messages in-band. Delivery of 596 out-of-band messages are outside the scope of this document. 598 The RBridge generating the Notification message MUST include up to 599 128bytes of the original frame that triggered the notification 600 message. If the original frame contains less than 128 bytes, then 601 the remaining bytes MUST be padded with zeros. 603 +-------------------------------+ 604 | TRILL Header | 605 +-------------------------------+ 606 | IP Header | 607 +-------------------------------+ 608 | ICMP Header | 609 +-------------------------------+ 610 | Pseudo IP header | 611 | | 612 +-------------------------------+ 613 | | 614 | original frame | 615 . (TRILL Header + L2+ Ethtype . 616 . + data) . 617 | | 618 +-------------------------------+ 619 |ICMP extensions | 620 +-------------------------------+ 622 Figure 4 Encoding of Notification message 624 The TRILL outer header of the frame that triggered the notification 625 message is not included in the notification message. The Next-Hop 626 header information in the original frame is of local significance to 627 the specific link and may not be of interest to the originator of 628 the data frame. 630 The Following error messages are currently supported 632 o Time Expiry 633 o Destination Unreachable 634 o Parameter Problem 636 Additional TRILL OAM error codes may be specified as ICMP multipart 637 extensions in above notifications messages. These error codes 638 indicate the cause of the error. Please see section 8. for error 639 code definitions and section 9.10. for theory of operation. 641 4.3.1. Pseudo IP Header 643 RFC 792 requires original payload section of ICMP messages, Time 644 Expiry, Destination Unreachable and Parameter Problem to contain a 645 valid IP header. RFC 1122 recommends ICMP implementations to 646 multiplex incoming error notification messages to the related 647 application based on the IP header information. The Pseudo IP header 648 defined here intends to serve that purpose. 650 In this document we propose, for the purpose of TRILL OAM, to 651 construct the pseudo IP header as a UDP header. IP addresses are 652 derived based on the in-band IP addresses of the RBridges (section 653 5. ). The destination port is the well known UDP destination port in 654 the block of assigned "User Ports" (1024-49151). We intend to 655 request IANA assignment of a UDP destination port for use in TRILL 656 OAM. 658 4.4. OAM Command Messages 660 +-------------------------------+ 661 | TRILL Header or MAC Header | 662 +-------------------------------+ 663 | IP Header | ^ 664 +-------------------------------+ | 665 | ICMP Header | 666 +-------------------------------+ Command Message 667 | Common ICMP Extension Header | | 668 +-------------------------------+ | 669 |ICMP extensions | | 670 +-------------------------------+ v 672 Figure 5 Encoding of OAM Command Message 674 OAM command messages are originated by RBridges to indicate other 675 RBridges in the network to execute commands on behalf of the 676 originating RBridge. OAM command messages are not required to follow 677 a specific ECMP path. Hence, OAM messages do not contain a 678 diagnostic payload section. 680 Destination IP address of the OAM command message is either in-band 681 OAM IP address or out-of-band management IP address of the 682 destination RBridge. Incoming OAM command message are delivered to 683 the ICMP stack by the IP stack. ICMP stack further identify the 684 message as an OAM message due to embedded ICMP extensions. ICMP 685 stack delivers OAM command message to the OAM processing module for 686 further processing. 688 The TTM (Traffic Triggered Monitoring) framework presented in 689 section 11. and the Diagnostic Payload discovery presented in 690 section 9.9. extensively utilizes OAM command messages. 692 5. 127/8 in-band OAM IP address 694 In this document we propose to use same ICMP framework deployed in 695 IP infrastructure for communicating OAM information. RBridges are 696 not required to have IP interfaces enabled. However, in order to 697 receive and process ICMP messages, RBridges are required to have at 698 least a pseudo IP address. In this document, we propose to use 127/8 699 addressing scheme similar to the MPLS data plane failure detection 700 methods [RFC 4379]. It is important that each RBridge have a 701 straightforward method of identifying corresponding in-band OAM IP 702 address of any given RBridge, without additional processing or 703 lookups. 705 The 127/8 Address range is allocated for internal loopback addresses 706 [RFC 1122] and required not to be routed. RFC 4379 updates RFC 1122 707 to utilize 127/8 addressing to communicate between devices in a 708 peer-to-peer model that does not require routing. In this document, 709 we propose to use 127/8 addressing model to identify in-band IP 710 address required for OAM purposes. Additional methods are provided 711 as ISIS LSP extension to announce, other addresses, user may desire 712 to use for OAM in-band purpose. By default all RBridges MUST support 713 the 127/8 addressing model specified here. 715 Each RBridge nickname is 16bits wide [RFC6325]. Let's assume RBridge 716 nickname RB is divided in RB(msb) and RB(lsb), such that, RB(msb) 717 takes the upper 8bits of the RB and RB(lsb) takes the lower 8bits of 718 the RB. Corresponding in-band IP address of RB is 719 127.RB(msb).RB(lsb).100. Implementation MUST facilitate methods to 720 avoid conflicts between in-band OAM address and implementation 721 specific 127/8 address allocations. 723 5.1. IPv6 default in-band address 725 IPv6 based systems have two options to derive the in-band IP 726 address. The systems may choose, IPv6 native loopback address 727 ::RBid:100 or IPv4 mapped IPv6 addressing format of 728 ::FFFF:127.RB(msb).RB(lsb).100. 730 RFC 4379, MPLS Data Plane failure detection methods, utilize IPV4 731 mapped IPv6 addressing. One of the design objectives of the proposal 732 is to re-use as many existing OAM extensions as possible. Hence, 733 implementation that support IPv6 MUST utilize the IPv4 mapped IPv6 734 addressing fomat for default IPv6 in-band address. Deployments that 735 desire to utilize native addressing MAY advertise native IPv6 in- 736 band address using OAM extensions in section 7. 738 6. Identification of Diagnostic frames 740 In this document we have proposed to use the TRILL header as defined 741 in [RFC6325], without modifications. The standard TRILL header 742 currently, does not provide option to identify diagnostic frames. 743 Hence, it is important to have circumstantial methods to identify 744 diagnostic frames intended for the local RBridge and prevent leaking 745 of diagnostic frames outside of TRILL network. In this section we 746 explain, various methods to attain the above goals. 748 6.1. Identification of Layer 2 Flow 750 As stated earlier, most RBridges use Destination and Source MAC 751 address, combination to determine the next hop ECMP interface to 752 forward non IP frames. It is required to provide flexibility for the 753 user to specify destination MAC address and source MAC address. We 754 propose to use special EthType (TBD) to indentify OAM (diagnostic) 755 frames that contain non IP diagnostic payloads. 757 Each RBridge, if TRILL data plane OAM enabled, MUST provide 758 following processing: 760 o Forward frames that have egress RBridge nickname equal to local 761 RBridge nickname and EthType equal to Diagnostic Ethtype, to 762 the Central Processing Unit (CPU). Such frames SHOULD NOT 763 egress out of the RBridge. 764 o The RBridge SHOULD not egress frames with Diagnostic Ethtype to 765 non TRILL interfaces. 767 6.2. Identification of IP Flows 769 As stated earlier, most RBridges use combination of IP address and 770 Layer 4 information such as UDP/TCP Port, to determine the next hop 771 ECMP interface to forward IP frames. Hence, it is important to 772 provide flexibility for users to specify destination IP addressing 773 and payload information. 775 In this section we propose several approaches to identify OAM 776 (diagnostic) frames with IP payloads that are addressed to the local 777 RBridge for processing 779 Method 1: 781 Use of Well known Destination MAC address: 783 We propose to use a well known diagnostic MAC address (TBD-DMAC-1), 784 as the Destination MAC address of the inner Layer 2 header. 786 Each RBridge, if TRILL data plane diagnostic is enabled, MUST 787 provide the following processing: 789 o Forward frames which have egress RBridge nickname equal to the 790 local RBridge nickname and Destination MAC address of the inner 791 Layer 2 header equal to the Well Known Diagnostic MAC address 792 (TBD-DMAC-1) to the Central Processing Unit (CPU). If RBridge 793 nickname is not equal to the local RBridge nickname, frame MUST 794 be forwarded normally. 795 o RBridge SHOULD NOT egress frames with the Diagnostic MAC 796 address (TBD-DMAC-1) as destination address to non TRILL 797 interfaces. 799 Method 2: 801 Use of Well known Source MAC address: 803 We propose to use a well known source MAC address (TBD-SMAC-1), as 804 the source MAC address of the inner Layer 2 header. 806 Each RBridge, if TRILL data plane diagnostic is enabled, MUST 807 provide following processing: 809 o Forward frames that have egress RBridge nickname equal to the 810 local RBridge nickname and source MAC address of the inner 811 Layer 2 header equal to Well Known source MAC address (TBD- 812 SMAC-1), to the Central Processing Unit (CPU). If the egress 813 RBridge nickname is not equal to the local RBridge nickname 814 then the frame MUST be forwarded normally. 815 o Each RBridge SHOULD NOT egress frames with Well known MAC 816 address as source address to non TRILL interfaces. 817 o RBridge SHOULD NOT dynamically learn the well known Source MAC 818 address (TBD-SMAC-1) specified above. 820 Method 3: 822 Use of RBridge specific OAM MAC address: 824 Each RBridge may advertise, MAC address for the purpose of receiving 825 OAM frames with IP payloads. Sending RBridges may use the advertised 826 MAC address as the destination MAC address of the inner Layer 2 827 header of originating diagnostic request frames. 829 Each RBridge, if TRILL OAM is enabled MUST provide following 830 processing: 832 o Forward frames that has egress RBridge equal to the local 833 RBridge nickname AND Destination MAC address of the inner Layer 834 2 header equal to the advertised RBridge specific OAM MAC 835 address, to the Central Processing Unit (CPU). 836 o RBridge SHOULD NOT egress frames with RBridge specific OAM MAC 837 address as destination address to non TRILL interfaces. 839 6.3. Identification of Flows using Hop-Count Restrictions 841 Methods presented in Sections 6.1. and 6.2. utilize one or more 842 fields in the data frame to identify OAM frames against real data 843 frames. As a result, operator does not have complete flexibility of 844 specifying all of the fields in the diagnostic payload. This 845 restriction while acceptable in most cases may not be acceptable in 846 some cases. There may be instances that operator desire to specify 847 the exact frame under investigation. 849 RFC 6325 section 3.6 explains handling of TRILL Hop-Count field. 850 Accordingly, frames received with Hop-Count of zero (0) MUST not be 851 forwarded. 853 OAM frames that wishes to utilize Hop-Count restriction process MUST 854 first discover the Hop-Count from ingress RBridge to the egress 855 RBridge. Hop-Count discovery may be accomplished using Path Trace 856 message specified in section 9.3. 858 Desired OAM frame is then encoded using methods specified in this 859 document. Hop-Count field of the TRILL header is updated with the 860 above discovered Hop-Count value. 862 Additionally, it is recommended, to invalidate the inner diagnostic 863 payload IP checksum, if the specified diagnostic payload is an IP 864 packet. Invalidation of the inner diagnostic payload IP checksum 865 prevent end stations processing of OAM packets, in the unlikely 866 event of such OAM packets leaking out to of the TRILL network. 868 Egress RBridge processing routines MUST have methods to identifying 869 OAM frames with Hop-Count expiry from actual data frames with Hop- 870 Count expiry. OAM frame validation process specified in section 6.6. 871 , MUST be followed. A frame MUST be treated as a data frame with 872 Hop-Count expiry, if the OAM validation process specified in section 873 6.6. failed. 875 6.4. Identification of Multicast Flows 877 Multicast frames are forwarded using one of the available multicast 878 trees in the TRILL network [RFC6325]. Selection of a multicast tree 879 is done at the ingress RBridge. Multicast frames are directed to a 880 selected multicast tree at the ingress. Hence exact payload 881 definition is not required for the purpose of ECMP selection. 882 However, based on multicast pruning, certain multicast addresses may 883 not be required to be forwarded to all members of the tree. 884 Intermediate switches perform, (S,G) or (*,G), forwarding based on 885 IP addresses for IP frames and MAC address for non IP frames. Hence, 886 in order to verify the effect of multicast pruning users may require 887 methods to specify Layer 2 and/or IP addressing information, as 888 applicable. There are two types of multicast tree verification 889 messages: 891 o Overall Tree Verification Messages 892 o Pruned Tree Verification Messages 894 6.4.1. Identification of overall tree verification frames 896 We propose to utilize a well known multicast diagnostic MAC address 897 (TBD-GMAC-1) for this purpose. If TRILL data plane diagnostics are 898 enabled, this specific MAC address MUST be installed on every 899 RBridge for all tress and MUST NOT be subject to pruning. 901 Each RBridge performs (*,G) forwarding of the frames based on the 902 well known multicast diagnostic MAC address (TBD-GMAC-1) in the 903 inner Layer 2 destination address. Additionally, it sends a copy of 904 the frame to the CPU for analysis and generates a response to the 905 requester. Please see section 8.3 for details of multicast tree 906 verification message processing. 908 A RBridge SHOULD NOT egress multicast frames with above diagnostic 909 MAC address in to non TRILL interfaces. Also, RBridge MUST discard 910 any native frame received on non TRILL interfaces with the above 911 diagnostic MAC address as the destination MAC address. 913 6.4.2. Identification of Layer 2 Multicast group verification frames 915 We propose to utilize the diagnostic EthType (TBD) that was defined 916 earlier for identification of Layer 2 group verification frames. 917 User SHOULD have the ability specify destination MAC address, source 918 MAC Address, VLAN and payload data up to 128 octets. 920 Each RBridge, performs standard multicast forwarding. Additionally, 921 if EthType of the frame is equal to the well known diagnostic 922 Ethtype (TBD), the RBridge sends a copy of the frame to the CPU for 923 analysis and generating response to the requester. Please see 924 section 9.3 for details of multicast tree verification message 925 processing. 927 RBridge MUST NOT egress multicast frames with above EthType in to 928 non TRILL interfaces. Also, RBridge MUST discard any native frame 929 received on non TRILL interfaces with the above EthType. 931 6.4.3. Identification of IP Multicast group verification frames 933 We propose to use the well known MAC address (TBD-SMAC-1) defined in 934 section 6.2 as the source MAC address. Users have flexibility to 935 define, IP Address, VLAN and other payload data upto 128 octets. The 936 Destination MAC address is derived based on the IP Multicast 937 destination address. 939 RBridges perform (S,G) or (*,G) forwarding using the IP address 940 information. Additionally, each RBridge send a copy of the frame to 941 the CPU, if the source MAC address matches the well known MAC 942 address defined here in. 944 RBridge MUST NOT egress multicast frames with above source MAC 945 address to non TRILL interfaces. Also, each RBridge MUST discard any 946 native frame received on a non TRILL interfaces with the above 947 source MAC address. 949 RBridge MUST NOT dynamically learn the well known source MAC address 950 specified here. 952 6.5. Default OAM flow Parameters 954 Parameters specified herein SHOULD be utilized as default 955 parameters. Parameters specified under the Fixed category MUST not 956 be changed based on user specification and MUST be followed exactly 957 as specified below. 959 +--------------+--------------------------+-----------------+ 960 | Flow type | Default Values | Fixed fields | 961 +--------------+--------------------------+-----------------+ 962 | Layer 2 | DA= Well Known MAC | EthType=OAM(TBD)| 963 | | SA= RBridge Interface MAC| | 964 | | VLAN=native VLAN | | 965 | | | | 966 +--------------+--------------------------+-----------------+ 967 | IPv4 | IP Address = | EthType=0x8000 | 968 | OR | in-band address | OR | 969 | IPv6 | IP Dest. Port = 3503 | EthType=0x86DD | 970 | | IP Src. Port = TBD | | 971 | | DA = OAM MAC of egress | | 972 | | RBridge | | 973 | | SA =ingress RBr interface| | 974 | | MAC | | 975 | | VLAN=native VLAN | | 976 +--------------+--------------------------+-----------------+ 977 | Multicast | SA= RBridge Interface MAC|DA=Well Known | 978 | Tree | VLAN=native VLAN |Multicast MAC | 979 | Verification | | EthType=OAM(TBD)| 980 +--------------+--------------------------+-----------------+ 981 | Layer 2 | DA= Well Known MAC | EthType=OAM(TBD)| 982 | Multicast | SA= RBridge Interface MAC| | 983 | | VLAN=native VLAN | | 984 +--------------+--------------------------+-----------------+ 985 | IP | IP Dest Address = | EthType=0x8000 | 986 | Multicast | Default OAM MCast address| OR | 987 | | IP Src. Address = | EthType=0x86DD | 988 | | in-band-address | | 989 | | IP Dest. Port = 3503 | | 990 | | IP Src. Port = TBD | | 991 | | DA = OAM MAC of egress | | 992 | | RBridge | | 993 | | SA =ingress RBr interface| | 994 | | MAC | | 995 | | VLAN=native VLAN | | 996 +--------------+--------------------------+-----------------+ 998 Figure 6 Default Parameters of Diagnostic(OAM) Payloads 1000 6.6. Validation of OAM Request and Response frames 1002 OAM processing module MUST further validate the received 1003 request/response messages to ensure their compliance to this 1004 specification using the methods specified herein. 1006 OAM messages are encodeded as specified above and contain an ICMP 1007 Header and an ICMP Common Header as specified in [PINGEXT]. 1009 0 1 2 3 1010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 |Version| Length | Checksum | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Magic-Number (0x54726163) | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 Figure 7 ICMP Common Extension Header 1019 The OAM process MUST offset to the common header and validate the 1020 Version and Magic-number fields. The Version MUST be one (1) and 1021 Magic-number MUST be 0x54726163. If the Version or the Magic-number 1022 does not match, then the frame is not an OAM frame. 1024 If these fields are matching the specified values, then the checksum 1025 is calculated over the Version, Length and Magic number fields. The 1026 calculated checksum is compared against the checksum in the frame. 1027 If the two values do not match then the frame is not an OAM frame. 1029 Frames that pass both the tests above are further qualified as 1030 below. 1032 The Length field in the common ICMP header specifies the starting 1033 location of the ICMP Extension. The first ICMP Extension is the 1034 Version and Flags Extension (C-type 1) (Section 8.1. ). 1036 Version and Flag fields of c-type 1 MUST be validated to identify 1037 whether the OAM frame is of a known version. OAM frames of unknown 1038 versions are discarded. 1040 Frames that pass all of the above tests are valid OAM frames and 1041 further processed according to the OAM code specified in the Version 1042 and Flags Extensions. 1044 7. ISIS Extensions 1046 A new ISIS subTLV definition is required to announce the following 1047 OAM related information: 1049 o OAM capability 1050 o OAM in-band IP address 1051 o OAM in-band MAC address 1053 We propose to define a single sub TLV structure within ROUTER- 1054 CAPABILITY ISIS TLV (242), to announce the above OAM information. 1056 +--------+ 1057 | Type | 1058 +--------+ 1059 | Length | 1060 +--------+--------+ 1061 |ver| Res |v|i|m|o| 1062 +-----------------+ 1063 | Sender nickname | 1064 +-----------------+ 1065 | | 1066 | OAM MAC address | 1067 | | 1068 +-----------------+ 1069 | | 1070 | OAM in-band | 1071 . IP address . 1072 | | 1073 +-----------------+ 1075 Figure 8 ISIS extension for OAM 1077 Type : (1 octet) TBD (one of the sub-TLV definitions under MT-PORT- 1078 CAP ISIS TLV) 1080 Length : ( 1 octet) Length of the subTLV, in octets, excluding Type 1081 and Length fields. Minimum 2. 1083 Ver : (4 bits) indicate the OAM version. Currently set to zero. 1085 Res : (1 octet), Reserved for future use. Set to zero on 1086 transmission and ignored on recipt. 1088 V : (1 bit) if set, indicates IP address included in the TLV is 1089 IPv6. Only one of I or V bit MUST be set. If both are set, it is a 1090 malformed TLV and must be discarded without further processing. 1092 I : (1 bit) if set indicate IP address included in the TLV is 1093 IPv4. Only one of I or V bits MUST be set. If both are set, it is 1094 malformed TLV and must be discarded without any further processing. 1096 M : (1 bit) If set, indicates MAC address is included in the TLV. 1098 O : (1 bit) If set, indicates announcing RBridge is OAM capable. 1100 MAC Address : (6 octets), IEEE MAC address, associated with the in- 1101 band IP address. If included, the MAC address MUST precede the IP 1102 address. 1104 IP Address : (4 or 16 octets), OAM in-band IP address. If present 1105 MUST follow MAC address. 1107 Above PDU encoding MUST follow exact order as specified and fields 1108 are not interchangeable. 1110 NOTE: Both I and V flags MAY be set to zero to indicate that 1111 announcing RBRidge desire to use the default OAM address. The 1112 default OAM address is the 127/8 address derived as specified in 1113 section 5. 1115 8. ICMP multi part extensions 1117 We propose to utilize a new Class-Num [RFC4884] to identify TRILL 1118 OAM related extensions specified in this document and other related 1119 documents. IANA has established a registry for ICMP extensions and 1120 we intend to seek a Class-Num assigned for this purpose. 1122 Within the TRILL OAM Class-Num, C-Types are defined and registered 1123 in the IANA to identify various different extensions specified 1124 herein and other related future documents. 1126 8.1. ICMP Echo Request and Response message extensions 1128 RFC 4884 proposes a framework to extend ICMP message types: Time 1129 Expiry, Parameter Problem and Destination Unreachable. RFC 4884 1130 therefore cannot be applied to extend other ICMP messages, such as 1131 ICMP echo request and response messages. ICMP Echo request and 1132 response is by far the most widely used OAM tool. Extensibility of 1133 ICMP Echo request in a backward compatible manner is very important. 1134 Such a framework provides flexibility to the ICMP message structure 1135 to carry application specific information. 1137 [PINGEXT] presents a framework to extend ICMP messages in a backward 1138 compatible manner and allow encoding specific extensions in RFC 4884 1139 compliant c-types. 1141 In this document, we propose to utilize the framework presented in 1142 [PINGEXT] to extend the ICMP echo request or response structures 1143 encoded within the TRILL OAM messages. 1145 8.2. C-Type Definitions 1147 C-Types defined in this section MUST be embedded in the ICMP 1148 Extension object format proposed in section 8 of RFC 4884. Figure 9 1149 presents the format of the ICMP Extension object defined in RFC 1150 4884. Figure 9 is entirely for reference purposes only and readers 1151 are referred to RFC 4884 for most up to date information. 1153 0 1 2 3 1154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Length | Class-Num | C-Type | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | | 1159 | // (Object payload) // | 1160 | | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 Figure 9 ICMP Extension Object 1165 Section below defines the format of the object payloads, only. ICMP 1166 Object header MUST precedes object payloads defined in section 8.2. 1167 Figure 10 below presents an example of encoding C-Type 1, i.e 1168 Version and Flags object. 1170 0 1 2 3 1171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Length | Class-Num | C-Type | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Version | code | Reserved |F|c|o| 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 Figure 10 Example of Encoding Version and Flags object 1180 Version and Flags: C-Type 1 1182 Contain Version number, code and associated flags. Currently Out-of 1183 band Request, Final and Cross Connect Error flags are defined. 1185 Bits 1186 31 24 16 2 1 0 1187 +------------+---------+-----------+--+--+--+ 1188 | Version | code | Reserved |F |C | o| 1189 +------------+---------+-----------+--+--+--+ 1191 Figure 11 C-Type 1, Version and Flags 1193 Version (8 bits): Currently set to zero 1195 Code (1 octet) : TRILL OAM Message codes. See below for currently 1196 available TRILL OAM Message codes. 1198 Reserved (22 bits): Set to zero on transmission and ignored on 1199 receipt 1201 F (1 bit) : Final flag, when set, indicates this is the last 1202 response. 1204 C (1 bit ): Cross connect error (VLAN mapping error), if set 1205 indicates VLAN cross connect error detected. This field is ignored 1206 in request messages and MUST only be interpreted in response 1207 messages. 1209 O (1 bit) : If set, indicates, OAM out-of-band response requested. 1211 TRILL OAM Message codes: 1213 0 : Loopback Message Request 1214 1 : Loopback Message Response 1215 2 : Path Trace Request 1216 3 : Path Trace Response 1217 4 : Time Expiry Notification (error) 1218 5 : Parameter Problem Notification (error) 1219 6 : Destination Unreachable (error) 1220 7 : Multicast Tree Verification Request 1221 8 : Multicast Tree Verification Response 1222 9 : MAC Address discovery Request 1223 10 : MAC Address discovery Response 1224 11 : DRB discovery request 1225 12 : DRB discovery response 1226 13 : AF discovery request 1227 14 : AF discovery response 1228 15 : AF-VLAN discovery request 1229 16 : AF-VLAN discovery response 1230 17 : TTM Set Message 1231 18 : TTM Get Message 1232 19 : TTM Remove Message 1233 20 : TTM Response Message 1234 21 : TTM Indication Message 1235 22 : Payload Generation request Message 1236 23 : Payload Generation response Message 1237 24 : Loopback Message request with Hop-count 1238 25 : Loopback Message response for message code 24. 1239 26 - 255 : Reserved 1241 Originator IP Address: (C-type 2) 1243 Length of the ICMP extension header indicates whether the address is 1244 IPv4 or IPv6. Please refer to RFC 4884 for ICMP extension encoding 1245 and ICMP header structure. 1247 Bits 1248 31 0 1249 +---------------------------------+ 1250 | | 1251 . IP Address . 1252 | | 1253 +------------+--------------------+ 1255 Figure 12 C-Type 2 Originator IP address 1257 Upstream Identification: (C-type 3) 1259 The Upstream Identification C-type structure encodes upstream path 1260 information such as upstream neighbor nickname, ingress interface 1261 index (ifindex) and name of the ingress port. 1263 Bits 1264 31 0 1265 +------------------+---------------+ 1266 | nickname | Reserved | 1267 +------------------+---------------. 1268 | ifindex | 1269 +------------+---------------------+ 1270 | Slot | Port | 1271 +------------------+---------------| 1272 | Speed | State | 1273 +------------------+---------------+ 1275 Figure 13 C-Type 3 Upstream Identification 1277 Nickname (2 octets): TRILL 16 bit nickname of the upstream RBRdige. 1278 [RFCtrill] 1280 Reserved (2 octetc) : Reserved, set to zero on transmission 1281 and ignored on receipt. 1283 Ifindex (2 octets) : unsigned integer of local significance 1285 Slot (2 octets) : Slot number 1287 Port (2 octets) : Port number 1289 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 1290 speeds less than 100Mbps. 1292 State (2 octets) : Represent the state of the port. 1294 0: Down - no errors 1295 1: Disable 1296 2: Forwarding-no errors 1297 3: Down - errors 1298 4: Forwarding - errors 1299 5: Forwarding - oversubscribed 1300 6: Link Monitoring disable 1301 All other values reserved. 1303 Monitored VLAN(diagnostic VLAN ) : (C-type 4) 1305 Monitored VLAN c-type include in the ICMP extensions allows for 1306 testing the integrity of the inner payload VLAN and the expected 1307 VLAN. The expected VLAN is encoded in the Monitored VLAN c-type. The 1308 destination RBRidge, compare the VLAN of the inner payload with the 1309 VLAN value encoded in the Monitored VLAN c-type. If these two VLAN 1310 values mismatch, RBRidge SHOULD set the cross connect flag in the 1311 response. A RBridge MUST NOT set the cross connect error flag for 1312 other than the above specified VLAN mismatch scenario. 1314 Bits 1315 16 0 1316 +---------------------------------+ 1317 | Reserved | VLAN | 1318 +------------+--------------------+ 1320 Figure 14 C-Type 4 Monitored (Diagnostic) VLAN 1322 Downstream Identification: (C-Type 5) 1324 The Downstream Identification C-type carries multiple sets of data, 1325 each corresponding to individual downstream neighbor among 1326 collection of equal cost paths. 1328 Bits 1329 31 0 1330 +------------------+---------------+ 1331 | ecmp count | Reserved | 1332 +------------------+---------------+ ---- 1333 | Reserved | nickname | ^ 1334 +------------------+---------------+ | 1335 | ifindex | | Next hop 1336 +------------+---------------------+ | neighbor 1337 | Slot | Port | | information 1338 +------------------+---------------| | 1339 | Speed | State | v 1340 +------------------+---------------+ ---- 1341 | | 1342 | Repeat next hop neighbor | 1343 . identification for each . 1344 | neighbor | 1345 | | 1346 +----------------------------------+ 1348 Figure 15 C-Type 5 Downstream Identification 1350 Ecmp count (2 octets): Number of equal cost paths to the given 1351 destination from this RBridge. 1353 Reserved (4 octets): Reserved, set to zero on transmission and 1354 ignored on receipt. 1356 Next-hop neighbor information: 1358 Nickname (16 bits): TRILL 16 bit nickname [RFCtrill] 1360 Ifindex (2 octets) : unsigned integer of local significance 1362 Slot (2 octets) : Slot number 1364 Port (2 octets) : Port number 1366 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 1367 speeds less than 100Mbps. 1369 State (2 octets) : Represent the state of the port. 1371 0: Down - no errors 1372 1: Disable 1373 2: Forwarding-no errors 1374 3: Down - errors 1375 4: Forwarding - errors 1376 5: Forwarding - oversubscribed 1377 6: Link monitoring disable 1378 All other values reserved. 1380 NOTE: Repeat Next-hope neighbor identification entry per each ECMP. 1381 Total number of neighbor entries MUST equal to ecmp count. 1382 Individual neighbor entry MAY have variable length. 1384 Path for this payload: (c-Type 6) 1386 Path for this payload indicates the next hop neighbor that this 1387 frame could have been forwarded on based on the payload hashing. 1389 Bits 1390 31 0 1391 +------------------+---------------+ 1392 | nickname | Reserved | 1393 +------------------+---------------. 1394 | ifindex | 1395 +------------+---------------------+ 1396 | Slot | Port | 1397 +------------------+---------------| 1398 | Speed | State | 1399 +------------------+---------------+ 1401 Figure 16 C-Type 6 Path for this payload 1403 Nickname (16 bits): TRILL 16 bit nickname [RFCtrill] 1405 Ifindex (2 octets) : unsigned integer of local significance. 0xFFFF 1406 indicate CPU. 1408 Slot (2 octets) : Slot number 1410 Port (2 octets) : Port number 1412 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 1413 speeds less than 100Mbps. 1415 State (2 octets) : Represent the state of the port. 1417 0: Down - no errors 1418 1: Disable 1419 2: Forwarding-no errors 1420 3: Down - errors 1421 4: Forwarding - errors 1422 5: Forwarding - oversubscribed 1423 6: Link monitoring disable 1424 All other values reserved. 1426 DRB Information (c-Type 7) 1428 31 16 8 0 1429 +---------------+--------+--+-+ 1430 | nickname | state | R|P| 1431 +---------------+--------+--+-+ 1433 Figure 17 Nickname of the DRB 1435 Nickname (2 octets) : TRILL nickname of the DRB 1437 State (1 octets) : DRB state 1439 R ( 7 bits ) : set to zero on Transmission and ignored on 1440 receipt 1442 P (1 bits ) : Set when pseudo node bypass is indicated by 1443 the DRB for the link 1445 AF Information (C-Type 7) 1447 Follow the same encoding as C-Type 6, above. 1449 Nickname and state are of the AF. 1451 Enable VLAN List (c-Type 8) 1453 31 27 16 12 0 1454 +--+-----------+--+----------+ 1455 |R | St-VLAN |R | End-VLAN | 1456 +--+-----------+--+----------+ 1458 Figure 18 Enabled VLAN List 1460 R (4 bits) : Reserved, set to zero on transmission and ignored on 1461 receipt. 1463 St-VLAN (12 bits) : Start VLAN 1465 End-VLAN (12 bits) : End VLAN 1467 Start VLAN and End VLAN represent the range of enabled VLANS. If the 1468 VLAN range is non contiguous, then multiple Enabled VLAN lists MUST 1469 be included, each representing a contiguous VLAN set. 1471 Announcing VLAN set (c-Type 9) 1473 Announcing VLAN list uses the same format as the Enable VLAN List 1474 (c-Type 8) 1475 31 27 16 12 0 1476 +--+-----------+--+----------+ 1477 |R | St-VLAN |R | End-VLAN | 1478 +--+-----------+--+----------+ 1480 Figure 19 Announcing VLAN List 1482 R (4 bits) : Reserved, set to zero on transmission and ignored on 1483 receipt. 1485 St-VLAN (12 bits) : Start VLAN 1487 End-VLAN (12 bits) : End VLAN 1489 Start VLAN and End VLAN represent the range of announcing VLANS. If 1490 the VLAN range is non contiguous, then multiple of announcing VLAN 1491 list MUST be included, each representing a contiguous VLAN set. 1493 AF List (c-Type 10) 1495 This c-Type lists the VLANs for which responding RBridge is a the 1496 appointed forwarder. 1498 31 27 16 12 0 1499 +--------------+-------------+ 1500 | Reserved | nickname | 1501 +--+-----------+--+----------+ 1502 |R | St-VLAN |R | End-VLAN | 1503 +--+-----------+--+----------+ 1505 Figure 20 AF List 1507 Reserved (2 octets) : set to zero on transmission and ignored on 1508 receipt. 1510 Nickname (2 octets) : TRILL 16 bit nickname of the RBridge 1512 R (4 bits) : Reserved, set to zero on transmission and ignored on 1513 receipt. 1515 St-VLAN (12 bits) : Start VLAN 1517 End-VLAN (12 bits) : End VLAN 1518 AF List MUST be repeated for each of the contiguous VLAN ranges that 1519 the responding RBridge function as Appointed Forwarder. 1521 DRB Life Time (c-Type 11) 1523 DRB Life time indicates the Life time, of the DRB operational role, 1524 of the RBridge. 1526 31 0 1527 +--------------------------------------+ 1528 | |0 1529 + Life Time + 1530 | |1 1531 +--------------------------------------+ 1533 Figure 21 DRB Life Time 1535 Life Time ( 8 octets): Indicates the Life time of the operational 1536 role in seconds. 1538 AF Lifetime (C-Type 12) 1540 AF Life time indicates the Life time, of the AF operational role, of 1541 the RBridge for the specified VLAN. 1543 Encoding follow the same format specified in C-Type 11. 1545 Designated VLAN changes (C-Type 13) 1547 Indicates number of times a given RBridge has observed Designated 1548 VLAN changes. Each change may potentially lead to traffic 1549 disruptions. 1551 15 0 1552 +-------------+ 1553 | Change count| 1554 +-------------+ 1556 Figure 22 Number of times Designated VLAN changes 1558 Change count (2 octets): Indicates number of times a given RBridge 1559 has observed Designated VLAN changes 1561 RBridge scope List (c-Type 14) 1562 15 0 1563 +-----------+ 1564 | R | Nu | 1565 +-----------+ 1566 | nickname 1| 1567 +-----------+ 1568 . . 1569 . . 1570 | nickname n| 1571 +-----------+ 1573 Figure 23 Scope List c-Type 14 1575 R (1 octet ) : Reserved, zero on transmission and ignored on recipt. 1577 Nu (1 octet) : number of nicknames listed 1579 Nickname 1 .. n (2 octets) each: List TRILL RBridge nickname of in 1580 scope RBridges. 1582 Nicknames MUST be numerically sorted. With nickname1 the lowest to 1583 nickname n the highest. This facilitate easy processing the 1584 receiving RBridge. 1586 Nu = 0 indicate no embedded nicknames in the message and response 1587 required from all RBridges, where applicable. 1589 Multicast Tree downstream List (c-Type 15) 1590 Multicast Tree downstream list provides information on downstream 1591 leaf Rbridges on the specified tree. 1593 Bits 1594 31 0 1595 +------------------+---------------+ 1596 | leaf count | Reserved | 1597 +------------------+---------------+ ---- 1598 | Reserved | nickname | ^ 1599 +------------------+---------------+ | 1600 | ifindex | | Downstream 1601 +------------+---------------------+ | leaf 1602 | Slot | Port | | information 1603 +------------------+---------------| | 1604 | Speed | State | v 1605 +------------------+---------------+ ---- 1606 | | 1607 | Repeat downstream | 1608 . leaf information for each . 1609 | downstream RBridge | 1610 | | 1611 +----------------------------------+ 1613 Figure 24 C-Type 15 Multicast Tree Downstream List 1615 Leaf count (16 bits): Number of RBridges downstream to this RBridge. 1617 Downstream leaf information: 1619 Nickname (16 bits): TRILL 16 bit nickname [RFCtrill] 1621 Ifindex (32 bits) : Unsigned 32 bit integer that has only a local 1622 significance to the sending RBridge. Value 0xFFFF indicates CPU 1623 interface. 1625 Slot (2 octets) : Slot number 1627 Port (2 octets) : Port number 1629 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 1630 speeds less than 100Mbps. 1632 State (2 octets) : Represent the state of the port. 1634 0: Down - no errors 1635 1: Disable 1636 2: Forwarding-no errors 1637 3: Down - errors 1638 4: Forwarding - errors 1639 5: Forwarding - oversubscribed 1640 All other values reserved. 1642 NOTE: Repeat downstream RBridges reachability information per each 1643 leaf node. Total number of neighbor entries MUST equal to leaf 1644 count. Individual neighbor entry MAY have variable length. 1646 MAC-discovery Address List (c-Type 16) 1648 15 0 1649 +------------+ 1650 | count | 1651 +------------+ 1652 | MAC | 1653 + Address 1 + 1654 | | 1655 + + 1656 | | 1657 +------------+ 1658 | | 1659 . . 1660 . . 1661 .MAC . 1662 |Address n | 1663 +------------+ 1665 Figure 25 MAC-discovery Address List 1667 Count (2 octets) : Number of MAC addresses embedded in the response 1669 MAC Address ( 6 octets) : 6 octet MAC address 1671 MAC-discovery response Address List (c-Type 17) 1672 15 0 1673 +--------------+ 1674 | count | 1675 +--------------+ 1676 | T | VLAN | 1677 +---+----------+ 1678 | L | Reserved | 1679 +---+----------+ 1680 | | 1681 + Service Tag + 1682 | | 1683 +--------------+ 1684 | | 1685 + MAC + 1686 | Address | 1687 + + 1688 | | 1689 +--------------+ 1690 | Age | 1691 + + 1692 | | 1693 + + 1694 | | 1695 + + 1696 | | 1697 +--------------+ 1698 | Ifindex | 1699 + + 1700 | | 1701 +--------------+ 1702 | vNTAG | 1703 +--------------+ 1704 | Slot | 1705 +--------------+ 1706 | Port | 1707 +--------------+ 1708 | State | 1709 +--------------+ 1710 | Speed | 1711 +--------------+ 1713 Figure 26 MAC-discovery response 1715 Count (2 octets) : Number of MAC addresses embedded in the response 1717 T (4 bits ) : Type of MAC address 0 - Dynamic, 1 Static, 2-15 1718 Reserved 1719 VLAN (12 bits) : VLAN identifier associated with the MAC address 1721 L (8 bits) : Length of Service Tag in bits. 1723 Service Tag (4 octes): Service Tag is right aligned. For 24 bit 1724 Length, left most 8 bits of Service Tag MUST be set to zero. 1726 MAC Address ( 6 octets) : 6 octet MAC address 1728 Age (8 octets ): Age of the MAC address in seconds. For a static MAC 1729 address, this field is ignored. 1731 Ifindex ( 4 octets) : Interface index on which MAC address is learnt 1733 Slot (2 octets) : Slot number of the interface on which this MAC 1734 address is learnt 1736 Port (2 octets): Port number of the interface on which this MAC 1737 address is learnt. 1739 vNTAG (2 octets): virtual TAG identifier associated with the MAC 1740 address. Value 0 indicate no vNTAG association with the MAC address. 1742 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 1743 speeds less than 100Mbps. 1745 State (2 octets) : Represent the state of the port. 1747 0: Down - no errors 1748 1: Disable 1749 2: Forwarding-no errors 1750 3: Down - errors 1751 4: Forwarding - errors 1752 5: Forwarding - oversubscribed 1753 6: Un-monitored 1754 All other values reserved. 1756 Error code (c-Type 18) 1758 Error code c-Type allows an RBridge to specify various error codes 1759 within high-level notification messages such as Time Expiry, 1760 Parameter Problem and Destination unreachable. The sub-error codes 1761 within each of the error code allow specifying further details of 1762 the error. 1764 Bits 1765 31 0 1766 +------------------+--------------+ 1767 | Error Code | sub-code | 1768 +------------------+--------------+ 1770 Figure 27 C-Type 18 Error code 1772 Error Code (2 octets) : Identify the error. Currently following 1773 errors are defined 1775 0 - VLAN non existent 1776 1 - VLAN in suspended state 1777 2 - Cross connect error 1778 3 - Unknwon RBridge nickname 1779 4 - Not AF 1780 5 - MTU mismatch 1781 6 - Interface not in forwarding state 1782 7 - Service Tag non existent 1783 8 - Service Tag in suspended state 1784 9 - 0xFFFF - Reserved for future use and MUST not be used in 1785 transmission. 1787 Sub-code (2 octets) : identify the sub-error code. 1788 0 - 0xFFFF - Reserved for future use and MUST not be used in 1789 transmission. 1791 Warning code (c-Type 19) 1793 Warning code c-Type allow a RBridge to specify various error codes 1794 within high-level notification messages such as Time Expiry, 1795 Parameter Problem and Destination unreachable. The sub-warning codes 1796 within each of the warning codes allow to specify further details of 1797 the warning. 1799 Bits 1800 31 0 1801 +------------------+--------------+ 1802 | Warning Code | sub-code | 1803 +------------------+--------------+ 1805 Figure 28 C-Type 19 Warning code 1807 Warning Code (2 octets) : Identify the Warning. Currently following 1808 Warnings are defined 1809 0 - Inavlid RBridge nickname (RBridge nickname in the range 0xffco 1810 to 0xffff) 1811 1 - Invalid VLAN (Reserved VLAN) 1812 2 - AF VLAN list Mismatch 1813 3 - 0xFFFF - Reserved for future use and MUST not be used in 1814 transmission. 1816 Sub-code (2 octets) : identify the sub-error code. 1818 0 - 0xFFFF - Reserved for future use and MUST not be used in 1819 transmission. 1821 Information code (c-Type 20) 1823 Information code c-Type allow a RBridge to specify various 1824 information codes within the high-level notification messages such 1825 as Time Expiry, Parameter Problem and Destination unreachable. The 1826 sub-info codes within each of the code allow specifying further 1827 details of the information. 1829 Bits 1830 31 0 1831 +------------------+--------------+ 1832 | Information Code | sub-code | 1833 +------------------+--------------+ 1835 Figure 29 C-Type 20 Information code 1837 Information Code (2 octets) : Identify the Information. Currently 1838 following Information are defined 1840 0 - 0xFFFF - Reserved for future use and MUST not be used in 1841 transmission. 1843 Sub-code (2 octets) : identify the sub-error code. 1845 0 - 0xFFFF - Reserved for future use and MUST not be used in 1846 transmission. 1848 Diagnostic-Payload (c-Type 21) 1850 The Disagnostic-Payload c-Type encodes Trill-header and diagnostic 1851 payload for response messages or original frame for notification 1852 messages. The length of the embedded diagnostic-payload is indicated 1853 by the Length in the C-type header ([RFC4884]). 1855 Bits 1856 31 0 1857 +------------------+--------------+ 1858 | | 1859 . Diagnostic-Payload . 1860 | | 1861 +------------------+--------------+ 1863 Figure 30 C-Type 21 Information code 1865 Diagnostic-Payload : 0 or more 32bit words. 1867 This c-type MUST only be included in Response or notification 1868 messages only. It MUST only occur exactly once within the message. 1870 Data (c-Type 22) 1872 The Data c-Type facilitates encoding of any arbitrary set of data in 1873 to the OAM messages. Such Opaque data may be utilized to generate 1874 TRILL OAM frames with different lengths. It may also be utilized for 1875 other purposes, such usage methods are outside the scope of this 1876 document. 1878 Bits 1879 31 0 1880 +------------------+--------------+ 1881 | | 1882 . Data-Payload . 1883 | | 1884 +------------------+--------------+ 1886 Figure 31 C-Type 21 Information code 1888 Data-Payload : 0 or more 32bit words. 1890 This c-type may occur zero or more times within a given OAM message 1892 Service Tag (c-Type 23) 1894 Overlay Technologies such as[FNGRAIN], utilize Identification Tags 1895 that are wider than the 12bit VLAN Tag used in IEEE 802.1Q. 1896 Objective of these tags, regardless of the width, is to identify 1897 virtual service instance within the overlay network. Hence, in this 1898 document the tag is referred to as Service Tag. 1900 0 1 2 3 1901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Service Tag | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 Figure 32 C-Type 23 Service Tag 1908 Service Tag: 4-octets wide opaque value. 1910 Applications that requires 24bit service Tags MUST set upper 8bits 1911 to zero in transmission and discards requests received with non zero 1912 value in upper 8bits. 1914 Control Plane Forwarding Verification Request(c-Type 24) 1916 Downstream Identification (c-Type 5) presented earlier facilitate 1917 users to discover forwarding paths available on the dataplane to 1918 reach the specified destination. It is often desirable to discover 1919 control and data plane inconsistencies. Control Plane Forwarding 1920 Verification c-Type facilitate the users to optionally obtain 1921 Forwarding information available on the control plane. 1923 0 1 2 3 1924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Ecmp Identifier | egress nickname | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 Figure 33 C-Type 24 control Plane Forwarding Verification Request 1931 Ecmp Count : (2 octets) : Ecmp Identifier indicates the ECMP to 1932 verified. Value 0xFF indicate all of the ECMP needed to be verified. 1934 Egress nickname : (2 octets), nickname of the destination RBridge. 1936 Control Plane Forwarding Verification Response(c-Type 25) 1938 Control Plane Forwarding Verification Response is generated in 1939 response to c-Type 24 above. 1941 0 1 2 3 1942 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | ECMP count | Reserved | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 | ECMP Identifier | nickname | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | ifindex | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | Slot | Port | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | Speed | State | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | | 1955 . Repeat next hop neighbor information for each neighbor . 1956 | ECMP Identifier to State represent next hop information | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 Figure 34 C-Type 25 control Plane Forwarding Verification Response 1961 Ecmp count (2 octets): Number of equal cost paths to the given 1962 destination from this RBridge. 1964 Reserved (2 octets): Reserved, set to zero on transmission and 1965 ignored on receipt. 1967 Next-hop neighbor information: 1969 ECMP Identifier: ECMP Identifier for this record. 1971 Nickname (2 octets): TRILL 2 octet nickname [RFCtrill]. Value 0xFFFF 1972 indicates requested ECMP Identifier is invalid. 1974 Ifindex (2 octets) : unsigned integer of local significance 1976 Slot (2 octets) : Slot number 1978 Port (2 octets) : Port number 1980 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 1981 speeds less than 100Mbps. 1983 State (2 octets) : Represent the state of the port. 1985 0: Down - no errors 1986 1: Disable 1987 2: Forwarding-no errors 1988 3: Down - errors 1989 4: Forwarding - errors 1990 5: Forwarding - oversubscribed 1991 6: Link monitoring disable 1992 All other values reserved. 1994 NOTE: Repeat Next-hope neighbor identification entry per each ECMP. 1995 Total number of neighbor entries MUST equal to ecmp count. 1996 Individual neighbor entry MAY have variable length. 1998 Reverse Path Forwarding Verification Request(c-Type 26) 2000 Downstream Identification (c-Type 5) presented earlier facilitate 2001 users to discover forwarding paths available on the data plane to 2002 reach the specified destination. It is often desirable to discover 2003 the reachability and ECMP information along the reverse path. C-Type 2004 presented here allows users to discover Reverse Path to a specified 2005 RBRidge from the receiver. This is an optional parameter and can be 2006 included in Loopback messages, Path Trace messages and OAM Command 2007 messages. 2009 0 1 2 3 2010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Ecmp Identifier | nickname | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 Figure 35 C-Type 26 Reverse Path Forwarding Verification Request 2017 Ecmp Count : (2 octets) : Ecmp Identifier indicates the interested 2018 Reverse Path ECMP. Value 0xFF indicate all of the ECMP. 2020 nickname : (2 octets), nickname of the destination RBridge. 2022 Reverse Path Forwarding Verification Response(c-Type 27) 2024 Reverse Path Forwarding Verification Response is generated in 2025 response to c-Type 26 above. 2027 0 1 2 3 2028 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Ecmp count | Reserved | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | ECMP Identifier | nickname | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | ifindex | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Slot | Port | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Speed | State | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | | 2041 . Repeat next hop neighbor information for each neighbor . 2042 | ECMP Identifier to State represent next hop information | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 Figure 36 C-Type 27 Reverse Path Forwarding Verification Response 2047 Ecmp count (2 octets): Number of equal cost paths to the given 2048 destination from this RBridge. 2050 Reserved (2 octets): Reserved, set to zero on transmission and 2051 ignored on receipt. 2053 Next-hop neighbor information: 2055 ECMP Identifier: ECMP Identifier for this record. 2057 Nickname (2 octets): TRILL 2 octet nickname [RFCtrill]. Value 0xFFFF 2058 indicates requested ECMP Identifier is invalid. 2060 Ifindex (2 octets) : unsigned integer of local significance 2062 Slot (2 octets) : Slot number 2064 Port (2 octets) : Port number 2066 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 2067 speeds less than 100Mbps. 2069 State (2 octets) : Represent the state of the port. 2071 0: Down - no errors 2072 1: Disable 2073 2: Forwarding-no errors 2074 3: Down - errors 2075 4: Forwarding - errors 2076 5: Forwarding - oversubscribed 2077 6: Link monitoring disable 2078 All other values reserved. 2080 NOTE: Repeat Next-hope neighbor identification entry per each ECMP. 2081 Total number of neighbor entries MUST equal to ecmp count. 2082 Individual neighbor entry MAY have variable length. 2084 Traffic Triggered Monitoring (TTM) Profile (c-Type 28) 2086 Details of Traffic Triggered Monitoring are presented in section 11. 2087 TTM profile defines the container c-Type for the TTM profile. With 2088 the TTM profile c-type, other related c-types are included. Included 2089 c-types are linked through next c-type field. Value zero in next c- 2090 type field indicate end of included c-types. 2092 0 1 2 3 2093 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Priority | Identifier | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | C | F | Frequency | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Count | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Reserved | Next c-type | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 Figure 37 C-Type 28 TTM Profile 2106 C Indicate the Class 2108 TTM Profile action (c-Type 29) 2110 0 1 2 3 2111 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Action | Reserved | Next c-type | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 Figure 38 C-Type 29 TTM action 2118 Action (2 octets): 2120 0: count RX packets 2122 1: Count TX packets 2123 2: Count RX bytes 2124 3: Count TX bytes 2125 4: Log 2126 5: Capture 2127 6: - 0xFF reserved 2129 NOTE: Given TTM Profile may contain multiple actions. E.g. count TX, 2130 count RX and Log. 2132 TTM Test Point (TP) (c-type 30) 2134 0 1 2 3 2135 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Slot | Port | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Reserved | Next c-type | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 Figure 39 C-Type 30 TTM Test Point 2144 NOTE: Given TTM Profile may contain multiple Test Points. 2146 TTM Ingress End Point (c-type 31) 2148 0 1 2 3 2149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | T | Reserved | next c-type | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | | 2154 . End Point Address . 2155 | | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 Figure 40 C-Type 31 TTM Ingress End Point 2160 T 3 bits: 2162 1: TRILL RBridge nickname (Length of End Point is 2 octets) 2163 2: IPv4 End Point (Length of the End Point is 4 octets) 2164 3: IPv6 End Point (Length of the End Point is 16 octets) 2165 4: 7 Reserved. 2167 End Point Address: Address of the End Point as defined by the T 2168 value. 2170 Next c-type is the c-type of the next information. Value zero 2171 indicates this as the last c-type. 2173 TTM Egress End Point (c-type 32) 2175 0 1 2 3 2176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | T | Reserved | next c-type | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | | 2181 . End Point Address . 2182 | | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 Figure 41 C-Type 32 TTM Egress End Point 2187 T 3 bits: 2189 5: TRILL RBridge nickname (Length of End Point is 2 octets) 2190 6: IPv4 End Point (Length of the End Point is 4 octets) 2191 7: IPv6 End Point (Length of the End Point is 16 octets) 2192 8: 7 Reserved. 2194 End Point Address: Address of the End Point as defined by the T 2195 value. 2197 Next c-type is the c-type of the next information. Value zero 2198 indicates this as the last c-type. 2200 TTM Pattern (c-type 33) 2201 0 1 2 3 2202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | T | Reserved | next c-type | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | | 2207 . TTM Pattern . 2208 | | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | | 2211 . TTM Pattern mask . 2212 | | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 Figure 42 C-Type 33 TTM Pattern 2217 T 4 bits: 2219 0: TRILL ingress RBridge nickname (Length of the pattern is 2 2220 octets) 2221 1: TRILL egress RBridge nickname (Length of the pattern is 2 2222 octets) 2223 2: IPv4 Source End Point (Length of the pattern is 4 octets) 2224 3: IPv4 Destination End Point (Length of the pattern is 4 octets) 2225 4: IPv6 Source End Point (Length of the pattern is 16 octets) 2226 5: IPv6 Destination End Point (Length of the pattern is 16 octets) 2227 6: Source MAC address (Length of the pattern is 6 octets) 2228 7: Destination MAC address (Length of the pattern is 6 octets) 2229 8: EthType (Length of the pattern is 2 octets) 2230 9: VLAN (Length of the pattern is 2 octets) Right justified, upper 2231 4 bits are do not care. 2232 10: Service Tag 24 bits. Right aligned with upper octet do not 2233 care. 2234 11: Service Tag 32 bits 2235 All other values Reserved. 2237 TTM Pattern Mask defines the mask of the specified pattern. Length 2238 of the pattern mask is identical to the length of the addres. 2240 Next c-type is the c-type of the next information. Value zero 2241 indicates this as the last c-type. 2243 TTM Opaque Pattern (c-Type 34) 2244 0 1 2 3 2245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | Length | Offset | next c-type | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | | 2250 . TTM Pattern . 2251 | | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | | 2254 . TTM Pattern mask . 2255 | | 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 Figure 43 C-Type 34 TTM Opaque pattern 2260 Length: (1 octets) define the length of the TTM pattern in octets. 2262 Offset: (1 octets) defines the offset from the pre-amble of the 2263 frame the specified pattern MUST be applied. 2265 TTM Pattern is the pattern to be matched. Length of the pattern is 2266 specified by the Length field. 2268 TTM Pattern mask is the mask for the specified pattern. Length of 2269 the pattern is specified by the Length field. 2271 NOTE: Only one TTM Opaque pattern MUST be included in a given TTM 2272 profile. TTM profiles with more than one Opaque Pattern MUST be 2273 rejected. 2275 End Point (c-type 35) 2277 End Point c-type (35) indicate the address on the device that is 2278 generating the message. For TRILL this represent the 16 bit nickname 2279 of the RBridge. 2281 0 1 2 3 2282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 | T | Reserved | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | | 2287 . End Point Address . 2288 | | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 Figure 44 C-Type 35 End Point 2293 T 3 bits: 2295 9: TRILL RBridge nickname (Length of End Point is 2 octets) 2296 10: IPv4 End Point (Length of the End Point is 4 octets) 2297 11: IPv6 End Point (Length of the End Point is 16 octets) 2298 12: 7 Reserved. 2300 End Point Address: Address of the End Point as defined by the T 2301 value. 2303 TTM Test Payload (c-type 36) 2305 TTM Profile allow users to inject test frames from an intermediate 2306 device. C-type 35 End Point allows specifying egress end point of 2307 the tunnel or RBridge. C-type 36 presented here provide methods of 2308 specifying the required frame. 2310 0 1 2 3 2311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Length of frame | next c-type | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | | 2316 . Test Frame . 2317 | | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 Figure 45 C-Type 36 TTM Test Payload 2322 Length (2 octets) specify the length of the Test Frame 2324 Next c-type is the next c-type within the TTM profile. 2326 Test frame is the payload of the frame, excluding pre-amble and FCS. 2328 Seed Destination MAC address (c-type 37) 2330 Seed Destination MAC address is used when discovering diagnostic 2331 payloads combinations that span certain ECMP path combination. A 2332 given payload discovery request may contain multiple Seed MAC 2333 addresses. The identification field within the seed MAC address 2334 uniquely identifies a specific seed. MAC address field within the 2335 seed is divided in to 6 fields. Each of these fields is named MA-1 2336 to MA-6 and one octet wide. MA-x can take any legal value specified 2337 by IEEE MAC address specification. Non zero value in MA-x indicates 2338 that specific octets cannot be changed by the downstream RBridge 2339 when generating the diagnostic payload. MA-x fields with zero 2340 indicates either it is a fixed field or field that is available for 2341 downstream Rbridges to derive appropriate payload value. Each of the 2342 Max with zero value has corresponding C-type 39, MAC-Octet bit 2343 vector. Each bit in the MAC-Octets Mask indicates a valid value for 2344 that MA-x field. MAC-Octet Mask of zero length indicates the 2345 corresponding MA-x field has fixed value zero. 2347 0 1 2 3 2348 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Identifier |Reserve| MAC-0 | MAC-1 | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | MAC-2 | MAC-3 | MAC-4 | MAC-5 | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 Figure 46 C-Type 37 Seed Destination MAC address 2357 Identifier (12 bits) Uniquely identify a MAC address seed within a 2358 diagnostic payload discovery message 2360 MAC-0 to MAC-5 Represent an octet in the IEEE MAC address and may 2361 take any legal value specified in IEEE 802.1. Any MAC-x field of 2362 value zero MUST have a corresponding C-type 39, MAC-Octet bit 2363 vector. 2365 Seed Source MAC address (c-type 38) 2367 Seed Source MAC address, c-type 38, has same format as c-type 37. 2369 MAC-Octet bit vector (c-type 39) 2370 0 1 2 3 2371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | Identifier |MAC-x | bit-offset | Length | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | | 2376 . bit-vector . 2377 | | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 Figure 47 C-Type 39 MAC-Octet bit vector 2382 Identifier (12 bits), uniquely identifies a MAC address seed within 2383 a diagnostic payload discovery message. 2385 MAC-x : Value 0-5 indicates the MAC address octet represented by 2386 this bit-vector. 2388 Bit-offset (octet) indicates the starting value of the bit-0 of bit 2389 vector. E.g. when bit-offset is 40, starting value of bit-0 is 40, 2390 bit-1 is 41 and so on. 2392 Length (octet) indicates the length of the bit vector in bits. 2394 A value 1 in a bit vector position indicates the value represented 2395 by that bit is an applicable value to be considered for the MAC-x 2396 field. 2398 Payload generation request (c-Type 40) 2400 0 1 2 3 2401 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | ECMP start | ECMP end | egress nickname | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 Figure 48 C-Type 40 Payload generation request 2408 ECMP start, ECMP end : (1 octet each) : ECMP start and ECMP end 2409 indicate the ECMP to verified. Value 0xFF in ECMP start and ECMP end 2410 indicate all of the available ECMP needed to be verified. 2412 Egress nickname : (2 octets), nickname of the destination RBridge. 2414 Payload generation response (c-Type 41) 2415 0 1 2 3 2416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 |ECMP identifier|Res | S | egress nickname | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 Figure 49 C-Type 41 Payload generation response 2423 ECMP Identifier: (1 octet) : 2425 Egress nickname : (2 octets), nickname of the destination RBridge. 2427 Res : (6 bits), set to zero on transmission and ignored on recipt. 2429 S : (3 bits) indicates the status. 2431 0. Success 2432 1. ECMP does not exist 2433 2. Unable to generate payload using the proposed seed 2434 3. System overloaded try later 2435 4. - 7 Reserved MUST not be used. 2437 TTM command Response sub-codes (c-Type 42) 2439 0 1 2 3 2440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 |Sub-code | Reserved |status | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 Figure 50 C-Type 42 TTM command Response sub-code 2447 Sub-codes (1 octet): 2449 0 : Set response 2450 1 : Get Response 2451 2 : Remove Response 2452 3- 255 : are reserved and must not be used. 2454 Reserved (1 octet): set to zero on transmission and ignored on 2455 recipt. 2457 Status (1 octet): 2459 0 : Success 2460 1 : TTM profile does not exist 2461 2 : Remove failed 2462 3 : Get failed 2463 4 : Set failed - resource exceeded 2464 5 : Set failed - other reasons 2466 6-255 : Reserved and MUST not be used 2468 EthType (c-Type 43) 2470 0 1 2 3 2471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | Reserved | Eth Type | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 Figure 51 C-Type 43 Eth Type 2478 Eth Type (2 octets): Represent IEEE Ether Type 2480 Reserved (2 octets): Set to zero on transmission and ignored on 2481 receipt. 2483 9. Details of Diagnostic tools 2485 In this section we present details of various diagnostic tools that 2486 are identified as part of the solution. We assume, readers are 2487 familiar with frame encoding methods, diagnostic frame 2488 identification methods, and ISIS and ICMP extensions presented 2489 earlier in the document. In this section we will only make reference 2490 to the extensions and methods, please refer to prior section for 2491 details. 2493 9.1. Loopback Message 2495 Loopback message is utilized for fault verification. It verifies 2496 connectivity between two RBridges, for a specified flow. Monitoring 2497 subsystem may use Loopback Message for connectivity monitoring and 2498 proactive fault detection. Users may specify exact flow, part of it 2499 or not at all. Additionally, users may also specify, ECMP choice at 2500 the ingress. ECMP choice can be a specific index, set of index, all 2501 of the index or non. If no ECMP index specified, payload is used to 2502 determine the ECMP choice. Method of deriving the ECMP choice using 2503 payload is implementation dependent and is outside the scope of this 2504 document. However, CPU generating the Loopback message SHOULD use 2505 the same ECMP selection algorithm as the data plane. Additionally 2506 some implementation may allow users to specify the ingress interface 2507 that actual flow may ingress to the RBridge. Although ability to 2508 inject the data plane diagnostic frames from the ingress interface 2509 is optional feature, it is highly desirable, as it allows verifying 2510 end-end connectivity from an ingress port to an egress RBridge. 2512 Egress RBridge can send its response either in-band or out-of-band. 2513 In-band-response, additionally allow to measure round trip delay. 2514 In-band responses are tagged with the same VLAN as the request 2515 frame. ICMP multi part extensions in the request message allow user 2516 to specify whether out-of-band response required. If out-of-band 2517 request required, IP address it desire to receive the response MUST 2518 be specified. 2520 Additionally, diagnostic VLAN, may be specified as part of the ICMP 2521 multi part extensions. Receiver RBridge may compare inner VLAN in 2522 the payload and the specified diagnostic VLAN. If the two specified 2523 VLAN values do not match, C flag in Version C-type SHOULD be set to 2524 indicate cross connect error.. 2526 9.1.1. Theory of Operation 2528 9.1.1.1. Originator RBridge 2530 Identify the destination RBridge based on user specification or 2531 based on location of the specified address (see below sections for 2532 MAC discovery and address locator). 2534 Construct the diagnostic payload based on user specified parameters. 2535 Default parameters MUST be utilized for unspecified payload 2536 parameters. See Figure 6 for default parameters. 2538 Construct the ICMP Echo request header. Assign applicable 2539 identification number and sequence number for the request. 2541 ICMP multi part extension Version MUST be included and set 2542 appropriate flags. Specify the code as Loopback Message Request(0). 2544 Construct following ICMP multipart extensions, where applicable 2546 o Out-of-band response request 2548 o Out-of-band IP address 2550 o Diagnostic VLAN 2552 Specify the Hop count of the TRILL data frame per user 2553 specification. Or utilize the applicable Hop count value, if TRILL 2554 TTL is not being specified. 2556 Dispatch the diagnostic frame to the TRILL data plane for 2557 transmission. 2559 RBridge may continue to retransmit, the request at periodic 2560 interval, until a response received or re-transmission count 2561 expires. At each new re-transmission sequence number may be 2562 incremented. 2564 9.1.1.2. Intermediate RBridge 2566 Intermediate RBridges forward the frame as a normal data frame and 2567 no special handling is required. 2569 9.1.1.3. Destination RBridge 2571 Destination RBridge performs, frame identification methods specified 2572 in above section 5. If the Loopback message is addressed to the 2573 local RBridge, then the RBridge forward the Loopback messages to the 2574 CPU for processing. CPU performs frame validation and constructs the 2575 response as stated below. 2577 Construct the IP header for the ICMP echo response. If no out-of- 2578 band response requested, IP address in the IP header MUST be in-band 2579 IP address. If out-of-band response requested destination IP address 2580 is the IP address specified in the request message. Source IP 2581 address is derived based on the outgoing IP interface address. 2583 Construct the ICMP echo reply header using the received ICMP echo 2584 request. 2586 Include the received TRILL header and diagnostic payload in to the 2587 data field of the ICMP echo request frame [section 4.2. ]. 2589 If in-band response was requested, dispatch the frame to the TRILL 2590 data plane with request-originator RBRidge nickname as the egress 2591 RBridge nickname. 2593 If out-of-band response was requested, dispatch the frame to the 2594 standard IP forwarding process. 2596 Error handling: 2598 If VLAN cross connect error detected or inner.VLAN does not exsist 2599 in the RBridge then generate Destination Unreachable message and 2600 specify the cause using error codes. 2602 9.2. Loopback Message Hop-count method 2604 The Loopback message procedures presented in section 9.1. utilize 2605 customers specified payload to derive the diagnostic payload 2606 embedded in the OAM message. Encoding methods presented in section 2607 6. , require that certain fields of the diagnostic payload to 2608 contain some fixed well-known values. Time to time operators may 2609 desire to include identical payload fields with no modifications. 2610 Hop-count method presented in this section facilitates inclusion of 2611 un-modified payload. When unmodified payloads are included as the 2612 diagnostic payload, there MUST be methods to identify such OAM 2613 frames from regular data frames and there MUST be methods to prevent 2614 such OAM frames leaking out of TRILL network. 2616 9.2.1. Identification of OAM frames 2618 Egress RBridge receives loopback messages employing hop-count method 2619 as hop-count expired frames. There MUST be methods to identify OAM 2620 frames employing hop-count expiry method from other frames that 2621 experience hop count expiry. 2623 Firstly, procedures specified in section 6.6. MUST be utilized by 2624 the egress RBridge to differentiate receiving hop-count expired OAM 2625 frames from data frames. 2627 Secondly, the egress RBridge identifies the hop-count expired OAM 2628 messages from loopback messages utilizing hop-count expiry method by 2629 examining OAM Message code. OAM messages utilizing hop-count expiry 2630 method MUST specify TRILL OAM Message code as "Loopback Message 2631 request with Hop-count" (24). 2633 9.2.2. Prevent leaking out from TRILL network 2635 First, the ingress RBRidge that is generating the loopback message 2636 MUST discover the TRILL hop count to the egress RBridge. Hop count 2637 to the egress RBRidge MAY be discovered either using the Path Trace 2638 Message specified in section 9.3. or some other method. The 2639 discovered Hop count MUST be used as the hop count included in the 2640 TRILL header. 2642 Further, if the specified payload is IP, the IP header checksum 2643 SHOULD BE invalidated. The invalidation of IP checksum, prevents end 2644 stations further processing the OAM frames, in the unlike event it 2645 reached the end station. 2647 All other operations are similar to Loopback Message processing 2648 presented in section 9.1. 2650 9.3. Path Trace Message 2652 Primary use of Path Trace Message, commonly known in the IP world as 2653 "traceroute", is fault isolation. It may also be used for plotting 2654 path taken from a given RBridge to another RBridge. Operation of 2655 Path Trace message is identical to Loopback message except, that it 2656 is first transmitted with a TRILL Hop count field value of 1. 2657 Sending RBridge expect a Time Expiry message from the next hop or a 2658 successful response. If a Time Expiry message is received as the 2659 response, the originator RBridge record the information received 2660 from intermediate node that generated the Time Expiry message and 2661 resend the message by incrementing the previous Hop count value by 2662 1. This process is continued until, a response is received from the 2663 destination RBridge or Path Trace process timeout occur or Hop count 2664 reach a configured maximum value. 2666 9.3.1. Theory of Operation 2668 9.3.1.1. Originator RBridge 2670 Identify the destination RBridge based on user specification or 2671 based on location of the specified address (see below sections for 2672 MAC discovery and address locator). 2674 Construct the diagnostic payload based on user specified parameters. 2675 Default parameters MUST be utilized for unspecified payload 2676 parameters. See Figure 4 for default parameters. 2678 Construct the ICMP Echo request header. Assign applicable 2679 identification number and sequence number for the request. 2681 ICMP multi part extension Version MUST be included and set 2682 appropriate flags. Set the code to Path Trace Request (2) 2684 Construct following ICMP multipart extensions, where applicable 2686 o Out-of-band response request 2688 o Out-of-band IP address 2690 o Diagnostic VLAN 2692 Specify the Hope Count of the TRILL data frame as 1 for the first 2693 frame. Or use Hope Count value incremented by 1 if this is a 2694 retransmission generated in response to received Time Expiry 2695 message. 2697 Dispatch the diagnostic frame to the TRILL data plane for 2698 transmission. 2700 RBridge may continue to retransmit, the request at periodic 2701 interval, until a response received or re-transmission count 2702 expires. At each new re-transmission sequence number may be 2703 incremented. 2705 9.3.1.2. Intermediate RBridge 2707 Intermediate RBridge receive the diagnostic frame as Hope count 2708 expired frame. Based on flow encoding methods explained in above 2709 section 5, RBridge identify TRILL data plane diagnostic frames from 2710 actual data frames with Hope count expiry. Hop count time expiry 2711 messages may be generated for actual data frames as well. However, 2712 Hop count expiry message for actual data frames are always sent in- 2713 band, as actual payload does not have methods to specify the 2714 response delivery method. 2716 CPU of intermediate RBridge that receives OAM frame with Hope count 2717 expiry performs following: 2719 Identify wheather in-band or out of band response requested. 2720 Construct the IP header accordingly. 2722 Construct the ICMP Time Expiry message as specified in RFC 792 and 2723 RFC 4884. RFC 4884 specifies format of ICMP header when including 2724 ICMP multipart messages. 2726 Include original TRILL header and diagnostic payload of the original 2727 frame as data for ICMP Time Expiry message. Update the length field 2728 to reflect the size of the TRILL header and diagnostic payload. 2730 Include following ICMP multipart extensions 2732 Version 2734 Set the code to Path Trace Response (3) 2736 Nickname of the RBridge 2737 Information of the ingress interface (speed,state,slot,port) 2739 Index of the interface where frame was received 2741 nickname of the upstream RBridge the frame was received 2743 Downstream ecmp count 2745 List of Downstream RBridges {nickname, interface index and interface 2746 information} 2748 Downstream path this specific payload take { RBridge nickname, 2749 interface index and interface information} 2751 Optionally include following ICMP multipart extensions 2753 If VLAN cross connect error detected, set C flag (Cross connect 2754 error detected) in the version. 2756 If in-band response was requested or the message was generated due 2757 to actual data frame, dispatch the frame to the TRILL data plane 2758 with request-originator nickname as the egress RBridge nickname. 2760 If out-of-band response was requested, dispatch the frame to the 2761 standard IP forwarding process. 2763 9.3.1.3. Destination RBridge 2765 Processing is identical to section 8.1.1.3 2767 9.4. Multicast Tree Verification (MTV) Message 2769 Multicast Tree Verification messages allow verifying multicast tree 2770 integrity and Multicast address pruning. IGMP snooping is widely 2771 deployed in Layer 2 networks for restricting forwarding of multicast 2772 traffic to unwanted destinations. This is accomplished by pruning 2773 the multicast tree such that for specified (S,G,VLAN) or (*,G,VLAN), 2774 only required destinations are included in the outgoing interface 2775 list. It is possible due to timing or implementation defects, 2776 inaccurate pruning of multicast tree, may occur. Such events lead to 2777 incorrect multicast connectivity. Multicast tree verification and 2778 Multicast group verification messages are design to detect such 2779 multicast connectivity defects. Additionally, these tools can be 2780 used for plotting a given multicast tree within the TRILL network. 2782 Multicast tree verification OAM frames are copied to the CPU of 2783 every intermediate RBridge that are part of the Multicast tree being 2784 verified. Originator of the Multicast Tree verification message, 2785 specify the scope of RBridges that a response is required. Only, the 2786 RBridges listed in the scope field response to the request. Other 2787 RBridges silently discard the request. Definition of scope parameter 2788 is required to prevent receiving large number of responses. Typical 2789 scenario of multicast tree verification or group verification 2790 involves verifying multicast connectivity to selected set of end- 2791 nodes as opposed to the entire network. Availability of the scope, 2792 facilitate narrowing down the focus only to the interested RBridges. 2794 Implementations MAY choose to rate limit CPU bound multicast 2795 traffic. As result of rate limiting or due to other congestion 2796 conditions, time to time, MTV messages may be discarded by the 2797 intermediate RBRidges and requester may be required to retransmit 2798 the request. Implementations SHOULD narrow the embedded scope of 2799 retransmission request only to RBRidges that has failed to respond. 2801 9.4.1. Theory of Operation 2803 9.4.1.1. Originator RBridge 2805 User is required at minimum to specify either the multicast trees 2806 that needed to be verified or Multicast MAC address and VLAN or VLAN 2807 and Multicast destination IP address. Alternatively, for more 2808 specific multicast flow verification, user MAY specify more 2809 information e.g. source MAC address, VLAN, Destination and Source IP 2810 addresses. Implementation, at minimum, must allow user to specify, 2811 choice of multicast trees, Destination Multicast MAC address and 2812 VLAN that needed to be verified. Although, it is not mandatory, it 2813 is highly desired to provide option to specify the scope. 2815 Default parameters MUST be used for unspecified parameters. Please 2816 refer to Figure 6 for default payload parameters for MTV message. 2818 Based on user specified parameters, originating RBridge identify the 2819 nickname that represent the multicast tree. 2821 Obtain the applicable Hop count value for the selected multicast 2822 tree. 2824 Construct the diagnostic payload based on user specified parameters. 2825 For overall multicast tree verification message only multicast tree 2826 is specified as input. For generic multicast group verification, 2827 additional information such as group address is specified. Based on 2828 user provided parameters, implementation SHOULD identify whether the 2829 request is for overall multicast tree verification or for specific 2830 group verification. 2832 For overall multicast tree verification, use well known multicast 2833 destination MAC address (TBD_GMAC-1) defined in above section 6.4.1. 2834 as the inner destination MAC address of the TRILL frame. Remaining 2835 parameters are derived based on default values specified in Figure 6 2837 Construct ICMP echo request message header and include sequence 2838 number and identifier. Identifier and sequence number facilitate the 2839 originator to map the response to the correct request. 2841 Version ICMP multipart extension MUST be included. 2843 Code MUST be specified as Multicast Tree Verification Request (7) 2845 Optionally, include following ICMP multipart extensions, where 2846 applicable 2848 o Out-of-band response request 2850 o Out-of-band IP address 2852 o Diagnostic VLAN 2854 o In scope RBridge list. 2856 o NOTE: "Nu" field in ICMP extension RBridge scope (section 2857 8.2. ) MUST be set to zero, if response required from all 2858 RBridges. 2860 Specify the Hop count of the TRILL data frame per user 2861 specification. Or utilize the applicable Hop count value, if TRILL 2862 Hop count is not being specified by the user. 2864 Dispatch the diagnostic frame to the TRILL data plane for 2865 transmission. 2867 RBridge may continue to retransmit, the request at a periodic 2868 interval, until a response received or re-transmission count 2869 expires. At each new re-transmission sequence number may be 2870 incremented. At each re-transmission, RBRidge may further reduce the 2871 scope to the RBRidges it has not received a response. 2873 9.4.1.2. Intermediate RBridge 2875 Intermediate RBridges identify multicast verification frames per the 2876 procedure explained in section 6.4. . 2878 CPU of the RBridge validate the frame and analyze the scope RBridge 2879 list. If the local RBridge nickname is not specified in the scope 2880 list, it will silently discard the frame. If the local RBridge is 2881 specified in the scope list, RBridge proceed to section 9.3.1.3 2882 for further processing. 2884 9.4.1.3. In scope RBridges 2886 RBridge go through following processing, upon identifying that it's 2887 nickname is specified in the scope RBridge list. 2889 Identify wheather in-band or out of band response requested. 2890 Construct the IP header accordingly. 2892 Construct the ICMP echo response message as specified in RFC 792. 2894 Include TRILL header and diagnostic payload of the received OAM 2895 message as data of the ICMP response message. 2897 Include following ICMP multipart extensions 2899 Version, update the code as Multicast Tree Verification Response (8) 2901 Nickname of the RBridge 2903 Name of the ingress interface frame was received 2905 Interface index where frame was received 2907 Nickname of the upstream RBRidge the frame was received 2909 Downstream leaf node count 2911 Leaf RBridge list {RBridge nickname, interface index and interface 2912 name} 2914 Optionally, if VLAN cross connect error detected, then set C flag 2915 (cross connect error) in the versions extension. 2917 If in-band response was requested dispatch the frame to the TRILL 2918 data plane with resuest-originator RBRidge nickname as the egress 2919 nickname. 2921 If out-of-band response was requested, dispatch the frame to the 2922 standard IP forwarding process. 2924 Error Handling: 2926 RBridge MUST generate applicable notification messages if any error 2927 such as inner VLAN not available, detected against the OAM message. 2929 9.5. MAC address discovery Message 2931 MAC address discovery message is defined to discover following 2932 information 2934 o RBridge nickname where the MAC address is learnt 2936 o Interface Index and Name on which the MAC address is learnt 2938 o Type (i.e. Static, Dynamic, Secure etc.) 2940 o Age of the MAC address 2942 o Virtual Interface Tag (vNTAG) 2944 o Interface Type (Legacy or TRILL Shared) 2946 o DRB on the VLAN (If Applicable) 2948 o AF for the VLAN (If Applicable) 2950 o Time AF operational (If Applicable) 2952 Optionally, an implementation may include the following information 2954 o System MAC address of the device connected to the port with 2955 which the MAC address is associated. 2957 o System information, such as name, IP address and location of 2958 the device connected to the port with which the MAC address is 2959 associated. 2961 o Information related to this MAC address from the remote 2962 device.. 2964 The method of obtaining the above optional information is outside 2965 the scope of this document. However, implementation may consider 2966 link level control protocols such as LLDP for the purpose. 2968 9.5.1. Theory of Operation 2970 There are two possible options to implement MAC address discovery. 2971 Either we may define a new MAC-discovery ISIS sub-TLV and use ESADI 2972 to propagate the request (similar to the MAC-Reachability TLV 2973 [RFC6165]) OR we may use multicast tree verification message and 2974 include a ICMP multipart extension to indicate that the message is a 2975 MAC discovery message. 2977 Using the ISIS based method has disadvantage of being non real time 2978 and subjected to protocol delays. The second method above is 2979 independent of any control plane protocol implementation and can be 2980 exercised in real-time. Hence, in this document, we propose to 2981 utilize second method. 2983 9.5.1.1. Originator RBridge 2985 Use the well known Multicast MAC address described in section 6.4.1. 2986 , above as the inner destination MAC address of the diagnostic 2987 payload. Use the applicable source MAC address and VLAN. Use the 2988 diagnostic EthType defined earlier as the EthtType. Pad the 2989 remainder of the diagnostic payload with zero. 2991 Construct ICMP echo request message and include sequence number and 2992 identifier. The sequence number and identifier facilitate the 2993 originator to map the response to the correct request. 2995 Construct following ICMP multipart extensions 2997 o Version 2999 o Set the OAM code to the MAC address discovery request (9) 3001 o Indicate that this is a MAC discovery message 3003 o One or more MAC address to be discovered 3005 o VLAN ID of MAC addresses (optional) 3007 o Service Tag that represent the overlay network (optional) 3009 o Out-of-band response request (optional) 3011 o Out-of-band IP address (optional) 3013 o In scope RBridge list. If response required from all RBridges, 3014 then the Nu count in RBridge scope list MUST be set to zero. 3016 Specify the TTL value of the TRILL data frame to the applicable 3017 value. 3019 Set the egress RBridge nickname to the nickname of the multicast 3020 tree used for broadcast and unknown unciast. 3022 Dispatch the diagnostic frame to the TRILL data plane for 3023 transmission. 3025 An RBridge may continue to retransmit the request at periodic 3026 interval until re-transmission count expires. At each new re- 3027 transmission sequence number may be incremented. The RBridge scope 3028 list of re-transmission messages MUST be pruned to include only the 3029 response pending RBridges. It is possible that more than one RBridge 3030 has learnt the requested MAC address. Hence the implementation MUST 3031 wait until the total wait time expires and SHOULD NOT abort the 3032 discovery process on receiving a single response. 3034 9.5.1.2. Receiving RBridges 3036 CPU of Intermediate RBridges receives a copy of the MAC discovery 3037 frame through methods explained in section 6.4.2. and 6.4.1. 3039 Receiving in scope RBridges analyze the embedded ICMP multipart 3040 extensions to identify whether the request is for MAC discovery. 3042 If the request is for MAC discovery, then the receiving RBridge 3043 queries its forwarding database to identify, whether requested MAC 3044 address is present with specified VLAN information. 3046 The receiving RBridge generate responses only for identified MAC 3047 entries. If there are no matching MAC entries, the receiving RBridge 3048 silently discards the MAC discovery request. 3050 If a matching MAC address is found, the receiving RBridge generates 3051 a Destination unreachable ICMP message (Type = 3) and code = 12, 3052 "Destination host unreachable for type of service". This essentially 3053 indicates, it has found the MAC address but has reached the end of 3054 the TRILL network where the MAC address is located. 3056 RFC 4884 allow extension of ICMP messages. Only ICMP messages 3057 Destination Unreachable, Time Expired and Parameter Problem are 3058 currently extensible in RFC 4884 compliant manner. Other messages 3059 are only extensible for known payload size and considered non 3060 compliant to RFC 4884. For MAC discovery messages there is no 3061 requirement to include original data payload. Also response to MAC 3062 discovery can contain large amount of MAC address information. 3063 Hence, we conclude to utilize Destination unreachable message as 3064 opposed to using an ICMP echo response with fixed pay load size. 3066 The receiving RBridge constructs the response as follows: 3068 Construct the IP header based on the requested response type, in- 3069 band or out-of-band. For an in-band response, use RBridge in-band IP 3070 address. For an out-of-band response, use the provided egress 3071 RBridge out-of-band address. 3073 Construct the ICMP Destination Unreachable message per section 4.1 3074 of RFC 4884. Specify, ICMP type=3 and code = 12. Specify the length 3075 as zero. (i.e, no data included and ICMP extensions directly 3076 follow). 3078 Construct the pseudo IP header per section 4.3.1. 3080 Include the following ICMP multi part extensions; 3082 nickname of this RBridge. (This is required in the event of out - 3083 of band response to identify the originating RBridge nickname) 3085 Version 3087 Code, set to MAC address discovery response (10) 3089 Additionally, include the following ICMP multipart extensions, for 3090 each MAC address that was specified in the request and is present in 3091 the RBridge forwarding DB: 3093 o Interface Index and Interface Information 3094 (Speed,Slot,Port,State) on which MAC address learnt 3096 o Type (i.e. static, Dynamic, Secure etc.) 3098 o Age of the MAC address 3100 o Virtual Interface Identification (vNTAG) 3102 o Interface Type (Legacy or Trill Shared) 3104 o DRB on the VLAN (If Applicable) 3106 o AF for the VLAN (If Applicable) 3107 o Time AF operational (If Applicable) 3109 Optionally an implementation may include the following information: 3111 o The system MAC address of the device connected to the port with 3112 which the MAC address is associated. 3114 o System information, such as name, IP address and location of 3115 the device connected to the port on which MAC address is 3116 associated. 3118 o Information related to this MAC address from the remote device. 3120 If the response size is greater than the maximum MTU size of the 3121 outgoing interface, then multiple responses MAY be generated. The 3122 final response frame MUST contain ICMP multipart extension Version 3123 (C-Type 1) with F (final response)flag set. 3125 The response frame is delivered to the TRILL data plane for in-band- 3126 response. 3128 If out of band response was requested, the response frame is 3129 delivered to the IP protocol stack. 3131 9.6. Address-Binding Verification Message 3133 Virtual machine provisioning is a very common practice in data 3134 centers and enterprises. It is normal for virtual machines to move 3135 from one physical machine to another physical machine. As a result 3136 ARP tables on gateways can be stale and network operators may need 3137 to resort to multiple tools to identify the location of a given IP 3138 address that is being diagnosed for connectivity. Even if the 3139 location of the server that host the given IP address is identified 3140 using other tools, additional steps may be required to further 3141 identify the RBridge that interface with the physical server. 3143 It is important to have set of tools that allow an operator to 3144 quickly and easily identify the physical MAC address associated with 3145 a given IP address, or IP addresses associated with a given physical 3146 MAC address. Additionally, it may be required to identify the 3147 RBridge that connects to the given IP address. In this section, we 3148 present methods to identify MAC address to IP addresses or IP 3149 address to MAC address bindings. 3151 Address binding tools presented here need to be exercised from 3152 either a router or an RBridge that has IP services enabled on a 3153 given VLAN. 3155 There are two different address binding resolutions required 3157 1. MAC address to IP addresses binding 3159 2. IP address to MAC address binding. 3161 We propose to use invARP [RFC 2390] to resolve MAC address to IP 3162 address(es) binding and ARP [RFC 826] to resolve IP address to MAC 3163 binding information. It is possible a given physical server to host 3164 multiple virtual machines (i.e. IP Addresses). Hence, it is expected 3165 to receive one or more responses, to an invARP request. However, 3166 invARP in its current form is incapable of identifying whether a 3167 single multi-homed host or multiple virtual hosts. At the time of 3168 RFC 2390 and original ARP standard RFC 892 were written, virtual 3169 machine concept did not exist. Hence, these protocols in its current 3170 form do not include virtual machine identifiers such as vNTAGs. This 3171 lapse of identification of virtual machines, make troubleshooting of 3172 large virtual machine networks, with dynamic server allocation, very 3173 difficult. Hence, we propose to extend, ARP [RFC 892] and invARP 3174 [RFC 2390], protocol to carry, virtual machine identification tags. 3176 Upon discovery of MAC address or identification that a given MAC 3177 address is associated with a valid IP addresses, user may employ the 3178 locator utilities listed in section 9.7. to identify the 3179 corresponding RBridge and associated interface information. 3180 Alternatively, implementation may support ARP response snooping with 3181 extension explained in 9.5.1 to encode RBridge and location 3182 information into ARP or invARP responses. 3184 9.6.1. Extension to ARP and invARP 3186 RFC 2390 presents methods to discover protocol address associated 3187 with a given hardware address. In this section we propose methods to 3188 extend RFC 2390 and RFC 892 to encode additional virtual interface 3189 tag information and device information that may facilitate 3190 identifying physical machine locations. 3192 It is important the extensions proposed in the standard are 3193 transparent to current implementations. 3195 Figure 53, below, depicts the format of an ARP/invARP frame with the 3196 proposed extensions embedded. 3198 ARP frame as defined in RFC 892 and RFC 2390 has a fixed structure 3199 and include only the length fields for addresses. Implementations 3200 index in to these fix address fields and do not check the total 3201 length of the response frame as part of validation. Hence, we 3202 propose to include the extensions at the end after the target 3203 protocol address. Implementations that do not support the new 3204 extensions will safely ignore these values. 3206 We expect additional identification information carried in ARP and 3207 invARP to be limited. Furthermore, these, identification information 3208 have compact and deterministic size. Hence, we propose not to use 3209 explicit, length identification field, instead derive the length of 3210 the value field implicitly, based on the class and class types 3211 defined below. ARP and invARP follow identical encoding structures. 3213 31 0 3214 +-----------+-----------+ 3215 | Hw Addr | Protocol | 3216 +-----+-----+-----------+ 3217 | HL | AL | Op Code | 3218 +-----+-----+-----------+ 3219 | | 3220 . Source Hw Address . 3221 | | 3222 +-----------------------+ 3223 | | 3224 . Source Proto Address . 3225 | | 3226 +-----------------------+ 3227 | | 3228 . Target Hw Address . 3229 | | 3230 +-----------------------+ 3231 | | 3232 . Target Proto Address . 3233 | | 3234 +-----------------------+ 3235 | Extensions | 3236 . . 3237 | | 3238 +-----------------------+ 3240 Figure 52 Encoding of ARP and invARP 3242 9.6.1.1. Encoding ARP-invARP extensions 3244 ARP Extension encoding structure and proposed extensions are 3245 presented in this section. We propose a compact structure for ARP 3246 encoding. In Figure 53 "Class" identifies the Object Class and the 3247 "Class Type" (c-Type) within the class identify specific data 3248 element within the object class. C-Type implicitly indicates the 3249 size of the object. The encoded object size MUST NOT exceed the 3250 implied size of the corresponding Class and c-Type. 3252 +-------+------+--------------+ 3253 |Class |C-Type| | 3254 +-------+------+ + 3255 | | 3256 . Object . 3257 | | 3258 +-----------------------------+ 3260 Figure 53 Encoding of ARP Extensions 3262 Class : (1 octet). Define to identify the Object Class. 3264 C-Type : (1 octet). Define Object type within Object class. 3266 Object : (Variable octet, depends on the Class and C-Types) 3268 +--------+--------+-------+---------------------------------+ 3269 |Class |C-Type |Name | Description | 3270 +--------+--------+-------+---------------------------------+ 3271 | 1 | 1 |vNTAG |vNTAG of the interface | 3272 +--------+--------+-------+---------------------------------+ 3273 | 2 | 1 |RBridge|TRILL RBridge nickname | 3274 +--------+--------+-------+---------------------------------+ 3275 | | 2 |ifindex|ifindex of RBridge interface ARP | 3276 | | | |response arrived | 3277 +--------+--------+-------+---------------------------------| 3278 | | 3 |Slot |Slot id of RBridge interface ARP | 3279 | | | |response arrived | 3280 +-----------------------------------------------------------+ 3281 | | 4 |Port |Port id of RBridge interface ARP| 3282 | | | |response arrived | 3283 +--------+--------+-------+---------------------------------+ 3285 Figure 54 Table of Class, C-Type and usage 3287 Figure 54, above, presents Class, c-Type and application definitions. 3288 vNTAG, rBridge, Slot and Port are each 2 octets in length. The length 3289 of ifindex is 4 octets. All of the above extensions are optional. vNTAG 3290 is inserted by the end station that is responding to the ARP request. 3291 All other fields are inserted by the TRILL RBridge that interface with 3292 the end-station and implement ARP response snooping. ARP response 3293 snooping is similar to Dynamic ARP inspections, implemented by many 3294 major vendors. Dynamic ARP inspection validates the Source IP address 3295 of ARP response against known IP addresses to prevent ARP cache 3296 poisoning by rogue stations. ARP response snooping, on the other hand, 3297 intercepts ARP response frames and inserts required fields as defined 3298 in this standard. Implementations may extend the dynamic ARP inspection 3299 framework to implement ARP response snooping. 3301 In the interim, most end stations and servers may not insert the 3302 proposed vNTAG information. Hence, optionally, ARP response snooping, 3303 process on TRILL RBridge, MAY insert vNTAG information on behalf of the 3304 end station or server. 3306 9.7. End-Station Attachment Point Discovery 3308 In traditional deployments, end stations and servers were relatively 3309 static in their locations. As a result localizing a fault was 3310 relatively easier. 3312 The virtual machine concept is an increasing trend in Datacenter and 3313 large enterprises. Dynamic load balancing policies of Virtual 3314 infrastructure, based on various load balancing policies, move 3315 virtual machines between different physical servers. This dynamic 3316 motion of virtual machines causes difficulty in associating a given 3317 virtual server to a RBridge. As a result, localizing a fault is a 3318 difficult task and requires use of multiple applications. Some 3319 virtual machine deployments utilize a single MAC address to 3320 represent all the virtual servers in a single physical server. 3321 Hence, it is important, to identify both the physical attachment 3322 point and the virtual segment information, such as VLAN and Virtual 3323 Tags. 3325 ARP/invARP extensions presented above facilitate discovery of the 3326 attachment information, however, some implementation may face 3327 scaling issues due to the large number of ARP requests. An 3328 alternative method is presented below. 3330 The End-Station attachment Point Discovery methods presented here, 3331 allow discovering, RBridge, interface information, VLAN, virtual 3332 Tags, etc, associated with a given IP Address. 3334 The End-Station attachment Point Discovery is a two step process. 3335 However implementations may present a single user interface that 3336 combines both the steps. 3338 Step 1: Utilize ARP to discover the MAC address associated with the 3339 specified IP address. Identify the ingress RBridge nickname by 3340 analyzing the TRILL header and identify the VLAN information based 3341 on the inner VLAN. 3343 Step 2: Utilize MAC discovery methods explained above to discover, 3344 interface and virtual Tag information associated with the MAC 3345 address discovered in above Step 1. Implementation SHOULD narrow the 3346 scope of the MAC discovery to include only the RBridge and VLAN 3347 discovered in step 1. 3349 9.8. DRB and AF Discovery 3351 The TRILL Base Protocol standard [RFC 6325] specifies support for 3352 multi-access legacy network and shared segments between TRILL and 3353 legacy devices. Legacy networks ensure loop free forwarding via the 3354 IEEE 802.1D (Spanning Tree) protocol. RFC 6325 and RFC 6327 specify 3355 loop prevention methods in mixed environments where the TRILL 3356 network borders with a legacy multi-access network. RFC 6325 also 3357 provide methods for load splitting of native traffic in to the TRILL 3358 network. These are accomplished by having a single Designated 3359 RBridge (DRB) for a given LAN segment which designates an Appointed 3360 Forwarder (AF) for each VLAN on the segment to ingress and egress 3361 traffic originating and destined to and from the legacy network. 3363 Based on network dynamics, configurations, and failures, DRB and/or 3364 AF designation may change from time to time. Hence, discovery of DRB 3365 and AF is very important to effectively troubleshoot network 3366 connectivity problems that involve TRILL and legacy networks 3367 connected via non P2P TRILL interfaces. 3369 DRB-AF discovery message has three variations. 3371 1. All DRB discovery 3373 2. All AF discovery 3375 3. VLAN,AF discovery 3377 Above messages are identified with a unique TRILL OAM message code 3378 (section 8. ). 3380 DRB-AF discovery messages allow for identifying the following 3381 parameters: 3383 o Nickname of the DRB 3385 o STP Root Bridge identifier 3387 o Up time of AF (if responder is the AF) 3389 o Up time of DRB (if Responder is DRB) 3391 o Enabled VLAN List 3392 o Announcing VLAN List 3394 o DRB State (If Responder is the DRB) 3396 o AF State (If Responder is AF) 3398 o Pseudo Node bypass (If the Responder is the DRB) 3400 o Number of times the Designated VLAN has changed 3402 o AF List (nickname,start VLAN,end VLAN)(If the Responder is DRB) 3404 The above parameters are encoded in to the response message via ICMP 3405 multipart extensions (section 8. ) 3407 9.8.1. Theory of Operation 3409 DRB-AF discovery message utilize same addressing and format as the 3410 MAC discovery message (Section 9.5. ) 3412 9.8.1.1. Originator RBridge 3414 Follow the steps specified in section 9.5.1.1. , with the following 3415 exceptions 3417 Specify the message as one of the DRB-AF messages. 3419 If the message is VLAN,AF discovery message, then include the 3420 interest VLAN list. 3422 9.8.1.2. Receiving RBridge 3424 Follow the processing steps specified in section 9.5.1.2. with the 3425 following exceptions: 3427 If RBridge is in the scope list or All-RBridge scope is specified, 3428 then the RBridge processes the message as follows: 3430 If the message is DRB discovery message then the receiving RBridge 3431 include the following information: 3433 o Response code set to DRB discovery response (12) 3435 o Nickname of the DRB 3437 o Nickname of AF of the specified VLAN 3438 o STP Root Bridge identifier 3440 o DRB Life time 3442 o Enabled VLAN List 3444 o Announcing VLAN List 3446 o DRB State 3448 o Pseudo Node bypass 3450 o Number of times Designated VLAN change 3452 o AF List (nickname,start VLAN,end VLAN) 3454 If the message is an AF discovery or VLAN, AF discovery message, 3455 then the receiving RBridge first validate whether the RBbridge is 3456 the AF for the specified VLAN list and include following 3457 information: 3459 o Response code set AF discover response (14) or AF-VLAN discover 3460 response (16) 3462 o Nickname of the DRB 3464 o Nickname of AF of the specified VLAN or AF VLAN-List if VLAN is 3465 not specified. 3467 o STP Root Bridge identifier 3469 o AF Life time (i.e. How long has been AF) 3471 o Enabled VLAN List 3473 o Announcing VLAN List 3475 o AF State 3477 o Number of times Designated VLAN change 3479 If RBridge is not the AF for specified VLAN then include ERROR code 3480 Not AF (4) (see Figure 27). 3482 If RBridge is AF for only a subset of VLANs specified in the request 3483 then include WARINING "AF VLAN list Mismatch" (3) and include the 3484 VLAN list that the RBridge is functioning as AF. (Figure 28) 3486 9.9. Diagnostic Payload Discovery for ECMP coverage 3488 This document specifies that a 128 byte Diagnostic Payload to be 3489 embedded in the OAM frame. The Diagnostic Payload embedded in the 3490 OAM frame determines the ECMP path taken by the OAM frame. Hence, It 3491 is important to have methods that allow operators to discover 3492 diagnostic payload constructs that direct OAM frames through desired 3493 ECMP paths. RFC 4379 proposes a method to discover payload 3494 combinations in MPLS networks. We propose to use a similar approach, 3495 with some modifications. 3497 RBridge MUST derive diagnostic payload combination such that when 3498 applicable hashing methods are applied to the diagnostic payload, 3499 the OAM frames that contain the diagnostic payload follow the 3500 requested path. The diagnostic payload contain Destination and 3501 Source MAC addresses, VLAN Tag, Ethertype, Layer 3 and Layer 4 3502 addressing information and packet data. TRILL RBridges operate as 3503 Layer 2 devices and learn source MAC addresses against ingress 3504 RBridge nickname. Use of any arbitrary MAC address as source MAC 3505 address may affect RBridge learning. Hence we suggest using either a 3506 well-known OAM MAC address or operator specified MAC address as the 3507 source MAC address of the generated diagnostic payload. TRILL, Layer 3508 2 forwarding happens in the context of a VLAN. Specification of a 3509 random VLAN in the generated diagnostic payload may lead to 3510 different forwarding behavior of OAM frames than the actual data 3511 frames that operator desire to diagnose. Hence, operator is required 3512 to specify the desired VLAN in the payload generation request. 3514 Operator generates Payload discovery command from RBridge RB(a), in 3515 the message operator MUST specify the seed Destination MAC address, 3516 desired VLAN and required ECMP coverage and final egress RBRidge 3517 RB(x). Receiving RBrdige (RBi) using the provided information in the 3518 request and using local hashing algorithm, generates series of 3519 proposed payloads. The generated payloads are returned to the 3520 requester. Requester may use the received proposal as a seed and 3521 request the next RBridge (RBj) downstream from RBi to generate 3522 diagnostic payloads that would cover the desired ECMP path 3523 downstream from RB(j). RB(a) may continue this process until 3524 specific set of payloads are derived such that it covers desired 3525 paths from ingress RBridge RB(i) to egress RBRidge RB(x). These 3526 derived payload allows RB(a) to test end-end coverage from RB(a) to 3527 RB(x) over a specific path. 3529 Encoding of proposed MAC address seed require further clarification 3530 and some illustration to ensure clearer understanding. 3532 Seed MAC address is encoded in c-type 37 as 6 octet value. A given 3533 request can contain multiple seeds. Each of the seeds are 3534 indentified with a unique 12 bit identifier. 3536 Each zero valued octet in a MAC address seed has a corresponding bit 3537 value vector (c-type 39). Non-zero octets of the MAC address seed 3538 are considered fixed valued and are not considered for payload 3539 proposal generation. 3541 Bit value vector is 256 bits long. Each bit in the bit vector value 3542 represents a value for the corresponding octet of the MAC address 3543 seed. Values that are included in the proposal are represented by 3544 setting the corresponding bit vector values to 1. 3546 As an Example let's consider requester desire to use destination MAC 3547 address 0x00:0A:0B:00:00:00 to 0x00:0A:0B:0F:0F:0F to generate the 3548 payload proposals. 3550 Requester encode the destination MAC address seed using c-type 37 3551 (Seed Destination MAC address) as follows 3553 0 1 2 3 3554 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3556 |0 0 0 0 1 1 0 1 0 1 0 0|0 0 0 0|0 0 0 0 0 0 0 0|0 0 0-0 1 0 1 0| 3557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3558 |0 0 0 0 1 0 1 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 3559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3561 Corresponding desired range for each of the octets that contain 0 3562 (zero) are encoded as follows, using c-type 39 (MAC octet bit 3563 vector). 3565 Example encoding of MAC-0: 3567 0 1 2 3 3568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3570 |0 0 0 0 1 1 0 1 0 1 0 0|0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 3571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 Octet zero (MAC-0) of MAC address seed is represented in the above 3574 c-type 39. Value zero in MAC-0 field of the above c-type 39 3575 indicates that other values may be considered for the proposal. 3576 However, in this example, for MAC-0 user requires maintaining value 3577 zero and does not desire for the responder to consider other options 3578 for MAC-0 field. Hence bit vector length is set to zero to indicate 3579 that. 3581 Example encoding of MAC-3: 3583 0 1 2 3 3584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3586 |0 0 0 0 1 1 0 1 0 1 0 0|0 0 1 1|0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 0| 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3588 |1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3591 In the above example MAC-3 bit vector is represented using c-type 3592 39. Bit vector offset has been set to zero to represent, propose 3593 value range start from 0. Bit vector length has been set to 16 to 3594 indicate 16 values from the bit vector offset to be considered for 3595 the proposal. In this example, the available range for the proposal 3596 is 0x0 to 0xF. 3598 9.9.1. Theory of Operations 3600 The ingress RBridge sends an Payload discovery OAM Command Message 3601 to the intermediate RBridge from which it desires to discover the 3602 diagnostic payloads for the specified ECMP choices. Also specified 3603 in the Command Message is the egress RBridge nickname, desired VLAN, 3604 EthType and ECMP choices. 3606 As an example consider the topology in Figure 55. RB1 desires to 3607 identify diagnostic payloads required to cover all of the ECMP 3608 choices RB2 has towards egress RBridge RB7 for a specific VLANx. 3610 RB1 generates an ECMP discovery OAM command message to RB2. In the 3611 ECMP discovery message, RB1 includes egress RBridge nickname (RB7), 3612 ECMP choices to be covered, interested VLAN (VLANx), Destination MAC 3613 address seed, and EthType. 3615 +-----+ 3616 --------| RB3 |--------- 3617 | | | | 3618 | +-----+ | 3619 +-----+ +-----+ +-----+ +-----+ 3620 | RB1 |------| RB2 | +-----+ | RB6 | | RB7| 3621 | | | |-----| RB4 |------| |-----| | 3622 +-----+ +-----+ | | +-----+ +-----+ 3623 | +-----+ | 3624 | | 3625 | +-----+ | 3626 | | RB5 | | 3627 --------| |--------- 3628 +-----+ 3630 Figure 55 Sample Topology 3632 9.9.1.1. Receiving RBridge 3634 The receiving RBridge (RB2), first, MUST perform the required pre- 3635 processing and OAM message validation as specified in section 6.6. 3637 Upon validation of the message, the receiving RBridge, using the 3638 ECMP selection algorithm of the local RBridge and the payload seed 3639 received from the requester, derives the required payload proposals 3640 for the requested ECMP choices such that OAM frames containing the 3641 proposed diagnostic payloads follow the requested ECMP path. If the 3642 received payload seed contain multiple seed values, the local 3643 RBridge is required to consider all of the seed values. Bit vector 3644 positions of the c-type 39 that do not generate the required ECMP 3645 choice or local RBridge did not consider for payload generation MUST 3646 be set to zero. 3648 If the requested ECMP choice is not available at the Receiving 3649 RBridge, an ECMP selection error is generated. (e.g.Ingres RBridge 3650 requested to generate payload for path 10, and local RBridge has 3651 only 5 paths to the egress RBridge, then ECMP paths 6-10 are at 3652 error) 3654 The resulting payload proposals are returned to the requester via 3655 Payload generation response OAM message. Payload generation response 3656 OAM message may be delivered either in-band or out of band to the 3657 requesting RBridge. 3659 Following TLVs are required to specify the requested operations and 3660 results. 3662 TLVs in the Command Request Message 3664 o Payload Generation Request (c-type 40) 3665 o Egress RBridge nickname (c-type 40) 3666 o ECMP choices (c-type 40) 3667 o Interested VLAN (c-type 4) 3668 o Interested EthType (c-type 43) 3669 o Seed Destination MAC Address (c-type 37) 3670 o Seed Source MAC Address (c-type 38) (optional) 3671 o MAC Octet bit-vector (c-type 39) 3672 o Service Tag (c-type 23) (optional) 3673 TLVS in the Command Response Message 3675 o Payload generation response (c-type 41) (for each ECMP choice) 3676 o ECMP choice status (for each of the requested ECMP) 3677 o Interested VLAN (c-type 4) 3678 o Interested EthType (c-type 43) 3679 o Seed Destination MAC Address (c-type 37) 3680 o Seed Source MAC Address (c-type 38) (optional, included only if 3681 present in the request) 3682 o MAC Octet bit-vector (c-type 39) (bit values appropriately set) 3683 o Service Tag (c-type 23) (optional) 3684 Please see section 8.2. for encoding format of the applicable TLVs. 3686 The request originator may utilize the above payload proposals 3687 received from an intermediate RBridge to iteratively discover 3688 payload proposals along the path from ingress RBridge to the desired 3689 RBridge. At each of the iteration requester may utilize received 3690 proposals as seeds to the next hop downstream RBridge. 3692 9.10. Notification Messages 3694 Notification messages are generated either due to regular TRILL data 3695 frames or TRILL OAM frames. Implementation MUST not generate 3696 notification messages on notification messages. 3698 There are 3 types of Notification messages: 3700 o Time Expiry 3701 o Destination Unreachable 3702 o Parameter Problem 3704 Within these Notification messages, error, warning and information 3705 ICMP extensions may be included to identify the details of the 3706 notification message. Section 4.3. above covers details of encoding 3707 Notification messages, section 8.2. covers ICMP extensions. 3709 Time expiry messages are generated when TRILL hope-count field reach 3710 to zero. If applicable, It may contain additional error, warning or 3711 information extensions. 3713 Destination unreachable notification may be generated for following 3714 scenarios; additional scenarios may be added later. 3716 o Egress RBridge nickname unknown 3717 o Inner VLAN does not exist or suspended 3718 o Not the AF for inner VLAN 3720 Parameter Problem notification may be generated for following 3721 scenarios; additional scenarios may be added later. 3723 o Invalid RBridge nickname (RBridge nickname is one of the 3724 reserved 0xFFC0 - 0xFFFF) 3725 o MTU mismatch 3726 o Invalid VLAN (Reserved VLANs) 3727 o Interface state is not forwarding 3729 10. Monitoring and Reporting 3731 Proactive identification of data plane failures are important part 3732 of maintaining Service Level Agreements (SLA). In traditional Layer 3733 2, networks, there is only a single active path to monitor and both 3734 multicast and unicast traffic follow identical paths. With TRILL, 3735 there are multiple active paths and unicast and multicast traffic 3736 take potentially different paths, depending on the flow parameters. 3738 TRILL deployment in a typical data center may have 10's of 1000 of 3739 links and 100's of RBridges. In such an enviorement, there may be 3740 large number of active paths between two end points. As an example, 3741 assume a topology with 4 RBridges connected serially with 32 ECMP 3742 links at each hop. In the stated example topology, there are 3743 32x32x32=32768 possible paths. Monitoring all of the possible path 3744 combinations is not scalable. However, skipping some combination of 3745 paths leads to reduce coverage and hence reduced effectiveness of 3746 monitoring data. Even if one was brave enough to monitor all of the 3747 links, analyzing and diagnosing a problem is quite cumbersome due to 3748 the large amount of data. In other words, there must be methods to 3749 scale the problem and present information in a more concise manner 3750 that is still effective. 3752 In this document we propose to use the "region" concept to partition 3753 the network in to logical sections. Regions are monitored 3754 independently. Detailed sets of monitoring data are distributed 3755 throughout the region. A summary set of monitoring data is 3756 distributed throughout the network. Network operators can obtain a 3757 network health snapshot of the entire network from any RBridge in 3758 the network. Detailed health report of a given region can be 3759 obtained from any RBridge in the region. 3761 An RBridge associate itself with a region through its interfaces. A 3762 given interface can belong to one and only one region. An RBridge 3763 can have multiple interfaces belonging to different regions. Each 3764 RBridge is responsible for collecting monitoring data, organizing 3765 the data in to regions and advertising the data to its peers. Please 3766 see section 10.2, Advertising Policy for details. 3768 In theory a network topology can be any arbitrary graph. In 3769 practices, however, it is some set of sub-graphs repeating to 3770 construct the overall topology. Each sub-graphs or set of sub-graphs 3771 can be considered a region for monitoring purpose. The manner in 3772 which regions are partitioned is an administrative choice such that; 3774 1. Maximize the fault coverage. 3776 2. Optimize network health data summarization. 3778 As an example consider a typical datacenter topology depicted in 3779 Figure 10. Typical datacenter may have multiple Points of 3780 Demarcation (POD)s connected with an aggregation layer. A POD can be 3781 considered as a region and may be individually monitored. 3783 +o--o+ +o---o+ +o--o+ 3784 +~~~~~~~~~~~~| |~~~~~~~~| |~~~~~~| |~~~~~~~~~~~~~~~+ 3785 | | RB | | RB | | RB | | 3786 | +o--o+ +o---o+ +o--o+ | 3787 | | | | | | | | 3788 | | 3789 | Region Rm | 3790 | | 3791 | | | | | | | | | | 3792 | +o--o+ +o--o+ +o--o+ +o--o+ | 3793 +~~~| RB |~~| RB |~~~~~~~~~~~~~~~~~~~~~| RB |~~| RB |~~~~~~~~+ 3794 +~| |~~| |~~+ +~| |~~| |~~+ 3795 | +o--o+ +o--o+ | | +o--o+ +o--o+ | 3796 | | | | | | | | | | | | 3797 | | | | 3798 | | | | 3799 | Region R1 | . . . | Region Rn | 3800 | | | | 3801 | | | | 3802 | | | | | | | | | | | | 3803 | +o--o+ +o--o+ | | +o--o+ +o--o+ | 3804 +~| |~~| |~~+ +~| |~~| |~~+ 3805 | RB | | RB | | RB | |RB | 3806 +-o--+ +o.o.+ +-o--+ +o.o.+ 3808 Figure 56 Example of "regions" 3810 10.1. Data categories 3812 There are 3 categories of monitoring data. They are, Summary 3813 Category, Detail Category and Vendor Specific Category. The Summary 3814 and Detail categories are mandatory. That is, every RBridge that is 3815 compliant to this standard and support Monitoring, MUST support all 3816 the elements defined under the Summary and Detail categories. The 3817 Vendor specific Category is optional. Vendor specific data elements 3818 are only available within the region. An RBridge that does not 3819 understand the Vendor specific data elements forward them to 3820 neighboring RBridges per Advertising Policies define in section 3821 10.2. Individual data elements and structure of encoding Summary, 3822 Detail and Vendor specific categories are presented in sections 3823 10.3. - 10.5. . 3825 10.2. Advertising Policy 3827 Each RBridge is responsible for advertising monitoring data to the 3828 OAM capable neighbors. 3830 Different interfaces on an RBridge can belong to different regions. 3831 However a given interface can belong to one and only one region. As 3832 a result a given RBridge may receive data from multiple regions. 3833 Each RBridge is responsible for advertising proper data categories 3834 over a given interface to the neighbor. 3836 Rule 1: No monitoring data are distributed: 3838 o On legacy interfaces 3840 o To neighbors not OAM capable 3842 o When ISIS state is not 2-way 3844 o When monitoring data advertisement is disabled 3846 Rule 2: Distribution of Summary category data: 3848 o Distribute on all OAM capable interfaces 3850 o Do not distribute summary data element of a region back to 3851 the originating region. (i.e. do not distribute on to 3852 interfaces that have the same region name as the data 3853 element) 3855 o Summary data for local region is derived from Detail data. 3856 (local summary data is never advertised into the local 3857 region per the above rule. However, it is advertised out to 3858 other regions the RBridge has interfaces in to) 3860 Rule 3: Distribution of Detail category 3862 o Distributed on OAM capable interfaces 3864 o Region of the data element and region of the interface must 3865 match for propagating a data element over an interface 3866 (i.e. Do not advertise to other regions) 3868 o Do not advertise data element back in to the originator 3869 RBridge. 3871 Each RBridge distribute data at periodic intervals. Each RBridge 3872 collects data it has received, analyzes them and redistribute 3873 according to the rules specified above. The distribution interval 3874 should be appropriately adjusted to not overload ISIS routing 3875 operations. 3877 Then Monitoring application is responsible for maintaining the 3878 Application specific LSP. We propose to use Generic Application 3879 Encoding methods explained in [GenAPP] for distributing Monitoring 3880 data. TRILL operates in ISIS Level-1 layer, hence S,D flags defined 3881 in [GenAPP] MUST be set to zero. 3883 We propose to obtain specific Application ID [GenAPP][RFC5226] from 3884 IANA for the purpose of registering TRILL Monitoring data 3885 distribution. 3887 Within the Application ID context, a series of sub-TLV are defined 3888 to carry specified information. 3890 10.2.1. Multi Instance ISIS and Flooding Scope 3892 As presented above, Summary data has a flooding scope of the entire 3893 ISIS domain and Detail and Vendor data have a flooding scope of the 3894 applicable monitoring region. 3896 [ISISMI] provides a frame work to define multiple instances of ISIS 3897 and multiple instances of ISIS topologies within a given ISIS 3898 instance. These topologies may have different flooding scopes. The 3899 flooding scope of a topology limits the extent of the distribution 3900 of an LSP associated with that topology. Topologies defined within 3901 the ISIS TRILL-OAM instance are independent of the TRILL data plane 3902 multi-topology definitions within the TRILL ISIS protocol instance. 3904 It is recommended to have a separate ISIS instance for the purpose 3905 of TRILL-OAM. Within the TRILL-OAM ISIS instance, the following 3906 topologies MUST be defined with the specified flooding scope. 3908 The Global Topology is created within the TRILL-OAM ISIS instance to 3909 include all of the RBridges in the OAM domain. Summary category 3910 GenAPP data LSPs are flooded within the scope of the Global 3911 Topology. 3913 Regional Topologies are created within the TRILL-OAM ISIS instance 3914 per each region for regions a given RBridge is associated with. A 3915 Regional Topology includes RBridges and interfaces within the 3916 applicable region. LSPs carrying Detail and Vendor category data are 3917 flooded within the applicable Regional Topology. 3919 10.3. Summary Category 3921 Then following individual data elements are defined within the 3922 summary category. 3924 o Name of the region 3926 o Total number of RBridges in the regions 3928 o Total number of TRILL enabled ports in the region 3930 o Percentage of TRILL enabled ports down 3932 o Percentage of TRILL enabled ports oversubscribed 3934 o Maximum number of paths in the largest ECMP in the region 3936 Then following structure encodes each of the data elements within 3937 the summary category. 3939 +----------+ 3940 | subTlv | 2 octets 3941 +----------+----------+ 3942 | Region-ID | 4 octets 3943 +---------------------+ 3944 |L | | 3945 .--+ . 3946 . . 3947 | | 3948 +----------+----------+ 3949 | #Rbrdidge| 2 octets 3950 +----------+ 3951 | #Ports | 2 octets 3952 +----------+ 3953 | #UpPorts | 2 octets 3954 +----------+ 3955 | #OsubPort| 2 octets 3956 +----------+ 3957 | #ErrPorts| 2 octets 3958 +----------+ 3959 | #ECMP | 2 octets 3960 +----------+ 3961 | #DwnPorts| 2 octets 3962 +----------+ 3964 Figure 57 Encoding Summary Category Data 3966 subType : (2 octets) is always 1 for summary category 3967 Regiond-ID : (4 octets) is unsigned 32 bit integer identifier of the 3968 region 3970 L : ( 1 octet), length of the subsequent field 3972 Region Name : '\0' terminated ASCII string of region name of 3973 variable size to maximum of 255 octets. 3975 #Rbridge: (2 octets), number of RBridges in the region 3977 #Ports: (2 octets) Total number of TRILL enabled ports available on 3978 this RBridge 3980 #Up Ports: (2 octets) Total number of TRILL enabled ports that are 3981 operationally up. 3983 #OSPorts : (2 octets) Total number of TRILL enabled ports that are 3984 oversubscribed. 3986 #ErrPorts : (2 octets) Total number of TRILL enabled ports that are 3987 indicating errors. 3989 #DwnPorts : (2 octets) Total number of TRILL enabled ports that are 3990 operationally down. 3992 #ECMP : (2 octets) Maximum number of ECMP as seen by this region 3993 ISIS routing table. 3995 10.4. Detail Category 3997 Following data elements MUST be present within the detail category. 3999 o Name of the region 4001 o Name of the RBridge 4003 o RBridge up time 4005 o Total number of neighbors 4007 o Total number of TRILL enabled ports in the RBridge 4009 o Total number of TRILL enabled ports Up 4011 o Total number of TRILL enabled ports oversubscribed 4012 o Total number of TRILL enabled ports observing errors 4014 o Maximum number of links in the largest ECMP of the switch 4016 o Port data: Name of each TRILL enabled Port and Port state (Up, 4017 oversubscribed, error) and interface index. 4019 o Adjacency Matrix 4021 o List of {neighbor RBridge nickname and interface index of 4022 ports connecting to the neighbor RBridge}. 4024 o NOTE: Interface index in the Adjacency matrix is used as 4025 key in to port data to obtain Port name and state. 4027 +----------+ 4028 | subType | 2 octets 4029 +----------+ 4030 | RBridge | 4031 +----------+----------+ 4032 | Region-ID | 4 octets 4033 +---------------------+ 4034 | L| | 4035 .--+ . 4036 . Region Name . 4037 | | 4038 +----------+----------+ 4039 | UpTime | 4040 | | 8 octets 4041 +---------------------+ 4042 | #Ports | 2 octets 4043 +----------+ 4044 | #Up Ports| 2 octets 4045 +----------+ 4046 | #OsubPort| 2 octets 4047 +----------+ 4048 | #ErrPorts| 2 octets 4049 +----------+ 4050 | #ECMP | 2 octets 4051 +----------+ 4052 | #DwnPorts| 2 octets 4053 +----------+ 4054 | subtype-2| 2 octets 4055 +----------+----------+ 4056 | | 4057 . Port Data . 4058 . . 4059 | | 4060 +----------+----------+ 4061 | subtype-3| 2 octets 4062 +----------+----------+ 4063 | | 4064 . Adjacency Matrix . 4065 . . 4066 | | 4067 +---------------------+ 4069 Figure 58 Encoding Detail Category Data 4071 subType : (2 octets) always 2 for Detail category 4073 RBridge: (2 octets) TRILL RBridge nickname [RFCtrill] 4074 Regiond-ID : (4 octets) unsigned 32 bit integer identifier of the 4075 region 4077 L : ( 1 octet), length of the subsequent field 4079 Region Name : '\0' terminated ASCII string of region name of 4080 variable size to maximum of 255 octets. 4082 Up Time: (8 octets), number of seconds RBridge has been operational. 4083 If an RBridge reaches maximum count, it MUST NOT rollover. 4085 #Ports: (2 octets) Total number of TRILL enabled ports available on 4086 this RBridge 4088 #Up Ports: (2 octets) Total number of TRILL enabled ports that are 4089 operationally up. 4091 #OSPorts : (2 octets) Total number of TRILL enabled ports that are 4092 oversubscribed. 4094 #ErrPorts : (2 octets) Total number of TRILL enabled ports that are 4095 indicating errors. 4097 #DwnPorts : (2 octets) Total number of TRILL enabled ports that are 4098 operationally down. 4100 #ECMP : (2 octets) Maximum number of ECMP as seen by this RBridge 4101 ISIS routing table. 4103 subtype-2: (2 octets): Set to 3. Following this sub type is the 4104 variable length Port Data. See below for details 4106 sutype-3: (2 octets): Set to 4. Following this sub type is the 4107 variable length Adjacency Matrix. See below for details 4108 +----------+ 4109 | subType | 2 octets 4110 +----------+ 4111 | RBridge | 4112 +----------+----------+ 4113 | F | 1 octets 4114 +----------+ 4115 | subtype-p| 2 octets 4116 +----------+----------+ 4117 | ifindex | 4 octets 4118 +----------+----------+ 4119 | Slot | Port | 4120 .----------+----------+ 4121 | Speed | State | 4122 +---------------------+ 4124 Figure 59 Encoding Port data 4126 subType : (2 octets) Set to3 for Port Data 4128 RBridge: (2 octets) TRILL RBridge nickname [RFCtrill] 4130 Regiond-ID : (4 octets) unsigned 32 bit integer identifier of the 4131 region 4133 L : ( 1 octet), length of the subsequent field in octets. 4135 Region Name : '\0' terminated ASCII string of region name of 4136 variable size to maximum of 255 octets. 4138 F : (1 octet) Flag. When set, indicates this is the last Port data 4139 set from this node. It is possible Port data encoding to exceed MTU 4140 size due to large number of interfaces. The F flag allows to for 4141 advertising the information in multiple LSP packets. 4143 subtype-p: (2 octets) set to 5 to indicate that this is a single 4144 Port entry within subtype 3. SubType 5 MUST always be embedded with 4145 subtype 3. Within subtype 3 there can be multiple subtype 5, one for 4146 each port entry. 4148 Ifindex : (4 octets) 32 bit unsigned integer, used as key to port 4149 data advertised. 4151 Slot (2 octets) : Slot number 4153 Port (2 octets) : Port number 4154 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 4155 speeds less than 100Mbps. 4157 State (2 octets) : Represent the state of the port. 4159 0: Down - no errors 4160 1: Disable 4161 2: Forwarding-no errors 4162 3: Down - errors 4163 4: Forwarding - errors 4164 5: Forwarding - oversubscribed 4165 6: Link Monitoring disable 4166 All other values reserved. 4168 +----------+ 4169 | subType | 2 octets 4170 +----------+ 4171 | RBridge | 4172 +----+-----+ 4173 | F | 1 octets 4174 +----+-----+ 4175 | subtype-a| 2 octets 4176 +----------+ 4177 | nrBridge | 2 octets 4178 +----------+ 4179 | #ports | 2 octets 4180 +----------+----------+ 4181 | ifindex | 4 octets 4182 +---------------------+ 4183 . . 4184 +---------------------+ 4186 Figure 60 Encoding Adjacency Matrix 4188 subType : (2 octets) set to 4 for Adjacency Matrix 4190 RBridge: (2 octets) TRILL RBridge nickname [RFCtrill] 4192 Regiond-ID : (4 octets) unsigned 32 bit integer identifier of the 4193 region 4195 L : ( 1 octet), length of the region name in octets 4196 Region Name : '\0' terminated ASCII string of region name of 4197 variable size to a maximum of 255 octets. 4199 F : (1 octet) Flag. When set, indicates this is the last Port data 4200 set from this node. It is possible Port data encoding to exceed MTU 4201 size due to large number of interfaces. The F flag allows to for 4202 advertising the information in multiple LSP packets. 4204 subtype-a: (2 octets) set to 6 to indicates a single adjacency entry 4205 within subtype 4. SubType 6 MUST always be embedded with subtype 4. 4206 Within subtype 4, there can be multiple subtype 6, one for each 4207 adjacency. 4209 nrBRIDGE : (2 octets), nickname of the next hop RBridge 4211 #ports : (2 octets), total number of parallel links from RBridge to 4212 nrBRIDGE 4214 Ifindex : (4 octets) 32 bit unsigned integer, used as key to port 4215 data advertised. 4217 10.5. Vendor Specific Category 4219 Vendors may specify additional data elements to be distributed as 4220 part of the monitoring data suite. All vendor specific data elements 4221 MUST contain the regions name and follow the structure defined 4222 below. 4224 +----------+ 4225 | subType | 2 octets 4226 +----------+ 4227 | RBridge | 2 octets 4228 +----------+----------+ 4229 | Region-ID | 4 octets 4230 +---+-----------------+ 4231 | L | | 4232 .---+ . 4233 . Region Name . 4234 | | 4235 +----------+----------+ 4236 | Vendor OUI | 4 octets 4237 +---------------------+ 4238 | | 4239 . Vendor specific . 4240 . Information . 4241 | | 4242 +---------------------+ 4244 Figure 61 Encoding Vendor specific category Data 4246 subType : (2 octets) set to250 for Vendor specific category 4248 RBridge: (2 octets) TRILL RBridge nickname [RFCtrill] 4250 Regiond-ID : (4 octets) unsigned 32 bit integer identifier of the 4251 region 4253 L : ( 1 octet), length of the region name in octets 4255 Region Name : '\0' terminated ASCII string of region name of 4256 variable size to maximum of 255 octets. 4258 Vendor OUI : 3 octets of IEEE vendor OUI. Right justified. Most 4259 significant octet in network byte order is set to zero and ignored 4260 on recipt. 4262 Vendor specific information : variable size and vendor dependent. 4264 11. Traffic Triggered Monitoring (TTM) 4266 Identification and verification of faults as well as fault 4267 monitoring methods using simplified payload structures were 4268 presented in previous sections of this document. In practice some 4269 faults may be due to more complex relationship between several 4270 flows. The Traffic Triggered Monitoring methods presented in this 4271 section proposes methods to monitor and analyze traffic passing 4272 through different Test Points (TP) in the network. Additionally, 4273 some of the methods presented earlier require having one or more 4274 fields of the payload to be fixed to some known pattern. Use of 4275 known patterns in payloads, while adequate in many occasions, may 4276 not be adequate in other occasions. TTM allows operators to monitor 4277 and/or diagnose a network using actual live traffic, with minimum or 4278 no impact on actual data flow. The TTM Framework has the following 4279 components. 4281 TTM Profile: Is bound to a TTM Test Point (interface). Specify the 4282 structure of the data stream (i.e. MAC, IP address, VLAN etc) that 4283 need to be monitored and associated actions, frequency and duration. 4285 TTM Initiator: An RBridge or external station that initiates a TTM 4286 profile. 4288 TTM Receptor: An RBridge that installs and monitors TTM Profiles on 4289 a TP on behalf of a TTM Initiator. 4291 TTM Test Point (TP): An interface on a specified RBridge. 4293 TTM Messages: TTM Messages provides a messaging framework for TTM 4294 related inter RBridge communications. The TTM messaging framework is 4295 an extension to the OAM command messages. 4297 TTM ingress End Point: The TTM ingress End Point is the ingress 4298 RBridge of the specified flow. 4300 TTM egress End Point: The TTM egress End Point is the egress RBridge 4301 of the specified flow. 4303 <-- ---------------------> 4304 TTM Messages 4305 TTM Receptor-1 4306 +-----+ 4307 --------| RB3 |--------- 4308 | TP| | | 4309 TTM Initiator | +-----+ | 4310 +-----+ +-----+ TTM Receptro-2 +-----+ +-----+ 4311 | RB1 |------| RB2 | +-----+ | RB6 | | RB7| 4312 | | | |-----| RB4 |------| |-----| | 4313 +-----+ +-----+ TP| |TP +-----+ +-----+ 4314 TTM ingress EP | +-----+ | 4315 | TTM Receptor-3 | TTM egress EP 4316 | +-----+ | 4317 | TP| RB5 | | 4318 --------| |--------- 4319 +-----+ 4321 Figure 62 Traffic Triggered Monitoring 4323 11.1. TTM Policy 4325 The TTM policy is a high level container that defines rules and 4326 actions. The TTM policy contains several sections. 4328 o TTM pattern 4329 o TTM mask 4330 o TTM Class 4331 o TTM frequency 4332 o TTM count 4333 o TTM actions 4334 o TTM Test Point 4335 o TTM Ingress Point 4336 o TTM Egress Point 4338 TTM pattern: The TTM pattern can be either 128byte opaque data or 4339 set of fixed fields. The 128byte opaque data section allows users to 4340 define a required pattern. The TTM fixed fields are Dest MAC, Src 4341 MAC, VLAN, EthType, Src IP, Dest IP, TTL, Protocol Type, or Src/Dest 4342 UDP ports. 4344 TTM mask: The TTM mask allows users to further refine the pattern 4345 matching criteria. 4347 TTM Class: The TTM Class defines whether the TTM policy is Forward 4348 Flow Monitoring (FFM) or Reverse Flow Monitoring (RFM). Please see 4349 below for details. 4351 TTM frequency: TTM frequency defines the frequency of actions 4352 specified. 4354 TTM Count: TTM Count defines number of times the given TTM actions 4355 such as Capturing, Logging, Sampling and Injecting must be applied. 4356 Count is a 32bit unsigned integer. 1 indicates single instance. 4357 0xFFFF indicates continued application until the TTM is removed by 4358 user actions. 4360 TTM actions: TTM actions are 4362 o count RX frames 4363 o count TX frames 4364 o count RX bytes 4365 o count TX bytes 4366 o count errors, 4367 o log, 4368 o Capture etc. 4370 NOTE: TTM action counters are 64bits wide. Counter values may be 4371 distributed using the distribution framework, specified in section 4372 10. Distribution of counter values allows user to monitor statistics 4373 from any remote RBridge. 4375 Logging indicates logging a copy of the received frame in to a 4376 locally defined space. 4378 Capture indicates forwarding a copy of the frame matching the TTM 4379 policy to a remote destination. 4381 Implementation of logging and capture are outside the scope of the 4382 document. 4384 TTM Test Point: TTM Test Point is an interface on an RBridge where 4385 the specified TTM profile is applied. User may either specify one or 4386 more interfaces or specify automatic. The automatic scope indicates 4387 the Receptor RBridge will derive the Test Points using ingress and 4388 egress End Point specifications. 4390 TTM ingress End Point: TTM ingress End Point is the nickname of the 4391 ingress RBridge. 4393 TTM egress End Point: TTM egress End Point is the nickname of the 4394 egress RBridge. 4396 11.2. TTM Commands 4398 TTM commands: 4400 o TTM Set 4401 o TTM Get 4402 o TTM Remove 4403 o TTM Response 4404 o TTM Indications 4406 TTM Set message is OAM Message type 17. This message is originated 4407 by the Initiator to install a TTM profile. 4409 TTM Get message is OAM Message type 18. This message is originated 4410 by the Initiator to Get a TTM profile or sub component of a profile 4411 such as a counter. 4413 TTM Remove message is OAM Message type 19. This message is 4414 originated by the Initiator to Remove a TTM profile. 4416 TTM Response message is OAM Message type 20. This message is 4417 originated by the Receptor in response to one of the Set, Get or 4418 Remove messages. The Response message contains a message sub-code to 4419 indicate whether it is a response to a Set, Get or Remove message. 4420 It also contains the status code of the original request. 4422 TTM Indications are generated by the receptors in response to 4423 asynchronous events such as packet capture. 4425 TTM policies are encoded in to the OAM command messages using 4426 structures defined in section 8.2. 4428 Forward Flow Monitoring (FFM) 4430 The exact path taken by a given frame depends on the pattern of the 4431 payload. Forward Flow monitoring allows users to specify TTM 4432 profiles that match a specified policy in the direction of the 4433 normal traffic flow. i.e. Traffic ingress from the TTM ingress End 4434 Point and egress from the TTM egress End Point. 4436 11.3. Reverse Flow Monitoring (RFM) 4438 Traffic is bi-directional in nature. Any effective OAM solution 4439 should have methods to detect and monitor traffic flows in both 4440 forward and reverse directions. RFM allows users to: 4442 1. Monitor frames traversing in the reverse direction. That is 4443 frames traversing from TTM egress End Point to TTM ingress End 4444 Point. 4446 2. Inject a given data frame from a specified RBridge (RBe) to 4447 (RBi). The TTM policy contains additional user data field that 4448 specify the frame that is to be injected from RBe to RBi. 4450 12. Security Considerations 4452 Security considerations are under investigation. 4454 13. IANA Considerations 4456 13.1. IANA considerations 4458 Following IANA considerations are required 4460 13.1.1. ICMP Extensions 4462 Request IANA to assign new Class-Num for TRILL OAM ICMP extensions. 4464 Request to form a sub-registry under ICMP extensions to include c- 4465 types defined in this document and allocate future requests. 4466 Currently c-types 1-20 are defined in section 8.2. 4468 13.1.2. TRILL-OAM UDP port 4470 Request IANA to assign a well-known UDP port for the purpose of 4471 TRILL-OAM. Details of usage of well-known UDP port are presented in 4472 section 4.3.1. 4474 13.1.3. ARP Extensions 4476 Request IANA to form a new registry to allocate ARP extensions 4477 defined in section 9.6.1. . Class-Num allocated within ARP 4478 extensions are allocated by IANA on first come first serve basis. C- 4479 type within a given Class-Num are defined by owners of the Class-Num 4480 and sub-registry MUST be established within ARP extensions. 4482 13.1.4. Well known Multicast MAC 4484 Request IETF authority to allocate one of the TRILL allocated 4485 Multicast MAC address (01-80-C2-00-00-43 to 01-80-C2-00-00-4F)for 4486 the purpose. 4488 13.2. IEEE Registration Authority Consideration 4490 Well known unicast MAC address for the purpose of identifying OAM 4491 frames. 4493 Well known unciast MAC address for the purpose of identifying 4494 certain OAM frames. 4496 EthType for the purpose of identifying OAM frames. 4498 14. References 4500 14.1. Normative References 4502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4503 Requirement Levels", BCP 14, RFC 2119, March 1997. 4505 [RFC6325] Perlman, R. et.al. "Routing Bridges (RBridges): Base 4506 Protocol Specification", RFC 6325, July 2011. 4508 [RFC6326] Eastlake, Donald. et.al. "Transparent Interconnection of 4509 Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. 4511 [RFC6327] Eastlake, Donald. et.al. "Routing Bridges (RBridges): 4512 Adjacency", RFC 6327, July 2011. 4514 [RFC6165] Barnajee, A. and Ward, D." Extensions to IS-IS for Layer-2 4515 Systems", RFC 6165, April 2011. 4517 [GenApp] Ginsberg, L. et.al. "Advertising Generic Information in 4518 IS-IS", draft-ietf-isis-genapp-04.txt, November,2010. 4520 [RFC4884] Bonica, R. et.al "Extended ICMP to support Multi-Part 4521 messages",RFC 4884, April, 2007. 4523 [RFC4379] Kompella, K, and Swallow, G. "Detecting Multi-Protocol 4524 Label Switched (MPLS) Data Plane Failures", RFC 4379, 4525 February, 2006. 4527 [TRILLCH] Eastlake, Donald. et.al. "RBridges: TRILL RBridge Channel 4528 Support", draft-ietf-trill-channel-02.txt, Work in 4529 Progress, July, 2011. 4531 [TRILLOAM] Bond, D. and Manral, V. "RBridges: Operations, 4532 Administration and Maintenance (OAM) Support", draft-ietf- 4533 trill-rbridge-oam-00.txt, Work in Progress, July, 2011. 4535 [PINGEXT] Shen, N. et.al. "Traceroute and Ping Message Extensions", 4536 draft-shen-traceroute-ping-msg-ext-03.txt, Work in 4537 Progress, October, 2011. 4539 [ISISMI] Previdi, S. et.al. "IS-IS Multi-Instance", draft-ietf-isis- 4540 mi-05.txt, Work in Progress, October, 2011. 4542 14.2. Informative References 4544 [RFC792] Postel, J. "Internet Control Message Proctocol (ICMP)", 4545 RFC 792, September, 1981. 4547 [RFC826] Plummer, D. "Address Resolution Protocol", RFC 826, 4548 November, 1982. 4550 [RFC2390] Bradley, T. et.al. "Inverse Address Resolution Protocol", 4551 September, RFC 2390, 1988. 4553 [RFC5226] Narten, T. and Alverstand, H. "Guidelines for writing an 4554 IANA sections in RFCs", RFC 5226, May 2008. 4556 15. Acknowledgments 4558 Authors wish to thank people who volunteered to review this document 4559 and provided comments. Les Ginsberg provided guidance, comments and 4560 support in defining usage of GenApp and ISIS-MI. Carlos Pignataro 4561 and Naiming Shen provided valuable comments related to ICMP 4562 extensions. 4564 This document was prepared using 2-Word-v2.0.template.dot. 4566 Appendix A. Reports 4568 A.1. Sample Reports 4570 In this section we present sample reports of summary data and sample 4571 output of detail data. 4573 A.2. Summary Report 4575 Region Number Max ECMP Total# % of Up %of Ports Err 4576 of switches Of Ports Ports Oversubscribed Ports 4577 xxx 40 16 400 100 10 1 4578 yyy 8 2 25 75 6 0 4579 A.3. Detail Report 4581 Region Name : 4583 Total Number of Switches in the region : 10 4584 Total Number of Core Ports in the region : 16 4585 Number of Operationally up Core Ports : 14 4586 Number of Oversubscribed Core Ports : 2 4587 Number of Error Core Ports : 0 4589 Maximum Switch Up Time : 15days:8Hr:10M:0S 4590 Minimum Switch Up Time : 0days:0Hr:1M:0S 4592 Switch Adjacency Matrix: 4594 (*) oversubscribed Links 4595 (x) down Links 4596 (?) error Links 4598 Switch Next Hop switch Interfaces 4599 S1 S2 eth81,eth8/2(*),eth81 4600 eth 10/2(x) 4602 S3 eth5/1 (?) 4604 S4 eth5/2,eth7/1 4606 S2 S1 eth4/1,eth4/2,eth3/1 4607 eth3/2(x) 4609 A.4. C-Type usage in messages 4611 The Table below lists various OAM messages and applicable mandatory 4612 and optional c-types. 4614 +------------------+---------------------+------------------+ 4615 | Message | Mandatory Parameters|OptionalParameters| 4616 +------------------+---------------------+------------------+ 4617 |Loopback Request | Version (1) | VLAN (4) | 4618 | | | Service Tag (23) | 4619 | | | Out-of-band | 4620 | | | request Flag (1) | 4621 | | | Reverse Path (26)| 4622 | | | Control Plane | 4623 | | | Verification (24)| 4624 | | | Originator | 4625 | | | IP address (2)| 4626 +------------------+---------------------+------------------+ 4627 |Loopback Response |Version (1) |Reverse Path | 4628 | |Cross Connect Error |Response (27)| 4629 | |Flag (1) |Control Plane | 4630 | |Final Flag (1) |Response (25)| 4631 +------------------+---------------------+------------------+ 4632 |Path Trace | Version (1) |VLAN (4) | 4633 |Request | |Service Tag (23)| 4634 | | |Out-of-band | 4635 | | |request flag (1) | 4636 | | |Reverse Path (26)| 4637 | | |Control Plane | 4638 | | |Verification (24)| 4639 | | |Originator | 4640 | | |IP address (2) | 4641 +------------------+---------------------+------------------+ 4642 |Path Trace |Version (1) |Reverse Path | 4643 |Response |Cross Connect Error |Response (27)| 4644 | |Flag (1) |Control Plane | 4645 | |Final Flag (1) |Response (25)| 4646 | |Upstream | | 4647 | |Identification (2)| | 4648 | |Downstream | | 4649 | |Identification (5)| | 4650 | |Path of this | | 4651 | |Payload (6)| | 4652 +------------------+---------------------+------------------+ 4654 Figure 63 Optional and Mandatory c-types 4656 +------------------+---------------------+------------------+ 4657 |Message |Mandatory Parameters |OptionalParameters| 4658 +------------------+---------------------+------------------+ 4659 |Multicast Tree |Version (1)|VLAN (4) | 4660 |Verification | |Service Tag (23)| 4661 |Request | |In Scope (14)| 4662 | | |Control Plane | 4663 | | |Verification (24)| 4664 | | |Originator | 4665 | | |IP address (2) | 4666 +------------------+---------------------+------------------+ 4667 |Multicast Tree |Version (1) |Control Plane | 4668 |Verification |Cross Connect Error |Response (25)| 4669 |Response |Flag (1) | | 4670 | |Final Flag (1) | | 4671 | |Upstream | | 4672 | |Identification (2) | | 4673 | |Multicast Tree | | 4674 | |Downstream List (15) | | 4675 | |RBridge nickname(35) | | 4676 +------------------+---------------------+------------------+ 4678 Figure 64 Optional and Mandatory c-types 4680 Authors' Addresses 4682 Tissa Senevirathne 4683 CISCO Systems 4684 375 East Tasman Drive, 4685 San Jose, CA 95134 4687 Phone: 408-853-2291 4688 Email: tsenevir@cisco.com 4689 Dinesh G Dutt 4690 CISCO Systems 4691 3800 Zankar Road 4692 San Jose, CA 95134 4694 Email: ddutt@cisco.com 4696 Vishwas Manral 4697 Hewlett-Packard Co. 4698 19111 Pruneridge Ave. 4699 Cupertino, CA 95014 4701 Phone: 408-447-0000 4702 EMail: vishwas.manral@hp.com 4704 Sam Aldrin 4705 Huawei Technologies 4706 2330 Central Express Way 4707 Santa Clara, CA 95951 4709 Email: aldrin.ietf@gmail.com