idnits 2.17.00 (12 Aug 2021)
/tmp/idnits28140/draft-ietf-trill-oam-fm-11.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
(Using the creation date from RFC6325, updated by this document, for
RFC5378 checks: 2006-05-11)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 24, 2014) is 2759 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)
-- Looks like a reference, but probably isn't: '2' on line 2257
-- Looks like a reference, but probably isn't: '3' on line 2259
-- Looks like a reference, but probably isn't: '64' on line 2284
-- Looks like a reference, but probably isn't: '65' on line 2286
-- Looks like a reference, but probably isn't: '66' on line 2287
-- Looks like a reference, but probably isn't: '67' on line 2288
-- Looks like a reference, but probably isn't: '68' on line 2289
-- Looks like a reference, but probably isn't: '69' on line 2290
-- Looks like a reference, but probably isn't: '70' on line 2292
-- Looks like a reference, but probably isn't: '71' on line 2294
-- Looks like a reference, but probably isn't: '72' on line 2296
-- Looks like a reference, but probably isn't: '73' on line 2297
-- Looks like a reference, but probably isn't: '74' on line 2298
== Missing Reference: '00-00-5E-90-01-00' is mentioned on line 2538, but
not defined
== Missing Reference: '01-5E-90-01-00' is mentioned on line 2307, but not
defined
== Missing Reference: '01-00-5E-90-01-01' is mentioned on line 2539, but
not defined
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
-- Possible downref: Non-RFC (?) normative reference: ref. '8021Q'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS'
-- Obsolete informational reference (is this intentional?): RFC 4379
(Obsoleted by RFC 8029)
-- Obsolete informational reference (is this intentional?): RFC 7180
(Obsoleted by RFC 7780)
-- No information found for draft-karp-isis-analysis - is the name correct?
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 20 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 TRILL Working group Tissa Senevirathne
2 Internet Draft Norman Finn
3 Intended status: Standard Track Samer Salam
4 Updates: 6325 Deepak Kumar
5 CISCO
7 Donald Eastlake
8 Sam Aldrin
9 Yizhou Li
10 Huawei
12 October 24, 2014
13 Expires: April 2015
15 TRILL Fault Management
16 draft-ietf-trill-oam-fm-11.txt
18 Status of this Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six
29 months and may be updated, replaced, or obsoleted by other
30 documents at any time. It is inappropriate to use Internet-
31 Drafts as reference material or to cite them other than as "work
32 in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html
40 This Internet-Draft will expire on April 24, 2009.
42 Copyright Notice
44 Copyright (c) 2014 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with
52 respect to this document. Code Components extracted from this
53 document must include Simplified BSD License text as described in
54 Section 4.e of the Trust Legal Provisions and are provided
55 without warranty as described in the Simplified BSD License.
57 Abstract
59 This document specifies TRILL OAM Fault Management. Methods in
60 this document follow the IEEE 802.1 CFM (Continuity Fault
61 Management) framework and reuse OAM tools where possible.
62 Additional messages and TLVs are defined for TRILL specific
63 applications or where a different set of information is required
64 other than IEEE 802.1 CFM. This document updates RFC 6325.
66 Table of Contents
68 1. Introduction ............................................... 4
69 2. Conventions used in this document .......................... 4
70 3. General Format of TRILL OAM Packets ........................ 5
71 3.1. Identification of TRILL OAM frames .................... 7
72 3.2. Use of TRILL OAM Alert Flag ........................... 7
73 3.2.1. Handling of TRILL frames with the "A" Flag ....... 8
74 3.3. OAM Capability Announcement ........................... 8
75 3.4. Identification of the OAM message .................... 10
76 4. TRILL OAM Layering vs. IEEE Layering ...................... 10
77 4.1. Processing at ISS Layer .............................. 12
78 4.1.1. Receive Processing .............................. 12
79 4.1.2. Transmit Processing ............................. 12
80 4.2. End Station VLAN and Priority Processing ............. 12
81 4.2.1. Receive Processing .............................. 12
82 4.2.2. Transmit Procession ............................. 12
83 4.3. TRILL Encapsulation and De-capsulation Layer ......... 12
84 4.3.1. Receive Processing for Unicast packets .......... 12
85 4.3.2. Transmit Processing for unicast packets ......... 13
86 4.3.3. Receive Processing for Multicast packets ........ 14
87 4.3.4. Transmit Processing of Multicast packets ........ 15
88 4.4. TRILL OAM Layer Processing ........................... 16
89 5. Maintenance Associations (MA) in TRILL .................... 17
90 6. MEP Addressing ............................................ 18
91 6.1. Use of MIP in TRILL .................................. 21
92 7. Continuity Check Message (CCM) ............................ 23
93 8. TRILL OAM Message Channel ................................. 25
94 8.1. TRILL OAM Message header ............................. 25
95 8.2. TRILL Specific OAM Opcodes ........................... 26
96 8.3. Format of TRILL OAM TLV .............................. 26
97 8.4. TRILL OAM TLVs ....................................... 27
98 8.4.1. Common TLVs between CFM and TRILL ............... 27
99 8.4.2. TRILL OAM Specific TLVs ......................... 28
100 8.4.3. TRILL OAM Application Identifier TLV ............ 28
101 8.4.4. Out Of Band Reply Address TLV ................... 30
102 8.4.5. Diagnostics Label TLV ........................... 31
103 8.4.6. Original Data Payload TLV ....................... 32
104 8.4.7. RBridge scope TLV ............................... 32
105 8.4.8. Previous RBridge nickname TLV ................... 33
106 8.4.9. Next Hop RBridge List TLV ....................... 34
107 8.4.10. Multicast Receiver Port count TLV .............. 35
108 8.4.11. Flow Identifier (flow-id) TLV .................. 35
109 8.4.12. Reflector Entropy TLV .......................... 36
110 8.4.13. Authentication TLV ............................. 37
111 9. Loopback Message .......................................... 39
112 9.1. Loopback OAM Message format .......................... 39
113 9.2. Theory of Operation .................................. 39
114 9.2.1. Actions by Originator RBridge ................... 39
115 9.2.2. Intermediate RBridge ............................ 40
116 9.2.3. Destination RBridge ............................. 40
117 10. Path Trace Message ....................................... 41
118 10.1. Theory of Operation ................................. 42
119 10.1.1. Action by Originator RBridge ................... 42
120 10.1.2. Intermediate RBridge ........................... 42
121 10.1.3. Destination RBridge ............................ 44
122 11. Multi-Destination Tree Verification Message (MTVM) ....... 44
123 11.1. Multi-Destination Tree Verification Message (MTVM)
124 Format .................................................... 44
125 11.2. Theory of Operation ................................. 45
126 11.2.1. Actions by Originator RBridge .................. 45
127 11.2.2. Receiving RBridge .............................. 46
128 11.2.3. In scope RBridges .............................. 46
129 12. Application of Continuity Check Message (CCM) in TRILL ... 47
130 12.1. CCM Error Notification .............................. 48
131 12.2. Theory of Operation ................................. 49
132 12.2.1. Actions by Originator RBridge .................. 49
133 12.2.2. Intermediate RBridge ........................... 50
134 12.2.3. Destination RBridge ............................ 50
135 13. Fragmented Reply ......................................... 51
136 14. Security Considerations .................................. 51
137 15. IANA Considerations ...................................... 53
138 15.1. OAM Capabilitiy Flags ............................... 53
139 15.2. CFM Code Points ..................................... 53
140 15.3. MAC Addresses ....................................... 54
141 15.4. Return codes and sub codes .......................... 54
142 15.5. TRILL RBridge Nickname Address Family ............... 55
143 16. References ............................................... 55
144 16.1. Normative References ................................ 55
145 16.2. Informative References .............................. 56
146 17. Acknowledgments .......................................... 57
147 Appendix A. Backwards Compatibility .......................... 58
148 Appendix B. Base Mode for TRILL OAM .......................... 61
149 Appendix C. MAC Addresses Request ............................ 63
151 1. Introduction
153 The general structure of TRILL OAM messages is presented in
154 [RFC7174]. TRILL OAM messages consist of five parts: link header,
155 TRILL header, flow entropy, OAM message channel, and link
156 trailer.
158 The OAM message channel carries various control information and
159 OAM related data between TRILL switches, also known as RBridges
160 or Routing Bridges.
162 A common OAM message channel representation can be shared between
163 different technologies. This consistency between different OAM
164 technologies promotes nested fault monitoring and isolation
165 between technologies that share the same OAM framework.
167 The TRILL OAM message channel is formatted as specified in IEEE
168 Connectivity Fault Management (CFM) [8021Q].
170 The ITU-T Y.1731 [Y1731] standard utilizes the same messaging
171 format as [8021Q] OAM messages where applicable. This document
172 takes a similar stance and reuses [8021Q] in TRILL OAM. It is
173 assumed readers are familiar with [8021Q] and [Y1731]. Readers
174 who are not familiar with these documents are encouraged to
175 review them.
177 This document updates [RFC6325] as specified in Section 3.1.
179 2. Conventions used in this document
181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
182 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
183 "OPTIONAL" in this document are to be interpreted as described in
184 RFC-2119 [RFC2119].
186 Capitalized IANA Considerations terms such as "Standards Action"
187 are to be interpreted as described in [RFC5226].
189 Acronyms used in the document include the following:
191 CCM - Continuity Check Message [8021Q]
193 ECMP - Equal Cost Multipath
195 ISS - Internal Sub Layer Service [8021Q]
197 LBM - Loop Back Message [8021Q]
199 LBR - Loop Back Reply Message [8021Q]
201 MP - Maintenance Point [RFC7174]
203 MEP - Maintenance End Point [RFC7174] [8021Q]
205 MIP - Maintenance Intermediate Point [RFC7174] [8021Q]
207 MA - Maintenance Association [8021Q] [RFC7174]
209 MD - Maintenance Domain [8021Q]
211 MTVM - Multi-destination Tree Verification Message
213 MTVR - Multi-destination Tree Verification Reply Message
215 OAM - Operations, Administration, and Maintenance [RFC6291]
217 PRI - Priority of Ethernet Frames [8021Q]
219 PTM - Path Trace Message
221 PTR - Path Trace Reply Message
223 TRILL - Transparent Interconnection of Lots of Links [RFC6325]
225 SAP - Service Access Point [8021Q]
227 3. General Format of TRILL OAM Packets
228 The TRILL forwarding paradigm allows an implementation to select
229 a path from a set of equal cost paths to forward a unicast TRILL
230 Data packet. For multi-destination TRILL Data packets, a
231 distribution tree is chosen by the TRILL switch that ingresses or
232 creates the packet. Selection of the path of choice is
233 implementation dependent at each hop for unicast and at the
234 ingress for multi-destination. However, it is a common practice
235 to utilize Layer 2 through Layer 4 information in the frame
236 payload for path selection.
238 For accurate monitoring and/or diagnostics, OAM Messages are
239 required to follow the same path as corresponding data packets.
240 [RFC7174] presents the high-level format of the OAM messages. The
241 details of the TRILL OAM frame format are defined in this
242 document.
244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
245 | |
246 . Link Header . (variable)
247 | |
248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
249 | |
250 + TRILL Header + 6 or more bytes
251 | |
252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
253 | |
254 . Flow Entropy . 96 bytes
255 . .
256 | |
257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
258 | OAM Ethertype |
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 | |
261 . OAM Message Channel . Variable
262 . .
263 | |
264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
265 | Link Trailer | Variable
266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268 Figure 1 Format of TRILL OAM Messages
270 Link Header: Media-dependent header. For Ethernet, this includes
271 Destination MAC, Source MAC, VLAN (optional) and Ethertype
272 fields.
274 TRILL Header: Fixed size of 6 bytes when the Extended Header is
275 not included [RFC6325]
277 Flow Entropy: This is a 96-byte fixed size field. The rightmost
278 bits of the field MUST be padded with zeros, up to 96 bytes, when
279 the flow entropy is less than 96 bytes. Flow entropy enables
280 emulation of the forwarding behavior of the desired data packets.
281 The Flow Entropy field starts with the Inner.MacDA. The offset of
282 the Inner.MacDA depends on whether extensions are included or not
283 as specified in [RFC7179] and [RFC6325]. Such extensions are not
284 commonly supported in current TRILL implementations.
286 OAM Ethertype: OAM Ethertype is 16-bit Ethertype that identifies
287 the OAM Message channel that follows. This document specifies
288 using the Ethertype 0x8902 allocated for CFM [8021Q]. OAM Message
289 Channel: This is a variable size section that carries OAM related
290 information. The message format is as specified in [8021Q].
292 Link Trailer: Media-dependent trailer. For Ethernet, this is the
293 FCS (Frame Check Sequence).
295 3.1. Identification of TRILL OAM frames
297 TRILL, as originally specified in [RFC6325], did not have a
298 specific flag or a method to identify OAM frames. This document
299 updates [RFC6325] to include specific methods to identify TRILL
300 OAM frames. Section 3.2. below explains the details of the
301 method.
303 3.2. Use of TRILL OAM Alert Flag
305 The TRILL Header, as defined in [RFC6325], has two reserved bits.
306 This document specifies use of the reserved bit next to Version
307 field in the TRILL header as the Alert flag. Alert flag will be
308 denoted by "A". RBridges MUST NOT use the "A" flag for forwarding
309 decisions such as the selection of which ECMP path or multi-
310 destination tree to select.
312 Implementations that comply with this document MUST utilize "A"
313 flag and CFM Ethertype to identify TRILL OAM frames.
315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316 | V |A|R|M|Op-Length| Hop Count |
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318 | Egress RBridge Nickname | Ingress RBridge Nickname |
319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
320 | Options...
321 +-+-+-+-+-+-+-+-+-+-+-+-
323 Figure 2 TRILL Header with the "A" Flag
325 A (1 bit) - Indicates this is a possible OAM frame and is subject
326 to specific handling as specified in this document.
328 All other TRILL Header fields carry the same meaning as defined
329 in RFC6325.
331 3.2.1. Handling of TRILL frames with the "A" Flag
333 Value "1" in the A flag indicates TRILL frames that may qualify
334 as OAM frames. Implementations are further REQUIRED to validate
335 such frames by comparing the value at the OAM Ethertype (Figure
336 1) location with the CFM Ethertype "0x8902" [8021Q]. If the value
337 matches, such frames are identified as TRILL OAM frames and
338 SHOULD be processed as discussed in Section 4.
340 Frames with the "A" flag set that do not contain CFM Ethertype
341 are not considered as OAM frames. Such frames MUST be silently
342 discarded.
344 OAM capable RBridges MUST NOT generate OAM frames to an RBridge
345 that is not OAM capable.
347 Intermediate RBridges, that are not OAM capable (i.e. do not
348 understand the "A" flag) follow the process defined in [RFC6325]
349 section 3.3 and forward OAM frames with "A" flag unaltered.
351 3.3. OAM Capability Announcement
353 Any given RBridge can be (1) OAM incapable or (2) OAM capable
354 with new extensions or (3) OAM capable with backwards-compatible
355 method. The OAM request originator, prior to origination of the
356 request is required to identify the OAM capability of the target
357 and generate the appropriate OAM message.
359 Capability flags defined in TRILL version sub-TLV (TRILL-VER)
360 [RFC7176] will be utilized for announcing OAM capabilities. The
361 following OAM related capability flags are defined:
363 O - OAM Capable
365 B - Backwards Compatible OAM
367 A capability announcement, with "O" Flag set to 1 and "B" flag
368 set to 1, indicates that the originating RBridge is OAM capable
369 but utilizes the backwards compatible method defined in Appendix
370 A. A capability announcement with "O" Flag set to 1 and "B" flag
371 set to 0, indicates that the originating RBridge is OAM capable
372 and utilizes the method specified in section 3.2.
374 When "O" Flag is set to 0, the announcing implementation is
375 considered not capable of OAM and the "B" flag is ignored.
377 +-+-+-+-+-+-+-+-+
378 | Type | (1 byte)
379 +-+-+-+-+-+-+-+-+
380 | Length | (1 byte)
381 +-+-+-+-+-+-+-+-+
382 | Max-version | (1 byte)
383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
384 |A|F|O|B|Other Capabilities and Header Flags| (4 bytes)
385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+
386 0 1 3
387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
389 Figure 3 TRILL-VER sub-TLV [RFC7176] with O and B flags
391 Capability flags "A" and "F" are defined by [RFC7176] and
392 [RFC7172]. "O" and "B" Flags are located after "F" flag in the
393 Capability and Header Flags field of TRILL-VER sub-TLV, as
394 depicted in Figure 3 above. Usage of "O" and "B" flags are as
395 discussed above.
397 Absence of TRILL-VER sub-TLV means the announcing RBridge is not
398 OAM capable.
400 3.4. Identification of the OAM message
402 The ingress RBridge nickname allows recipients to identify the
403 origin of the message in most cases. However, when an out of band
404 reply is generated, the responding RBridge nickname is not easy
405 to identify.
407 The [8021Q] Sender ID TLV (1) provides methods to identify the
408 device by including the chassis ID. Chassis ID allows different
409 addressing formats such as IANA Address Family enumerations. IANA
410 has allocated Address Family Number 16396 for TRILL RBridge
411 nickname. In TRILL OAM the Chassis ID subtype of Sender ID TLV is
412 set to 16396 and Chassis ID field contains the corresponding
413 TRILL RBridge nickname.
415 When the Sender ID TLV is present and chassis sub type is set to
416 16396, the sender RBridge nickname SHOULD be derived from the
417 nickname embedded in the Chassis ID. Otherwise, sender RBridge
418 nickname SHOULD be derived from the ingress RBridge nickname.
420 4. TRILL OAM Layering vs. IEEE Layering
422 This section presents the placement of the TRILL OAM shim within
423 the IEEE 802.1 layers. The Transmit and Receive processing are
424 explained.
426 +-+-+-+-+-+-+-+-+-+-+
427 | RBridge Layer |
428 | Processing |
429 +-+-+-+-+-+-+-+-+-+-+
430 |
431 |
432 +-+-+-+-+-+-+
433 | TRILL OAM | UP MEP
434 | Layer | MIP
435 +-+-+-+-+-+-+ Down MEP
436 |
437 |
438 +-+-+-+-+-+-+
439 (3)--------> | TRILL |
440 | Encap/Decap
441 +-+-+-+-+-+-+
442 |
443 +-+-+-+-+-+-+
444 (2)--------> |End station|
445 | VLAN & priority Processing
446 +-+-+-+-+-+-+
447 |
448 +-+-+-+-+-+-+
449 (1)--------> |ISS |
450 |Processing |
451 +-+-+-+-+-+-+
452 |
453 |
454 |
456 Figure 4 Placement of TRILL MP within IEEE 802.1
458 [RFC6325] Section 4.6 as updated by [RFC7180] provides a detailed
459 explanation of frame processing. Please refer to those documents
460 for additional details and for processing scenarios not covered
461 herein.
463 Sections 4.1 and 4.2 below apply to links using a broadcast LAN
464 technology such as Ethernet.
466 On links using an inherently point-to-point technology, such as
467 PPP [RFC6361], there is no Outer.MacDA, Outer.MacSA, or
468 Outer.VLAN because these are part of the link header for
469 Ethernet. Point-to-point links typically have link headers
470 without these fields.
472 4.1. Processing at ISS Layer
474 4.1.1. Receive Processing
476 The ISS Layer receives an indication from the port. It extracts
477 DA, SA and marks the remainder of the payload as M1. ISS Layer
478 passes on (DA, SA, M1) as an indication to the higher layer.
480 For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA.
481 M1 is the remainder of the packet.
483 4.1.2. Transmit Processing
485 The ISS layer receives an indication from the higher layer that
486 contains (DA, SA, M1). It constructs an Ethernet frame and passes
487 down to the port.
489 4.2. End Station VLAN and Priority Processing
491 4.2.1. Receive Processing
493 Receives (DA, SA, M1) indication from ISS Layer. Extracts the
494 VLAN ID and priority from the M1 part of the received indication
495 (or derive them from the port defaults or other default
496 parameters) and constructs (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2
497 map to M1 in the received indication. Pass (DA, SA, VLAN, PRI,
498 M2) to the TRILL encap/decap procession layer.
500 4.2.2. Transmit Procession
502 Receive (DA, SA, VLAN, PRI, M2) indication from TRILL encap/decap
503 processing layer. Merge VLAN, PRI, M2 to form M1. Pass down (DA,
504 SA, M1) to the ISS processing Layer.
506 4.3. TRILL Encapsulation and De-capsulation Layer
508 4.3.1. Receive Processing for Unicast packets
510 Receive indication (DA, SA, VLAN, PRI, M2) from End Station VLAN
511 and Priority Processing Layer.
513 o If DA matches port Local DA and Frame is of TRILL Ethertype
514 . Discard DA, SA, VLAN, PRI. From M2, derive (TRILL-HDR, iDA,
515 iSA, i-VL, M3)
517 . If TRILL nickname is Local and TRILL-OAM Flag is set
519 Pass on to OAM processing
521 . Else pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to RBridge
522 Layer
524 o If DA matches port Local DA and EtherType is RBridge-Channel
525 [RFC7178]
527 . Process as a possible unicast native RBridge Channel packet
529 o If DA matches port Local DA and Ethertype is neither TRILL
530 nor RBridge-Channel
532 . Discard packet
534 o If DA does not match and port is Appointed Forwarder for VLAN
535 and Ethertype is not TRILL or RBridge-Channel
537 . Insert TRILL-Hdr and send (TRILL-HDR, iDA, iSA,i-VL, M3)
538 indication to RBridge Layer <- This is the TRILL Ingress
539 Function.
541 4.3.2. Transmit Processing for unicast packets
543 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from
544 RBridge Layer
546 o If egress TRILL nickname is local
548 o If port is Appointed Forwarder for iVL and the port is
549 not configured as a trunk or p2p port and (TRILL Alert
550 Flag set and OAM Ethertype present) then
552 . Strip TRILL-HDR and construct (DA, SA, VLAN, M2)
553 <- This is the TRILL Egress Function.
555 o Else
557 . Discard packet
559 o If egress TRILL nickname is not local
560 o Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, TRILL
561 Ethertype and construct (DA, SA, VLAN, M2). Where M2 is
562 (TRILL-HDR, iDA, iSA, iVL, M)
564 o Forward (DA, SA, V, M2) to the VLAN End Station processing
565 Layer.
567 4.3.3. Receive Processing for Multicast packets
569 o Receive (DA, SA, V, M2) from VLAN aware end station
570 processing layer
572 o If the DA is All-RBridges and the Ethertype is TRILL
574 o Strip DA, SA and V. From M2, extract (TRILL-HDR, iDA,
575 iSA, iVL and M3).
577 o If TRILL Alert Flag is set and OAM Ethertype is present
578 at the end of Flow entropy
580 . Perform OAM Processing
582 o Else extract the TRILL header, inner MAC addresses and
583 inner VLAN and pass indication (TRILL-HDR, iDA, iSA,
584 iVL and M3) to TRILL RBridge Layer
586 o If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS-
587 IS then pass frame up to TRILL IS-IS processing
589 o If the DA is All-RBridges or All-IS-IS-RBridges but
590 Ethertype is not TRILL or L2-IS-IS respectively
592 o Discard the packet
594 o If the Ethertype is TRILL but the multicast DA is not All-
595 RBridges; or if the Ethertype is L2-IS-IS but the multicast
596 DA is not All-IS-IS-RBridges
598 o Discard the packet
600 o If DA is All-Edge-RBridges and Ethertype is RBridge-Channel
601 [RFC7178]
603 o Process as a possible multicast native RBridge
604 Channel packet
606 o If the DA is in the initial bridging/link protocols block
607 (01-80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL
608 block and not assigned for Outer.MacDA use (01-80-C2-00-00-
609 42 to 01-80-C2-00-00-4F) then
611 o The frame is not propagated through an RBridge although
612 some special processing may be done at the port as
613 specified in [RFC6325] and the frame may be dispatched
614 to Layer 2 processing at the port if certain protocols
615 are supported by that port (examples: Link Aggregation
616 Protocol, Link Layer Discovery Protocol).
618 o If the DA is some other multicast value
620 o Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA,
621 IVL, M3)
623 o Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to RBridge Layer
625 4.3.4. Transmit Processing of Multicast packets
627 The following ignores the case of transmitting TRILL IS-IS
628 packets.
630 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from
631 RBridge layer.
633 o If TRILL-HDR multicast flag set and TRILL-HDR Alert flag
634 set and OAM Ethertype present then:
636 o (DA, SA, V, M2) by inserting TRILL Outer.MacDA of All-
637 RBridges, Outer.MacSA, Outer.VLAN and TRILL Ethertype.
638 M2 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL,
639 M)
641 NOTE: Second copy of native format is not made.
643 o Else If TRILL-HDR multicast flag set and Alert flag not set
645 o If the port is appointed Forwarder for iVL and the port
646 is not configured as a trunk port or a p2p port, Strip
647 TRILL-HDR, iSA, iDA, iVL and construct (DA, SA, V, M2)
648 for native format.
650 o Make a second copy (DA, SA, V, M2) by inserting TRILL
651 Outer.MacDA, Outer.MacSA, Outer.VLAN and TRILL
652 Ethertype. M2 here is (Ethertype TRILL, TRILL-HDR, iDA,
653 iSA, iVL, M)
655 o Pass the indication (DA, SA, V, M2) to End Station VLAN
656 processing layer.
658 4.4. TRILL OAM Layer Processing
660 TRILL OAM Processing Layer is located between the TRILL
661 Encapsulation / De-capsulation layer and RBridge Layer. It
662 performs the following: 1. Identification of OAM frames that
663 need local processing and 2. performs OAM processing or redirect
664 to the CPU for OAM processing.
666 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from
667 RBridge layer. M3 is the payload after inner VLAN iVL.
669 o If the TRILL Multicast Flag is set and TRILL Alert Flag is
670 set and TRILL OAM Ethertype is present then
671 o If MEP or MIP is configured on the Inner.VLAN/FGL of the
672 packet then
673 . discard packets that have MD-LEVEL Less than that
674 of the MEP or packets that do not have MD-LEVEL
675 present (e.g., due to packet truncation).
676 . If MD-LEVEL matches MD-LEVEL of the MEP then
677 . Re-direct to OAM Processing (Do not forward
678 further)
679 . If MD-LEVEL matches MD-LEVEL of MIP then
680 . Make a Copy for OAM processing and continue
681 . If MD-LEVL matches MD-LEVEL of MEP then
682 . Redirect the OAM packet to OAM processing
683 and do not forward along or forward as a
684 native packet.
686 o Else if TRILL Alert Flag is set and TRILL OAM Ethertype is
687 present then
688 o If MEP or MIP is configured on the Inner.VLAN/FGL of the
689 packet then
690 . discard packets that have MD-LEVEL not present or
691 MD-LEVEL is Less than that of the MEP.
692 . If MD-LEVEL matches MD-LEVEL of the MEP then
693 . Re-direct to OAM Processing (Do not forward
694 further)
695 . If MD-LEVEL matches MD-LEVEL of MIP then
696 . Make a Copy for OAM processing and continue
698 o Else // Non-OAM Packet
699 o Continue
701 o Pass the indication (DA, SA, V, M2) to End Station VLAN
702 processing layer.
704 NOTE: In the Receive path, processing above compares against Down
705 MEP and MIP Half functions. In the transmit processing it
706 compares against Up MEP and MIP Half functions.
708 Appointed Forwarder is a function the TRILL Encap/De-Cap layer
709 performs. The TRILL Encap/De-cap Layer is responsible for
710 prevention of leaking of OAM packets as native frames.
712 5. Maintenance Associations (MA) in TRILL
714 [8021Q] defines a maintenance association as a logical
715 relationship between a group of nodes. Each Maintenance
716 Association (MA) is identified with a unique MAID of 48 bytes
717 [8021Q]. CCM and other related OAM functions operate within the
718 scope of an MA. The definition of MA is technology independent.
719 Similarly it is encoded within the OAM message, not in the
720 technology dependent portion of the packet. Hence the MAID as
721 defined in [8021Q] can be utilized for TRILL OAM, without
722 modifications. This also allows us to utilize CCM and LBM
723 messages defined in [8021Q], as is.
725 In TRILL, an MA may contain two or more RBridges (MEPs). For
726 unicast, it is likely that the MA contains exactly two MEPs that
727 are the two end-points of the flow. For multicast, the MA may
728 contain two or more MEPs.
730 For TRILL, in addition to all of the standard [8021Q] CFM MIB
731 definitions, each MEP's MIB contains one or more flow entropy
732 definitions corresponding to the set of flows that the MEP
733 monitors.
735 [8021Q] CFM MIB is augmented to add the TRILL specific
736 information. Figure 5, below depicts the augmentation of the CFM
737 MIB to add the TRILL specific Flow Entropy.
739 MA---
740 |
741 --- MEP
742 |
743 . - Remote MEP List
744 .
745 |
746 --- MEP-A
747 |
748 --- MEP-B
749 .
751 |
752 . - Flow Entropy List { Augments IEEE8021-CFM-MIB}
754 |
755 --- (Flow Entropy-1)
756 |
757 --- (Flow-entropy-2)
758 |
759 . --- (Flow Entropy n)
760 |
761 Other MIB entries
763 Figure 5 Correlation of TRILL augmented MIB
765 The detailed TRILL OAM MIB will be specified in a separate
766 document [TRILLOAMMIB].
768 6. MEP Addressing
770 In IEEE CFM [8021Q], OAM messages address the target MEP by
771 utilizing a unique MAC address. In TRILL a MEP is addressed by
772 combination of the egress RBridge nickname and the Inner
773 VLAN/FGL.
775 Additionally, MEPs are represented by 2 octet MEP-ID that is
776 independent of the underlying technology. In CFM [8021Q] the
777 value of MEP-ID is restricted to 1 to 8191. However, on CFM
778 [8021Q] packet, MEP-ID are encoded as a 2 octet field. In TRILL
779 Base Mode operation presented in Appendix B MEP-IDs are mapped 1
780 to 1 with the RBridge nicknames. Hence, In TRILL, MEP-ID MUST be
781 a number in the range from 1 to 65535.
783 At the MEP, OAM packets go through a hierarchy of op-code de-
784 multiplexers. The op-code de-multiplexers channel the incoming
785 OAM packets to the appropriate message processor (e.g. LBM) The
786 reader may refer to Figure 6 below for a visual depiction of
787 these different de-multiplexers.
789 1. Identify the packets that need OAM processing at the Local
790 RBridge as specified in Section 4.
792 a. Identify the MEP that is associated with the
793 Inner.VLAN/FGL.
795 2. The MEP first validates the MD-LEVEL and then
797 a. Redirect to MD-LEVEL De-multiplexer
799 3. MD-LEVEL de-multiplexer compares the MD-Level of the packet
800 against the MD level of the local MEPs of a given MD-Level on
801 the port (Note: there can be more than one MEP at the same MD-
802 Level but belonging to different MAs)
804 a. If the packet MD-LEVEL is equal to the configured MD-
805 LEVEL of the MEP, then pass to the Opcode de-multiplexer
807 b. If the packet MD-LEVEL is less than the configured MD-
808 LEVEL of the MEP, discard the packet
810 c. If the packer MD-LEVEL is greater than the configured
811 MD-LEVEL of the MEP, then pass on to the next higher MD-
812 LEVEL de-multiplexer, if available. Otherwise, if no such
813 higher MD-LEVEL de-multiplexer exists, then forward the
814 packet as normal data.
816 4. Opcode De-multiplexer compares the opcode in the packet with
817 supported opcodes
819 a. If Op-code is CCM, LBM, LBR, PTM, PTR, MTVM, MTVR, then
820 pass on to the correct Processor
822 b. If Op-code is Unknown, then discard.
824 |
825 .CCM LBM PTM MTVM . .
826 | | | |
827 +-+-+-+-+-+-+-+-+-+-+-+-+
828 | OP Code DE-Mux |--- Unknown
829 +-+-+-+-+-+-+-+-+-+-+-+-+
830 ^ ^ ^
831 MD==Li | | |
832 +-+-+ +-+-+ +-+-+
833 | L |-->|L2 |-.- |Ln |---- >
834 +-+-+ +-+-+ +-+-+ |
835 | ^ | | |
836 MD
| T |----------------- >| M |--- >
843 + TRILL OAM ---- + pass through OAM ----
845 Figure 6 OAM De-Multiplexers at MEP for active SAP
847 T : Denotes Tap, that identifies OAM frames that need local
848 processing. These are the packets with Alert flag set and
849 OAM Ethertype is present after the flow entropy of the
850 packet
852 M : Is the post processing merge, merges data and OAM
853 messages that are passed through. Additionally, the Merge
854 component ensures, as explained earlier, that OAM packets
855 are not forwarded out as native frames.
857 L : Denotes MD-Level processing. Packets with MD-Level less
858 than the Level will be dropped. Packets with equal MD-Level
859 are passed on to the opcode de-multiplexer. Others are
860 passed on to the next level MD processors or eventually to
861 the merge point (M).
863 NOTE: LBM, LBR, MTVM, MTVR, PTM and PTR are not subject to
864 MA de-multiplexers. These packets do not have an MA encoded
865 in the packet. Adequate response can be generated to these
866 packets, without loss of functionality, by any of the MEPs
867 present on that interface or an entity within the RBridge.
869 6.1. Use of MIP in TRILL
871 Maintenance Intermediate Points (MIP) are mainly used for fault
872 isolation. Link Trace Messages in [8021Q] utilize a well-known
873 multicast MAC address and MIPs generate responses to Link Trace
874 messages. Response to Link Trace messages or lack thereof can be
875 used for fault isolation in TRILL.
877 As explained in section 10. , a hop-count expiry approach will be
878 utilized for fault isolation and path tracing. The approach is
879 very similar to the well-known IP trace-route approach. Hence,
880 explicit addressing of MIPs is not required for the purpose of
881 fault isolation.
883 Any given RBridge can have multiple MIPs located within an
884 interface. As such, a mechanism is required to identify which MIP
885 should respond to an incoming OAM message. Any MIP residing
886 within the ingress interface may reply to the incoming Path Trace
887 message without loss of functionality or information. As
888 specified in Section 3.4. , the address of the responding RBridge
889 can be identified by means of Sender ID TLV (1). The Reply
890 Ingress TLV (5) identifies the interface id. The combination of
891 these allows recipient of the response to uniquely identify the
892 responder.
894 A similar approach to that presented above for MEPs can be used
895 for MIP processing. It is important to note that "M", the merge
896 block of a MIP, does not prevent OAM packets leaking out as
897 native frames. On edge interfaces, MEPs MUST be configured to
898 prevent the leaking of TRILL OAM packets out of the TRILL Campus.
900 PTM PTR MTVM MTVR
901 | | | |
902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
903 | OP Code De-Mux |-> Unknown
904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
905 ^ ^ ^
906 MD==Li | | |
907 +-+-+ +-+-+ +-+-+
908 | L |- >|L2 |-.- |Ln |------+
909 +-+-+ +-+-+ +-+-+ |
910 ^ |
911 | |
912 Drop | |
913 MD not --- |TRILL OAM |
914 Present | |
915 | v
916 TRILL Data ---- TRILL Data -----
917 ------- >| T |------------------ >| M |---->
918 + TRILL OAM ---- ----
920 Figure 7 OAM De-Multiplexers at MIP for active SAP
922 T: TAP processing for MIP. All packets with OAM flag set are
923 captured.
925 L : MD Level Processing, Packet with matching MD Level are
926 "copied" to the Opcode de-multiplexer and original packet is
927 passed on to the next MD level processor. Other packets are
928 simply passed on to the next MD level processor, without copying
929 to the OP code de-multiplexer.
931 M : Merge processor, merge OAM packets to be forwarded along with
932 the data flow.
934 Packets that carry Path Trace Message (PT) or Multi-destination
935 Tree Verification (MTVM) OpCodes are passed on to the respective
936 processors.
938 Packets with unknown OpCodes are counted and discarded.
940 7. Continuity Check Message (CCM)
942 CCMs are used to monitor connectivity and configuration errors.
943 [8021Q] monitors connectivity by listening to periodic CCM
944 messages received from its remote MEP partners in the MA. An
945 [8021Q] MEP identifies cross-connect errors by comparing the MAID
946 in the received CCM message with the MEP's local MAID. The MAID
947 [8021Q] is a 48-byte field that is technology independent.
948 Similarly, the MEPID is a 2-byte field that is independent of the
949 technology. Given this generic definition of CCM fields, CCM as
950 defined in [8021Q] can be utilized in TRILL with no changes.
951 TRILL specific information may be carried in CCMs when encoded
952 using TRILL specific TLVs or sub-TLVs. This is possible since
953 CCMs may carry optional TLVs.
955 Unlike classical Ethernet environments, TRILL contains multipath
956 forwarding. The path taken by a packet depends on the payload of
957 the packet. The Maintenance Association identifies the interested
958 end-points (MEPs) of a given monitored path. For unicast there
959 are only two MEPs per MA. For multicast there can be two or more
960 MEPs in the MA. The entropy values of the monitored flows are
961 defined within the MA. CCM transmit logic will utilize these flow
962 entropy values when constructing the CCM packets. Please see
963 section 12. below for the theory of operation of CCM.
965 The MIB of [8021Q] is augmented with the definition of flow-
966 entropy. Please see [TRILLOAMMIB] for definition of these and
967 other TRILL related OAM MIB definitions. The below Figure depicts
968 the correlation between MA, CCM and the flow-entropy.
970 MA---
971 |
972 --- MEP
973 |
974 . - Remote MEP List
975 .
976 |
977 --- MEP-A
978 |
979 --- MEP-B
980 .
982 |
983 . - Flow Entropy List {Augments IEEE8021-CFM-MIB}
985 |
986 --- (Flow Entropy-1)
987 |
988 --- (Flow-entropy-2)
989 |
990 . ---(Flow Entropy n)
991 |
992 . - CCM
993 |
994 --- (standard 8021ag entries)
995 |
996 --- (hop-count) { Augments IEEE8021-CFM-MIB}
997 |
998 --- (Other TBD TRILL OAM specific entries)
999 {Augmented}
1000 |
1001 .
1002 |
1003 - Other MIB entries
1005 Figure 8 Augmentation of CCM MIB in TRILL
1007 In a multi-pathing environment, a Flow - by definition - is
1008 unidirectional. A question may arise as to what flow entropy
1009 should be used in the response. CCMs are unidirectional and have
1010 no explicit reply; as such, the issue of the response flow
1011 entropy does not arise. In the transmitted CCM, each MEP reports
1012 local status using the Remote Defect Indication (RDI) flag.
1013 Additionally, a MEP may raise SNMP TRAPs [TRILLOAMMIB] as Alarms
1014 when a connectivity failure occurs.
1016 8. TRILL OAM Message Channel
1018 The TRILL OAM Message Channel can be divided into two parts:
1019 TRILL OAM Message header and TRILL OAM Message TLVs. Every OAM
1020 Message MUST contain a single TRILL OAM message header and a set
1021 of one or more specified OAM Message TLVs.
1023 8.1. TRILL OAM Message header
1025 As discussed earlier, a common messaging framework between
1026 [8021Q], TRILL, and other similar standards such as Y.1731 is
1027 accomplished by re-using the OAM message header defined in
1028 [8021Q].
1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1031 |MD-L | Version | OpCode | Flags |FirstTLVOffset |
1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1033 | |
1034 . Opcode Specific Information .
1035 | |
1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1037 | |
1038 . TLVs .
1039 | |
1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1042 Figure 9 OAM Message Format
1044 o MD-L: Maintenance Domain Level (3 bits). Identifies the
1045 maintenance domain level. For TRILL, in general, this field
1046 is set to a single value across the TRILL campus. When using
1047 TRILL base mode as specified in Appendix B, MD-L is set to
1048 3. However, extension of TRILL, for example to support
1049 multilevel, may create different MD-LEVELs and MD-L field
1050 must be appropriately set in those scenarios. (Please refer
1051 to [8021Q] for the definition of MD-Level)
1053 o Version: Indicates the version (5 bits) as specified in
1054 [8021Q]. This document does not require changing the Version
1055 defined in [8021Q].
1057 o OpCode: Operation Code (8 bits). Specifies the operation
1058 performed by the message. See Section 8.2.
1060 o Flags: Includes operational flags (1 byte). The definition
1061 of flags is Opcode-specific and is covered in the applicable
1062 sections.
1064 o FirstTLVOffset: Defines the location of the first TLV, in
1065 bytes, starting from the end of the FirstTLVOffset field (1
1066 byte). (Refer to [8021Q] for the definition of the
1067 FirstTLVOffset.)
1069 MD-L, Version, Opcode, Flags and FirstTLVOffset fields
1070 collectively are referred to as the OAM Message Header.
1072 The Opcode specific information section of the OAM Message may
1073 contain Session Identification number, time-stamp, etc.
1075 8.2. TRILL Specific OAM Opcodes
1077 The following TRILL specific CFM Opcodes are defined. Each of the
1078 Opcodes indicates a separate type of TRILL OAM message. Details
1079 of the messages are presented in the related sections.
1081 TRILL OAM Message Opcodes:
1083 TBD1: Path Trace Reply
1084 TBD2: Path Trace Message
1085 TBD3: Multicast Tree Verification Reply
1086 TBD4: Multicast Tree Verification Message
1088 Loopback and CCM Messages reuse the opcodes defined by [8021Q]
1090 8.3. Format of TRILL OAM TLV
1092 The same CFM TLV format as defined in [8021Q] is used for TRILL
1093 OAM. The following figure depicts the general format of a TRILL
1094 OAM TLV:
1096 0 1 2
1097 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1099 | Type | Length |
1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1101 | |
1102 . Value(variable) .
1103 | |
1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1106 Figure 10 TRILL OAM TLV
1108 Type (1 octet): Specifies the Type of the TLV (see sections 8.4.
1109 for TLV types).
1111 Length (2 octets): Specifies the length of the 'Value' field in
1112 octets. Length of the 'Value' field can be either zero or more
1113 octets.
1115 Value (variable): The length and the content of this field depend
1116 on the type of the TLV. Please refer to applicable TLV
1117 definitions for the details.
1119 Semantics and usage of Type values allocated for TRILL OAM
1120 purpose are defined by this document and other future related
1121 documents.
1123 8.4. TRILL OAM TLVs
1125 TRILL related TLVs are defined in this section. [8021Q] defined
1126 TLVs are reused, where applicable.
1128 8.4.1. Common TLVs between CFM and TRILL
1130 The following TLVs are defined in [8021Q]. We re-use them where
1131 applicable. The format and semantics of the TLVs are as defined
1132 in [8021Q].
1134 Type Name of TLV in [8021Q]
1135 ---- ----------------------
1136 0 End TLV
1137 1 Sender ID TLV
1138 2 Port Status TLV
1139 3 Data TLV
1140 4 Interface Status TLV
1141 5 Reply Ingress TLV
1142 6 Reply Egress TLV
1143 7 LTM Egress Identifier TLV
1144 8 LTR Egress Identifier TLV
1145 9-30 Reserved
1146 31 Organization Specific TLV
1148 8.4.2. TRILL OAM Specific TLVs
1150 Listed below is a summary of TRILL OAM TLVs and their
1151 corresponding codes. Format and semantics of TRILL OAM TLVs are
1152 defined in subsequent sections.
1154 Type TLV Name
1155 ----------- ----------------------
1156 TBDa TRILL OAM Application Identifier TLV
1157 TBDb Out of Band Reply Address TLV
1158 TBDc Diagnostic Label TLV
1159 TBDd Original Data Payload TLV
1160 TBDe RBridge scope TLV
1161 TBDf Previous RBridge nickname TLV
1162 TBDg Next Hop RBridge List (ECMP) TLV
1163 TBDh Multicast Receiver Port count TLV
1164 TBDi Flow Identifier TLV
1165 TBDj Reflector Entropy TLV
1166 TBDk Authentication TLV
1168 The TRILL OAM Application Identifier TLV (TBDa) MUST be the first
1169 TLV. An End TLV (0) MUST be included as the last TLV. All other
1170 TLVs can be included in any order.
1172 8.4.3. TRILL OAM Application Identifier TLV
1174 The TRILL OAM Application Identifier TLV carries TRILL OAM
1175 application specific information. The TRILL OAM Application
1176 Identifier TLV MUST always be present and MUST be the first TLV
1177 in TRILL OAM messages. Messages that do not include the TRILL OAM
1178 Application Identifier TLV as the first TLV MUST be discarded by
1179 a TRILL MP.
1181 1 2 3
1182 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
1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1184 | Type | Length | Version |
1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1186 | Reserved1 | Fragment-ID |
1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1188 | Return Code |Return sub-code| Reserved2 |F|C|O|I|
1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1191 Figure 11 TRILL OAM Application Identifier TLV
1193 Type (1 octet) = TBDa indicate that this is the TRILL OAM
1194 Application Identifier TLV.
1196 Length (2 octets) = 9.
1198 TRILL OAM Version (1 octet), currently set to zero. Indicates the
1199 TRILL OAM version. TRILL OAM version can be different than the
1200 [8021Q] version.
1202 Reserved1 (3 octets): set to zero on transmission and ignored on
1203 reception.
1205 Fragment-ID (1 octet): Indicates the fragment number of the
1206 current message. This applies only to reply messages; in request
1207 messages it must be set to zero on transmission and ignored on
1208 receipt. F flag defined below MUST be set with the final message
1209 whether it is the last fragment of the fragmented message or only
1210 message of the reply. Section 13. below provides more details on
1211 OAM Message fragmentation.
1213 Return Code (1 octet): Set to zero on requests. Set to an
1214 appropriate value in response messages.
1216 Return sub-code (1 Octet): Return sub-code is set to zero on
1217 transmission of request message. Return sub-code identifies
1218 categories within a specific Return code. Return sub-code MUST be
1219 interpreted within a Return code.
1221 Reserved2 (12 bits): Set to zero on transmission and ignored on
1222 reception.
1224 F (1 bit): Final flag, when set, indicates this is the last
1225 response.
1227 C (1 bit): Cross connect error flag(VLAN/Label mapping error), if
1228 set indicates that the label (VLAN/FGL) in the flow entropy is
1229 different than the label included in the diagnostic TLV. This
1230 field is ignored in request messages and MUST only be interpreted
1231 in response messages.
1233 O (1 bit): If set, indicates, OAM out-of-band response requested.
1235 I (1 bit): If set, indicates, OAM in-band response requested.
1237 NOTE: When both O and I bits are set to zero, indicates that no
1238 response is required (silent mode). User MAY specify both O and I
1239 or one of them or none. When both O and I bits are set response
1240 is sent both in-band and out-of-band.
1242 8.4.4. Out Of Band Reply Address TLV
1244 Out of Band Reply Address TLV specifies the address to which an
1245 out of band OAM reply message MUST be sent. When O bit in the
1246 TRILL Version TLV is not set, Out of Band Reply Address TLV is
1247 ignored.
1249 1 2 3
1250 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
1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1252 | Type | Length | Address Type |
1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1254 | Addr Length | |
1255 +-+-+-+-+-+-+-+-+ |
1256 | |
1257 . Reply Address .
1258 | |
1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1261 Figure 12 Out of Band IP Address TLV
1263 Type (1 octet) = TBDb
1265 Length (2 octets) = Variable. Minimum length is 2 + the length
1266 (in octets) of the shortest address. Currently the minimum value
1267 of this field is 4, but this could change in the future if a new
1268 address shorter than the TRILL RBridge nickname is defined.
1270 Address Type (1 octet) = 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
1271 nickname. All other values reserved.
1273 Addr Length (1 octet) = Depends on the Address Type. Currently
1274 defined values are: 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge
1275 nickname. Other lengths may be acceptable for future Address
1276 Types.
1278 Reply Address (variable): Address where the reply needed to be
1279 sent. Length depends on the address specification.
1281 8.4.5. Diagnostics Label TLV
1283 Diagnostic label specifies the data label (VLAN or FGL) in which
1284 the OAM messages are generated. Receiving RBridge MUST compare
1285 the data label of the Flow entropy to the data label specified in
1286 the Diagnostic Label TLV. Label Error Flag in the response (TRILL
1287 OAM Message Version TLV) MUST be set when the two VLANs do not
1288 match.
1290 1 2 3
1291 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
1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1293 | Type | Length | L-Type |
1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1295 | Reserved | Label(VLAN) |
1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1298 Figure 13 Diagnostic VLAN TLV
1300 Type (1 octet) = TBDc indicates that this is the TRILL Diagnostic
1301 VLAN TLV
1303 Length (2 octets) = 5
1305 L-Type (Label type, 1 octet)
1307 0- indicate 802.1Q 12 bit VLAN.
1309 1 - indicate TRILL 24 bit fine grain label
1311 Reserved (1 octet) = set to zero on transmission and ignored on
1312 reception.
1314 Label (24 bits)= Either 12 bit VLAN or 24 bit fine grain label.
1316 RBridges do not perform Label error checking when the Label TLV
1317 is not included in the OAM message. In certain deployments
1318 intermediate devices may perform label translation. In such
1319 scenarios, originator should not include the diagnostic Label TLV
1320 in OAM messages. Inclusion of diagnostic TLV will generate
1321 unwanted label error notifications.
1323 8.4.6. Original Data Payload TLV
1325 1 2 3
1326 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
1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1328 | Type | Length | |
1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
1330 | |
1331 . Original Payload .
1332 | |
1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1335 Figure 14 Original Data Payload TLV
1337 Type (1 octet) = TBDd
1339 Length (2 octets) = variable
1341 Original Payload: The original TRILL Header and Entropy. Used in
1342 constructing replies to the Loopback Message (see Section 9) and
1343 the Path Trace Message (see Section 10).
1345 8.4.7. RBridge scope TLV
1347 RBridge scope TLV identifies nicknames of RBridges from which a
1348 response is required. The RBridge scope TLV is only applicable to
1349 Multicast Tree Verification messages. This TLV SHOULD NOT be
1350 included in other messages. Receiving RBridges MUST ignore this
1351 TLV on messages other than Multicast Verification Message.
1353 Each TLV can contain up to 255 nicknames of in-scope RBridges. A
1354 Multicast Verification Message may contain multiple "RBridge
1355 scope TLVs", in the event that more than 255 in scope RBridges
1356 need to be specified.
1358 Absence of the "RBridge scope TLV" indicates that a response is
1359 needed from all the RBridges. Please see section 11. for details.
1361 1 2 3
1362 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
1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1364 | Type | Length | nOfnicknames |
1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1366 | nickname-1 | nickname-2 |
1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1368 . .
1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1370 | | nickname-n |
1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1373 Figure 15 RBridge Scope TLV
1375 Type (1 octet) = TBDe indicates that this is the "RBridge scope
1376 TLV"
1378 Length (2 octets) = variable. Minimum value is 1.
1380 nOfnicknames (1 octet) = indicates number of nicknames included
1381 in this TLV. Zero (0) indicates no nicknames are included in the
1382 TLV. When this field is set to zero (0), length field MUST be set
1383 to 1.
1385 Nickname (2 octets) = 16 bit RBridge nickname.
1387 8.4.8. Previous RBridge nickname TLV
1389 The "Previous RBridge nickname TLV" identifies the nickname or
1390 nicknames of the Previous RBridge. [RFC6325] allows a given
1391 RBridge to hold multiple nicknames.
1393 The "Previous RBridge nickname TLV" is an optional TLV. Multiple
1394 instances of this TLV MAY be included when an upstream RBridge is
1395 represented by more than 255 nicknames (highly unlikely).
1397 1 2 3
1398 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
1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1400 | Type | Length | Reserved |
1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1402 | Reserved (continued) | nickname |
1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1405 Figure 16 Previous RBridge nickname TLV
1407 Type (1 octet) = TBDf indicates that this is the "Previous
1408 RBridge nickname"
1410 Length (2 octets) = 5.
1412 Reserved (3 octet) = set to zero on transmission and ignored on
1413 reception.
1415 Nickname (2 octets) = RBridge nickname.
1417 8.4.9. Next Hop RBridge List TLV
1419 "Next Hop RBridge List TLV" identifies the nickname or nicknames
1420 of the downstream next hop RBridges. [RFC6325] allows a given
1421 RBridge to have multiple Equal Cost Paths to a specified
1422 destination. Each next hop RBridge is represented by one of its
1423 nicknames.
1425 "Next Hop RBridge List TLV" is an optional TLV. Multiple
1426 instances of this TLV MAY be included when there are more than
1427 255 Equal Cost Paths to the destination.
1429 1 2 3
1430 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
1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1432 | Type | Length | nOfnicknames |
1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1434 | nickname-1 | nickname-2 |
1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1436 . .
1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1438 | | nickname-n |
1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1441 Figure 17 Next Hop RBridge List TLV
1443 Type (1 octet) = TBDg indicates that this is the "Next nickname"
1445 Length (2 octets) = variable. Minimum value is 1.
1447 Nickname (2 octets) = 16 bit RBridge nickname.
1449 nOfnicknames (1 octet) = indicates number of nicknames included
1450 in this TLV. Zero (0) indicates no nicknames are included in the
1451 TLV. When this field is set to zero (0), length field MUST be set
1452 to 1.
1454 8.4.10. Multicast Receiver Port count TLV
1456 "Multicast Receiver Port Count TLV" identifies the number of
1457 ports interested in receiving the specified multicast stream
1458 within the responding RBridge on the label (VLAN or FGL)
1459 specified by the Diagnostic Label TLV.
1461 Multicast Receiver Port count is an Optional TLV.
1463 1 2 3
1464 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
1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1466 | Type | Length | Reserved |
1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1468 | number of Receivers |
1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1471 Figure 18 Multicast Receiver Availability TLV
1473 Type (1 octet) = TBDh indicates that this is the "Multicast
1474 Availability TLV"
1476 Length (2 octets) = 5.
1478 Reserved (1 octet) = set to zero on transmission and ignored on
1479 reception.
1481 Number of Receivers (4 octets) = Indicates the number of
1482 Multicast receivers available on the responding RBridge on the
1483 label specified by the diagnostic label.
1485 8.4.11. Flow Identifier (flow-id) TLV
1487 Flow Identifier (flow-id) uniquely identifies a specific flow.
1488 The flow-id value is unique per MEP and needs to be interpreted
1489 as such.
1491 1 2 3
1492 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
1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1494 | Type | Length | Reserved |
1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1496 | MEP-ID | flow-id |
1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1499 Figure 19 Flow Identifier TLV
1501 Type (1 octet) = TBDi
1503 Length (2 octets) = 5.
1505 Reserved (1 octet) set to 0 on transmission and ignored on
1506 reception.
1508 MEP-ID (2 octets) = MEP-ID of the originator [8021Q]. In TRILL
1509 MEP-ID can take a value from 1 to 65535.
1511 Flow-id (2 octets) = uniquely identifies the flow per MEP.
1512 Different MEPs may allocate the same flow-id value. The {MEP-ID,
1513 flow-id} pair is globally unique.
1515 Inclusion of the MEP-ID in the flow-id TLV allows the inclusion
1516 of a MEP-ID for messages that do not contain a MEP-ID in their
1517 OAM header. Applications may use MEP-ID information for different
1518 types of troubleshooting.
1520 8.4.12. Reflector Entropy TLV
1522 Reflector Entropy TLV is an optional TLV. This TLV, when present,
1523 tells the responder to utilize the Reflector Entropy specified
1524 within the TLV as the flow-entropy of the response message.
1526 1 2 3
1527 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
1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1529 | Type | Length | Reserved |
1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1531 | |
1532 . Reflector Entropy .
1533 | |
1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1536 Figure 20 Reflector Entropy TLV
1538 Type (1 octet) = TBDj Reflector Entropy TLV.
1540 Length (2 octets) = 97.
1542 Reserved (1 octet) = set to zero on transmission and ignored by
1543 the recipient.
1545 Reflector Entropy (96-octet) = Flow Entropy to be used by the
1546 responder. May be padded with zero if the desired flow entropy is
1547 less than 96 octets.
1549 8.4.13. Authentication TLV
1551 The Authentication TLV is an optional TLV that can appear in any
1552 OAM Message or Reply in TRILL.
1554 1 2 3
1555 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
1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1557 | Type | Length | Auth Type |
1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1559 | |
1560 . Authentication Value .
1561 | |
1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1564 Type (1 octet) = TBDk Authentication TLV.
1566 Length (2 octets) = variable length
1567 The Auth Type and following Authentication Value are the same as
1568 the Auth Type and following value for the [IS-IS] Authentication
1569 TLV. It is RECOMMENDED that Auth Type 3 be used. Auth Types 0, 1,
1570 2, and 54 MUST NOT be used. With Type 3, the Authentication TLV
1571 is as follows:
1573 1 2 3
1574 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
1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1576 | Type | Length | Auth Type = 3 |
1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1578 | Key ID | |
1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
1580 . Authentication Data (variable) .
1581 | |
1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1584 With Auth Type 3, the process is generally as specified in
1585 [RFC5310] using the same Key ID space as TRILL [IS-IS]. The area
1586 covered by the Authentication TLV is from the beginning of the
1587 TRILL Header to the end of the TRILL OAM Message Channel - the
1588 Link Header and Trailer are not included. The TRILL Header Alert
1589 and Reserved bit and Hop Count are treated as if zero for the
1590 purposes of computing and verifying the Authentication Data.
1592 Key distribution is out of scope for this document as the keying
1593 distributed for IS-IS is used.
1595 An RBridge supporting OAM authentication can be configured to
1596 either (1) ignore received OAM Authentication TLVs and not send
1597 them, (2) ignore received OAM Authentication TLVs but include
1598 them in all OAM packets sent, or (3) to include Authentication
1599 TLVs in all OAM messages sent and enforce authentication of OAM
1600 messages received. When an RBridge is enforcing authentication,
1601 it discards any OAM message subject to OAM processing that does
1602 not contain an Authentication TLV or if the Authentication TLV
1603 does not verify.
1605 9. Loopback Message
1607 9.1. Loopback OAM Message format
1609 1 2 3
1610 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
1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1612 |MD-L | Version | OpCode | Flags |FirstTLVOffset |
1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1614 | Loopback Transaction Identifier |
1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1616 | |
1617 . TLVs .
1618 | |
1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1621 Figure 21 Loopback OAM Message Format
1623 The above figure depicts the format of the Loopback Request and
1624 response messages as defined in [8021Q]. The Opcode for Loopback
1625 Message is set to 3 and the Opcode for the Reply Message is set
1626 to 2 [8021Q]. The Loopback Transaction Identifier (commonly
1627 called the Session Identification Number or Session ID in this
1628 document) is a 32-bit integer that allows the requesting RBridge
1629 to uniquely identify the corresponding session. Responding
1630 RBridges, without modification, MUST echo the received "Loopback
1631 Transaction Identifier" number.
1633 9.2. Theory of Operation
1635 9.2.1. Actions by Originator RBridge
1637 The originator RBridge takes the following actions:
1639 Identifies the destination RBridge nickname based on user
1640 specification or based on the specified destination MAC or IP
1641 address.
1643 Constructs the flow entropy based on user specified parameters or
1644 implementation specific default parameters.
1646 Constructs the TRILL OAM header: sets the opcode to Loopback
1647 message type (3)[8021Q]. Assigns applicable Loopback Transaction
1648 Identifier number for the request.
1650 The TRILL OAM Application Identifier TLV MUST be included and
1651 with the flags set to applicable values.
1653 Include following OAM TLVs, where applicable
1655 o Out of Band Reply Address TLV
1657 o Diagnostic Label TLV
1659 o Sender ID TLV
1661 Specify the Hop count of the TRILL data frame per user
1662 specification or utilize an applicable Hop count value.
1664 Dispatch the OAM frame for transmission.
1666 RBridges may continue to retransmit the request at periodic
1667 intervals, until a response is received or the re-transmission
1668 count expires. At each transmission Session Identification number
1669 MUST be incremented.
1671 9.2.2. Intermediate RBridge
1673 Intermediate RBridges forward the frame as a normal data frame
1674 and no special handling is required.
1676 9.2.3. Destination RBridge
1678 If the Loopback message is addressed to the local RBridge and
1679 satisfies the OAM identification criteria specified in section
1680 3.1. then, the RBridge data plane forwards the message to the CPU
1681 for further processing.
1683 The TRILL OAM application layer further validates the received
1684 OAM frame by checking for the presence of OAM-Ethertype at the
1685 end of the flow entropy. Frames that do not contain OAM-Ethertype
1686 at the end of the flow entropy MUST be discarded.
1688 Construction of the TRILL OAM response:
1690 TRILL OAM application encodes the received TRILL header and flow
1691 entropy in the Original payload TLV and includes it in the OAM
1692 message.
1694 Set the Return Code to (1) "Reply" and Return sub code to zero
1695 (0) "Valid Response". Update the TRILL OAM opcode to 2 (Loopback
1696 Message Reply)
1697 Optionally, if the VLAN/FGL identifier value of the received flow
1698 entropy differs from the value specified in the diagnostic Label,
1699 set the Label Error Flag on TRILL OAM Application Identifier TLV.
1701 Include the sender ID TLV (1)
1703 If in-band response was requested, dispatch the frame to the
1704 TRILL data plane with request-originator RBridge nickname as the
1705 egress RBridge nickname.
1707 If out-of-band response was requested, dispatch the frame to the
1708 IP forwarding process.
1710 10. Path Trace Message
1712 The primary use of the Path Trace Message is for fault isolation.
1713 It may also be used for plotting the path taken from a given
1714 RBridge to another RBridge.
1716 [8021Q] accomplishes the objectives of the TRILL Path Trace
1717 Message using Link Trace Messages. Link Trace Messages utilize a
1718 well-known multicast MAC address. This works for [8021Q], because
1719 for 802.1 both the unicast and multicast paths are congruent.
1720 However, in TRILL multicast and unicast are not congruent. Hence,
1721 TRILL OAM uses a new message format: the Path Trace message.
1723 The Path Trace Message has the same format as Loopback Message.
1724 The Opcode for Path Trace Reply is TBD1 and for Path Trace
1725 Message is TBD2.
1727 Operation of the Path Trace message is identical to the Loopback
1728 message except that it is first transmitted with a TRILL Header
1729 Hop count field value of 1. The sending RBridge expects an
1730 "Intermediate RBridge" Return sub-code from the next hop or a
1731 "Valid response" Return sub-Code response from the destination
1732 RBridge. If an "Intermediate RBridge" Return sub-code is
1733 received in the response, the originator RBridge records the
1734 information received from intermediate node that generated the
1735 message and resends the message by incrementing the previous Hop
1736 count value by 1. This process is continued until, a response is
1737 received from the destination RBridge or Path Trace process
1738 timeout occur or Hop count reaches a configured maximum value.
1740 10.1. Theory of Operation
1742 10.1.1. Action by Originator RBridge
1744 Identify the destination RBridge based on user specification or
1745 based on location of the specified MAC address.
1747 Construct the flow entropy based on user specified parameters or
1748 implementation specific default parameters.
1750 Construct the TRILL OAM header: Set the opcode to Path Trace
1751 Request message type (TBD2). Assign an applicable Session
1752 Identification number for the request. Return-code and sub-code
1753 MUST be set to zero.
1755 The TRILL OAM Application Identifier TLV MUST be included and set
1756 the flags to applicable values.
1758 Include following OAM TLVs, where applicable
1760 o Out of Band Reply Address TLV
1762 o Diagnostic Label TLV
1764 o Include the Sender ID TLV
1766 Specify the Hop count of the TRILL data frame as 1 for the first
1767 request.
1769 Dispatch the OAM frame to the TRILL data plane for transmission.
1771 An RBridge may continue to retransmit the request at periodic
1772 intervals, until a response is received or the re-transmission
1773 count expires. At each new re-transmission, the Session
1774 Identification number MUST be incremented. Additionally, for
1775 responses received from intermediate RBridges, the RBridge
1776 nickname and interface information MUST be recorded.
1778 10.1.2. Intermediate RBridge
1780 Path Trace Messages transit through Intermediate RBridges
1781 transparently, unless Hop-count has expired.
1783 TRILL OAM application layer further validates the received OAM
1784 frame by examining the presence of TRILL Alert Flag and OAM-
1785 Ethertype at the end of the flow entropy and by examining the MD
1786 Level. Frames that do not contain OAM-Ethertype at the end of the
1787 flow entropy MUST be discarded.
1789 Construction of the TRILL OAM response:
1791 TRILL OAM application encodes the received TRILL header and flow
1792 entropy in the Original payload TLV and include it in the OAM
1793 message.
1795 Set the Return Code to (1) "Reply" and Return sub code to zero
1796 (2) "Intermediate RBridge". Update the TRILL OAM opcode to TBD1
1797 (Path Trace Reply).
1799 If the VLAN/FGL identifier value of the received flow entropy
1800 differs from the value specified in the diagnostic Label, set the
1801 Label Error Flag on TRILL OAM Application Identifier TLV.
1803 Include following TLVs
1805 Previous RBridge nickname TLV (69)
1807 Reply Ingress TLV (5)
1809 Reply Egress TLV (6)
1811 Interface Status TLV (4)
1813 TRILL Next Hop RBridge (Repeat for each ECMP) (70)
1815 Sender ID TLV (1)
1817 If Label error detected, set C flag (Label error detected) in the
1818 version.
1820 If in-band response was requested, dispatch the frame to the
1821 TRILL data plane with request-originator RBridge nickname as the
1822 egress RBridge nickname.
1824 If out-of-band response was requested, dispatch the frame to the
1825 standard IP forwarding process.
1827 10.1.3. Destination RBridge
1829 Processing is identical to section 10.1.2. With the exception
1830 that TRILL OAM Opcode is set to Path Trace Reply (TBD1).
1832 11. Multi-Destination Tree Verification Message (MTVM)
1834 Multi-Destination Tree Verification messages allow verifying
1835 TRILL distribution tree integrity and pruning. TRILL VLAN/FGL and
1836 multicast pruning are described in [RFC6325] [RFC7180] and
1837 [RFC7172]. Multi-destination tree verification and Multicast
1838 group verification messages are designed to detect pruning
1839 defects. Additionally, these tools can be used for plotting a
1840 given multicast tree within the TRILL campus.
1842 Multi-Destination tree verification OAM frames are copied to the
1843 CPU of every intermediate RBridge that is part of the
1844 distribution tree being verified. The originator of the Multi-
1845 destination Tree verification message specifies the scope of
1846 RBridges from which a response is required. Only the RBridges
1847 listed in the scope field respond to the request. Other RBridges
1848 silently discard the request. Inclusion of the scope parameter is
1849 required to prevent receiving an excessive number of responses.
1850 The typical scenario of distribution tree verification or group
1851 verification, involves verifying multicast connectivity to a
1852 selected set of end-nodes as opposed to the entire network.
1853 Availability of the scope facilitates narrowing down the focus to
1854 only the RBridges of interest.
1856 Implementations MAY choose to rate-limit CPU bound multicast
1857 traffic. As a result of rate-limiting or due to other congestion
1858 conditions, MTVM messages may be discarded from time to time by
1859 the intermediate RBRidges and the requester may be required to
1860 retransmit the request. Implementations SHOULD narrow the
1861 embedded scope of retransmission request only to RBridges that
1862 have failed to respond.
1864 11.1. Multi-Destination Tree Verification Message (MTVM) Format
1866 Format of MTVM is identical to that of Loopback Message format
1867 defined in section 9. with the exception that the Op-Code used is
1868 TBD4.
1870 11.2. Theory of Operation
1872 11.2.1. Actions by Originator RBridge
1874 The user is required at a minimum to specify either the
1875 distribution trees that need to be verified, or the Multicast MAC
1876 address and VLAN/FGL, or VLAN/FGL and Multicast destination IP
1877 address. Alternatively, for more specific multicast flow
1878 verification, the user MAY specify more information e.g. source
1879 MAC address, VLAN/FGL, Destination and Source IP addresses.
1880 Implementations, at a minimum, must allow the user to specify a
1881 choice of distribution trees, Destination Multicast MAC address
1882 and VLAN/FGL that needs to be verified. Although, it is not
1883 mandatory, it is highly desired to provide an option to specify
1884 the scope. It should be noted that the source MAC address and
1885 some other parameters may not be specified if the Backwards
1886 Compatibility Method of Appendix A is used to identify the OAM
1887 frames.
1889 Default parameters MUST be used for unspecified parameters. Flow
1890 entropy is constructed based on user specified parameters and/or
1891 default parameters.
1893 Based on user specified parameters, the originating RBridge does
1894 the following:
1896 Identifies the nickname that represents the multicast tree.
1898 Obtains the applicable Hop count value for the selected
1899 multicast tree.
1901 Constructs TRILL OAM message header and include Session
1902 Identification number. Session Identification number facilitate
1903 the originator mapping the response to the correct request.
1905 Includes TRILL OAM Application Identifier TLV, which MUST be
1906 included.
1908 Includes the Op-Code Multicast Tree Verification Message
1909 (TBD4)
1911 Includes RBridge scope TLV (TBDe)
1913 Optionally, include following TLV, where applicable
1915 o Out-of-band IP address (TBDb)
1916 o Diagnostic Label (TBDd)
1918 o Sender ID TLV (1)
1920 Specify the Hop count of the TRILL data frame per user
1921 specification or alternatively utilize the applicable Hop count
1922 value if TRILL Hop count is not being specified by the user; and
1924 Dispatch the OAM frame to the TRILL data plane to be ingressed
1925 for transmission.
1927 The RBridge may continue to retransmit the request at a periodic
1928 interval until either a response is received or the re-
1929 transmission count expires. At each new re-transmission, the
1930 Session Identification number MUST be incremented. At each re-
1931 transmission, the RBridge may further reduce the scope to the
1932 RBridges that it has not received a response from.
1934 11.2.2. Receiving RBridge
1936 Receiving RBridges identify multicast verification frames per the
1937 procedure explained in sections 3.2.
1939 The RBridge validates the frame and analyzes the scope RBridge
1940 list. If the RBridge scope TLV is present and the local RBridge
1941 nickname is not specified in the scope list, it will silently
1942 discard the frame. If the local RBridge is specified in the scope
1943 list OR RBridge scope TLV is absent, the receiving RBridge
1944 proceeds with further processing as defined in section 11.2.3.
1946 11.2.3. In scope RBridges
1948 Construction of the TRILL OAM response:
1950 TRILL OAM application encodes the received TRILL header and flow
1951 entropy in the Original payload TLV and includes them in the OAM
1952 message.
1954 Set the Return Code to (0) and Return sub code to zero (0).
1955 Update the TRILL OAM opcode to TBD3 (Multicast Tree Verification
1956 Reply).
1958 Include following TLVs:
1960 Previous RBridge nickname TLV (TBDf)
1962 Reply Ingress TLV (5)
1963 Interface Status TLV (4)
1965 TRILL Next Hop RBridge List (TBDg)
1967 Sender ID TLV (1)
1969 Multicast Receiver Availability TLV (TBDh)
1971 If a Label (VLAN or FGL) cross connect error is detected, set the
1972 C flag (Cross connect error detected) in the Application
1973 Identifier TLV.
1975 If in-band response was requested, dispatch the frame to the
1976 TRILL data plane with request-originator RBridge nickname as the
1977 egress RBridge nickname.
1979 If out-of-band response was requested, dispatch the frame to the
1980 standard IP forwarding process.
1982 12. Application of Continuity Check Message (CCM) in TRILL
1984 Section 7. provides an overview of CCM Messages defined in
1985 [8021Q] and how they can be used within the TRILL OAM. This
1986 section, presents the application and Theory of Operations of CCM
1987 within the TRILL OAM framework. Readers are referred to [8021Q]
1988 for CCM message format and applicable TLV definitions and usages.
1989 Only the TRILL specific aspects are explained below.
1991 In TRILL, between any two given MEPs there can be multiple
1992 potential paths. Whereas in [8021Q], there is always a single
1993 path between any two MEPs at any given time. [RFC6905] requires
1994 solutions to have the ability to monitor continuity over one or
1995 more paths.
1997 CCM Messages are uni-directional, such that there is no explicit
1998 response to a received CCM message. Connectivity status is
1999 indicated by setting the applicable flags (e.g. RDI) of the CCM
2000 messages transmitted by an MEP.
2002 It is important that the solution presented in this document
2003 accomplishes the requirements specified in [RFC6905] within the
2004 framework of [8021Q] in a straightforward manner and with minimum
2005 changes. Section 8 above defines multiple flows within the CCM
2006 object, each corresponding to a flow that a given MEP wishes to
2007 monitor. Hence, CCM, in multipath environments like TRILL,
2008 monitors per flow connectivity and cross connect errors.
2010 Receiving MEPs do not cross check whether a received CCM belongs
2011 to a specific flow from the originating RBridge. Any attempt to
2012 track status of individual flows may explode the amount of state
2013 information that any given RBridge has to maintain.
2015 The obvious question arises: How does the originating RBridge
2016 know which flow or flows are at fault?
2018 This is accomplished with a combination of the RDI flag in the
2019 CCM header, flow-id TLV, and SNMP Notifications (Traps). Section
2020 12.1. below discuss the procedure.
2022 12.1. CCM Error Notification
2024 Each MEP transmits 4 CCM messages per each flow. ([8021Q] detects
2025 CCM fault when 3 consecutive CCM messages are lost). Each CCM
2026 Message has a unique sequence number (Session ID) and unique
2027 flow-identifier. The flow identifier is included in the OAM
2028 message via flow-id TLV.
2030 When an MEP notices a CCM timeout from a remote MEP (MEP-A), it
2031 sets the RDI flag on the next CCM message it generates.
2032 Additionally, it logs and sends SNMP notification that contain
2033 the remote MEP Identification, flow-id and the Sequence Number of
2034 the last CCM message it received and if available, the flow-id
2035 and the Sequence Number of the first CCM message it received
2036 after the failure. Each MEP maintains a unique flow-id per each
2037 flow, hence the operator can easily identify flows that
2038 correspond to the specific flow-id.
2040 The following example illustrates the above.
2042 Assume there are two MEPs, MEP-A and MEP-B.
2044 Assume there are 3 flows between MEP-A and MEP-B.
2046 Let's assume MEP-A allocates sequence numbers as follows
2048 Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-id=(1)
2050 Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-id=(2)
2052 Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-id=(3)
2054 Let's Assume Flow-2 is at fault.
2056 MEP-B, receives CCM from MEP-A with sequence numbers 1,2,3,4, but
2057 did not receive 5,6,7,8. CCM timeout is set to 3 CCM intervals in
2058 [8021Q]. Hence MEP-B detects the error at the 8'th CCM message.
2059 At this time the sequence number of the last good CCM message
2060 MEP-B has received from MEP-A is 4 and flow-id of the last good
2061 CCM Message is (1). Hence MEP-B will generate a CCM error SNMP
2062 notification with MEP-A and Last good flow-id (1) and sequence
2063 number 4.
2065 When MEP-A switches to flow-3 after transmitting flow-2, MEP-B
2066 will start receiving CCM messages. In the foregoing example it
2067 will be CCM message with Sequence Numbers 9,10,11,12,21 and so
2068 on. When in receipt of a new CCM message from a specific MEP,
2069 after a CCM timeout, the TRILL OAM will generate an SNMP
2070 Notification of CCM resume with remote MEP-ID and the first valid
2071 flow-id and the Sequence number after the CCM timeout. In the
2072 foregoing example, it is MEP-A, flow-id (3) and Sequence Number
2073 9.
2075 The remote MEP list under the CCM MIB Object is augmented to
2076 contain "Last Sequence Number", flow-id and "CCM Timeout"
2077 variables. Last Sequence Number and flow-id are updated every
2078 time a CCM is received from a remote MEP. CCM Timeout variable is
2079 set when the CCM timeout occurs and is cleared when a CCM is
2080 received.
2082 12.2. Theory of Operation
2084 12.2.1. Actions by Originator RBridge
2086 Derive the flow entropy based on flow entropy specified in the
2087 CCM Management object.
2089 Construct the TRILL CCM OAM header as specified in [8021Q].
2091 TRILL OAM Version TLV MUST be included as the first TLV and set
2092 the flags to applicable values.
2094 Include other TLVs specified in [8021Q]
2096 Include the following optional TLV, where applicable
2098 o Sender ID TLV (1)
2100 Specify the Hop count of the TRILL data frame per user
2101 specification or utilize an applicable Hop count value.
2103 Dispatch the OAM frame to the TRILL data plane for transmission.
2105 An RBridge transmits a total of 4 requests, each at CCM
2106 retransmission interval. At each transmission the Session
2107 Identification number MUST be incremented by one.
2109 At the 5'th retransmission interval, flow entropy of the CCM
2110 packet is updated to the next flow entropy specified in the CCM
2111 Management Object. If current flow entropy is the last flow
2112 entropy specified, move to the first flow entropy specified and
2113 continue the process.
2115 12.2.2. Intermediate RBridge
2117 Intermediate RBridges forward the frame as a normal data frame
2118 and no special handling is required.
2120 12.2.3. Destination RBridge
2122 If the CCM Message is addressed to the local RBridge or multicast
2123 and satisfies OAM identification methods specified in sections
2124 3.2. then the RBridge data plane forwards the message to the CPU
2125 for further processing.
2127 The TRILL OAM application layer further validates the received
2128 OAM frame by examining the presence of OAM-Ethertype at the end
2129 of the flow entropy. Frames that do not contain OAM-Ethertype at
2130 the end of the flow entropy MUST be discarded.
2132 Validate the MD-LEVEL and pass the packet to the Opcode de-
2133 multiplexer. The Opcode de-multiplexer delivers CCM packets to
2134 the CCM process.
2136 The CCM Process performs processing specified in [8021Q].
2138 Additionally the CCM process updates the CCM Management Object
2139 with the sequence number of the received CCM packet. Note: The
2140 last received CCM sequence number and CCM timeout are tracked per
2141 each remote MEP.
2143 If the CCM timeout is true for the sending remote MEP, then clear
2144 the CCM timeout in the CCM Management object and generate the
2145 SNMP notification as specified above.
2147 13. Fragmented Reply
2149 TRILL OAM allows Fragmented reply messages. In case of Fragmented
2150 Replies, all part of the reply MUST follow the procedure defined
2151 in this section.
2153 The same session Identification Number MUST be included in all
2154 related fragments of the same message.
2156 The TRILL OAM Application Identifier TLV MUST be included, with
2157 fragment-ID field monotonically increasing with each fragment
2158 transmitted with the appropriate Final Flag field. The Final
2159 Flag, MUST, only be equal to one on the final fragment of the
2160 reply.
2162 On the receiver, process MUST order the fragments based on the
2163 fragment id. Any fragments received after final fragment MUST be
2164 discarded. Messages with incomplete fragments (i.e. messages with
2165 one or missing fragments after the receipt of the fragment with
2166 the final flag set) MUST be discarded as well.
2168 If number of fragments exceed the maximum supported fragments
2169 (255), then return code of MUST be set according to the message
2170 and return sub code MUST be set to 1 indicating fragment limit
2171 exceed.
2173 14. Security Considerations
2175 Forged OAM packets could cause false error or failure indications
2176 or mask actual errors or failures or be used for denial of
2177 service. Source addresses for messages can be forged and the Out
2178 of Band reply facility (Section 8.4.4) provides for explicitly
2179 supplying the address for replies. For protection against forged
2180 OAM packets, the Authentication TLV (see Section 8.4.13) can be
2181 used in an OAM message in TRILL. This TLV depends on IS-IS keying
2182 material and the current state of IS-IS keying and the use of the
2183 virtually identical IS-IS Authentication TLV is analyzed in
2184 [KARPISIS]. In particular, there is currently no standardized IS-
2185 IS automated key management.
2187 Of course, authentication is ineffective unless verified and
2188 ineffective against senders who have the keying material needed
2189 to produce OAM messages that will pass authentication checks.
2190 Implementations MUST implement rate-limiting functionality to
2191 protect against exploitation of OAM messages as a means of denial
2192 of service attacks. Aggressive rate limiting may trigger false
2193 positive errors against CCM and LBM based session monitoring.
2195 Even with authentication, replay of authenticated messages may be
2196 possible. There are four types of messages: Continuity Check
2197 (CCM), Loopback, Path Trace, and Multi-Destination Tree
2198 Verification (MTVM). In the case of CCM messages, sequence
2199 numbers are required (see Section 12.1) that can protect against
2200 replay. In the case of Loopback Messages (see Section 9.1), a
2201 Loopback Transaction Identifier is included that, as required by
2202 [8021Q], is incremented with each transmission and can detect
2203 replays. Path Trace Messages (see Section 10) and MTVM (see
2204 section 11.1) are specified to have the same format, although
2205 with a different OpCodes, as the Loopback Message and so also
2206 have an identifier increment with each transmission that can
2207 detect replays. Thus all TRILL OAM messages have a field that can
2208 be used for replay protection.
2210 For general TRILL related security considerations, please refer
2211 to [RFC6325].
2213 [8021Q] requires that the MEP filters or pass through OAM
2214 messages based on the MD-Level. The MD-Level is embedded deep in
2215 the OAM message. Hence, conventional methods of frame filtering
2216 may not be able to filter frames based on the MD-Level. As a
2217 result, OAM messages that must be dropped due to MD level
2218 mismatch may leak into a TRILL domain with different MD-Level.
2220 This leaking may not cause any functionality loss. The receiving
2221 MEP/MIP is required to validate the MD-level prior to acting on
2222 the message. Any frames received with an incorrect MD-Level need
2223 to be dropped.
2225 Generally, a single operator manages each TRILL campus, hence
2226 there is no risk of security exposure. However, in the event of
2227 multi operator deployments, operators should be aware of possible
2228 exposure of device specific information and appropriate measures
2229 must be taken.
2231 It is also important to note that the MPLS OAM [RFC4379]
2232 framework does not include the concept of domains and OAM
2233 filtering based on operators. It is our opinion that the lack of
2234 OAM frame filtering based on domains does not introduce
2235 significant functional deficiency or security risk.
2237 It is possible to mandate requiring different credentials to use
2238 different OAM functions or capabilities within a specific OAM
2239 function. Implementations may consider grouping users to
2240 different security clearance levels and restricting functions and
2241 capabilities to different clearance levels. However, Exact
2242 implementation details of such a framework are outside the scope
2243 of this document.
2245 15. IANA Considerations
2247 IANA is requested to assign the following:
2249 15.1. OAM Capabilitiy Flags
2251 Assign two TRILL-VER sub-TLV Capability Flags (see Section 3.3)
2252 as follows:
2254 Bit Description Reference
2255 --- ----------- ---------
2257 TBD[2] OAM capable [this document]
2259 TBD[3] Backwards compatible OAM [this document]
2261 15.2. CFM Code Points
2263 IANA is requested to assign four Op-Codes from the CFM OAM IETF
2264 Op-Codes sub-registry as follows [suggested values in square
2265 brackets]:
2267 Value Assignment Reference
2268 ===== ========== =========
2270 TBD1[64] Path Trace Reply [this document]
2271 TBD2[65] Path Trace Message [this document]
2272 TBD3[66] Multicast Tree Verification Reply
2273 [this document]
2274 TBD4[67] Multicast Tree Verification Message
2275 [this document]
2277 IANA is requested to assign eleven TLV Types from the CFM OAM
2278 IETF TLV Types sub-registry as follows [suggested values in square
2279 brackets]:
2281 Value Assignment Reference
2282 ===== ========== =========
2284 TBDa[64] TRILL OAM Application Identifier TLV
2285 [this document]
2286 TBDb[65] Out of Band Reply Address TLV [this document]
2287 TBDc[66] Diagnostic Label TLV [this document]
2288 TBDd[67] Original Data Payload TLV [this document]
2289 TBDe[68] RBridge Scope TLV [this document]
2290 TBDf[69] Previous RBridge nickname TLV
2291 [this document]
2292 TBDg[70] Next Hop RBridge List TLV
2293 [this document]
2294 TBDh[71] Multicast Receiver Port count TLV
2295 [this document]
2296 TBDi[72] Flow Identifier TLV [this document]
2297 TBDj[73] Reflector Entropy TLV [this document]
2298 TBDk[74] Authentication TLV [this document]
2300 15.3. MAC Addresses
2302 IANA is requested to assigned a unicast and a multicast MAC
2303 address under the IANA OUI, for identification of OAM packets as
2304 discussed for the backward compatibility method (Appendix A,
2305 Section A.2) based on the request template in Appendix C. The
2306 assigned addresses are TBDmac1 [00-00-5E-90-01-00] (unicast) and
2307 TBDmac2 [01-5E-90-01-00] (multicast).
2309 15.4. Return codes and sub codes
2311 IANA is requested to create TRILL OAM Return Code registry within
2312 the TRILL Parameter Registry and, for each return code a separate
2313 sub code Sub-Registry as below:
2315 Registry: TRILL OAM Return Codes.
2316 Registration Procedure: Standards Action.
2318 Return Code Assignment References
2319 =========== ========== ==========
2320 0 Request message [this document]
2322 1 Reply message [this document]
2323 2-255 Unassigned [this document]
2325 Sub-Registry: Sub Codes for TRILL OAM Return Code 0.
2327 Registration Procedure: Standards Action.
2329 Sub Code Assignment References
2330 =========== ========== ==========
2331 0 Valid request [this document]
2332 1-255 Unassigned [this document]
2334 Sub-Registry: Sub Codes for TRILL OAM Return Code 1.
2336 Registration Procedure: Standards Action.
2338 Sub Code Assignment References
2339 =========== ========== ==========
2340 0 Valid response [this document]
2341 1 Fragment limit exceeded [this document]
2342 2 Intermediate RBridge [this document]
2343 3-255 Unassigned [this document]
2345 15.5. TRILL RBridge Nickname Address Family
2347 IANA has allocated 16396 as the Address Family Number for TRILL
2348 RBridge nicknames.
2350 16. References
2352 16.1. Normative References
2354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2355 Requirement Levels", BCP 14, RFC 2119, March 1997.
2357 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
2358 an IANA Considerations Section in RFCs", BCP 26, RFC
2359 5226, May 2008.
2361 [RFC5310] Bhatia, M., "IS-IS Cryptographic Generic Cryptographic
2362 Authentication", RFC 5310, February 2009.
2364 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base
2365 Protocol Specification", RFC 6325, July 2011.
2367 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
2368 and D. Dutt, "Transparent Interconnection of Lots of
2369 Links (TRILL): Fine-Grained Labeling", RFC 7172, May
2370 2014.
2372 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual
2373 Bridged Local Area Networks", IEEE Std 802.1Q-2011,
2374 August, 2011.
2376 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System
2377 to Intermediate System Intra-Domain Routing Exchange
2378 Protocol for use in Conjunction with the Protocol for
2379 Providing the Connectionless-mode Network Service (ISO
2380 8473)", 2002.
2382 16.2. Informative References
2384 [RFC4379] Kompella, K. et.al, "Detecting Multi-Protocol Label
2385 Switched (MPLS) Data Plane Failures", RFC 4379,
2386 February 2006.
2388 [RFC6291] Andersson, L., et.al., "Guidelines for the use of the
2389 "OAM" Acronym in the IETF" RFC 6291, June 2011.
2391 [RFC6361] Carlson, J. and Eastlake, D. "PPP Transparent
2392 Interconnection of Lots of Links (TRILL) Protocol
2393 Control Protocol", RFC 6361, August 201.
2395 [RFC6905] Senevirathne, T. et.al, "Requirements for Operations,
2396 Administration, and Maintenance (OAM) in Transparent
2397 Interconnection of Lots of Links (TRILL)", RFC 6905,
2398 March 2013.
2400 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D.,
2401 and A. Banerjee, "Transparent Interconnection of Lots
2402 of Links (TRILL) Use of IS-IS", RFC 7176 May 2014.
2404 [RFC7180] Eastlake, Donald, et.al. "TRILL: Clarifications,
2405 Corrections, and Updates, RFC 7180 May 2014.
2407 [RFC7174] Salam, S., et.al., "TRILL OAM Framework", RFC 7174 ,
2408 May 2014.
2410 [RFC7179] Eastlake, Donald, et.al. "TRILL: Header Extension", RFC
2411 7179, May 2014.
2413 [Y1731] ITU-T Recommendation Y.1731, "OAM functions and
2414 mechanisms for Ethernet based networks", ITU-T
2415 G.8013/Y.1731, July 2013.
2417 [RFC7178] D. Eastlake, et.al. , "TRILL: RBridge Channel Support",
2418 RFC 7178, May 2014.
2420 [TRILLOAMMIB] Deepak Kumar et.al, "TRILL OAM MIB", draft-deepak-
2421 trill-oam-mib, May 2013, work in progress.
2423 [KARPISIS] U. Chunduri, et.a., "KARP IS-IS security analysis",
2424 draft-karp-isis-analysis, September 2014, work in
2425 progress.
2427 17. Acknowledgments
2429 Work in this document was largely inspired by the directions
2430 provided by Stewart Bryant in finding a common OAM solution
2431 between SDOs.
2433 Acknowledgments are due for many who volunteered to review this
2434 document, notably, Jari Arkko, Adrian Farrel, Pete Resnick,
2435 Stephen Farrell, Dan Romascanu, Gayle Nobel and Tal Mizrahi.
2437 Special appreciations are due for Dinesh Dutt for his support and
2438 encouragement, especially during the initial discussion phase of
2439 TRILL OAM.
2441 This document was prepared using 2-Word-v2.0.template.dot.
2443 Appendix A. Backwards Compatibility
2445 Methodology presented above in this document is in-line with the
2446 [8021Q] framework for providing fault management coverage.
2447 However, in practice, some TRILL platforms may not have the
2448 capabilities to support some of the required techniques. In this
2449 section, we present a method that allows RBridges, which do not
2450 have the required hardware capabilities, to participate in the
2451 TRILL OAM solution.
2453 There are two broad areas to be considered; 1. Maintenance Point
2454 (MEP/MIP) Model 2. Data plane encoding and frame identification
2456 A.1 Maintenance Point (MEP/MIP) Model
2458 For backwards compatibility, MEPs and MIPs are located in the
2459 CPU. This will be referred to as the "central brain" model as
2460 opposed to "port brain" model.
2462 In the "central brain" model, an RBridge using either ACLs or
2463 some other method, forwards qualifying OAM messages to the CPU.
2464 The CPU then performs the required processing and multiplexing to
2465 the correct MP (Maintenance Point).
2467 Additionally, RBridges MUST have the capability to prevent the
2468 leaking of OAM packets, as specified in [RFC6905].
2470 A.2 Data plane encoding and frame identification
2472 The backwards compatibility method presented in this section
2473 defines methods to identify OAM frames when implementations do
2474 not have capabilities to utilize TRILL OAM Alert flag presented
2475 earlier to identify OAM frames, in the hardware.
2477 It is assumed ECMP path selection of non-IP flows utilize MAC DA,
2478 MAC SA and VLAN, IP Flows utilize IP DA, IP SA and TCP/UDP port
2479 numbers and other Layer 3 and Layer 4 information. The well-known
2480 fields to identify OAM flows are chosen such that they mimic the
2481 ECMP selection of the actual data along the path. However, it is
2482 important to note that, there may be implementations that would
2483 utilize these well-known fields for ECMP selections. Hence,
2484 implementations that support OAM SHOULD move to utilizing TRILL
2485 Alert Flag, as soon as possible and methods presented here SHOULD
2486 be used only as an interim solution.
2488 Identification methods are divided in to 4 broader groups:
2490 1. Identification of Unicast non-IP OAM Flows,
2492 2. Identification of Multicast non-IP OAM Flows,
2494 3. Identification of Unicast IP OAM Flows and
2496 4. Identification of Multicast IP OAM Flows
2498 As presented in the table below, based on the flow type (as
2499 defined above), implementations are required to use a well-known
2500 value in either the Inner.MacSA field or OAM Ethertype field to
2501 identify OAM flows.
2503 Receiving RBridge identifies OAM flows based on the presence of
2504 the well-known values in the specified fields, and additionally,
2505 for unicast flows, egress RBridge nickname of the packet MUST
2506 match that of the local RBridge or for multicast flows, TRILL
2507 header mutlicast flag MUST be set.
2509 Unicast OAM flows that qualify for local processing MUST be
2510 redirected to the OAM process and MUST NOT be forwarded (that to
2511 prevent leaking of the packet out of the TRILL campus).
2513 A copy of Multicast OAM flows that qualify for local processing
2514 MUST be sent to the OAM process and packet MUST be forwarded
2515 along the normal path. Additionally, methods MUST be in place to
2516 prevent multicast packets leaking out of the TRILL campus.
2518 The following table summarizes the identification of different
2519 OAM frames from data frames.
2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2522 |Flow Entropy |Inner |OAM Ether|Egress |
2523 | |MacSA |Type |nickname |
2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2525 |unicast no IP | N/A |Match |Match |
2526 | | | | |
2527 |Multicast no IP| N/A |Match |N/A |
2528 | | | | |
2529 |Unicast IP | Match |N/A |Match |
2530 | | | | |
2531 |Multicast IP | Match |N/A |N/A |
2532 | | | | |
2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2535 Figure 22 Identification of TRILL OAM Frames
2537 The unicast and multicast Inner.MacSAs used for the unicast and
2538 multicast IP cases, respectively, are TBDmac1 [00-00-5E-90-01-00]
2539 and TBDmac2 [01-00-5E-90-01-01] assigned by the request in
2540 Appendix C.
2542 It is important to note that all RBridges MUST generate OAM flows
2543 with "A" flag set and CFM EtherType "0x8902" at the flow entropy
2544 off-set. However, well-known values MUST be utilized as part of
2545 the flow-entropy when generating OAM messages destined for older
2546 RBridges that are compliant to the backwards compatibility method
2547 defined in this appendix.
2549 Appendix B. Base Mode for TRILL OAM
2551 CFM, as defined in [8021Q], requires configuration of several
2552 parameters before the protocol can be used. These parameters
2553 include MAID, Maintenance Domain Level (MD-LEVEL) and MEPIDs. The
2554 Base Mode for TRILL OAM defined here facilitates ease of use and
2555 provides out of the box plug-and-play capabilities, supporting
2556 the Operational and Manageability considerations described in
2557 Section 6 of [RFC7174].
2559 All RBridges that support TRILL OAM MUST support Base Mode
2560 operation.
2562 All Rbridges MUST create a default MA with MAID as specified
2563 herein.
2565 MAID [8021Q] has a flexible format and includes two parts:
2566 Maintenance Domain Name and Short MA name. In the Based Mode of
2567 operation, the value of the Maintenance Domain Name must be the
2568 character string "TrillBaseMode" (excluding the quotes "). In
2569 Base Mode operation Short MA Name format is set to 2-octet
2570 integer format (value 3 in Short MA Format field) and Short MA
2571 name set to 65532 (0xFFFC).
2573 The Default MA belongs to MD-LEVEL 3.
2575 In the Base Mode of operation, each RBridge creates a single UP
2576 MEP associated with a virtual OAM port with no physical layer
2577 (NULL PHY). The MEPID associated with this MEP is the 2-octet
2578 RBridge Nickname.
2580 By default, all RBridges operating in the Base Mode for TRILL OAM
2581 are able to initiate LBM, PT and other OAM tools with no
2582 configuration.
2584 Implementations MAY provide default flow-entropy to be included
2585 in OAM messages. Content of the default flow-entropy is outside
2586 the scope of this document.
2588 Figure 23, below depicts encoding of MAID within CCM messages.
2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2591 |Field Name |Size |
2592 | | |
2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2594 |Maintenance | 1 |
2595 |Domain Format | |
2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2597 |Maintenance | 2 |
2598 |Domain Length | |
2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2600 |Maintenance | variable|
2601 |Domain Name | |
2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2603 |Short MA | 1 |
2604 |Name Format | |
2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2606 |Short MA | 2 |
2607 |Name Length | |
2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2609 |Short MA | variable|
2610 |Name | |
2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2612 |Padding | Variable|
2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+
2615 Figure 23 MAID structure as defined in [8021Q]
2617 Maintenance Domain Name Format is set to Value: 4
2619 Maintenance Domain Name Length is set to value: 13
2621 Maintenance Domain Name is set to: TrillBaseMode
2623 Short MA Name Format is set to value: 3
2625 Short MA Name Length is set to value: 2
2627 Short MA Name is set to: FFFC
2629 Padding: set of zero up to 48 octets of total length of the MAID.
2631 Please refer to [8021Q] for details.
2633 Appendix C. MAC Addresses Request
2635 Applicant Name: IETF TRILL Working Group
2637 Applicant Email: tsenevir@cisco.com
2639 Applicant Telephone: +1-408-853-2291
2641 Use Name: TRILL OAM
2643 Document: draft-tissa-trill-oam-fm
2645 Specify whether this is an application for EUI-48 or EUI-64
2647 identifiers: EUI-48
2649 Size of Block requested: 1
2651 Specify multicast, unicast, or both: Both
2653 Authors' Addresses
2655 Tissa Senevirathne
2656 CISCO Systems
2657 375 East Tasman Drive.
2658 San Jose, CA 95134
2659 USA.
2661 Phone: +1 408-853-2291
2662 Email: tsenevir@cisco.com
2664 Norman Finn
2665 CISCO Systems
2666 510 McCarthy Blvd
2667 Milpitas, CA 95035
2668 USA
2670 Email: nfinn@cisco.com
2672 Samer Salam
2673 CISCO Systems
2674 595 Burrard St. Suite 2123
2675 Vancouver, BC V7X 1J1, Canada
2677 Email: ssalam@cisco.com
2679 Deepak Kumar
2680 CISCO Systems
2681 510 McCarthy Blvd,
2682 Milpitas, CA 95035, USA
2684 Phone : +1 408-853-9760
2685 Email: dekumar@cisco.com
2687 Donald Eastlake
2688 Huawei Technologies
2689 155 Beaver Street
2690 Milford, MA 01757
2692 Phone: +1-508-333-2270
2693 Email: d3e3e3@gmail.com
2694 Sam Aldrin
2695 Huawei Technologies
2696 2330 Central Express Way
2697 Santa Clara, CA 95951
2698 USA
2700 Email: aldrin.ietf@gmail.com
2702 Yizhou Li
2703 Huawei Technologies
2704 101 Software Avenue,
2705 Nanjing 210012
2706 China
2708 Phone: +86-25-56625375
2709 Email: liyizhou@huawei.com