RFC 7455
Transparent Interconnection of Lots of Links (TRILL): Fault Management
4. TRILL OAM Layering vs. IEEE Layering
This section presents the placement of the TRILL OAM shim within the IEEE 802.1 layers. The transmit and receive processing are explained. +-+-+-+-+-+-+-+-+-+-+ | RBridge Layer | | Processing | +-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+ | TRILL OAM | UP MEP | Layer | MIP +-+-+-+-+-+-+ Down MEP | | +-+-+-+-+-+-+ (3)--------> | TRILL | | Encap/Decap +-+-+-+-+-+-+ | +-+-+-+-+-+-+ (2)--------> |End-station| | VLAN & Priority Processing +-+-+-+-+-+-+ | +-+-+-+-+-+-+ (1)--------> |ISS | |Processing | +-+-+-+-+-+-+ | | | Figure 4: Placement of TRILL MP within IEEE 802.1 [RFC6325], Section 4.6 as updated by [RFC7180] provides a detailed explanation of frame processing. Please refer to those documents for additional details and for processing scenarios not covered herein. Sections 4.1 and 4.2 apply to links using a broadcast LAN technology such as Ethernet.
On links using an inherently point-to-point technology, such as PPP [RFC6361], there is no Outer.MacDA, Outer.MacSA, or Outer.VLAN because these are part of the Link Header for Ethernet. Point-to- point links typically have Link Headers without these fields.4.1. Processing at the ISS Layer
4.1.1. Receive Processing
The ISS layer receives an indication from the port. It extracts DA and SA, and it marks the remainder of the payload as M1. The ISS layer passes on (DA, SA, M1) as an indication to the higher layer. For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA. M1 is the remainder of the packet.4.1.2. Transmit Processing
The ISS layer receives an indication from the higher layer that contains (DA, SA, M1). It constructs an Ethernet frame and passes down to the port.4.2. End-Station VLAN and Priority Processing
4.2.1. Receive Processing
Receive (DA, SA, M1) indication from the ISS layer. Extract the VLAN ID and priority from the M1 part of the received indication (or derive them from the port defaults or other default parameters) and construct (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 maps to M1 in the received indication. Pass (DA, SA, VLAN, PRI, M2) to the TRILL Encapsulation/Decapsulation layer.4.2.2. Transmit Processing
Receive (DA, SA, VLAN, PRI, M2) indication from the TRILL Encapsulation/Decapsulation layer. Merge VLAN, PRI, M2 to form M1. Pass down (DA, SA, M1) to the ISS layer.4.3. TRILL Encapsulation and Decapsulation Layer
4.3.1. Receive Processing for Unicast Packets
o Receive indication (DA, SA, VLAN, PRI, M2) from the End-Station VLAN and Priority Processing layer. o If the DA matches the port Local DA and the frame is of TRILL Ethertype:
- Discard DA, SA, VLAN, and PRI. From M2, derive (TRILL-HDR,
iDA, iSA, i-VL, M3).
- If TRILL nickname is Local and TRILL Header Alert flag is set:
* Pass on to OAM processing.
- Else, pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to the RBridge
layer.
o If the DA matches the port Local DA and the Ethertype is RBridge-
Channel [RFC7178]:
- Process as a possible unicast native RBridge Channel packet.
o If the DA matches the port Local DA and the Ethertype is neither
TRILL nor RBridge-Channel:
- Discard packet.
o If the DA does not match, the port is Appointed Forwarder for
VLAN, and the Ethertype is not TRILL or RBridge-Channel:
- Insert TRILL-HDR and send (TRILL-HDR, iDA, iSA,i-VL, M3)
indication to the RBridge layer (this is the TRILL Ingress
Function).
4.3.2. Transmit Processing for Unicast Packets
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge
layer.
o If the egress TRILL nickname is local:
- If the port is Appointed Forwarder for iVL, the port is not
configured as a trunk or point-to-point (P2P) port, the TRILL
Alert flag is set, and the OAM Ethertype is present, then:
* Strip TRILL-HDR and construct (DA, SA, VLAN, M2) (this is
the TRILL Egress Function).
- Else:
* Discard packet.
o If the egress TRILL nickname is not local:
- Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL
Ethertype, and construct (DA, SA, VLAN, M2) where M2 is (TRILL-
HDR, iDA, iSA, iVL, M).
o Forward (DA, SA, V, M2) to the End-Station VLAN and Priority
Processing layer.
4.3.3. Receive Processing for Multicast Packets
o Receive (DA, SA, V, M2) from the End-Station VLAN and Priority
Processing layer.
o If the DA is All-RBridges and the Ethertype is TRILL:
- Strip DA, SA, and V. From M2, extract (TRILL-HDR, iDA, iSA,
iVL, and M3).
- If the TRILL Alert flag is set and the OAM Ethertype is present
at the end of Flow Entropy:
* Perform OAM processing.
- Else, extract the TRILL Header, inner MAC addresses, and
Inner.VLAN, and pass indication (TRILL-HDR, iDA, iSA, iVL and
M3) to the TRILL RBridge layer.
o If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS,
then pass frame up to TRILL IS-IS processing.
o If the DA is All-RBridges or All-IS-IS-RBridges but the Ethertype
is not TRILL or L2-IS-IS respectively:
- Discard the packet.
o If the Ethertype is TRILL but the multicast DA is not All-RBridges
or if the Ethertype is L2-IS-IS but the multicast DA is not All-
IS-IS-RBridges:
- Discard the packet.
o If the DA is All-Edge-RBridges and the Ethertype is RBridge-
Channel [RFC7178]:
- Process as a possible multicast native RBridge Channel packet.
o If the DA is in the initial bridging/link protocols block
(01-80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL block
and not assigned for Outer.MacDA use (01-80-C2-00-00-42 to
01-80-C2-00-00-4F), then:
- The frame is not propagated through an RBridge although some
special processing may be done at the port as specified in
[RFC6325], and the frame may be dispatched to Layer 2
processing at the port if certain protocols are supported by
that port (examples include the Link Aggregation Protocol and
the Link-Layer Discovery Protocol).
o If the DA is some other multicast value:
- Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL, M3).
- Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to the RBridge layer.
4.3.4. Transmit Processing of Multicast Packets
The following ignores the case of transmitting TRILL IS-IS packets.
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge
layer.
o If the TRILL Header multicast ("M") flag is set, the TRILL-HDR
Alert flag is set, and the OAM Ethertype is present, then:
- Construct (DA, SA, V, M2) by inserting TRILL Outer.MacDA of
All-RBridges, Outer.MacSA, Outer.VLAN, and TRILL Ethertype. M2
here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).
Note: A second copy of native format is not made.
o Else, if the TRILL Header multicast ("M") flag is set and the
Alert flag not set:
- If the port is Appointed Forwarder for iVL and the port is not
configured as a trunk port or a P2P port, strip TRILL-HDR, iSA,
iDA, and iVL and construct (DA, SA, V, M2) for native format.
- Make a second copy (DA, SA, V, M2) by inserting TRILL
Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL Ethertype. M2
here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).
o Pass the indication (DA, SA, V, M2) to the End-Station VLAN and
Priority Processing layer.
4.4. TRILL OAM Layer Processing
The TRILL OAM layer is located between the TRILL Encapsulation/Decapsulation layer and the RBridge layer. It performs the following: 1) identifies OAM frames that need local processing and 2) performs OAM processing or redirects to the CPU for OAM processing. o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer. M3 is the payload after Inner.VLAN iVL. o If the TRILL Header multicast ("M") flag is set, the TRILL Alert flag is set, and TRILL OAM Ethertype is present, then: - If MEP or MIP is configured on the Inner.VLAN/FGL of the packet, then: * Discard packets that have MD-Level less than that of the MEP or packets that do not have MD-Level present (e.g., due to packet truncation). * If MD-Level matches MD-Level of the MEP, then: + Redirect to OAM processing (Do not forward further). * If MD-Level matches MD-Level of MIP, then: + Make a copy for OAM processing and continue. * If MD-Level matches MD-Level of MEP, then: + Redirect the OAM packet to OAM processing and do not forward along or forward as a native packet. o Else, if the TRILL Alert flag is set and the TRILL OAM Ethertype is present, then: - If MEP or MIP is configured on the Inner.VLAN/FGL of the packet, then: * Discard packets that have MD-Level not present or where MD- Level is less than that of the MEP. * If MD-Level matches MD-Level of the MEP, then: + Redirect to OAM processing (do not forward further).
* If MD-Level matches MD-Level of MIP, then:
+ Make a copy for OAM processing and continue.
o Else, for a non-OAM packet:
- Continue.
o Pass the indication (DA, SA, V, M2) to the End-Station VLAN and
Priority Processing layer.
Note: In the receive path, the processing above compares with the
Down MEP and MIP Half functions. In the transmit processing, it
compares with Up MEP and MIP Half functions.
Appointed Forwarder is a function that the TRILL
Encapsulation/Decapsulation layer performs. The TRILL
Encapsulation/Decapsulation layer is responsible for prevention of
leaking of OAM packets as native frames.
5. Maintenance Associations (MAs) in TRILL
[8021Q] defines a Maintenance Association as a logical relationship
between a group of nodes. Each Maintenance Association (MA) is
identified with a unique MAID of 48 bytes [8021Q]. CCM and other
related OAM functions operate within the scope of an MA. The
definition of MA is technology independent. Similarly, it is encoded
within the OAM message, not in the technology-dependent portion of
the packet. Hence, the MAID as defined in [8021Q] can be utilized
for TRILL OAM without modifications. This also allows us to utilize
CCM and LBM messages defined in [8021Q] as is.
In TRILL, an MA may contain two or more RBridges (MEPs). For
unicast, it is likely that the MA contains exactly two MEPs that are
the two end points of the flow. For multicast, the MA may contain
two or more MEPs.
For TRILL, in addition to all of the standard [8021Q] CFM MIB
definitions, each MEP's MIB contains one or more Flow Entropy
definitions corresponding to the set of flows that the MEP monitors.
[8021Q] CFM MIB is augmented to add the TRILL-specific information.
Figure 5 depicts the augmentation of the CFM MIB to add the TRILL-
specific Flow Entropy.
MA--- | --- MEP | . - Remote MEP List . | --- MEP-A | --- MEP-B . | . - Flow Entropy List { Augments IEEE8021-CFM-MIB} | --- (Flow Entropy-1) | --- (Flow Entropy-2) | . --- (Flow Entropy-n) | Other MIB entries Figure 5: Correlation of TRILL-Augmented MIB The detailed TRILL OAM MIB will be specified in a separate document [TRILLOAMMIB].6. MEP Addressing
In IEEE CFM [8021Q], OAM messages address the target MEP by utilizing a unique MAC address. In TRILL, a MEP is addressed by a combination of the egress RBridge nickname and the Inner.VLAN/FGL. Additionally, MEPs are represented by a 2-octet MEP-ID that is independent of the underlying technology. In CFM [8021Q], the value of MEP-ID is restricted to the range of 1 to 8191. However, on a CFM [8021Q] packet, MEP-IDs are encoded as a 2-octet field. In the TRILL Base Mode operation presented in Appendix B, MEP-IDs are mapped 1-to-1 with the RBridge nicknames. Hence, in TRILL, a MEP-ID MUST be a number in the range from 1 to 65535. At the MEP, OAM packets go through a hierarchy of OpCode demultiplexers. The OpCode demultiplexers channel the incoming OAM packets to the appropriate message processor (e.g., LBM). Refer to Figure 6 for a visual depiction of these different demultiplexers.
The demultiplexing sequence is as follows:
1. Identify the packets that need OAM processing at the local
RBridge as specified in Section 4.
a. Identify the MEP that is associated with the Inner.VLAN/FGL.
2. The MEP first validates the MD-Level and then:
a. Redirects to the MD-Level demultiplexer.
3. The MD-Level demultiplexer compares the MD-Level of the packet
against the MD-Level of the local MEPs of a given MD-Level on the
port. (Note: there can be more than one MEP at the same MD-Level
but they belong to different MAs.)
a. If the packet MD-Level is equal to the configured MD-Level of
the MEP, then pass to the OpCode demultiplexer.
b. If the packet MD-Level is less than the configured MD-Level
of the MEP, discard the packet.
c. If the packet MD-Level is greater than the configured
MD-Level of the MEP, then pass on to the next-higher MD-Level
demultiplexer, if available. Otherwise, if no such higher
MD-Level demultiplexer exists, then forward the packet as
normal data.
4. The OpCode demultiplexer compares the OpCode in the packet with
supported OpCodes.
a. If the OpCode is CCM, LBM, LBR, PTM, PTR, MTVM, or MTVR, then
pass on to the correct processor.
b. If the OpCode is unknown, then discard.
| .CCM LBM PTM MTVM . . | | | | +-+-+-+-+-+-+-+-+-+-+-+-+ | OP Code DE-Mux |--- Unknown +-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ MD==Li | | | +-+-+ +-+-+ +-+-+ | L |-->|L2 |-.- |Ln |---- > +-+-+ +-+-+ +-+-+ | | ^ | | | MD<LI Drop | Drop Drop | | | MD not --- |TRILL OAM need local | Present | Processing | | | TRILL Data ---- TRILL Data ---- ------->| T |----------------- >| M |--- > + TRILL OAM ---- + pass through OAM ---- Figure 6: OAM Demultiplexers at MEP for Active SAP o T: Denotes Tap. Identifies OAM frames that need local processing. These are the packets with the Alert flag set and OAM Ethertype present after the Flow Entropy of the packet. o M: The post-processing merge that merges data and OAM messages that are passed through. Additionally, the merge component ensures, as explained earlier, that OAM packets are not forwarded out as native frames. o L: Denotes MD-Level processing. Packets whose MD-Level is less than the MD-Level of the current processing step will be dropped. Packets with equal MD-Levels are passed on to the OpCode demultiplexer. Others are passed on to the next-level MD processors or eventually to the merge point (M). NOTE: LBM, LBR, MTVM, MTVR, PTM, and PTR are not subject to MA demultiplexers. These packets do not have an MA encoded in the packet. Adequate response can be generated to these packets, without loss of functionality, by any of the MEPs present on that interface or an entity within the RBridge.
6.1. Use of MIP in TRILL
Maintenance Intermediate Points (MIPs) are mainly used for fault isolation. Link Trace Messages in [8021Q] utilize a well-known multicast MAC address, and MIPs generate responses to Link Trace Messages. Response to Link Trace Messages or lack thereof can be used for fault isolation in TRILL. As explained in Section 10, a Hop Count expiry approach will be utilized for fault isolation and path tracing. The approach is very similar to the well-known IP trace-route approach. Hence, explicit addressing of MIPs is not required for the purpose of fault isolation. Any given RBridge can have multiple MIPs located within an interface. As such, a mechanism is required to identify which MIP should respond to an incoming OAM message. Any MIP residing within the ingress interface may reply to the incoming Path Trace Message without loss of functionality or information. As specified in Section 3.4, the address of the responding RBridge can be identified by means of the Sender ID TLV (1). The Reply Ingress TLV (5) identifies the interface id. The combination of these allows the recipient of the response to uniquely identify the responder. A similar approach to that presented above for MEPs can be used for MIP processing. It is important to note that "M", the merge block of a MIP, does not prevent OAM packets leaking out as native frames. On edge interfaces, MEPs MUST be configured to prevent the leaking of TRILL OAM packets out of the TRILL campus.
PTM PTR MTVM MTVR | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OP Code De-Mux |-> Unknown +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ MD==Li | | | +-+-+ +-+-+ +-+-+ | L |- >|L2 |-.- |Ln |------+ +-+-+ +-+-+ +-+-+ | ^ | | | Drop | | MD not --- |TRILL OAM | Present | | | v TRILL Data ---- TRILL Data ----- ------- >| T |------------------ >| M |----> + TRILL OAM ---- ---- Figure 7: OAM Demultiplexers at MIP for Active SAP o T: Tap processing for MIP. All packets with the TRILL Header Alert flag set are captured. o L: MD-Level Processing. Packets with matching MD-Levels are "copied" to the OpCode demultiplexer, and the original packet is passed on to the next MD-Level processor. Other packets are simply passed on to the next MD-Level processor without copying to the OpCode demultiplexer. o M: The intermediate point processing merge that merges data and OAM messages that are passed through. Packets that carry Path Trace Message (PTM) or Multi-destination Tree Verification Message (MTVM) OpCodes are passed on to the respective processors. Packets with unknown OpCodes are counted and discarded.7. Continuity Check Message (CCM)
CCMs are used to monitor connectivity and configuration errors. [8021Q] monitors connectivity by listening to periodic CCM messages received from its remote MEP partners in the MA. An [8021Q] MEP identifies cross-connect errors by comparing the MAID in the received CCM message with the MEP's local MAID. The MAID [8021Q] is a 48-byte field that is technology independent. Similarly, the MEP-ID is a
2-byte field that is independent of the technology. Given this generic definition of CCM fields, CCM as defined in [8021Q] can be utilized in TRILL with no changes. TRILL-specific information may be carried in CCMs when encoded using TRILL-specific TLVs or sub-TLVs. This is possible since CCMs may carry optional TLVs. Unlike classical Ethernet environments, TRILL contains multipath forwarding. The path taken by a packet depends on the payload of the packet. The Maintenance Association (MA) identifies the interested Maintenance End Points (MEPs) of a given monitored path. For unicast, there are only two MEPs per MA. For multicast, there can be two or more MEPs in the MA. The entropy values of the monitored flows are defined within the MA. CCM transmit logic will utilize these Flow Entropy values when constructing the CCM packets. Please see Section 12 for the theory of operation of CCM. The MIB in [8021Q] is augmented with the definition of Flow Entropy. Please see [TRILLOAMMIB] for this and other TRILL-related OAM MIB definitions. Figure 8 depicts the correlation between MA, CCM, and the Flow Entropy.
MA--- | --- MEP | . - Remote MEP List . | --- MEP-A | --- MEP-B . | . - Flow Entropy List {Augments IEEE8021-CFM-MIB} | --- (Flow Entropy-1) | --- (Flow Entropy-2) | . ---(Flow Entropy-n) | . - CCM | --- (standard 8021ag entries) | --- (Hop Count) { Augments IEEE8021-CFM-MIB} | --- (Any other TRILL OAM-specific entries) {Augmented} | . | - Other MIB entries Figure 8: Augmentation of CCM MIB in TRILL In a multi-pathing environment, a flow, by definition, is unidirectional. A question may arise as to what Flow Entropy should be used in the response. CCMs are unidirectional and have no explicit reply; as such, the issue of the response Flow Entropy does not arise. In the transmitted CCM, each MEP reports local status using the Remote Defect Indication (RDI) flag. Additionally, a MEP may raise SNMP TRAPs [TRILLOAMMIB] as alarms when a connectivity failure occurs.
8. TRILL OAM Message Channel
The TRILL OAM Message Channel can be divided into two parts: TRILL OAM message header and TRILL OAM TLVs. Every OAM message MUST contain a single TRILL OAM message header and a set of one or more specified OAM message TLVs.8.1. TRILL OAM Message Header
As discussed earlier, a common messaging framework between [8021Q], TRILL, and other similar standards such as Y.1731 is accomplished by reusing the OAM message header defined in [8021Q]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MD-L | Version | OpCode | Flags |FirstTLVOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . OpCode-Specific Information . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . TLVs . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: OAM Message Format o MD-L: Maintenance Domain Level (3 bits). For TRILL, in general, this field is set to a single value across the TRILL campus. When using the TRILL Base Mode as specified in Appendix B, MD-L is set to 3. However, extension of TRILL (for example, to support multilevel) may create different MD-Levels, and the MD-L field must be appropriately set in those scenarios. (Please refer to [8021Q] for the definition of MD-Level). o Version: Indicates the version (5 bits) as specified in [8021Q]. This document does not require changing the Version defined in [8021Q]. o OpCode: Operation Code (8 bits). Specifies the operation performed by the message. See Section 8.2. o Flags: Includes operational flags (1 byte). The definition of flags is OpCode-specific and is covered in the applicable sections.
o FirstTLVOffset: Defines the location of the first TLV, in bytes,
starting from the end of the FirstTLVOffset field (1 byte).
(Refer to [8021Q] for the definition of the FirstTLVOffset.)
o OpCode-Specific Information: May contain Session Identification
Number, timestamp, etc.
The MD-L, Version, OpCode, Flags, and FirstTLVOffset fields
collectively are referred to as the OAM message header.
8.2. TRILL-Specific OAM OpCodes
The following TRILL-specific CFM OpCodes are defined. Each of the
OpCodes indicates a separate type of TRILL OAM message. Details of
the messages are presented in Sections 10 and 11.
TRILL OAM message OpCodes:
64: Path Trace Reply
65: Path Trace Message
66: Multi-destination Tree Verification Reply
67: Multi-destination Tree Verification Message
Loopback and CCM Messages reuse the OpCodes defined by [8021Q].
8.3. Format of TRILL OAM TLV
The same CFM TLV format as defined in [8021Q] is used for TRILL OAM.
The following figure depicts the general format of a TRILL OAM TLV:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRILL OAM TLV
o Type (1 octet): Specifies the type of the TLV (see Section 8.4 for
TLV types).
o Length (2 octets): Specifies the length of the Value field in
octets. Length of the Value field can be zero or more octets.
o Value (variable): The length and the content of this field depend
on the type of TLV. Please refer to applicable TLV definitions
for details.
Semantics and usage of Type values allocated for TRILL OAM purpose
are defined by this document and other future related documents.
8.4. TRILL OAM TLVs
TRILL-related TLVs are defined in this section. TLVS defined in
[8021Q] are reused, where applicable.
8.4.1. Common TLVs between CFM and TRILL
The following TLVs are defined in [8021Q]. We reuse them where
applicable. The format and semantics of the TLVs are as defined in
[8021Q].
Type Name of TLV in [8021Q]
---- ----------------------
0 End TLV
1 Sender ID TLV
2 Port Status TLV
3 Data TLV
4 Interface Status TLV
5 Reply Ingress TLV
6 Reply Egress TLV
7 LTM Egress Identifier TLV
8 LTR Egress Identifier TLV
9-30 Reserved
31 Organization Specific TLV
8.4.2. TRILL OAM-Specific TLVs
Listed below is a summary of TRILL OAM TLVs and their corresponding
codes. Format and semantics of TRILL OAM TLVs are defined in
subsequent sections.
Type TLV Name
---- ------------------------------------
64 TRILL OAM Application Identifier TLV
65 Out-of-Band Reply Address TLV
66 Diagnostic Label TLV
67 Original Data Payload TLV
68 RBridge Scope TLV
69 Previous RBridge Nickname TLV
70 Next-Hop RBridge List TLV
71 Multicast Receiver Port Count TLV
72 Flow Identifier TLV
73 Reflector Entropy TLV
74 Authentication TLV
The TRILL OAM Application Identifier TLV (64) MUST be the first TLV.
An End TLV (0) MUST be included as the last TLV. All other TLVs can
be included in any order.
8.4.3. TRILL OAM Application Identifier TLV
The TRILL OAM Application Identifier TLV carries information specific
to TRILL OAM applications. The TRILL OAM Application Identifier TLV
MUST always be present and MUST be the first TLV in TRILL OAM
messages. Messages that do not include the TRILL OAM Application
Identifier TLV as the first TLV MUST be discarded by a TRILL MP.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Fragment-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |Return Sub-code| Reserved2 |F|C|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TRILL OAM Application Identifier TLV
o Type (1 octet): 64, TRILL OAM Application Identifier TLV
o Length (2 octets): 9
o Version (1 octet): Currently set to zero. Indicates the TRILL OAM
version. The TRILL OAM version can be different than the [8021Q]
version.
o Reserved1 (3 octets): Set to zero on transmission and ignored on
reception.
o Fragment-ID (1 octet): Indicates the fragment number of the
current message. This applies only to reply messages; in request
messages, it must be set to zero on transmission and ignored on
receipt. The "F" flag defined below MUST be set with the final
message, whether it is the last fragment of the fragmented message
or the only message of the reply. Section 13 provides more
details on OAM message fragmentation.
o Return Code (1 octet): Set to zero on requests. Set to an
appropriate value in response messages.
o Return Sub-code (1 octet): Set to zero on transmission of request
message. The Return Sub-code identifies categories within a
specific Return Code and MUST be interpreted within a Return Code.
o Reserved2 (12 bits): Set to zero on transmission and ignored on
reception.
o F (1 bit): Final flag. When set, indicates this is the last
response.
o C (1 bit): Cross-Connect Error flag (VLAN/FGL mapping error). If
set, indicates that the label (VLAN/FGL) in the Flow Entropy is
different than the label included in the Diagnostic Label TLV.
This field is ignored in request messages and MUST only be
interpreted in response messages.
o O (1 bit): If set, indicates OAM out-of-band response requested.
o I (1 bit): If set, indicates OAM in-band response requested.
NOTE: When both O and I bits are set to zero, this indicates that no
response is required (silent mode). Users MAY specify both O and I,
one of them, or none. When both O and I bits are set, the response
is sent both in-band and out-of-band.
8.4.4. Out-of-Band Reply Address TLV
The Out-of-Band Reply Address TLV specifies the address to which an out-of-band OAM reply message MUST be sent. When the O bit in the TRILL Version sub-TLV (Section 3.3) is not set, the Out-of-Band Reply Address TLV is ignored. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+ | | | . Reply Address . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Out-of-Band Reply Address TLV o Type (1 octet): 65, Out-of-Band Reply Address TLV o Length (2 octets): Variable. Minimum length is 2 + the length (in octets) of the shortest address. Currently, the minimum value of this field is 4, but this could change in the future if a new address shorter than the TRILL nickname is defined. o Address Type (1 octet): 0 - IPv4 1 - IPv6 2 - TRILL nickname All other values reserved. o Addr Length (1 octet): Depends on the Address Type. Currently, defined values are: 4 - IPv4 16 - IPv6 2 - TRILL nickname Other lengths may be acceptable for future Address Types.
o Reply Address (variable): Address where the reply needs to be
sent. Length depends on the address specification.
8.4.5. Diagnostic Label TLV
The Diagnostic Label TLV specifies the data label (VLAN or FGL) in
which the OAM messages are generated. Receiving RBridge MUST compare
the data label of the Flow Entropy to the data label specified in the
Diagnostic Label TLV. The "C" flag (Cross Connect Error) in the
response (TRILL OAM Application Identifier TLV; Section 8.4.3) MUST
be set when the two VLANs do not match.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | L-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Diagnostic Label TLV
o Type (1 octet): 66, Diagnostic Label TLV
o Length (2 octets): 5
o L-Type (1 octet): Label type
0 - Indicates a right-justified 802.1Q 12-bit VLAN padded on the
left with bits that must be sent as zero and ignored on
receipt
1 - Indicates a TRILL 24-bit fine-grained label
o Reserved (1 octet): Set to zero on transmission and ignored on
reception.
o Label (24 bits): Either 12-bit VLAN or 24 bit fine-grained label.
RBridges do not perform label error checking when the Diagnostic
Label TLV is not included in the OAM message. In certain
deployments, intermediate devices may perform label translation. In
such scenarios, the originator should not include the Diagnostic
Label TLV in OAM messages. Inclusion of Diagnostic Label TLV will
generate unwanted label error notifications.
8.4.6. Original Data Payload TLV
1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . Original Payload . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Original Data Payload TLV o Type (1 octet): 67, Original Data Payload TLV o Length (2 octets): variable o Original Payload: The original TRILL Header and Flow Entropy. Used in constructing replies to the Loopback Message (see Section 9) and the Path Trace Message (see Section 10).8.4.7. RBridge Scope TLV
The RBridge Scope TLV identifies nicknames of RBridges from which a response is required. The RBridge Scope TLV is only applicable to Multi-destination Tree Verification Messages. This TLV SHOULD NOT be included in other messages. Receiving RBridges MUST ignore this TLV on messages other than Multi-destination Tree Verification Messages. Each TLV can contain up to 255 nicknames of in-scope RBridges. A Multi-destination Tree Verification Message may contain multiple RBridge scope TLVs, in the event that more than 255 in-scope RBridges need to be specified. Absence of the RBridge Scope TLV indicates that a response is needed from all the RBridges. Please see Section 11 for details.
1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | nOfnicknames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname-1 | Nickname-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Nickname-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: RBridge Scope TLV o Type (1 octet): 68, RBridge Scope TLV o Length (2 octets): Variable. Minimum value is 1. o nOfnicknames (1 octet): Indicates the number of nicknames included in this TLV. Zero (0) indicates no nicknames are included in the TLV. When this field is set to zero (0), the Length field MUST be set to 1. o Nickname (2 octets): 16-bit RBridge nickname8.4.8. Previous RBridge Nickname TLV
The Previous RBridge Nickname TLV identifies the nickname or nicknames of the previous RBridge. [RFC6325] allows a given RBridge to hold multiple nicknames. The Previous RBridge Nickname TLV is an optional TLV. Multiple instances of this TLV MAY be included when an upstream RBridge is represented by more than 255 nicknames (highly unlikely). 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (continued) | Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Previous RBridge Nickname TLV o Type (1 octet): 69, Previous RBridge Nickname TLV o Length (2 octets): 5
o Reserved (3 octet): Set to zero on transmission and ignored on
reception.
o Nickname (2 octets): RBridge nickname
8.4.9. Next-Hop RBridge List TLV
The Next-Hop RBridge List TLV identifies the nickname or nicknames of
the downstream next-hop RBridges. [RFC6325] allows a given RBridge
to have multiple equal-cost paths to a specified destination. Each
next-hop RBridge is represented by one of its nicknames.
The Next-Hop RBridge List TLV is an optional TLV. Multiple instances
of this TLV MAY be included when there are more than 255 equal-cost
paths to the destination.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname-1 | Nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Next-Hop RBridge List TLV
o Type (1 octet): 70, Next-Hop RBridge List TLV
o Length (2 octets): Variable. Minimum value is 1.
o nOfnicknames (1 octet): Indicates the number of nicknames included
in this TLV. Zero (0) indicates no nicknames are included in the
TLV. When this field is set to zero (0), the Length field MUST be
set to 1.
o Nickname (2 octets): 16-bit RBridge nickname
8.4.10. Multicast Receiver Port Count TLV
The Multicast Receiver Port Count TLV identifies the number of ports
interested in receiving the specified multicast stream within the
responding RBridge on the label (VLAN or FGL) specified by the
Diagnostic Label TLV.
The Multicast Receiver Port Count TLV is an optional TLV. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Receivers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Multicast Receiver Port Count TLV o Type (1 octet): 71, Multicast Receiver Port Count TLV o Length (2 octets): 5 o Reserved (1 octet): Set to zero on transmission and ignored on reception. o Number of Receivers (4 octets): Indicates the number of multicast receivers available on the responding RBridge on the label specified by the diagnostic label.8.4.11. Flow Identifier TLV
The Flow Identifier TLV uniquely identifies a specific flow. The flow-identifier value is unique per MEP and needs to be interpreted as such. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MEP-ID | flow-identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: Flow Identifier TLV o Type (1 octet): 72, Flow Identifier TLV o Length (2 octets): 5 o Reserved (1 octet): Set to 0 on transmission and ignored on reception. o MEP-ID (2 octets): MEP-ID of the originator [8021Q]. In TRILL, MEP-ID can take a value from 1 to 65535.
o flow-identifier (2 octets): Uniquely identifies the flow per MEP.
Different MEPs may allocate the same flow-identifier value. The
{MEP-ID, flow-identifier} pair is globally unique.
Inclusion of the MEP-ID in the Flow Identifier TLV allows the
inclusion of a MEP-ID for messages that do not contain a MEP-ID in
their OAM header. Applications may use MEP-ID information for
different types of troubleshooting.
8.4.12. Reflector Entropy TLV
The Reflector Entropy TLV is an optional TLV. This TLV, when
present, tells the responder to utilize the Reflector Entropy
specified within the TLV as the flow-entropy of the response message.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Reflector Entropy .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Reflector Entropy TLV
o Type (1 octet): 73, Reflector Entropy TLV
o Length (2 octets): 97
o Reserved (1 octet): Set to zero on transmission and ignored by the
recipient.
o Reflector Entropy (96 octets): Flow Entropy to be used by the
responder. May be padded with zeros if the desired flow-entropy
information is less than 96 octets.
8.4.13. Authentication TLV
The Authentication TLV is an optional TLV that can appear in any OAM message or reply in TRILL. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Auth Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Authentication Value . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: Authentication TLV o Type (1 octet): 74, Authentication TLV o Length (2 octets): Variable o The Auth Type and following Authentication Value are the same as the Auth Type and following value for the [IS-IS] Authentication TLV. It is RECOMMENDED that Auth Type 3 be used. Auth Types 0, 1, 2, and 54 MUST NOT be used. With Auth Type 3, the Authentication TLV is as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Auth Type = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . Authentication Data (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: Authentication TLV with Auth Type 3 With Auth Type 3, the process is generally as specified in [RFC5310] using the same Key ID space as TRILL [IS-IS]. The area covered by the Authentication TLV is from the beginning of the TRILL Header to the end of the TRILL OAM Message Channel; the Link Header and Trailer are not included. The TRILL Header Alert, Reserved bit, and Hop Count are treated as zero for the purposes of computing and verifying the Authentication Data.
Key distribution is out of the scope of this document as the keying distributed for IS-IS is used. An RBridge supporting OAM authentication can be configured to either (1) ignore received OAM Authentication TLVs and not send them, (2) ignore received OAM Authentication TLVs but include them in all OAM packets sent, or (3) to include Authentication TLVs in all OAM messages sent and enforce authentication of OAM messages received. When an RBridge is enforcing authentication, it discards any OAM message subject to OAM processing that does not contain an Authentication TLV or an Authentication TLV does not verify.
(page 38 continued on part 3)
