idnits 2.17.1 draft-rohit-trill-proactive-oam-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 179 has weird spacing: '...on then all p...' == Line 265 has weird spacing: '...nitiate the t...' == Line 501 has weird spacing: '... number for a...' == Line 614 has weird spacing: '...name of the n...' == 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 data not found 2. System overloaded try later 3. -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: 0. Success 1. ECMP data not found 2. System overloaded try later 3. Not availabe 4. 4-7 Reserved MUST not be used -- The document date (September 17, 2013) is 3867 days in the past. Is this intentional? 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: 'RFCtrill' is mentioned on line 615, but not defined == Unused Reference: 'RFC6326' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC4884' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 735, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 738, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) -- Possible downref: Non-RFC (?) normative reference: ref. 'TRILLOAM' Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL working Group Rohit Watve 2 Internet Draft Tissa Senevirathne 3 Intended status: Standards Track Chandan Mishra 4 CISCO 5 Gayatri Ramachandran 6 ARISTA Networks 7 September 17, 2013 8 Expires: March 2014 10 Pro-active connectivity monitoring for TRILL 11 draft-rohit-trill-proactive-oam-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 18, 2009. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 Pro-active fault monitoring for TRILL monitors all the paths between 54 any two given RBridges in the network. Number of paths to be 55 monitored can be of exponential order based on the distance between 56 two RBridges. In this document novel fault monitoring mechanism 57 based on a distributed approach is presented. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Conventions used in this document..............................3 63 3. Motivation.....................................................3 64 4. Solution overview..............................................6 65 4.1. Details for monitoring paths upto 2nd hop Rbridge.........8 66 5. Frame formats..................................................9 67 5.1.1. Pro-active fault monitoring request..................9 68 5.1.2. Pro-active Payload discovery request................10 69 5.1.3. Pro-active Payload discovery response...............12 70 5.1.4. Pro-active fault notification.......................13 71 6. Formal Syntax.................................................16 72 7. Security Considerations.......................................16 73 8. IANA Considerations...........................................16 74 9. Conclusions...................................................16 75 10. References...................................................16 76 10.1. Normative References....................................17 77 10.2. Informative References..................................17 78 11. Acknowledgments..............................................17 79 Appendix A. Sample report........................................19 80 A.1. Summary Report per monitor...............................19 81 A.2. Detail Report............................................19 82 A.2.1.

................................................20 83 A.2.1.1.

...........................................20 84 A.2.1.1.1.

......................................20 85 A.2.1.1.1.1.

.................................20 86 A.3. C type usage is messages.................................20 88 1. Introduction 90 Pro-active fault monitoring is necessary for all OAM solutions. It 91 gives network service providers confidence about the health of their 92 network. Whenever network service is provided to customers with SLA 93 (Service Level Agreement), it becomes even more important to monitor 94 the network pro-actively. In traditional Layer-2 networks (CE) pro- 95 active fault monitoring is done based on VLANs. Since spanning-tree 96 ensures that there is a single path between any two nodes, it is 97 straightforward mechanism to monitor path between 2 given RBridges 98 and given VLAN. 100 TRILL Base Protocol Specification [RFC6325] provides a method for 101 forwarding Layer 2 data frames over multiple active links. There can 102 be number of ECMPs (Equal Cost Multiple Paths) between any two given 103 TRILL RBridges. As the number of hops between given two RBridges 104 increases, number of ECMPs increases exponentially. Pro-active 105 monitoring in this case needs to monitor all the ECMPs between two 106 given RBridges. 108 TRILL OAM draft [TRILLOAM] proposes OAM suite for TRILL. This draft 109 is for adding pro-active functionality to the OAM suite. It extends 110 C-types defined in TRILL OAM draft, for pro-active monitoring. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC-2119 [RFC2119]. 118 3. Motivation 120 As we discussed in the introduction, number of paths to be tested 121 increases exponentially as the number of hops between ingress and 122 egress RBridge increases. Identifying the header parameters 123 (mac/IP/L4 addresses) to exercise each unique path is a hard problem 124 and needs information about hashing functions from each intermediate 125 RBridge. 127 Sending test packets, with random header parameters, expecting that 128 will exercise different ECMPs is one option. But in this case number 129 of packets that need to be sent can be even higher than total number 130 of ECMPs. 132 In this document we take a different approach to address this 133 problem. 135 Testing end-to-end connectivity means, testing connectivity of all 136 links along the path as well as exercising switching on all 137 intermediate RBridges. Instead of doing it end to end, same can be 138 done after splitting it into multiple short paths, such that, paths 139 overlap to cover complete end-to-end connectivity. If each such 140 short path is limited only to two hops, it brings down number of 141 packets to be sent from exponential order of number of hops (k^n) to 142 order of (k^3)*n, where k is assumed to be number of ECMPs for each 143 hop for simplification of calculation and n is number of hops 144 between the Ingress and Egress RBridges. 146 Consider following Figure 1. In the figure, Rbridges are numbered 147 from 1 to 10. The problem is to monitor end-to-end connectivity 148 between Rbridge 1 and 10. 150 +------------------------------------------------+ 151 | | 152 | +-+ +-+ +-+ +-+ +-+ +--+ | 153 | |1|--|2|---|4|---|6|---|8|--|10 | | 154 | +-+ +-+ +-+ -+-+ +-+ +--+ | 155 | | \ / \ / \ / | | 156 | | \ \ \ | | 157 | | / \ / \ / \ | | 158 | | +-+ +-+ +-+ +-+ | | 159 | +---|3|---|5|---|7|---|9|---+ | 160 | +-+ +-+ +-+ +-+ | 161 | | 162 +------------------------------------------------+ 164 Figure 1 Example network. 166 In above Figure 1, RBridges 2 and 3 are connected to RBRidges 4 and 167 5, RBridges 4 and 5 are connected to RBridges 6 and 7. Rbridges 6 168 and 7 are connected to RBridges 8 and 9. 170 Total number of ECMPs between RBridge 1 and RBridge 10 is - 171 2x2x2x2x2 = 32 173 Hence Rbridge 1 will need to send 32 packets to test all ECMPs to 174 Rbridge 10, assuming Rbridge 1 knows payloads required to exercise 175 all these paths. 177 Above network can be split into four overlapping sections as shown 178 in Figure 2 and Figure 3. If we test all paths between Ingress and 179 Egress Rbridges of each section then all paths between 1 and 10 180 will be tested. 182 +------------------------------------------------+ 183 | | 184 | +-+ +-+ +-+ +-+ +-+ +-+ | 185 | |1|--|2|---|4| |2|---|4|--|6| | 186 | +-+ +-+ +-+ +-+ +-+ +-+ | 187 | | \ / \ / \ / | 188 | | \ \ \ | 189 | | / \ / \ / \ | 190 | | +-+ +-+ +-+ +-+ +-+ | 191 | +---|3|---|5| |3|---|5|--|7 | | 192 | +-+ +-+ +-+ +-+ +-+ | 193 | | 194 | section1 section2 | 195 | | 196 | path tested 4 paths tested 8 | 197 | | 198 +------------------------------------------------+ 200 Figure 2 Section 1 and 2 for network in Fig.1 202 +------------------------------------------------+ 203 | | 204 | +-+ +-+ +-+ +-+ +-+ +--+ | 205 | |4|--|6|---|8| |6|---|8|--|10| | 206 | +-+ +-+ +-+ +-+ +-+ +--+ | 207 | \ / \ / \ / | | 208 | \ \ \ | | 209 | / \ / \ / \ | | 210 | +-+ +-+ +-+ +-+ +-+ | | 211 | |5|--|7|---|9| |7|---|9|-- + | 212 | +-+ +-+ +-+ +-+ +-+ | 213 | | 214 | section3 section4 | 215 | | 216 | path tested 8 paths tested 4 | 217 | | 218 +------------------------------------------------+ 220 Figure 3 Section 3 and 4 for network in Fig.1 222 In Figure 2, for the section 1, the number of paths between RBridges 223 1 and 4 is 2 and number of paths between RBridges 1 and 5 is 2. 224 Hence total number of paths to be tested for sub-network1 is 4. 226 Similarly, number of paths between RBridges 2 and 6 is 2, between 227 RBridges 2 and 7 is 2. Number of paths between RBRidges 3 and 6 is 2 228 and between RBridges 3 and 7 is 2. 230 Hence total number of paths to be tested is 8. 232 Similarly from Figure 3. total number paths to be tested for 233 section3 is 8 and for section 4 is 4. 235 Note that, in the above example network, maximum number of paths to 236 be tested by any given Rbridge is limited to 8. Hence load of 237 monitoring network is now distributed. Also total number of paths 238 tested is 4+8+8+4=24. 240 Note that if Rbridge 1 was to do testing for all paths, number of 241 paths to be tested would be 32. As the complexity of the network 242 increases and number of paths between Ingress and Egress Rbridges 243 increases, the mechanism proposed here will yield even more 244 benefits. 246 4. Solution overview 248 Here we present high level overview of the solution. More details 249 are discussed in the subsequent sections. 251 Pro-active fault monitoring is initiated by the user. As part of the 252 request, user identifies a VLAN and 2 RBridges - Ingress and Egress 253 Rbridges. All Equal Cost Paths ECMPs on this vlan and between these 254 two RBridges need to be monitored. User provides total time interval 255 for monitoring session as the part of the request. 257 Here are the high-level steps of the mechanism 259 1. Ingress Rbridge starts connectivity tests for paths upto its 2nd 260 hop Rbridge(s)(on the path to egress RBridge). 262 2. If 2nd hop Rbridge is egress Rbridge, it stops the test. 264 3. Else it requests its 1st hop Rbridge(s) (on the path to egress), 265 to initiate the tests, starting with step1. 267 Once the request is distributed, whenever a fault is detected, it is 268 indicated to the Originator Rbridge using a fault notification 269 message which includes fault details. 271 Consider Figure 4 as example network. Let us assume user requests 272 proactive fault monitoring between ingress RBridge RB1 and egress 273 RBridge RB5. P1 to P5 are the Egress ports along the ECMPs netween 274 RB1 and RB5. 276 +------------------------------------------------+ 277 | | 278 | | 279 | | 280 | RB1 RB2 RB3 RB5 | 281 | +---+ +---+p3 +---+ +---+ | 282 | | |p1 | o----| |p4 | | | 283 | | o----o | | o----o | | 284 | +---+ +-o-+ +---+ +-o-+ | 285 | |p2 | | 286 | | | | 287 | | RB4 | | 288 | | +---+ p5 | | 289 | | | o------| | 290 | |------o | | 291 | +---+ | 292 | | 293 | | 294 +------------------------------------------------+ 296 Figure 4 Example network. 298 As per step1, RB1 tests all paths upto its 2nd hop Rbridge on the 299 path along RB5. 301 For that, RB1 sends 'payload request' message to its 1st hop 302 Rbridges on the path along RB5. RB1 looks up its local forwarding 303 table, and finds that p1 is Egress port for path towards RB5. It 304 then sends 'payload request' with TTL=1 on p1. RB2, will reply back 305 with 2 payloads say PL1 and PL2, for taking path along ports p3 and 306 p2, respectively. 308 RB1 now sends two packets with payloads PL1 and PL2, and TTL=2. When 309 RB1 receives 'hop count expiry' message for both, it confirms that 310 paths up to its 2nd hop Rbridge(s) are fault-free( i.e. paths 311 between RB1 and RB3 , as well as between RB1 and RB4 are fault- 312 free). 314 As per step3, RB1 also forwards the 'pro-active fault monitoring 315 request' message defined in section 5.1.1, to monitor connectivity, 316 to its 1st hop Rbridges along the path. It does so by sending 317 request with TTL=1, on port p1. 319 RB2 on receiving this request, will repeat the step1. It will send 320 'payload request' with TTL=1, on port p2 and p3. For each request, 321 it will get one payload, say PL3 for request sent on p2 and PL4 for 322 request sent on p2. It will test paths upto its 2nd hop Rbridges, by 323 sending a packet with payload PL3 on port p2 and a packet with 324 payload PL4 on port p3 and TTL=2. 326 As RB2 will receive 'hop count expiry' message from RB5, it will not 327 forward the requests for monitoring paths till RB5, to its 1st hop 328 Rbridges. 330 4.1. Details for monitoring paths upto 2nd hop Rbridge 332 For a given egress TRILL RBridge, local TRILL routing table can 333 provide information about different next hop RBridges/Egress ports 334 to exercise the ECMPs. 336 We propose to send 'Payload Discovery request' message on each of 337 these ports, with TTL=1. 'Payload Discovery request' (section 338 5.1.1. ) message carries information about egress TRILL RBridge 339 (RB5) in the original request made by the user. 341 Based on the egress RBridge (RB5), each 1st hop Rbridge looks up its 342 TRILL forwarding tables, and for each equal cost multi path towards 343 egress RBridge (RB5) identifies a unique inner destination MAC 344 adresses, that will exercise the ECMPs towards egress Rbridge-id. 345 These MAC addresses will be sent back in a 'Payload Discovery 346 response packet'. 348 The source mac address is not used for payload generation, as it 349 might be learnt by other Rbridge, if the packets are originated by 350 TRILL Edge Rbridges. Well known source mac address is used, so that 351 it will not be used by any real data packets. Ethtype is fixed to 352 TRILL OAM Diagnostic ethtype to restrict these frames from leaving 353 TRILL network (refer section 6.2, from [TRILLOAM]). VLAN is 354 specified by the user as a part of the request. For payload 355 generation, nickname of the requester Rbridge, provided in 'payload 356 generation request'(section 5.1.2), is used as ingress Rbridge 357 nickname. Egress Rbridge nickname provided in the request is used as 358 Egress Rbridge nickname for payload generation. 360 The current TRILL RBridge, receives list of destination mac 361 addresses on each port on ECMP. It constructs 'loopback message' 362 (TRILLOAM) message with TTL=2 and these mac addresses as inner 363 destination mac addresses and sends these on ports on which 364 corresponding mac address was received. 366 Each packet sent, will now test the switching at next hop and test 367 all links on the path taken by the packet. The inband or out of band 368 ICMP 'hop count expiry response' (TRILLOAM), will confirm that both 369 are fault-free. When all such responses are received, it will 370 confirm that all paths towards egress Rbridge are error free, till 371 2nd hop. If there is a fault, fault details are sent to the 372 originator Rbridge. If current Rbridge itself is the originator 373 Rbridge, it saves the fault information. 375 Payload generation request is sent periodically based on the 376 'Payload generation request time interval' specified in the user 377 request. Test packets are also sent at an 'test time interval' 378 provided by the user. Finally this whole monitoring process is 379 continued till the 'Monitor time interval', also specified by the 380 user. 'Pro-active fault monitoring request' defined in next section 381 is used for forwarding the request to 1st hop Rbridges. 383 5. Frame formats 385 5.1.1. Pro-active fault monitoring request 387 Pro-active fault monitoring request includes C-type 44 which 388 provides Egress Rbridge ID and originator Rbridge ID. It also 389 provides information about timers required in fault monitoring. C- 390 type 4 (interested vlan) is included in the request to indicate 391 monitored vlan, if the request packet is not using the same vlan. 392 Source Mac address and ethtype are fixed to the values used in the 393 request packet. Pro active fault monitoring message is represented 394 by TRILL OAM message code 26. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | egress nickname | originator nickname | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | ingress nickname | Reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |S|G| Reserved | MonitorId | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Monitor interval | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Payload Generation Interval | test interval | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 5 Pro-active fault monitoring request details (C-type 44) 412 Egress nickname (2 octets): nickname of the Egress/egress Rbridge. 414 Originator nickname (2 octets): nickname of the originator Rbridge. 416 Ingress nickname (2 octets): nickname of the ingress Rbridge. 418 S (1 bit),start/stop request: if set to 1, specifies request to 419 start monitoring, if set to 0, specifies request to stop monitoring. 421 G (1bit); Global stop, when set to 1, stops all pro-active 422 monitoring requests on this Rbridge requested by same Originator 423 RBridge, irrespective of other information in the C-type. Set to 1 424 only for debugging. 426 Reserved (14 bits): 428 MonitorId (16bits): Identifier for the current session. It is 429 generated by Originator Rbridge such that it is unique locally, and 430 propogated while forwarding request to next hops. MonitorId, 431 combined with Originator Rbridge ID, forms unique identifier for 432 fault monitoring session. 434 Monitor interval (4octets): total interval of fault monitoring 435 session in seconds. 0 is a special value, indicating it needs to run 436 till request to stop comes. 438 Payload Generation Interval(2 octets): interval for refreshing 439 payload parameters by sending payload generation request in seconds. 441 Test interval (2 octets): interval for sending test packets with 442 TTL=2, for testing paths till 2nd hop in seconds. 444 5.1.2. Pro-active Payload discovery request 446 C-type 'Payload discovery request for pro-active monitoring' is 447 different from Payload Discovery request defined in section 8.2 in 448 [TRILLOAM]. This C-type by definition allows use of any Destination 449 Mac address for payload generation. It also expects that response 450 will include payloads for exercising all available ECMPs. Along with 451 this new type, interested vlan (ctype 4) is also specified, if 452 packet is not using same vlan. Source Mac address and ethtype are 453 fixed to the values used in the request packet. Payload discovery 454 message is represented by TRILL OAM message code (22). 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | egress nickname | originator nickname | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | ingress nickname | Requester nickname | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 6 Pro-active Payload Discovery request (C-type 45) 466 Egress nickname (2 octets): nickname of the Egress Rbridge provided 467 by user (used as Egress Rbridge nickname for payload generation). 469 Originator nickname (2 octets): nickname of the originator Rbridge. 471 Ingress nickname (2 octets): nickname of the ingress Rbridge. 473 Requester nickname (2octets): nickname of the Rbridge sending this 474 request (Used as Ingress nickname for payload generation). 476 5.1.3. Pro-active Payload discovery response 478 'Payload generation response for Proactive monitoring' specifies one 479 or more Destination MAC addresses, one for each ECMP. Its uses new 480 C-type 46 which lists down destination mac addresses (DMAC1, 481 DMAC2..DMACn where n is number of ECMPs). TRILL OAM code is set to 482 payload generation response (23). 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | egress nickname | S | ECMP count | R | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-^- 489 | DMAC1 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 491 | DMAC1 | next hop nickname | R 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 493 | ifindex | p 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 495 | Port | Slot | a 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 497 | State | Speed | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-v- 499 : : 500 : DMAC and Next hop path information (from ifindex to speed) : 501 : repeated for number for all ECMPs. : 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 7 Pro-active Payload Discovery Response(C-type 46) 506 Egress nickname (2 octets): nickname of the Egress Rbridge. 508 S (3 bits) : indicates the status 510 0. Success 511 1. ECMP data not found 512 2. System overloaded try later 513 3. -7 Reserved MUST not be used 515 ECMP count(8bit) - specifies number of ECMPs 517 DMAC1- DMACn - Destination mac addresses, (number of MAC addresses 518 is equal to number if ECMP count). 520 Next hop nickname ( 2 octets): nickname of the next hop Rbridge, to 521 which packet will be forwarded if Destination mac given with this 522 field is used. 524 Ifindex (4 octets) : unsigned integer of local significance 526 Slot (2 octets) : Slot number 528 Port (2 octets) : Port number 530 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 531 speeds less than 100Mbps. 533 State (2 octets) : Represent the state of the port. 535 0: Down - no errors 537 1: Disable 539 2: Forwarding-no errors 541 3: Down - errors 543 4: Forwarding - errors 545 5: Forwarding - oversubscribed 547 6: Link monitoring disable 549 All other values reserved. 551 Total number of DMAC and next hop path information entries MUST 552 be equal to ECMP count. 554 5.1.4. Pro-active fault notification 556 Fault details are sent to the originator Rbridge provided in the 557 'proactive monitoring request' by including C-type 47 (downstream 558 identification for pro-active monitoring). 560 C type 47 gives information about interface on which connectivity 561 test failed, i.e, hop count expiry message was not received. 563 If 'payload discovery generation response', had succeeded, one more 564 copy of C_type 47 is included in the pro-active fault notification. 565 The fields in this entry, are copied from the 'payload discovery 566 generation response'. If connectivity was being tested using DMAC3 567 (DMAC provided in the 3rd entry in payload discovery response), the 568 details of the interface provided with the DMAC3 will be used in 569 this instance of C type 47. 571 The notification can be sent either inband or out of band. TRILL OAM 572 code is set to parameter problem notification (5). 574 0 31 575 +----------------------+-------------------+ 576 | S | Reserved1 | responder-nickname| 577 +----------------------+-------------------+ 578 | Local nickname | next hop nickname| 579 +----------------------+-------------------+ 580 | ifindex | 581 +----------------------+-------------------+ 582 | Port | Slot | 583 +----------------------+-------------------| 584 | State | Speed | 585 +----------------------+-------------------+ 587 Figure 8 downstream identification for pro-active monitoring (C-type 588 47) 590 Responder nickname (16 bits): TRILL 16 bit nickname of responder 591 RBridge [RFCtrill] 593 S (3 bits): 'Payload discover generation response' status from 594 section 5.1.3. If Status is not Success, remaining fields below can 595 be set to 0. 597 0. Success 598 1. ECMP data not found 599 2. System overloaded try later 600 3. Not availabe 601 4. 4-7 Reserved MUST not be used 603 ECMP count (8 bits): Copied from for 'payload generation response', 604 if Status was 'Success'. 606 Reserved1 (13 bits): Reserved, set to zero on transmission and 607 ignored on receipt. 609 Next-hop neighbor information: 611 Local Nickname (16 bits): TRILL 16 bit nickname of the local 612 RBridge [RFCtrill] 614 Next hop Nickname (16 bits): TRILL 16 bit nickname of the next 615 hop RBridge[RFCtrill] 617 Slot (2 octets) : Slot number 619 Port (2 octets) : Port number 621 Speed (2 octets) : Speed in 100Mbps. Zero (0) indicates port 622 speeds less than 100Mbps. 624 State (2 octets) : Represent the state of the port. 626 0: Down - no errors 628 1: Disable 630 2: Forwarding-no errors 632 3: Down - errors 634 4: Forwarding - errors 636 5: Forwarding - oversubscribed 638 6: Link monitoring disable 640 All other values reserved. 641 st 1 instance of C-type 47 gives information about interface 642 connecting local Rbridge and 1st hop Rbridges. 644 If 'payload generation response' status (section 5.1.3), was 645 SUCCESS, one more instance of C-type 47 is also included as part of 646 'pro-active fault notification. 648 2nd instance of C-type 47 gives information about interface 649 connecting 1st hop Rbridge and 2nd hop Rbridges, that 'loopback 650 message' (TRILLOAM) message would have encountered, if connectivity 651 test was successful (i.e if hop count expiry message was received 652 from 2nd hop Rbrige). 654 If 'loopback message' message (TRILLOAM) used Destination Mac 655 address provided in the nth entry of 'payload generation response' 656 (section 5.1.3), 2nd instance of Ctype 47 will include interface 657 information provided in that particular entry. In this instance of 658 C-type 47, Status is set to 3 (not available). 660 6. Formal Syntax 662 INFO (REMOVE): Include this section only if needed. Commonly used 663 grammar is BNF grammar defined in RFC-2234. Suggested wording. 665 The following syntax specification uses the augmented Backus-Naur 666 Form (BNF) as described in RFC-2234 [RFC2234]. 668 670 7. Security Considerations 672 INFO (REMOVE): Every draft MUST have a Security Considerations 673 section. 675 Security consideration for pro-active monitoring are similar to 676 TRILL OAM draft [TRILLOAM]. Request/response packet can not go out 677 of the TRILL cloud, as TRILL OAM ethtype packets are dropped at the 678 Edge Rbridge. Since Pro-active monitoring request can be issued only 679 at a TRILL Rbridge, consideration is needed only for ensuring packet 680 with TRILL OAM ethtype and c-type 43 is dropped at Ingress Rbridge. 682 8. IANA Considerations 684 INFO (REMOVE): Every draft MUST have an IANA Considerations 685 section, although it may be removed prior to publication by the RFC 686 Editor if null. 688 690 9. Conclusions 692 694 10. References 696 INFO (REMOVE): Authors can use either the auto-numbered references 697 OR the named references; typically, these would not be mixed in a 698 single document. This template includes both examples for 699 illustration of the two variations. Named references are preferred 700 (e.g., [RFC2119] or [Fab1999]. 702 10.1. Normative References 704 INFO (REMOVE): Normative refs are references to standards documents 705 **required** to understand this doc. These are usually Standards- 706 track and BCP RFCs, or external (IEEE, ANSI, etc.) standards, but 707 may include other publications. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 713 Syntax Specifications: ABNF", RFC 2234, Internet Mail 714 Consortium and Demon Internet Ltd., November 1997. 716 [RFC6325] Perlman, R. et.al. "Routing Bridges (RBridges): Base 717 Protocol Specification", RFC 6325, July 2011. 719 [RFC6326] Eastlake, Donald. et.al. "Transparent Interconnection of 720 Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. 722 [RFC4884] Bonica, R. et.al "Extended ICMP to support Multi-Part 723 messages",RFC 4884, April, 2007. 725 [TRILLOAM] Senevirathne, T. et.al., "ICMP based OAM solution for 726 TRILL", work in progress, January 2012. 728 10.2. Informative References 730 INFO (REMOVE): Informative refs are those that are not standards or 731 standards not required to understand this doc. These are usually 732 informative RFCs, internet-drafts (avoid if possible), and other 733 external documents. 735 [RFC792] Postel, J. "Internet Control Message Proctocol (ICMP)", 736 RFC 792, September, 1981. 738 [1] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 739 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 740 1583. 742 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 743 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 744 pp. 1573-1583. 746 11. Acknowledgments 748 749 INFO (REMOVE): The author of this template would appreciate if you 750 would keep the following line in your final IDs and RFCs: 752 This document was prepared using 2-Word-v2.0.template.dot. 754 Appendix A. Sample report 756 INFO (REMOVE): Starts on a new page. These are optional. 758 INFO (REMOVE): Careful with headers in appendices - they won't 759 renumber when moved in/out levels in outline mode. Only Headers 1-9 760 do that trick, as used in the body of the RFC! 762 A.1. Summary Report per monitor 764 Monitor Vlan: 766 Monitor paths to RbridgeID: 768 Monitor Id: 770 Monitoring for time: x days x hours x minutes x seconds 772 Total Faults reported : x faults 774 Faulty paths detected (RbridgeId1 to RbridgeId3) 776 (RbridgeId1/Interface)-> (RbridgeId2/Interface)->RbridgeId3 778 S1/eth3/2 S2/eth4/5 S3 780 S4/eth5/2 S5/eth4/5 S3 782 784 A.2. Detail Report 786 Fault detection log: 788 2012 Jan 31 13:50:34 Fault at (S1/eth3/2,S2) "ECMP information not 789 found" for monitor to S7, vlan 2, MonitorId 10. 791 2012 Jan 31 13:51:24 Fault at (S4/eth5/2,S5/eth4/5,S3) "Packet flow 792 test failed" for monitor to S8, vlan 1, MonitorId 3. 794 2012 Jan 31 13:52:24 Fault at (S4/eth5/2,S5/eth4/5,S3)"Packet flow 795 test failed" for monitor to S8, vlan 1, MonitorId 3. 797 A.2.1.

799 801 A.2.1.1.

803 805 A.2.1.1.1.

807 809 A.2.1.1.1.1.
811 813 A.3. C type usage is messages 815 +----------------------+--------------------+---------------------+ 816 | Message |Mandatory parameters|Optional parameters | 817 +----------------------+--------------------+---------------------+ 818 | Proactive fault |Version(1) |Interested vlan(4) | 819 | monitoring request |Pro-active fault | | 820 | |monitoring request | | 821 | |details(44) | | 822 +----------------------+--------------------+---------------------| 823 | Proactive fault |Version(1) |Interested vlan(4) | 824 | discovery request |Pro-active fault | | 825 | |discovery request | | 826 | |(45) | | 827 +----------------------+--------------------+---------------------| 828 | Proactive fault |Version(1) | | 829 | discovery response |Pro-active fault | | 830 | |discovery response | | 831 | | (46) | | 832 +----------------------+--------------------+---------------------| 833 | Proactive fault |Version(1) | Pro-active fault | 834 | notication |Pro-active fault | notification(47) | 835 | |notification(47) | (2nd instance) | 836 +----------------------+--------------------+---------------------| 838 Figure 9 Optional and mandatory C-types. 840 New TRILL OAM code 26: Pro-active fault monitoring request 841 Authors' Addresses 843 Rohit Watve 844 CISCO Systems 845 375 East Tasman Drive, 846 San Jose, CA 95134 848 Phone: 408-424-2091 849 Email: rwatve@cisco.com 851 Tissa Senevirathne 852 CISCO Systems 853 375 East Tasman Drive, 854 San Jose, CA 95134 856 Phone: 408-853-2291 857 Email: tsenevir@cisco.com 859 Chandan Mishra 860 CISCO Systems 861 375 East Tasman Drive, 862 San Jose, CA 95134 864 Phone: 408-526-5376 865 Email: cmishra@cisco.com 867 Gayatri Ramachandran 868 5470 Great America Parkway, 869 Santa Clara, CA 95054 870 Phone:(408) 547-5946 871 Email: gayatri@aristanetworks.com