idnits 2.17.1
draft-tissa-trill-oam-fm-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 28, 2013) is 3957 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)
-- Possible downref: Non-RFC (?) normative reference: ref. '8021Q'
-- Obsolete informational reference (is this intentional?): RFC 4379
(Obsoleted by RFC 8029)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 Deepak Kumar
5 CISCO
7 Donald Eastlake
8 Sam Aldrin
9 Yizhou Li
10 Huawei
12 May 28, 2013
13 Expires: November 2013
15 TRILL Fault Management
16 draft-tissa-trill-oam-fm-02.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 months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html
39 This Internet-Draft will expire on November 28, 2013.
41 Copyright Notice
43 Copyright (c) 2013 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Abstract
58 TRILL OAM Fault Management specification is presented in this
59 document. Methods in this document follow the IEEE 802.1 CFM
60 framework and reuse OAM tools where possible. Additional messages and
61 TLVs are defined for TRILL specific applications or where a different
62 set of information is required other than IEEE 802.1 CFM.
64 Table of Contents
66 1. Introduction...................................................4
67 2. Conventions used in this document..............................4
68 3. General Format of TRILL OAM frames.............................5
69 3.1. Identification of TRILL OAM frames........................7
70 3.2. Use of TRILL OAM Flag.....................................7
71 3.2.1. Handling of TRILL frames with the "A" Flag...........8
72 3.3. Backwards Compatibility Method............................8
73 3.4. OAM Capability Announcement..............................10
74 4. TRILL OAM Layering vs. IEEE Layering..........................11
75 4.1. Processing at ISS Layer..................................12
76 4.1.1. Receive Processing..................................12
77 4.1.2. Transmit Processing.................................12
78 4.2. End Station VLAN and Priority Processing.................12
79 4.2.1. Receive Processing..................................12
80 4.2.2. Transmit Procession.................................12
81 4.3. TRILL Encapsulation and De-capsulation Layer.............13
82 4.3.1. Receive Processing for Unicast packets..............13
83 4.3.2. Transmit Processing for unicast packets.............13
84 4.3.3. Receive Processing for Multicast packets............14
85 4.3.4. Transmit Processing of Multicast packets............15
86 4.4. TRILL OAM Layer Processing...............................16
87 5. Maintenance Associations (MA) in TRILL........................17
88 6. MEP Addressing................................................18
89 6.1. Use of MIP in TRILL......................................21
90 7. Approach for Backwards Compatibility..........................23
91 8. Continuity Check Message (CCM)................................24
92 9. TRILL OAM Message Channel.....................................26
93 9.1. TRILL OAM Message header.................................26
94 9.2. TRILL OAM Opcodes........................................27
95 9.3. Format of TRILL OAM TLV..................................27
96 9.4. TRILL OAM TLVs...........................................28
97 9.4.1. Common TLVs between 802.1ag and TRILL...............28
98 9.4.2. TRILL OAM Specific TLVs.............................29
99 9.4.3. TRILL OAM Application Identifier TLV................29
100 9.4.4. Out Of Band Reply Address TLV.......................31
101 9.4.5. Diagnostics Label TLV...............................31
102 9.4.6. Original Data Payload TLV...........................32
103 9.4.7. RBridge scope TLV...................................33
104 9.4.8. Previous RBridge nickname TLV.......................33
105 9.4.9. Next Hop RBridge List TLV...........................34
106 9.4.10. Multicast Receiver Port count TLV..................35
107 9.4.11. Flow Identifier (flow-id) TLV......................35
108 10. Loopback Message.............................................37
109 10.1. Loopback OAM Message format.............................37
110 10.2. Theory of Operation.....................................37
111 10.2.1. Originator RBridge.................................37
112 10.2.2. Intermediate RBridge...............................38
113 10.2.3. Destination RBridge................................38
114 11. Path Trace Message...........................................39
115 11.1. Theory of Operation.....................................39
116 11.1.1. Originator RBridge.................................39
117 11.1.2. Intermediate RBridge...............................40
118 11.1.3. Destination RBridge................................41
119 12. Multi-Destination Tree Verification (MTV) Message............41
120 12.1. Multi-Destination Tree Verification (MTV) OAM Message Format
121 ..............................................................42
122 12.2. Theory of Operation.....................................42
123 12.2.1. Originator RBridge.................................42
124 12.2.2. Receiving RBridge..................................44
125 12.2.3. In scope RBridges..................................44
126 13. Application of Continuity Check Message (CCM) in TRILL.......45
127 13.1. CCM Error Notification..................................45
128 13.2. Theory of Operation.....................................47
129 13.2.1. Originator RBridge.................................47
130 13.2.2. Intermediate RBridge...............................47
131 13.2.3. Destination RBridge................................47
132 14. Fragmented Reply.............................................48
133 15. Security Considerations......................................48
134 16. IEEE Allocation Considerations...............................48
135 17. IANA Considerations..........................................49
136 18. References...................................................49
137 18.1. Normative References....................................49
138 18.2. Informative References..................................49
140 19. Acknowledgments..............................................50
141 Appendix A. Unicast MAC Request..................................51
143 1. Introduction
145 The general structure of TRILL OAM messages is presented in
146 [TRLOAMFRM]. According to [TRLOAMFRM], TRILL OAM messages consist of
147 five parts: link header, TRILL header, flow entropy, OAM message
148 channel, and link trailer.
150 The OAM message channel allows defining various control information
151 and carrying OAM related data between TRILL switches, also known as
152 RBridges or Routing Bridges.
154 A common OAM message channel representation can be shared between
155 different technologies. This enables consistency between different
156 OAM technologies and promotes nested fault monitoring and isolation
157 between technologies that share the same OAM framework.
159 This document uses the message format defined in IEEE 802.1ag
160 Connectivity Fault Management (CFM) [8021Q] as the basis for the
161 TRILL OAM message channel.
163 The ITU-T Y.1731 [Y1731] standard utilizes the same messaging format
164 as [8021Q] and OAM messages where applicable. This documenttake a
165 similar stance and propose reusing [8021Q] in TRILL OAM. It is
166 assumed readers are familiar with [8021Q] and [Y1731]. Readers who
167 are not familiar with these documents are encouraged to review them.
169 2. Conventions used in this document
171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
173 document are to be interpreted as described in RFC-2119 [RFC2119].
175 Acronyms used in the document include the following:
177 MP - Maintenance Point [TRLOAMFRM]
179 MEP - Maintenance End Point [TRLOAMFRM] [8021Q]
181 MIP - Maintenance Intermediate Point [TRLOAMFRM] [8021Q]
183 MA - Maintenance Association [8021Q] [TRLOAMFRM]
185 MD - Maintenance Domain [8021Q]
186 CCM - Continuity Check Message [8021Q]
188 LBM - Loop Back Message [8021Q]
190 PTM - Path Trace Message
192 MTV - Multi-destination Tree Verification Message
194 OAM - Operations, Administration, and Maintenance [RFC6291]
196 TRILL - Transparent Interconnection of Lots of Links [RFC6325]
198 FGL - Fine Grained Label [RFCfgl]
200 ECMP - Equal Cost Multipath
202 ISS - Internal Sub Layer Service [8021Q]
204 3. General Format of TRILL OAM frames
206 The TRILL forwarding paradigm allows an implementation to select a
207 path from a set of equal cost paths to forward a unicast TRILL Data
208 packet. For multi-destination TRILL Data packets, a distribution tree
209 is chosen by the TRILL switch that ingresses or creates the packet.
210 Selection of the path of choice is implementation dependent at each
211 hop for unicast and at the ingress for multi-destination. However, it
212 is a common practice to utilize Layer 2 through Layer 4 information
213 in the frame payload for path selection.
215 For accurate monitoring and/or diagnostics, OAM Messages are required
216 to follow the same path as corresponding data packets. [TRLOAMFRM]
217 proposes a high-level format of the OAM messages. The details of the
218 TRILL OAM frame format are defined in this document.
220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
221 | |
222 . Link Header . (variable)
223 | |
224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
225 | |
226 + TRILL Header + 8 or more bytes
227 | |
228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
229 | |
230 . Flow Entropy . 96 bytes
231 . .
232 | |
233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
234 | OAM Ether Type |
235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
236 | |
237 . OAM Message Channel . Variable
238 . .
239 | |
240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
241 | Link Trailer | Variable
242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244 Figure 1 Format of TRILL OAM Messages
246 Link Header: Media-dependent header. For Ethernet, this includes
247 Destination MAC, Source MAC, VLAN (optional) and EtherType fields.
249 TRILL Header: Minimum of 8 bytes when the Extended Header is not
250 included [RFC6325]
252 Flow Entropy: This is a 96-byte fixed size field. The least
253 significant bits of the field MUST be padded with zeros, up to 96
254 bytes, when the flow entropy is less than 96 bytes. Flow entropy
255 enables emulation of the forwarding behavior of the desired data
256 packets. The Flow Entropy field starts with the Inner.MacDA. The
257 offset of the Inner.MacDA depends on whether extensions are included
258 or not as specified in [TRILLEXT] and [RFC6325].
260 OAM Ether Type: OAM Ether Type is 16-bit EtherType that identifies
261 the OAM Message channel that follows. This document specifies using
262 the EtherType allocated for 802.1ag for this purpose. Identifying the
263 OAM Message Channel with a dedicated EtherType allows the easy
264 identification of the beginning of the OAM message channel across
265 multiple standards.
267 OAM Message Channel: This is a variable size section that carries OAM
268 related information. Message format defined in [8021Q] will be reused
269 for TRILL OAM.
271 Link Trailer: Media-dependent trailer. For Ethernet, this is the FCS
272 (Frame Check Sequence).
274 3.1. Identification of TRILL OAM frames
276 TRILL, as originally specified in [RFC6325], did not have a specific
277 flag or a method to identify OAM frames. This document updates
278 [RFC6325] to include specific methods to identify TRILL OAM frames.
279 Section 3.2. below explains the details of the method. However, it is
280 important, for backwards compatibility reasons, to define methods of
281 identifying TRILL OAM frames without using these extensions. Section
282 3.3. presents a set of possible methods for identifying OAM frames
283 without using the proposed extensions of section 3.2. The methods
284 defined in section 3.3. impose limitations on the construction of the
285 flow entropy field of the OAM frames but MUST be used when backward
286 compatibility is required with TRILL switches not supporting the
287 method specified in Section 3.2.
289 3.2. Use of TRILL OAM Flag
291 The TRILL Header, as defined in [RFC6325], has two reserved bits that
292 are currently unused. RBridges are currently required to ignore these
293 fields. This document specifies use of the reserved bit next to
294 Version field in the TRILL header as the Alert flag. Alert flag will
295 be denoted by "A".
297 Implementations that support the extension of using the "A" flag to
298 identify frames MUST use that flag and the methods specified in
299 section 3.2.1. The "A" flag MUST NOT be utilized for forwarding
300 decisions such as the selection of which ECMP path or multi-
301 destination tree to use.
303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
304 | V |A|R|M|Op-Length| Hop Count |
305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306 | Egress RBridge Nickname | Ingress RBridge Nickname |
307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308 | Options...
309 +-+-+-+-+-+-+-+-+-+-+-+-
311 Figure 2 TRILL Header
313 A (1 bit) - Indicates this is a possible OAM frame and is subject to
314 specific handling as specified in this document.
316 All other fields carry the same meaning as defined in RFC6325.
318 3.2.1. Handling of TRILL frames with the "A" Flag
320 Value "1" in the A flag indicates TRILL frames that may qualify as
321 OAM frames. Implementations are further required to validate such
322 frames by comparing the value at the OAM Ether Type (Figure 1)
323 location with the CFM EtherType "0x8902" [8021Q]. If the value
324 matches, such frames are identified as TRILL OAM frames and SHOULD be
325 processed as discussed in Section 4.
327 3.3. Backwards Compatibility Method
329 Backward compatibility method presented in this section defines
330 methods to identify OAM frames when implementations do not have
331 capabilities to utilize TRILL OAM Alert flag presented earlier. It is
332 assumed ECMP path selection of non-IP flows utilize MAC DA, MAC SA
333 and VLAN, IP Flows utilize IP DA, IP SA and TCP/UDP port numbers and
334 other Layer 3 and Layer 4 information. The well-known fields to
335 identify OAM flows are chosen such that, they mimic the ECMP
336 selection of the actual data along the path. However, it is important
337 to note that, there may be implementations that would utilize these
338 well-known fields for ECMP selections. Hence, implementations that
339 support OAM SHOULD move to utilizing TRILL OAM Flag, as soon as
340 possible and methods presented here SHOULD be used only as an interim
341 solution.
343 Identification methods are divided in to 4 broader groups.
345 Identification of Unicast non-IP OAM Flows,
346 Identification of Multicast non-IP OAM Flows,
348 Identification of Unicast IP OAM Flows and
350 Identification of Multicast IP OAM Flows
352 As presented in the table below, based on the flow type (as defined
353 above), implementations are required to use a well-known value in
354 either the source MAC field or Ethertype field to identify OAM flows.
356 Receiving RBridges identifies OAM flows based on the presence of the
357 well-known values in the specified fields, AND additionally, for
358 unicast flows, egress RBRdige nickname of the packet MUST match that
359 of the local RBRidge or for multicast flows, TRILL header mutlicast
360 flag MUST be set.
362 Unicast OAM flows that qualify for local processing MUST be
363 redirected to the OAM process and MUST NOT be forward along (that to
364 prevent leaking of the packet out of the TRILL campus).
366 A copy of Multicast OAM flows that qualify for local processing MUST
367 be sent to the OAM process and packet MUST be forwarded along the
368 normal path. Additionally, methods MUST be in place to prevent
369 multicast packets leaking out of the TRILL campus.
371 The following table summarizes the identification of different OAM
372 frames from data frames.
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 |Flow Entropy |Inner |OAM Ether|Egress |
376 | |MacSA |Type |nickname |
377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378 |unicast no IP | N/A |Match |Match |
379 | | | | |
380 |Multicast no IP| N/A |Match |N/A |
381 | | | | |
382 |Unicast IP | Match |N/A |Match |
383 | | | | |
384 |Multicast IP | Match |N/A |N/A |
385 | | | | |
386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
388 Figure 3 Identification of TRILL OAM Frames
390 3.4. OAM Capability Announcement
392 Any given TRILL RBridge can be (1) OAM incapable or (2) OAM capable
393 with new extensions or (3) OAM capable with backwards-compatible
394 method. The OAM request originator, prior to origination of the
395 request is required to identify the OAM capability of the target and
396 generate the appropriate OAM message.
398 Capability flags defined in TRILL version sub-TLV (TRILL-VER)
399 [rfc6326bis] will be utilized for announcing OAM capabilities. The
400 following OAM related Flags are defined:
402 O - OAM Capable
404 B - Backwards Compatible.
406 A capability announcement, with O Flag set to 1 and B flag set to 1,
407 indicates that the implementation is OAM capable but utilize
408 backwards compatible method defined in section 3.3. A capability
409 announcement, with O Flag set to 1 and B flag set to 0, indicates
410 that the implementation is OAM capable and utilizes the method
411 specified in section 3.2.
413 When O Flag is set to 0, the announcing implementation is considered
414 not capable of OAM and in this case the B flag is ignored.
416 +-+-+-+-+-+-+-+-+
417 | Type | (1 byte)
418 +-+-+-+-+-+-+-+-+
419 | Length | (1 byte)
420 +-+-+-+-+-+-+-+-+
421 | Max-version | (1 byte)
422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
423 |A|O|B|Other Capabilities and Header Flags| (4 bytes)
424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
425 0 1 3
426 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
428 Figure 4 TRILL-VER sub-TLV [rfc6326bis] with O and B flags
430 NOTE: Bit position of O and B flags in the TRILL-VER sub-TLV are
431 presented above as an example. Actual positions of the flags will be
432 determined by TRILL WG and IANA and future revision of this document
433 will be updated to include the allocations.
435 4. TRILL OAM Layering vs. IEEE Layering
437 This section presents the placement of the TRILL OAM shim within the
438 IEEE 802.1 layers. The processing of both the Transmit and Receive
439 directions is explained.
441 +-+-+-+-+-+-+-+-+-+-+
442 | RBridge Layer |
443 | Processing |
444 +-+-+-+-+-+-+-+-+-+-+
445 |
446 |
447 +-+-+-+-+-+-+
448 | TRILL OAM | UP MEP
449 | Layer | MIP
450 +-+-+-+-+-+-+ Down MEP
451 |
452 |
453 +-+-+-+-+-+-+
454 (3)--------> | TRILL |
455 | Encap/Decap
456 +-+-+-+-+-+-+
457 |
458 +-+-+-+-+-+-+
459 (2)--------> |End station|
460 | VLAN & priority Processing
461 +-+-+-+-+-+-+
462 |
463 +-+-+-+-+-+-+
464 (1)--------> |ISS |
465 |Processing |
466 +-+-+-+-+-+-+
467 |
468 |
469 |
471 Figure 5 Placement of TRILL MP within IEEE 802.1
473 [RFC6325] Section 4.6 provides a detailed explanation of frame
474 processing. Please refer to [RFC6325] for processing scenarios not
475 covered herein.
477 Sections 4.1 and 4.2 below apply to links using a broadcast LAN
478 technology such as Ethernet.
480 On links using an inherently point-to-point technology, such as PPP
481 [RFC6361], there is no Outer.MacDA, Outer.MacSA, our Outer.VLAN
482 because these are part of the link for Ethernet. Point-to-point links
483 typically have link headers without these fields. These fields are
484 primarily significant for native frames from and/or to end stations.
486 4.1. Processing at ISS Layer
488 4.1.1. Receive Processing
490 The ISS Layer receives an indication from the port. It extracts DA,
491 SA and marks the remainder of the payload as M1. ISS Layer passes on
492 (DA,SA,M1) as an indication to the higher layer.
494 For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA. M1 is
495 the remainder of the packet.
497 4.1.2. Transmit Processing
499 The ISS layer receives an indication from the higher layer that
500 contains (DA, SA, M1). It constructs an Ethernet frame and passes
501 down to the port.
503 4.2. End Station VLAN and Priority Processing
505 4.2.1. Receive Processing
507 Receives (DA, SA, M1) indication from ISS Layer. Extracts the VLAN ID
508 an priority from the M1 part of the received indication and
509 constructs (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 map to M1 in the
510 received indication. Pass (DA, SA, VLAN, PRI, M2) to the TRILL
511 encap/decap procession layer.
513 4.2.2. Transmit Procession
515 Receive (DA, SA, VLAN, PRI, M2) indication from TRILL encap/decap
516 processing layer. Merge VLAN, M2 to form M1. Pass down (DA, SA, M1)
517 to the ISS processing Layer.
519 4.3. TRILL Encapsulation and De-capsulation Layer
521 4.3.1. Receive Processing for Unicast packets
523 Receive indication (DA, SA, VLAN,PRI,M2) from End Station VLAN and
524 Priority Processing Layer.
526 o If DA matches port Local DA and Frame is of TRILL EtherType
528 . Discard DA, SA, VLAN, PRI. From M2, derive (TRILL-HDR, iDA,
529 iSA, i-VL, M3)
531 . If TRILL nickname is Local and TRILL-OAM Flag is set
533 Pass on to OAM processing
535 . Else pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to RBridge
536 Layer
538 o If DA matches port Local DA and EtherType is RBridge-Channel
539 [Channel]
541 . Process as a possible unicast native RBridge Channel packet
543 o If DA matches port Local DA and EtherType is neither TRILL nor
544 RBridge-Channel
546 . Discard packet
548 o If DA does not match and port is Appointed Forwarder for VLAN and
549 EtherType is not TRILL or RBridge-Channel
551 . Insert TRILL-Hdr and send (TRILL-HDR, iDA, iSA,i-VL, M3)
552 indication to RBridge Layer <- This is the ingress function
554 4.3.2. Transmit Processing for unicast packets
556 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge
557 Layer
559 o If egress TRILL nickname is local
561 o If port is Appointed Forwarder for iVL and the port is not
562 configured as a trunk or p2p port and (TRILL Alert Flag set
563 and OAM EtherType present) then
565 . Strip TRILL-HDR and construct (DA, SA, VLAN, M2)
567 o Else
569 . Discard packet
571 o If egress TRILL nickname is not local
573 o Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, TRILL EtherType
574 and construct (DA,SA,VLAN,M2). Where M2 is (TRILL-HDR, iDA,
575 iSA, iVL, M)
577 o Forward (DA,SA,V,M2) to the VLAN End Station processing Layer.
579 4.3.3. Receive Processing for Multicast packets
581 o Receive (DA,SA,V,M2) from VLAN aware end station processing
582 layer
584 o If the DA is All-RBridges and the EtherType is TRILL
586 o Strip DA,SA and V. From M2, extract (TRILL-HDR, iDA, iSA,
587 iVL and M3).
589 o If TRILL OAM Flag is set and OAM EtherType is present at the
590 end of Flow entropy
592 . Perform OAM Processing
594 o Else extract the TRILL header, inner MAC addresses and inner
595 VLAN and pass indication (TRILL-HDR, iDA, iSA, iVL and M3)
596 to TRILL RBridge Layer
598 o If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS
599 then pass frame up to TRILL IS-IS processing
601 o If the DA is All-RBridges or All-IS-IS-RBridges but Ethertype
602 is not TRILL or L2-IS-IS respectively
604 o Discard the packet
606 o If the EtherType is TRILL but the multicast DA is not All-
607 RBridge or if the EtherType is L2-IS-IS but the multicast Da is
608 not All-IS-IS-RBridges
610 o Discard the packet
612 o If DA is All-Edge-RBridges and EtherType is RBridge-Channel
613 [Channel]
614 o Process as a possible multicast native RBridge Channel
615 packet
617 o If the DA is in the initial bridging/link protocols block (01-
618 80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL block
619 and not assigned for Outer.MacDA use (01-80-C2-00-00-42 to 01-
620 80-C2-00-00-4F) then
622 o The frame is not propagated through an RBridge although some
623 special processing may be done at the port as specified in
624 [RFC6325] and the frame may be dispatched to Layer 2
625 processing at the port if certain protocols are supported
626 by that port (examples: Link Aggregation Protocol, Link
627 Layer Discovery Protocol).
629 o If the DA is some other multicast value
631 o Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL,
632 M3)
634 o Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to RBridge Layer
636 4.3.4. Transmit Processing of Multicast packets
638 The following ignores the case of transmitting TRILL IS-IS packets.
640 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge
641 layer.
643 o If TRILL-HDR multicast flag set and TRILL-HDR Alert flag set
644 and OAM EtherType present then:
646 o (DA,SA,V,M2) by inserting TRILL Outer.MacDA of All-
647 RBridges, Outer.MacSA, Outer.VL and TRILL EtherType. M2
648 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M)
650 NOTE: Second copy of native format is not made.
652 o Else If TRILL-HDR multicast flag set and Alert flag not set
654 o If the port is appointed Forwarder for iVL and the port is
655 not configured as a trunk port or a p2p port, Strip TRILL-
656 HDR, iSA, iDA, iVL and construct (DA,SA,V,M2) for native
657 format.
659 o Make a second copy (DA,SA,V,M2) by inserting TRILL
660 Outer.MacDA, Outer.MacSA, Outer.VL and TRILL EtherType. M2
661 here is (EtherType TRILL, TRILL-HDR, iDA, iSA, iVL, M)
663 o Pass the indication (DA,SA,V,M2) to End Station VLAN processing
664 layer.
666 4.4. TRILL OAM Layer Processing
668 TRILL OAM Processing Layer is located between the TRILL Encapsulation
669 / De-capsulation layer and RBridge Layer. It performs 1.
670 Identification of OAM frames that need local processing 2. Perform
671 OAM processing or redirect to the CPU for OAM processing.
673 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge
674 layer.
676 o If the TRILL Multicast Flag is set and TRILL Alert Flag is set
677 and TRILL OAM EtherType is present then
678 o If MEP or MIP is configured on the Inner.VLAN of the packet
679 then
680 . discard packets that have MD-LEVEL Less than that of
681 the MEP or packets that do not have MD-LEVEL present
682 (e.g due to packet truncation).
683 . If MD-LEVEL matches MD-LEVEL of the MEP then
684 . Re-direct to OAM Processing (Do not forward
685 further)
686 . If MD-LEVEL matches MD-LEVEL of MIP then
687 . Make a Copy for OAM processing and continue
689 o Else if TRILL Alert Flag is set and TRILL OAM EtherType is
690 present then
691 o If MEP or MIP is configured on the Inner.VLAN of the packet
692 then
693 . discard packets that have MD-LEVEL not present or MD-
694 LEVEL is Less than that of the MEP.
695 . If MD-LEVEL matches MD-LEVEL of the MEP then
696 . Re-direct to OAM Processing (Do not forward
697 further)
698 . If MD-LEVEL matches MD-LEVEL of MIP then
699 . Make a Copy for OAM processing and continue
701 o Else // Non OAM l Packet
702 o Continue
704 o Pass the indication (DA,SA,V,M2) to End Station VLAN processing
705 layer.
707 NOTE: In the Received path, processing above compares against Down
708 MEP and MIP Half functions. In the transmit processing it compares
709 against Up MEP and MIP Half functions.
711 Appointed Forwarder is a Functionality that TRILL Encap/De-Cap layer
712 performs. The TRILL Encap/De-cap Layer is responsible for prevention
713 of leaking of OAM packets as native frames.
715 5. Maintenance Associations (MA) in TRILL
717 [8021Q] defines a maintenance association as a logical relationship
718 between a group of nodes. Each Maintenance Association (MA) is
719 identified with a unique MAID of 48 bytes [8021Q]. CCM and other
720 related OAM functions operate within the scope of an MA. The
721 definition of MA is technology independent. Similarly it is encoded
722 within the OAM message, not in the technology dependent portion of
723 the packet. Hence the MAID as defined in [8021Q] can be utilized for
724 TRILL OAM, without modifications. This also allows us to utilize CCM
725 and LBM messages defined in [8021Q], as is.
727 In TRILL, an MA may contain two or more RBridges (MEPs). For unicast,
728 it is likely that the MA contains exactly two MEPs that are the two
729 end-points of the flow. For multicast, the MA may contain two or more
730 MEPs.
732 For TRILL, in addition to all of the standard 802.ag MIB definitions,
733 each MEP's MIB contains one or more flow entropy definitions
734 corresponding to the set of flows that the MEP monitors.
736 [8021Q] MIB is augmented to add the TRILL specific information.
737 Figure 6, below depicts the augmentation of the CFM MIB to add the
738 TRILL specific Flow Entropy.
740 MA---
741 |
742 --- MEP
743 |
744 . - Remote MEP List
745 .
746 |
747 --- MEP-A
748 |
749 --- MEP-B
750 .
752 |
753 . - Flow Entropy List { Augments IEEE8021-CFM-MIB}
755 |
756 --- (Flow Entropy-1)
757 |
758 --- (Flow-entropy-2)
759 |
760 . --- ( Flow Entropy n)
761 |
762 Other MIB entries
764 Figure 6 Correlation of TRILL augmented MIB
766 6. MEP Addressing
768 In IEEE 802.1ag [8021Q], OAM messages address the target MEP by
769 utilizing a unique MAC address. In TRILL MEP is addressed by
770 combination of the egress RBridge nickname and the Inner VLAN/FGL.
772 At the MEP, OAM packets go through a hierarchy of op-code de-
773 multiplexers. The op-code de-multiplexers channel the incoming OAM
774 packets to the appropriate message processor (e.g. LBM) The reader
775 may refer to Figure 7 below for a visual depiction of these different
776 de-multiplexers.
778 1. Identify the packets that need OAM processing at the Local RBridge
779 as specifies in Section 4.
781 a. Identify the MEP that is associated with the Inner.VLAN.
783 2. The MEP first validates the MD-LEVEL and then
785 a. Redirect to MD-LEVEL De-multiplexer
787 3. MD-LEVEL de-multiplexer compares the MD-Level of the packet
788 against the MD level of the local MEPs of a given MD-Level on the
789 port (Note: there can be more than one MEP at the same MD-Level
790 but belonging to different MAs)
792 a. If the packet MD-LEVEL is equal to the configured MD-LEVEL
793 of the MEP, then pass to the Opcode de-multiplexer
795 b. If the packet MD-LEVEL is less than the configured MD-LEVEL
796 of the MEP, discard the packet
798 c. If the packer MD-LEVEL is greater than the configured MD-
799 LEVEL of the MEP, then pass on to the next higher MD-LEVEL
800 de-multiplexer, if available. Otherwise, if no such higher
801 MD-LEVEL de-multiplexer exists, then forward the packet as
802 normal data.
804 4. Opcode De-multiplexer compares the opcode in the packet with
805 supported opcodes
807 a. If Op-code is CCM, LBM, LBR, PTM, PTR, MTVM, MTVR, then pass
808 on to the correct Processor
810 b. If Op-code is Unknown, then discard.
812 |
813 .CCM LBM PTM MTV
814 | | | |
815 +-+-+-+-+-+-+-+-+-+-+-+-+
816 | OP Code DE-Mux |--- Unknown
817 +-+-+-+-+-+-+-+-+-+-+-+-+
818 ^ ^ ^
819 MD==Li | | |
820 +-+-+ +-+-+ +-+-+
821 | L |-->|L2 |-.- |Ln |---- >
822 +-+-+ +-+-+ +-+-+ |
823 | ^ | | |
824 MD
| T |----------------- >| M |--- >
831 + TRILL OAM ---- + pass through OAM ----
833 Figure 7 OAM De-Multiplexers at MEP for active SAP
835 T : Denotes Tap, that identifies OAM frames that need local
836 processing. These are the packets with OAM flag set AND OAM
837 Ether type is present after the flow entropy of the packet
839 M : Is the post processing merge, merges data and OAM messages
840 that are pass through. Additionally, Merge the component
841 ensures, as explained earlier, that OAM packets are not
842 forwarded out as native frames.
844 L : Denotes MD-Level processing. Packets with MD-Level less than
845 the Level will be dropped. Packets with equal MD-Level are
846 passed on to the opcode de-multiplexer. Others are passed on to
847 the next level MD processors or eventually to the merge point
848 (M).
850 NOTE: LBM, MTV and PT are not subject to MA de-multiplexers.
851 These packets do not have an MA encoded in the packet. Adequate
852 response can be generated to these packets, without loss of
853 functionality, by any of the MEPs present on that interface or
854 an entity within the RBridge.
856 6.1. Use of MIP in TRILL
858 Maintenance Intermediate Points (MIP) are mainly used for fault
859 isolation. Link Trace Messages in [8021Q] utilize a well-known
860 multicast MAC address and MIPs generate responses to Link Trace
861 messages. Response to Link Trace messages or lack thereof can be used
862 for fault isolation in TRILL.
864 As explained in section 11. , hop-count expiry approach will be
865 utilized for fault isolation and path tracing. The approach is very
866 similar to the well-known IP trace-route approach. Hence, explicit
867 addressing of MIPs is not required for the purpose of fault
868 isolation.
870 Any given RBridge can have multiple MIPs located within an interface.
871 As such, a mechanism is required to identify which MIP should respond
872 to an incoming OAM message.
874 Similar approach as presented above for MEPs can be used for MIP
875 processing. It is important to note that "M", the merge block of a
876 MIP, does not prevent OAM packets leaking out as native frames. On
877 edge interfaces, MEPs MUST be configured to prevent the leaking of
878 TRILL OAM packets out of the TRILL Campus.
880 PT MTV
881 | |
882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
883 | OP Code De-Mux |-> Unknown
884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
885 ^ ^ ^
886 MD==Li | | |
887 +-+-+ +-+-+ +-+-+
888 | L |- >|L2 |-.- |Ln |------+
889 +-+-+ +-+-+ +-+-+ |
890 ^ |
891 | |
892 Drop | |
893 MD not --- |TRILL OAM |
894 Present | |
895 | v
896 TRILL Data ---- TRILL Data -----
897 ------- >| T |------------------ >| M |---->
898 + TRILL OAM ---- ----
900 Figure 8 OAM De-Multiplexers at MIP for active SAP
902 T: TAP processing for MIP. All packets with OAM flag set are
903 captured.
905 L : MD Level Processing, Packet with matching MD Level are "copied"
906 to the Opcode de-multiplexer and original packet is passed on to the
907 next MD level processor. Other packets are simply passed on to the
908 next MD level processor, without copying to the OP code de-
909 multiplexer.
911 M : Merge processor, merge OAM packets to be forwarded along with the
912 data flow.
914 Packets that carry Path Trace Message (PTM) or Multi-destination Tree
915 Verification (MTV) OpCode are passed on to the respective processors.
917 Packets with unknown OpCodes are counted and discarded.
919 7. Approach for Backwards Compatibility
921 Methodology presented above in this document is in-line with the
922 [8021Q] framework for providing fault management coverage. However,
923 in practice, some platforms may not have the required capabilities to
924 support some of the proposed techniques. In this section, we present
925 a method that allows RBridges, which do not have the required
926 hardware capabilities, to participate in the proposed OAM solution.
928 For backwards compatibility, MEPs and MIPs are located in the CPU.
929 This will be referred to as the "central brain" model as opposed to
930 "port brain" model.
932 In the "central brain" model, an RBridge using either ACLs or some
933 other method, forwards qualifying OAM messages to the CPU. The CPU
934 then performs the required processing and multiplexing to the correct
935 MP (Maintenance Point).
937 Additionally, RBridges MUST have the capability to prevent the
938 leaking of OAM packets, as specified in [RFC6905] and in the
939 Transmission processing in Figure 9.
941 Receiver Processing:
943 If (M==1 && F==1) then
944 Copy to CPU and Forward normally as defined in [RFC6325]
945 Else if (M==0 && F==1 && egress nickname is the processing RBridge)
946 then
947 Forward to CPU BUT DO NOT forward along the data plane
949 Else
950 Forward as defined in [RFC6325]
951 End;
953 Transmit Processing:
955 If (F==1) then
956 Forward as defined in [RFC6325] BUT Do not de-capsulate and forward
957 as a native frame
958 Else
959 Forward as defined in [RFC6325]
961 Figure 9 Pseudo code for Backward compatible Processing
963 [8021Q] requires that the MEP filters or pass through OAM messages
964 based on the MD-Level. The MD-Level is embedded deep in the OAM
965 message. Hence, conventional methods of frame filtering may not be
966 able to filter frames based on the MD-Level. As a result, OAM
967 messages that must be dropped due to MD level mismatch may leak in to
968 a TRILL domain with different MD-Level.
970 This leaking may not cause any functionality loss. The receiving
971 MEP/MIP is required to validate the MD-level prior to acting on the
972 message. Any frames received with an incorrect MD-Level will be
973 dropped.
975 Generally, TRILL campuses are managed by a single operator, hence
976 there is no risk of security exposure. However, in the event of multi
977 operator deployments, operators should be aware of possible exposure
978 of device specific information and appropriate measures must be
979 taken.
981 It is also important to note that the MPLS OAM [RFC4379] framework
982 does not include the concept of domains and OAM filtering based on
983 operators. It is our opinion that the lack of OAM frame filtering
984 based on domains does not introduce significant functional deficiency
985 or security risk.
987 8. Continuity Check Message (CCM)
989 CCMs are used to monitor connectivity and configuration errors.
990 [8021Q] monitors connectivity by listening to periodic CCM messages
991 received from its remote MEP partners in the MA. An [8021Q] MEP
992 identifies cross-connect errors by comparing the MAID in the received
993 CCM message with the MEP's local MAID. The MAID [8021Q] is a 48 byte
994 field that is technology independent. Similarly, the MEPID is a 2
995 byte field that is independent of the technology. Given this generic
996 definition of CCM fields, CCM as defined in [8021Q] can be utilized
997 in TRILL with no changes. TRILL specific information may be carried
998 in CCMs when encoded using TRILL specific TLVs or sub-TLVs. This is
999 possible since CCMs may carry optional TLVs.
1001 Unlike classical Ethernet environments, TRILL contains multipath
1002 forwarding. The path taken by a packet depends on the payload of the
1003 packet. The Maintenance Association identifies the interested end-
1004 points (MEPs) of a given monitored path. For unicast there are only
1005 two MEPs per MA. For multicast there can be two or more MEPs in the
1006 MA. The entropy values of the monitored flows is defined within the
1007 MA. CCM transmit logic will utilize these flow entropy values when
1008 constructing the CCM packets. Please see section 13. below for the
1009 theory of operation of CCM.
1011 The MIB of [8021Q] is augmented with the definition of flow-entropy.
1012 Please see [TRILLOAMMIB] for definition of these and other TRILL
1013 related OAM MIB definitions. Below Figure depicts the correlation
1014 between MA, CCM and proposed flow-entropy.
1016 MA---
1017 |
1018 --- MEP
1019 |
1020 . - Remote MEP List
1021 .
1022 |
1023 --- MEP-A
1024 |
1025 --- MEP-B
1026 .
1028 |
1029 . - Flow Entropy List {Augments IEEE8021-CFM-MIB}
1031 |
1032 --- (Flow Entropy-1) {note we have to define
1033 | destination nickname with
1034 --- (Flow-entropy-2) the flow entropy discuss}
1035 |
1036 . ---(Flow Entropy n)
1037 |
1038 . - CCM
1039 |
1040 --- (standard 8021ag entries)
1041 |
1042 --- (hop-count) { Augments IEEE8021-CFM-MIB}
1043 |
1044 --- (Other TBD TRILL OAM specific entries)
1045 {Augmented}
1046 |
1047 .
1048 |
1049 - Other MIB entries
1050 Figure 10Augmentation of CCM MIB in TRILL
1052 In a multi-pathing environment, a Flow - by definition - is
1053 unidirectional. A question may arise as to what flow entropy should
1054 be used in the response. CCMs are unidirectional and have no explicit
1055 reply; as such, the issue of the response flow entropy does not
1056 arise. In the transmitted CCM, each MEP reports local status using
1057 the Remote Defect Indication (RDI) flag. Additionally, a MEP may
1058 raise SNMP TRAPs [TRILLOAMMIB] as Alarms when a connectivity failure
1059 occurs.
1061 9. TRILL OAM Message Channel
1063 The TRILL OAM Message Channel can be divided into two parts: TRILL
1064 OAM Message header and TRILL OAM Message TLVs. Every OAM Message MUST
1065 contain a single TRILL OAM message header and a set of one or more
1066 specified OAM Message TLVs.
1068 9.1. TRILL OAM Message header
1070 As discussed earlier, a common messaging framework between [8021Q],
1071 TRILL, and other similar standards such as Y.1731 can be accomplished
1072 by re-using the OAM message header defined in [8021Q].
1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1075 |MD-L | Version | OpCode | Flags |FirstTLVOffset |
1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1077 | |
1078 . Opcode Specific Information .
1079 | |
1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1081 | |
1082 . TLVs .
1083 | |
1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1086 Figure 11OAM Message Format
1088 o MD-L: Maintenance Domain Level (3 bits). Identifies the
1089 maintenance domain level. For TRILL, in general, this field is
1090 set to zero. However, extension of TRILL, for example to support
1091 multilevel, may create different MD-LEVELs and MD-L field must
1092 be appropriately set in those scenarios. (Please refer to
1093 [8021Q] for the definition of MD-Level)
1095 o Version: Indicates the version (5 bits). As specified in
1096 [8021Q]. This document does not propose to change the Version
1097 defined in [8021Q].
1099 o Flags: Includes operational flags (1 byte). The definition of
1100 flags is Opcode-specific and is covered in the applicable
1101 sections.
1103 o FirstTLVOffset: Defines the location of the first TLV, in
1104 bytes, starting from the end of the FirstTLVOffset field (1
1105 byte). (Refer to [8021Q] for the definition of the
1106 FirstTLVOffset.)
1108 MD-L, Version, Opcode, Flags and FirstTLVOffset fields collectively
1109 are referred to as the OAM Message Header.
1111 The Opcode specific information section of the OAM Message may
1112 contain Session Identification number, time-stamp, etc.
1114 9.2. TRILL OAM Opcodes
1116 The following Opcodes are defined for TRILL. Each of the Opcodes
1117 indicates a separate type of TRILL OAM message. Details of the
1118 messages are presented in the related sections.
1120 TRILL OAM Message Opcodes:
1122 TBD-64 : Path Trace Reply
1123 TBD-65 : Path Trace Message
1124 TBD-66 : Multicast Tree Verification Reply
1125 TBD-67 : Multicast Tree Verification Message
1127 9.3. Format of TRILL OAM TLV
1129 The same TLV format as defined in section 21.5.1 of [8021Q] is used
1130 for TRILL OAM. The following figure depicts the general format of a
1131 TRILL OAM TLV:
1133 0 1 2
1134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1136 | Type | Length |
1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1138 | |
1139 . Value(variable) .
1140 | |
1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1143 Figure 12 TRILL OAM TLV
1145 Type (1 octet) : Specifies the Type of the TLV (see sections 9.4.
1146 for TLV types).
1148 Length (2 octets) : Specifies the length of the 'Value' field in
1149 octets. Length of the 'Value' field can be either zero or more
1150 octets.
1152 Value (variable): The length and the content of this field depend on
1153 the type of the TLV. Please refer to applicable TLV definitions for
1154 the details.
1156 Semantics and usage of Type values allocated for TRILL OAM purpose
1157 are defined by this document and other future related documents.
1159 9.4. TRILL OAM TLVs
1161 TRILL related TLVs are defined in this section. [8021Q] defined TLVs
1162 are reused, where applicable. Types 32-63 are reserved for ITU-T
1163 Y.1731. We propose to reserve Types 64-95 for TRILL OAM TLVs.
1165 9.4.1. Common TLVs between 802.1ag and TRILL
1167 The following TLVs are defined in [8021Q]. We propose to re-use them
1168 where applicable. The format and semantics of the TLVs are as defined
1169 in [8021Q].
1171 Type Name of TLV in [8021Q]
1172 ---- -------------
1173 0 End TLV
1174 1 Sender ID TLV
1175 2 Port Status TLV
1176 3 Data TLV
1177 4 Interface Status TLV
1178 5 Reply Ingress TLV
1179 6 Reply Egress TLV
1180 7 LTM Egress Identifier TLV
1181 8 LTR Egress Identifier TLV
1182 9-30 Reserved
1183 31 Organization Specific TLV
1185 9.4.2. TRILL OAM Specific TLVs
1187 As indicated above, Types 64-95 will be requested to be reserved for
1188 TRILL OAM purposes. Listed below is a summary of TRILL OAM TLVs and
1189 their corresponding codes. Format and semantics of TRILL OAM TLVs are
1190 defined in subsequent sections.
1192 Type TLV Name
1193 ----------- ----------------------
1194 TBD-TLV-64 TRILL OAM Application Identifier
1195 TBD-TLV-65 Out of Band IP Address
1196 TBD-TLV-66 Diagnostic VLAN
1197 TBD-TLV-67 RBridge Scope
1198 TBD-TLV-68 Original Payload
1199 TBD-TLV-69 Previous RBridge Nickname
1200 TBD-TLV-70 RILL Next Hop RBridge List (ECMP)
1201 TBD-TLV-71 Multicast Receiver Availability
1202 TBD-TLV-72 Flow Identifier
1203 TBD-TLV-73 to TBD-TLV-95 Reserved
1205 9.4.3. TRILL OAM Application Identifier TLV
1207 TRILL OAM Application Identifier TLV carries TRILL OAM application
1208 specific information. The TRILL OAM Application Identifier TLV MUST
1209 always be present and MUST be the first TLV in TRILL OAM messages.
1210 Messages that do not include the TRILL OAM Application Identifier TLV
1211 as the first TLV MUST be discarded by an RBridge, unless that RBridge
1212 is also running Ethernet CFM.
1214 1 2 3
1215 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
1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1217 | Type | Length | Version |
1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1219 | Return Code |Return sub-code| Reserved |F|C|O|I|
1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1222 Figure 13TRILL OAM Message TLV
1224 Type (1 octet) = 64 indicate that this is the TRILL OAM Version
1226 Length (2 octets) = 6
1228 TRILL OAM Version (1 Octet), currently set to zero. Indicates the
1229 TRILL OAM version. TRILL OAM version can be different than the
1230 [8021Q] version.
1232 Return Code (1 Octet): Set to zero on requests. Set to an appropriate
1233 value in response messages.
1235 Return sub-code (1 Octet): Return sub-code is set to zero on
1236 transmission of request message. Return sub-code identifies
1237 categories within a specific Return code. Return sub-code MUST be
1238 interpreted within a Return code.
1240 Reserved: set to zero on transmission and ignored on reception.
1242 F (1 bit) : Final flag, when set, indicates this is the last
1243 response.
1245 C (1 bit ): Label error (VLAN/Label mapping error), if set indicates
1246 that the label (VLAN/FGL) in the flow entropy is different than the
1247 label included in the diagnostic TLV. This field is ignored in
1248 request messages and MUST only be interpreted in response messages.
1250 O (1 bit) : If set, indicates, OAM out-of-band response requested.
1252 I (1 bit) : If set, indicates, OAM in-band response requested.
1254 NOTE: When both O and I bits are set to zero, indicates that no
1255 response is required (silent mode). User MAY specify both O and I or
1256 one of them or none. When both O and I bits are set response is sent
1257 both in-band and out-of-band.
1259 9.4.4. Out Of Band Reply Address TLV
1261 Out of Band Reply Address TLV specifies the address to which an out
1262 of band OAM reply message MUST be sent. When O bit in the TRILL
1263 Version TLV is not set, Out of Band Reply Address TLV is ignored.
1265 1 2 3
1266 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
1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1268 | Type | Length | Address Type |
1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1270 | Addr Length | |
1271 +-+-+-+-+-+-+-+-+ |
1272 | |
1273 . Reply Address .
1274 | |
1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1277 Figure 14Out of Band IP Address TLV
1279 Type (1 octet) = 64
1281 Length (2 octets) = Variable. Minimum length is 2.
1283 Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
1284 nickname. All other values reserved.
1286 Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBRidge
1287 nickname.
1289 Reply Address (variable): Address where the reply needed to be sent.
1290 Length depends on the address specification.
1292 9.4.5. Diagnostics Label TLV
1294 Diagnostic label specifies the data label (VLAN or FGL) in which the
1295 OAM messages are generated. Receiving RBridge MUST compare the data
1296 label of the Flow entropy to the data label specified in the
1297 Diagnostic Label TLV. Label Error Flag in the response (TRILL OAM
1298 Message Version TLV) MUST be set when the two VLANs do not match.
1300 1 2 3
1301 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
1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1303 | Type | Length | L-Type |
1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1305 | Reserved | Label(VLAN) |
1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1308 Figure 15Diagnostic VLAN TLV
1310 Type (1 octet) = 65 indicates that this is the TRILL Diagnostic VLAN
1311 TLV
1313 Length (2 octets) = 5
1315 L-Type (Label type, 1 octet)
1317 0- indicate 802.1Q 12 bit VLAN.
1319 1 - indicate TRILL 24 bit fine grain label
1321 Label (24 bits): Either 12 bit VLAN or 24 bit fine grain label.
1323 RBridges do not perform Label error checking when Label TLV is not
1324 included in the OAM message. In certain deployments intermediate
1325 devices may perform label (VLAN) translation. In such scenarios,
1326 originator should not include the diagnostic Label TLV in OAM
1327 messages. Inclusion of diagnostic TLV will generate unwanted label
1328 error notifications.
1330 9.4.6. Original Data Payload TLV
1332 1 2 3
1333 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
1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1335 | Type | Length | |
1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
1337 | |
1338 . Original Payload .
1339 | |
1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1342 Figure 16Original Data Payload TLV
1344 Length (2 octets) = variable
1346 9.4.7. RBridge scope TLV
1348 RBridge scope TLV identifies nicknames of RBridges from which a
1349 response is required. The RBridge scope TLV is only applicable to
1350 Multicast Tree Verification messages. This TLV SHOULD NOT be included
1351 in other messages. Receiving RBridges MUST ignore this TLV on
1352 messages other than Multicast Verification Message.
1354 Each TLV can contain up to 255 nicknames of in scope RBridges. A
1355 Multicast Verification Message may contain multiple "RBridge scope
1356 TLVs", in the event that more than 255 in scope RBridges need to be
1357 specified.
1359 Absence of the "RBridge scope TLV" indicates that a response is
1360 needed from all the RBridges. Please see section 12. for details.
1362 1 2 3
1363 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
1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1365 | Type | Length | nOfnicknames |
1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1367 | nickname-1 | nickname-2 |
1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1369 . .
1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1371 | | nickname-n |
1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1374 Figure 17RBridge Scope TLV
1376 Type (1 octet) = 67 indicates that this is the "RBridge scope TLV"
1378 Length (2 octets) = variable. Minimum value is 2.
1380 Nickname (2 octets) = 16 bit RBridge nickname.
1382 9.4.8. Previous RBridge nickname TLV
1384 "Previous RBridge nickname TLV" identifies the nickname or nicknames
1385 of the upstream RBridge. [RFC6325] allows a given RBridge to hold
1386 multiple nicknames.
1388 "Upstream RBridge nickname TLV" is an optional TLV. Multiple
1389 instances of this TLV MAY be included when an upstream RBridge is
1390 represented by more than 255 nicknames (highly unlikely).
1392 1 2 3
1393 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
1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1395 | Type | Length | Reserved |
1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1397 | Reserved | nickname |
1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1400 Figure 18Upstream RBridge nickname TLV
1402 Type (1 octet) = 69 indicates that this is the "Upstream RBridge
1403 nickname"
1405 Length (2 octets) = 4.
1407 Nickname (2 octets) = 16 bit RBridge nickname.
1409 9.4.9. Next Hop RBridge List TLV
1411 "Next Hop RBridge List TLV" identifies the nickname or nicknames of
1412 the downstream next hop RBridges. [RFC6325] allows a given RBridge to
1413 have multiple Equal Cost Paths to a specified destination. Each next
1414 hop RBridge is represented by one of its nicknames.
1416 "Next Hop RBridge List TLV" is an optional TLV. Multiple instances of
1417 this TLV MAY be included when there are more than 255 Equal Cost
1418 Paths to the destination.
1420 1 2 3
1421 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
1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1423 | Type | Length | nOfnicknames |
1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1425 | nickname-1 | nickname-2 |
1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1427 . .
1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1429 | | nickname-n |
1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1432 Figure 19Next Hop RBridge List TLV
1434 Type (1 octet) = 70 indicates that this is the "Next nickname"
1436 Length (2 octets) = variable. Minimum value is 2.
1438 Nickname (2 octets) = 16 bit RBridge nickname.
1440 9.4.10. Multicast Receiver Port count TLV
1442 "Multicast Receiver Port Count TLV" identifies the number of ports
1443 interested in receiving the specified multicast stream within the
1444 responding RBridge on the VLAN specified by the Diagnostic VLAN TLV.
1446 Multicast Receiver Port count is an Optional TLV.
1448 1 2 3
1449 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
1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1451 | Type | Length | Reserved |
1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1453 | number of Receivers |
1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1456 Figure 20Multicast Receiver Availability TLV
1458 Type (1 octet) = 71 indicates that this is the "Multicast
1459 Availability TLV"
1461 Length (2 octets) = 5.
1463 Number of Receivers (4 octets) = Indicates the number of Multicast
1464 receivers available on the responding RBridge on the VLAN specified
1465 by the diagnostic VLAN.
1467 9.4.11. Flow Identifier (flow-id) TLV
1469 Flow Identifier (flow-id) uniquely identifies a specific flow. The
1470 flow-id value is unique per MEP and needs to be interpreted as such.
1472 1 2 3
1473 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
1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1475 | Type | Length | Reserved |
1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1477 | MEP-ID | flow-id |
1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1480 Figure 21Out of Band IP Address TLV
1482 Type (1 octet) = 72
1484 Length (2 octets) = 5.
1486 Reserved (1 octet) set to 0 on transmission and ignored on reception.
1488 MEP-ID (2 octets) = MEP-ID of the originator [8021Q].
1490 Flow-id (2 octets) = uniquely identifies the flow per MEP. Different
1491 MEPs may allocate the same flow-id value. The {MEP-ID, flow-id} pair
1492 is globally unique.
1494 Inclusion of the MEP-ID in the flow-id TLV allows inclusion of MEP-ID
1495 for messages that do not contain MEP-ID in OAM header. Applications
1496 may use MEP-ID information for different types of troubleshooting.
1498 10. Loopback Message
1500 10.1. Loopback OAM Message format
1502 1 2 3
1503 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
1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1505 |MD-L | Version | OpCode | Flags |FirstTLVOffset |
1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1507 | Loopback Transaction Identifier |
1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1509 | |
1510 . TLVs .
1511 | |
1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1514 Figure 22Loopback OAM Message Format
1516 The above figure depicts the format of the Loopback Request and
1517 response messages as defined in [8021Q]. The Opcode for Loopback
1518 Message is set to 65 and the Opcode for the Reply Message is set to
1519 64. The Session Identification Number is a 32-bit integer that allows
1520 the requesting RBridge to uniquely identify the corresponding
1521 session. Responding RBridges, without modification, MUST echo the
1522 received "Loopback Transaction Identifier" number..
1524 10.2. Theory of Operation
1526 10.2.1. Originator RBridge
1528 Identifies the destination RBridge nickname based on user
1529 specification or based on the specified destination MAC or IP
1530 address.
1532 Constructs the flow entropy based on user specified parameters or
1533 implementation specific default parameters.
1535 Constructs the TRILL OAM header: sets the opcode to Loopback message
1536 type (3). Assign applicable Loopback Transaction Identifier number
1537 for the request.
1539 The TRILL OAM Version TLV MUST be included and with the flags set to
1540 applicable values.
1542 Include following OAM TLVs, where applicable
1544 o Out-of-band Reply address TLV
1546 o Diagnostic Label TLV
1548 o Sender ID TLV
1550 Specify the Hop count of the TRILL data frame per user specification
1551 or utilize an applicable Hop count value.
1553 Dispatch the OAM frame for transmission.
1555 RBridge may continue to retransmit the request at periodic intervals,
1556 until a response is received or the re-transmission count expires. At
1557 each transmission Session Identification number MUST be incremented.
1559 10.2.2. Intermediate RBridge
1561 Intermediate RBridges forward the frame as a normal data frame and no
1562 special handling is required.
1564 10.2.3. Destination RBridge
1566 If the Loopback message is addressed to the local RBridge and
1567 satisfies the OAM identification criteria specified in section 3.1.
1568 then, the RBridge data plane forwards the message to the CPU for
1569 further processing.
1571 The TRILL OAM application layer further validates the received OAM
1572 frame by checking for the presence of OAM-Ethertype at the end of the
1573 flow entropy and the MD Level. Frames that do not contain OAM-
1574 Ethertype at the end of the flow entropy MUST be discarded.
1576 Construction of the TRILL OAM response:
1578 TRILL OAM application encodes the received TRILL header and flow
1579 entropy in the Original payload TLV and includes it in the OAM
1580 message.
1582 Set the Return Code and Return sub code to applicable values. Update
1583 the TRILL OAM opcode to 2 (Loopback Message Reply)
1585 Optionally, if the VLAN/FGL identifier value of the received flow
1586 entropy differs from the value specified in the diagnostic Label, set
1587 the Label Error Flag on TRILL OAM Application Identifier TLV.
1589 Include the sender ID TLV (1)
1591 If in-band response was requested, dispatch the frame to the TRILL
1592 data plane with request-originator RBridge nickname as the egress
1593 RBridge nickname.
1595 If out-of-band response was requested, dispatch the frame to the IP
1596 forwarding process.
1598 11. Path Trace Message
1600 The primary use of the Path Trace Message is for fault isolation. It
1601 may also be used for plotting the path taken from a given RBridge to
1602 another RBridge.
1604 [8021Q] accomplishes the objectives of the TRILL Path Trace Message
1605 using Link Trace Messages. Link Trace Messages utilize a well-known
1606 multicast MAC address. This works for [8021Q], because for 802.1 both
1607 the unicast and multicast paths are congruent. However, TRILL is
1608 multicast and unicast incongruent. Hence, TRILL OAM is required to
1609 utilize a new message format: the Path Trace message.
1611 The Path Trace Message has the same format as Loopback Message.
1612 Opcode for Path Trace Reply Message is 65 and Request 64
1614 Operation of the Path Trace message is identical to the Loopback
1615 message except that it is first transmitted with a TRILL Hop count
1616 field value of 1. The sending RBridge expects a Time Expiry Return-
1617 Code from the next hop or a successful response. If a Time Expiry
1618 Return-code is received as the response, the originator RBridge
1619 records the information received from intermediate node that
1620 generated the Time Expiry message and resends the message by
1621 incrementing the previous Hop count value by 1. This process is
1622 continued until, a response is received from the destination RBridge
1623 or Path Trace process timeout occur or Hop count reaches a configured
1624 maximum value.
1626 11.1. Theory of Operation
1628 11.1.1. Originator RBridge
1630 Identify the destination RBridge based on user specification or based
1631 on location of the specified MAC address.
1633 Construct the flow entropy based on user specified parameters or
1634 implementation specific default parameters.
1636 Construct the TRILL OAM header: Set the opcode to Path Trace Request
1637 message type (65). Assign an applicable Session Identification number
1638 for the request. Return-code and sub-code MUST be set to zero.
1640 The TRILL OAM Application Identifier TLV MUST be included and set the
1641 flags to applicable values.
1643 Include following OAM TLVs, where applicable
1645 o Out-of-band IP address TLV
1647 o Diagnostic Label TLV
1649 o Include the Sender ID TLV
1651 Specify the Hop count of the TRILL data frame as 1 for the first
1652 request.
1654 Dispatch the OAM frame to the TRILL data plane for transmission.
1656 An RBridge may continue to retransmit the request at periodic
1657 intervals, until a response is received or the re-transmission count
1658 expires. At each new re-transmission, the Session Identification
1659 number MUST be incremented. Additionally, for responses received from
1660 intermediate RBridges, the RBridge nickname and interface information
1661 MUST be recorded.
1663 11.1.2. Intermediate RBridge
1665 Path Trace Messages transit through Intermediate RBridges
1666 transparently, unless Hop-count has expired.
1668 TRILL OAM application layer further validates the received OAM frame
1669 by examining the presence of TRILL OAM Flag and OAM-Ethertype at the
1670 end of the flow entropy and by examining the MD Level. Frames that do
1671 not contain OAM-Ethertype at the end of the flow entropy MUST be
1672 discarded.
1674 Construction of the TRILL OAM response:
1676 TRILL OAM application encodes the received TRILL header and flow
1677 entropy in the Original payload TLV and include it in the OAM
1678 message.
1680 Set the Return Code to (2) "Time Expired" and Return sub code to zero
1681 (0). Update the TRILL OAM opcode to 64 (Path Trace Message Reply).
1683 If the VLAN/FGL identifier value of the received flow entropy differs
1684 from the value specified in the diagnostic Label, set the Label Error
1685 Flag on TRILL OAM Application Identifier TLV.
1687 Include following TLVs
1689 Upstream RBridge nickname TLV (69)
1691 Reply Ingress TLV (5)
1693 Reply Egress TLV (6)
1695 Interface Status TLV (4)
1697 TRILL Next Hop RBridge (Repeat for each ECMP) (70)
1699 Sender ID TLV (1)
1701 If Label error detected, set C flag (Label error detected) in the
1702 version.
1704 If in-band response was requested, dispatch the frame to the TRILL
1705 data plane with request-originator RBRidge nickname as the egress
1706 RBridge nickname.
1708 If out-of-band response was requested, dispatch the frame to the
1709 standard IP forwarding process.
1711 11.1.3. Destination RBridge
1713 Processing is identical to section 11.1.2. With the exception that
1714 TRILL OAM Opcode is set to Path Trace Reply (64).
1716 12. Multi-Destination Tree Verification (MTV) Message
1718 Multi-Destination Tree Verification messages allow verifying TRILL
1719 distribution tree integrity and pruning. TRILL VLAN/FGL and multicast
1720 pruning are described in [RFC6325] [RFCclcorrect] and [RFCfgl].
1722 Multi-destination tree verification and Multicast group verification
1723 messages are designed to detect pruning defects. Additionally, these
1724 tools can be used for plotting a given multicast tree within the
1725 TRILL campus.
1727 Multi-Destination tree verification OAM frames are copied to the CPU
1728 of every intermediate RBridge that is part of the distribution tree
1729 being verified. The originator of the Multi-destination Tree
1730 verification message specifies the scope of RBridges from which a
1731 response is required. Only the RBridges listed in the scope field
1732 respond to the request. Other RBridges silently discard the request.
1733 Inclusion of the scope parameter is required to prevent receiving an
1734 excessive number of responses. The typical scenario of distribution
1735 tree verification or group verification, involves verifying multicast
1736 connectivity to a selected set of end-nodes as opposed to the entire
1737 network. Availability of the scope facilitates narrowing down the
1738 focus to only the RBridges of interest.
1740 Implementations MAY choose to rate-limit CPU bound multicast traffic.
1741 As a result of rate-limiting or due to other congestion conditions,
1742 MTV messages may be discarded from time to time by the intermediate
1743 RBRidges and the requester may be required to retransmit the request.
1744 Implementations SHOULD narrow the embedded scope of retransmission
1745 request only to RBRidges that have failed to respond.
1747 12.1. Multi-Destination Tree Verification (MTV) OAM Message Format
1749 Format of MTV OAM Message format is identical to that of Loopback
1750 Message format defined in section 10. with the exception that the
1751 Loopback Transaction Identifier, in section 10.1. , is replaced with
1752 the Session Identifier.
1754 12.2. Theory of Operation
1756 12.2.1. Originator RBridge
1758 The user is required at a minimum to specify either the distribution
1759 trees that need to be verified, or the Multicast MAC address and
1760 VLAN/FGL, or VLAN/FGL and Multicast destination IP address.
1761 Alternatively, for more specific multicast flow verification, the
1762 user MAY specify more information e.g. source MAC address, VLAN/FGL,
1763 Destination and Source IP addresses. Implementations, at a minimum,
1764 must allow the user to specify a choice of distribution trees,
1765 Destination Multicast MAC address and VLAN/FGL that needed to be
1766 verified. Although, it is not mandatory, it is highly desired to
1767 provide an option to specify the scope. It should be noted that the
1768 source MAC address and some other parameters may not be specified if
1769 the Backwards Compatibility Method of section 3.2 is used to identify
1770 the OAM frames.
1772 Default parameters MUST be used for unspecified parameters. Flow
1773 entropy is constructed based on user specified parameters and/or
1774 default parameters.
1776 Based on user specified parameters, the originating RBridge
1777 identifies the nickname that represents the multicast tree.
1779 Obtain the applicable Hop count value for the selected multicast
1780 tree.
1782 Construct TRILL OAM message header and include Session Identification
1783 number. Session Identification number facilitate the originator to
1784 map the response to the correct request.
1786 TRILL OAM Application Identifier TLV MUST be included.
1788 Op-Code MUST be specified as Multicast Tree Verification Message (70)
1790 Include RBridge scope TLV (67)
1792 Optionally, include following TLV, where applicable
1794 o Out-of-band IP address
1796 o Diagnostic Label
1798 o Sender ID TLV (1)
1800 Specify the Hop count of the TRILL data frame per user specification
1801 or alternatively utilize the applicable Hop count value if TRILL Hop
1802 count is not being specified by the user.
1804 Dispatch the OAM frame to the TRILL data plane to be ingressed for
1805 transmission.
1807 The RBridge may continue to retransmit the request at a periodic
1808 interval until either a response is received or the re-transmission
1809 count expires. At each new re-transmission, the Session
1810 Identification number MUST be incremented. At each re-transmission,
1811 the RBridge may further reduce the scope to the RBridges that it has
1812 not received a response from.
1814 12.2.2. Receiving RBridge
1816 Receiving RBridges identify multicast verification frames per the
1817 procedure explained in sections 3.2.
1819 CPU of the RBridge validates the frame and analyzes the scope RBridge
1820 list. If the RBridge scope TLV is present and the local RBridge
1821 nickname is not specified in the scope list, it will silently discard
1822 the frame. If the local RBridge is specified in the scope list OR
1823 RBridge scope TLV is absent, the receiving RBridge proceeds with
1824 further processing as defined in section 12.2.3.
1826 12.2.3. In scope RBridges
1828 Construction of the TRILL OAM response:
1830 TRILL OAM application encodes the received TRILL header and flow
1831 entropy in the Original payload TLV and includes them in the OAM
1832 message.
1834 Set the Return Code to (0) and Return sub code to zero (0). Update
1835 the TRILL OAM opcode to 66 (Multicast Tree Verification Reply).
1837 Include following TLVs:
1839 Upstream RBridge nickname TLV (69)
1841 Reply Ingress TLV (5)
1843 Interface Status TLV (4)
1845 TRILL Next Hop RBridge (Repeat for each downstream RBridge) (70)
1847 Sender ID TLV (1)
1849 Multicast Receiver Availability TLV (71)
1851 If VLAN cross connect error detected, set C flag (Cross connect error
1852 detected) in the version.
1854 If in-band response was requested, dispatch the frame to the TRILL
1855 data plane with request-originator RBridge nickname as the egress
1856 RBridge nickname.
1858 If out-of-band response was requested, dispatch the frame to the
1859 standard IP forwarding process.
1861 13. Application of Continuity Check Message (CCM) in TRILL
1863 Section 8. provides an overview of CCM Messages defined in [8021Q]
1864 and how they can be used within the TRILL OAM. This section,
1865 presents the application and Theory of Operations of CCM within the
1866 TRILL OAM framework. Readers are referred to [8021Q] for CCM message
1867 format and applicable TLV definitions and usages. Only the TRILL
1868 specific aspects are explained below.
1870 In TRILL, between any two given MEPs there can be multiple potential
1871 paths. Whereas in [8021Q], there is always a single path between any
1872 two MEPs at any given time. [RFC6905] requires solutions to have the
1873 ability to monitor continuity over one or more paths.
1875 CCM Messages are uni-directional, such that there is no explicit
1876 response to a received CCM message. Connectivity status is indicated
1877 by setting the applicable flags (e.g. RDI) of the CCM messages
1878 transmitted by an MEP.
1880 It is important that the proposed solution accomplishes the
1881 requirements specified in [RFC6905] within the framework of [8021Q]
1882 in a straightforward manner and with minimum changes. Section 8,
1883 above proposed to define multiple flows within the CCM object, each
1884 corresponding to a flow that a given MEP wishes to monitor.
1886 Receiving MEPs do not cross check whether a received CCM belongs to a
1887 specific flow from the originating RBridge. Any attempt to track
1888 status of individual flows may explode the amount of state
1889 information that any given RBridge has to maintain.
1891 The obvious question arises: How does the originating RBridge know
1892 which flow or flows are at fault?
1894 13.1. CCM Error Notification
1896 This is accomplished with a combination of the RDI flag in the CCM
1897 header, flow-id TLV, and SNMP Notifications (Traps).
1899 Each MEP transmits 4 CCM messages per each flow. ([8021Q] detects CCM
1900 fault when 3 consecutive CCM messages are lost). Each CCM Message has
1901 a unique sequence number and unique flow-identifier. The flow
1902 identifier is included in the OAM message via flow-id TLV.
1904 When an MEP notices a CCM timeout from a remote MEP ( MEP-A), it sets
1905 the RDI flag on the next CCM message it generates. Additionally, it
1906 logs and sends SNMP notification that contain the remote MEP
1907 Identification, flow-id and the Sequence Number of the last CCM
1908 message it received and if available, the flow-id and the Sequence
1909 Number of the first CCM message it received after the failure. Each
1910 MEP maintains a unique flow-id per each flow, hence the operator can
1911 easily identify flows that correspond to the specific flow-id.
1913 The following example illustrates the above.
1915 Assume there are two MEPs, MEP-A and MEP-B.
1917 Assume there are 3 flows between MEP-A and MEP-B.
1919 Let,s assume MEP-A allocates sequence numbers as follows
1921 Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-id=(1)
1923 Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-id=(2)
1925 Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-id=(3)
1927 Let's Assume Flow-2 is at fault.
1929 MEP-B, receives CCM from MEP-A with sequence numbers 1,2,3,4, but did
1930 not receive 5,6,7,8. CCM timeout is set to 3 CCM intervals in
1931 [8021Q]. Hence MEP-B detects the error at the 8'th CCM message. At
1932 this time the sequence number of the last good CCM message MEP-B has
1933 received from MEP-A is 4 and flow-id of the last good CCM Message is
1934 (1). Hence MEP-B will generate a CCM error SNMP notification with
1935 MEP-A and Last good flow-id (1) and sequence number 4.
1937 When MEP-A switches to flow-3 after transmitting flow-2, MEP-B will
1938 start receiving CCM messages. In the foregoing example it will be CCM
1939 message with Sequence Numbers 9,10,11,12,21 and so on. When in
1940 receipt of a new CCM message from a specific MEP, after a CCM
1941 timeout, the TRILL OAM will generate an SNMP Notification of CCM
1942 resume with remote MEP-ID and the first valid flow-id and the
1943 Sequence number after the CCM timeout. In the foregoing example, it
1944 is MEP-A, flow-id (1) and Sequence Number 9.
1946 The remote MEP list under the CCM MIB Object is augmented to contain
1947 "Last Sequence Number", flow-id and "CCM Timeout" variables. Last
1948 Sequence Number and flow-id are updated every time a CCM is received
1949 from a remote MEP. CCM Timeout variable is set when the CCM timeout
1950 occurs and is cleared when a CCM is received.
1952 13.2. Theory of Operation
1954 13.2.1. Originator RBridge
1956 Derive the flow entropy based on flow entropy specified in the CCM
1957 Management object.
1959 Construct the TRILL CCM OAM header as specified in [8021Q].
1961 TRILL OAM Version TLV MUST be included as the first TLV and set the
1962 flags to applicable values.
1964 Include other TLVs specified in [8021Q]
1966 Include the following optional TRILL OAM TLVs, where applicable
1968 o Sender ID TLV
1970 Specify the Hop count of the TRILL data frame per user specification
1971 or utilize an applicable Hop count value.
1973 Dispatch the OAM frame to the TRILL data plane for transmission.
1975 An RBridge transmits a total of 4 requests, each at CCM
1976 retransmission interval. At each transmission the Session
1977 Identification number MUST be incremented by one.
1979 At the 5'th retransmission interval, flow entropy of the CCM packet
1980 is updated to the next flow entropy specified in the CCM Management
1981 Object. If current flow entropy is the last flow entropy specified,
1982 move to the first flow entropy specified and continue the process.
1984 13.2.2. Intermediate RBridge
1986 Intermediate RBridges forward the frame as a normal data frame and no
1987 special handling is required.
1989 13.2.3. Destination RBridge
1991 If the CCM Message is addressed to the local RBridge or multicast and
1992 satisfies OAM identification methods specified in sections 3.2. then
1993 the RBridge data plane forwards the message to the CPU for further
1994 processing.
1996 The TRILL OAM application layer further validates the received OAM
1997 frame by examining the presence of OAM-Ethertype at the end of the
1998 flow entropy. Frames that do not contain OAM-Ethertype at the end of
1999 the flow entropy MUST be discarded.
2001 Validate the MD-LEVEL and pass the packet to the Opcode de-
2002 multiplexer. The Opcode de-multiplexer delivers CCM packets to the
2003 CCM process.
2005 The CCM Process performs processing specified in [8021Q].
2007 Additionally the CCM process updates the CCM Management Object with
2008 the sequence number of the received CCM packet. Note: The last
2009 received CCM sequence number and CCM timeout are tracked per each
2010 remote MEP.
2012 If the CCM timeout is true for the sending remote MEP, then clear the
2013 CCM timeout in the CCM Management object and generate the SNMP
2014 notification as specified above.
2016 14. Fragmented Reply
2018 The response Message allow Fragmented Replies.. In case of Fragmented
2019 Replies, all messages MUST follow the procedure defined in this
2020 section.
2022 All Reply Messages MUST be encoded as described in this document.
2024 The same session Identification Number MUST be included in all
2025 related fragments of the same message.
2027 The TRILL OAM Application Identifier TLV MUST be included with the
2028 appropriate Final Flag field. The Final Flag, MUST, only be set on
2029 the final fragment of the reply.
2031 15. Security Considerations
2033 For general TRILL related security considerations, please refer to
2034 [RFC6325]. Specific security considerations related methods presented
2035 in this document are currently under investigation.
2037 16. IEEE Allocation Considerations
2039 The IEEE 802.1 Working Group is requested to allocate a separate
2040 opcode and TLV space within 802.1QCFM messages for TRILL purpose.
2042 17. IANA Considerations
2044 - IANA is requested to allocate a multicast MAC address from the
2045 block assigned to TRILL [RFC6325].
2047 - Set up sub-registry within the TRILL Parameters registry for block
2048 of TRILL "OAM OpCodes" (Section 9.2. )-
2050 - Set up sub-registry within the TRILL Parameters registry for TRILL
2051 "OAM TLV Types" (Section 9.4. )-
2053 - Request a unicast MAC addressed, reserved for identification of
2054 OAM packets discussed in backward compatibility method (Section 3.3.
2055 ) See Appendix A.
2057 18. References
2059 18.1. Normative References
2061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2062 Requirement Levels", BCP 14, RFC 2119, March 1997.
2064 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base
2065 Protocol Specification", RFC 6325, July 2011.
2067 [RFCfgl] D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
2068 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine-
2069 labeling, work in progress.
2071 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged
2072 Local Area Networks", IEEE Std 802.1Q-2011, August, 2011.
2074 18.2. Informative References
2076 [RFC4379] Kompella, K. et.al, "Detecting Multi-Protocol Label
2077 Switched (MPLS) Data Plane Failures", RFC 4379, February
2078 2006.
2080 [RFC6291] Andersson, L., et.al., "Guidelines f