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