RFC 7455
Transparent Interconnection of Lots of Links (TRILL): Fault Management
9. Loopback Message
9.1. Loopback Message Format
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MD-L | Version | OpCode | Flags |FirstTLVOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loopback Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . TLVs . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: Loopback Message Format The figure above depicts the format of the Loopback Request and Response messages as defined in [8021Q]. The OpCode for the Loopback Message is set to 3, and the OpCode for the reply message is set to 2 [8021Q]. The Loopback Transaction Identifier (commonly called the Session Identification Number or Session ID in this document) is a 32-bit integer that allows the requesting RBridge to uniquely identify the corresponding session. Responding RBridges, without modification, MUST echo the received "Loopback Transaction Identifier" number.
9.2. Theory of Operation
9.2.1. Actions by Originator RBridge
The originator RBridge takes the following actions: o Identifies the destination RBridge nickname based on user specification or based on the specified destination MAC or IP address. o Constructs the Flow Entropy based on user-specified parameters or implementation-specific default parameters. o Constructs the TRILL OAM header: sets the OpCode to Loopback Message type (3) [8021Q]. Assigns applicable Loopback Transaction Identifier number for the request. o The TRILL OAM Application Identifier TLV MUST be included with the flags set to applicable values. o Includes following OAM TLVs, where applicable: - Out-of-Band Reply Address TLV - Diagnostic Label TLV - Sender ID TLV o Specifies the Hop Count of the TRILL Data frame per user specification or utilize an applicable Hop Count value. o Dispatches the OAM frame for transmission. RBridges may continue to retransmit the request at periodic intervals until a response is received or the retransmission count expires. At each transmission, the Session Identification Number MUST be incremented.9.2.2. Intermediate RBridge
Intermediate RBridges forward the frame as a normal data frame; no special handling is required.
9.2.3. Destination RBridge
If the Loopback Message is addressed to the local RBridge and satisfies the OAM identification criteria specified in Section 3.1, then the RBridge data plane forwards the message to the CPU for further processing. The TRILL OAM application layer further validates the received OAM frame by checking for the presence of OAM Ethertype at the end of the Flow Entropy. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded. Construction of the TRILL OAM response: o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes it in the OAM message. o Set the Return Code to (1) "Reply" and Return Sub-code to zero (0) "Valid Response". Update the TRILL OAM OpCode to 2 (Loopback Message Reply). o Optionally, if the VLAN/FGL identifier value of the received Flow Entropy differs from the value specified in the Diagnostic Label TLV, set the "C" flag (Cross Connect Error) in the TRILL OAM Application Identifier TLV. o Include the Sender ID TLV (1). o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname. o If out-of-band response was requested, dispatch the frame to the IP forwarding process.10. Path Trace Message
The primary use of the Path Trace Message is for fault isolation. It may also be used for plotting the path taken from a given RBridge to another RBridge. [8021Q] accomplishes the objectives of the TRILL Path Trace Message using Link Trace Messages. Link Trace Messages utilize a well-known multicast MAC address. This works for [8021Q] because both the unicast and multicast paths are congruent. However, in TRILL, multicast and unicast are not congruent. Hence, TRILL OAM uses a new message format: the Path Trace Message.
The Path Trace Message has the same format as the Loopback Message. The OpCode for Path Trace Reply is 64, and the OpCode for the Path Trace Message is 65. Operation of the Path Trace Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop Count field value of 1. The sending RBridge expects an "Intermediate RBridge" Return Sub-code from the next hop or a "Valid response" Return Sub-code response from the destination RBridge. If an "Intermediate RBridge" Return Sub-code is received in the response, the originator RBridge records the information received from the intermediate node that generated the message and resends the message by incrementing the previous Hop Count value by 1. This process is continued until, a response is received from the destination RBridge, a Path Trace process timeout occurs, or the Hop Count reaches a configured maximum value.10.1. Theory of Operation
10.1.1. Actions by Originator RBridge
The originator RBridge takes the following actions: o Identifies the destination RBridge based on user specification or based on location of the specified MAC address. o Constructs the Flow Entropy based on user-specified parameters or implementation-specific default parameters. o Constructs the TRILL OAM header: set the OpCode to Path Trace Message type (65). Assign an applicable Session Identification number for the request. Return Code and Return Sub-code MUST be set to zero. o The TRILL OAM Application Identifier TLV MUST be included with the flags set to applicable values. o Includes the following OAM TLVs, where applicable: - Out-of-Band Reply Address TLV - Diagnostic Label TLV - Sender ID TLV o Specifies the Hop Count of the TRILL Data frame as 1 for the first request.
o Dispatches the OAM frame to the TRILL data plane for transmission. An RBridge may continue to retransmit the request at periodic intervals until a response is received or the retransmission count expires. At each new retransmission, the Session Identification number MUST be incremented. Additionally, for responses received from intermediate RBridges, the RBridge nickname and interface information MUST be recorded.10.1.2. Intermediate RBridge
Path Trace Messages transit through Intermediate RBridges transparently, unless the Hop Count has expired. The TRILL OAM application layer further validates the received OAM frame by examining the presence of the TRILL Alert flag and OAM Ethertype at the end of the Flow Entropy and by examining the MD-Level. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded. Construction of the TRILL OAM response: o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes it in the OAM message. o Set the Return Code to (1) "Reply" and Return Sub-code to two (2) "Intermediate RBridge". Update the TRILL OAM OpCode to 64 (Path Trace Reply). o If the VLAN/FGL identifier value of the received Flow Entropy differs from the value specified in the diagnostic label, set the "C" flag (Cross Connect Error) in the TRILL OAM Application Identifier TLV. o Include the following TLVs: - Previous RBridge Nickname TLV (69) - Reply Ingress TLV (5) - Reply Egress TLV (6) - Interface Status TLV (4) - Next-Hop RBridge List TLV (70) (Repeat for each ECMP) - Sender ID TLV (1)
o If a cross-connect error is detected, set the "C" flag (Cross-
Connect Error) in the reply's TRILL OAM Application Identifier
TLV.
o If in-band response was requested, dispatch the frame to the TRILL
data plane with request-originator RBridge nickname as the egress
RBridge nickname.
o If out-of-band response was requested, dispatch the frame to the
standard IP forwarding process.
10.1.3. Destination RBridge
Processing is identical to that in Section 10.1.2 with the exception
that the TRILL OAM OpCode is set to Path Trace Reply (64).
11. Multi-Destination Tree Verification Message (MTVM)
Multi-destination Tree Verification Messages allow verifying TRILL
distribution tree integrity and pruning. TRILL VLAN/FGL and
multicast pruning are described in [RFC6325], [RFC7180], and
[RFC7172]. Multi-destination Tree Verification and Multicast Group
Verification Messages are designed to detect pruning defects.
Additionally, these tools can be used for plotting a given multicast
tree within the TRILL campus.
Multi-destination Tree Verification OAM frames are copied to the CPU
of every intermediate RBridge that is part of the distribution tree
being verified. The originator of the Multi-destination Tree
Verification Message specifies the scope of RBridges from which a
response is required. Only the RBridges listed in the scope field
respond to the request. Other RBridges silently discard the request.
Inclusion of the scope field is required to prevent receiving an
excessive number of responses. The typical scenario of distribution
tree verification or group verification involves verifying multicast
connectivity to a selected set of end nodes as opposed to the entire
network. Availability of the scope facilitates narrowing down the
focus to only the RBridges of interest.
Implementations MAY choose to rate-limit CPU-bound multicast traffic.
As a result of rate-limiting or due to other congestion conditions,
MTVM messages may be discarded from time to time by the intermediate
RBridges, and the requester may be required to retransmit the
request. Implementations SHOULD narrow the embedded scope of
retransmission requests only to RBridges that have failed to respond.
11.1. MTVM Format
The format of MTVM is identical to the Loopback Message format defined in Section 9 with the exception that the OpCode used is 67.11.2. Theory of Operation
11.2.1. Actions by Originator RBridge
The user is required, at a minimum, to specify either the distribution trees that need to be verified, the Multicast MAC address and VLAN/FGL, or the VLAN/FGL and Multicast Destination IP address. Alternatively, for more specific multicast flow verification, the user MAY specify more information, e.g., source MAC address, VLAN/FGL, and Destination and Source IP addresses. Implementations, at a minimum, must allow the user to specify a choice of distribution trees, Destination Multicast MAC address, and VLAN/FGL that needs to be verified. Although it is not mandatory, it is highly desired to provide an option to specify the scope. It should be noted that the source MAC address and some other parameters may not be specified if the backwards-compatibility method in Appendix A is used to identify the OAM frames. Default parameters MUST be used for unspecified parameters. Flow Entropy is constructed based on user-specified parameters and/or default parameters. Based on user specified parameters, the originating RBridge does the following: o Identifies the nickname that represents the multicast tree. o Obtains the applicable Hop Count value for the selected multicast tree. o Constructs TRILL OAM message header and includes the Session Identification number. The Session Identification Number facilitates the originator mapping the response to the correct request. o Includes the TRILL OAM Application Identifier TLV, which MUST be included. o Includes the OpCode Multicast Tree Verification Message (67). o Includes RBridge Scope TLV (68).
o Optionally, includes the following TLVs, where applicable:
- Out-of-Band IP Address TLV (65)
- Diagnostic Label TLV (66)
- Sender ID TLV (1)
o Specifies the Hop Count of the TRILL Data frame per user
specification or alternatively utilizes the applicable Hop Count
value if the TRILL Hop Count is not being specified by the user.
o Dispatches the OAM frame to the TRILL data plane to be ingressed
for transmission.
The RBridge may continue to retransmit the request at a periodic
interval until either a response is received or the retransmission
count expires. At each new retransmission, the Session
Identification Number MUST be incremented. At each retransmission,
the RBridge may further reduce the scope to the RBridges that it has
not received a response from.
11.2.2. Receiving RBridge
Receiving RBridges identify multicast verification frames per the
procedure explained in Section 3.2.
The RBridge validates the frame and analyzes the scope RBridge list.
If the RBridge Scope TLV is present and the local RBridge nickname is
not specified in the scope list, it will silently discard the frame.
If the local RBridge is specified in the scope list OR the RBridge
Scope TLV is absent, the receiving RBridge proceeds with further
processing as defined in Section 11.2.3.
11.2.3. In-Scope RBridges
Construction of the TRILL OAM response:
o The TRILL OAM application encodes the received TRILL Header and
Flow Entropy in the Original Data Payload TLV and includes them in
the OAM message.
o Set the Return Code to zero (0) and Return Sub-code to zero (0).
Update the TRILL OAM OpCode to 66 (Multi-destination Tree
Verification Reply).
o Include following TLVs:
- Previous RBridge Nickname TLV (69)
- Reply Ingress TLV (5)
- Interface Status TLV (4)
- Next-Hop RBridge List TLV (70)
- Sender ID TLV (1)
- Multicast Receiver Port Count TLV (71)
o If a VLAN/FGL cross-connect error is detected, set the "C" flag
(Cross-Connect Error) in the TRILL OAM Application Identifier TLV.
o If in-band response was requested, dispatch the frame to the TRILL
data plane with request-originator RBridge nickname as the egress
RBridge nickname.
o If out-of-band response was requested, dispatch the frame to the
standard IP forwarding process.
12. Application of Continuity Check Message (CCM) in TRILL
Section 7 provides an overview of CCM Messages defined in [8021Q] and
how they can be used within TRILL OAM. This section presents the
application and theory of operations of CCM within the TRILL OAM
framework. Readers are referred to [8021Q] for CCM message format
and applicable TLV definitions and usages. Only the TRILL-specific
aspects are explained below.
In TRILL, between any two given MEPs, there can be multiple potential
paths. Whereas in [8021Q], there is always a single path between any
two MEPs at any given time. [RFC6905] requires solutions to have the
ability to monitor continuity over one or more paths.
CCM Messages are uni-directional, such that there is no explicit
response to a received CCM message. Connectivity status is indicated
by setting the applicable flags (e.g., RDI) of the CCM messages
transmitted by a MEP.
It is important that the solution presented in this document
accomplishes the requirements specified in [RFC6905] within the
framework of [8021Q] in a straightforward manner and with minimum
changes. Section 8 defines multiple flows within the CCM object,
each corresponding to a flow that a given MEP wishes to monitor. Hence, CCM, in multipath environments like TRILL, monitors per-flow connectivity and cross-connect errors. Receiving MEPs do not cross-check whether a received CCM belongs to a specific flow from the originating RBridge. Any attempt to track status of individual flows may explode the amount of state information that any given RBridge has to maintain. The obvious question arises: how does the originating RBridge know which flow or flows are at fault? This is accomplished with a combination of the RDI flag in the CCM header, Flow Identifier TLV, and SNMP Notifications (Traps). Section 12.1 discusses the procedure.12.1. CCM Error Notification
Each MEP transmits four CCM messages per each flow. ([8021Q] detects CCM fault when three consecutive CCM messages are lost). Each CCM message has a unique sequence number (Session ID) and unique flow- identifier. The flow-identifier is included in the OAM message via the Flow Identifier TLV. When a MEP notices a CCM timeout from a remote MEP (MEP-A), it sets the RDI flag on the next CCM message it generates. Additionally, it logs and sends an SNMP notification that contains the remote MEP Identification, flow-identifier, and the sequence number of the last CCM message it received, and, if available, the flow-identifier and the sequence number of the first CCM message it received after the failure. Each MEP maintains a unique flow-identifier per each flow; hence, the operator can easily identify flows that correspond to the specific flow-identifier. The following example illustrates the above. Assume there are two MEPs: MEP-A and MEP-B. Assume there are three flows between MEP-A and MEP-B. Let's assume MEP-A allocates sequence numbers as follows: Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-identifier=(1) Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-identifier=(2) Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-identifier=(3)
Let's assume Flow-2 is at fault. MEP-B receives CCM from MEP-A with sequence numbers 1, 2, 3, and 4 but did not receive 5, 6, 7, and 8. CCM timeout is set to three CCM intervals in [8021Q]. Hence, MEP-B detects the error at the 8th CCM message. At this time, the sequence number of the last good CCM message MEP-B has received from MEP-A is 4, and the flow-identifier of the last good CCM Message is (1). Hence, MEP-B will generate a CCM error SNMP notification with MEP-A, last good flow-identifier (1), and sequence number 4. When MEP-A switches to Flow-3 after transmitting Flow-2, MEP-B will start receiving CCM messages. In the foregoing example, it will be a CCM message with sequence numbers 9, 10, 11, 12, and 21 and so on. When in receipt of a new CCM message from a specific MEP, after a CCM timeout, the TRILL OAM will generate an SNMP Notification of CCM resume with remote MEP-ID, the first valid flow-identifier, and the sequence number after the CCM timeout. In the foregoing example, it is MEP-A, flow-identifier (3), and sequence number 9. The remote MEP list under the CCM MIB Object is augmented to contain "Last Sequence Number", flow-identifier, and "CCM Timeout" variables. "Last Sequence Number" and flow-identifier are updated every time a CCM is received from a remote MEP. The CCM Timeout variable is set when the CCM timeout occurs and is cleared when a CCM is received.12.2. Theory of Operation
12.2.1. Actions by Originator RBridge
The originator RBridge takes the following actions: o Derives the Flow Entropy field based on flow-entropy information specified in the CCM Management object. o Constructs the TRILL CCM OAM header as specified in [8021Q]. o The TRILL OAM Application Identifier TLV MUST be included as the first TLV with the flags set to applicable values. o Includes other TLVs specified in [8021Q]. o Includes the following optional TLV, where applicable: - Sender ID TLV (1) o Specifies the Hop Count of the TRILL Data frame per user specification or utilize an applicable Hop Count value.
o Dispatches the OAM frame to the TRILL data plane for transmission. An RBridge transmits a total of four requests, each at CCM retransmission interval. At each transmission, the Session Identification number MUST be incremented by one. At the 5th retransmission interval, the Flow Entropy of the CCM packet is updated to the next flow-entropy information specified in the CCM Management object. If the current Flow Entropy is the last Flow Entropy specified, move to the first Flow Entropy specified and continue the process.12.2.2. Intermediate RBridge
Intermediate RBridges forward the frame as a normal data frame; no special handling is required.12.2.3. Destination RBridge
If the CCM Message is addressed to the local RBridge or multicast and satisfies the OAM identification methods specified in Section 3.2, then the RBridge data plane forwards the message to the CPU for further processing. The TRILL OAM application layer further validates the received OAM frame by examining the presence of OAM Ethertype at the end of the Flow Entropy. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded. The TRILL OAM application layer then validates the MD-Level and pass the packet to the OpCode demultiplexer. The OpCode demultiplexer delivers CCM packets to the CCM process. The CCM process performs the processing specified in [8021Q]. Additionally, the CCM process updates the CCM Management object with the sequence number of the received CCM packet. Note: The last received CCM sequence number and CCM timeout are tracked per each remote MEP. If the CCM timeout is true for the sending remote MEP, then clear the CCM timeout in the CCM Management object and generate the SNMP notification as specified above.
13. Fragmented Reply
TRILL OAM allows fragmented reply messages. In case of fragmented replies, all parts of the reply MUST follow the procedure defined in this section. The same Session Identification Number MUST be included in all related fragments of the same message. The TRILL OAM Application Identifier TLV MUST be included, with the Fragment-ID field monotonically increasing with each fragment transmitted with the appropriate Final flag field. The Final flag MUST only be equal to one on the final fragment of the reply. On the receiver, the process MUST order the fragments based on the Fragment-ID. Any fragments received after the final fragment MUST be discarded. Messages with incomplete fragments (i.e., messages with one or missing fragments after the receipt of the fragment with the final flag set) MUST be discarded as well. If the number of fragments exceeds the maximum supported fragments (255), then the Return Code of the reply message MUST be set to 1 (Reply message), and the Return Sub-code MUST be set to 1 (Fragment limit exceeded).14. Security Considerations
Forged OAM packets could cause false error or failure indications, mask actual errors or failures, or be used for denial of service. Source addresses for messages can be forged and the out-of-band reply facility (see Section 8.4.4) provides for explicitly supplying the address for replies. For protection against forged OAM packets, the Authentication TLV (see Section 8.4.13) can be used in an OAM message in TRILL. This TLV is virtually identical to the IS-IS Authentication TLV specified in [IS-IS] and depends on IS-IS keying material and the current state of IS-IS keying as discussed in [KARPISIS] and [RFC5310]. In particular, there is currently no standardized IS-IS automated key management. Of course, authentication is ineffective unless verified and ineffective against senders who have the keying material needed to produce OAM messages that will pass authentication checks. Implementations MUST implement rate-limiting functionality to protect against exploitation of OAM messages as a means of denial-of-service attacks. Aggressive rate-limiting may trigger false positive errors against CCM and LBM-based session monitoring.
Even with authentication, replay of authenticated messages may be possible. There are four types of messages: Continuity Check (CCM), Loopback, Path Trace, and Multi-destination Tree Verification (MTVM). In the case of CCM messages, sequence numbers are required (see Section 12.1) that can protect against replay. In the case of Loopback Messages (see Section 9.1), a Loopback Transaction Identifier is included that, as required by [8021Q], is incremented with each transmission and can detect replays. PTMs (see Section 10) and MTVMs (see Section 11.1) are specified to have the same format as Loopback Messages (although with different OpCodes), so they also have an identifier incremented with each transmission that can detect replays. Thus, all TRILL OAM messages have a field that can be used for replay protection. For general TRILL-related security considerations, please refer to [RFC6325]. [8021Q] requires that the MEP filters or passes through OAM messages based on the MD-Level. The MD-Level is embedded deep in the OAM message. Hence, conventional methods of frame filtering may not be able to filter frames based on the MD-Level. As a result, OAM messages that must be dropped due to MD-Level mismatch may leak into a TRILL domain with a different MD-Level. This leaking may not cause any functionality loss. The receiving MEP/MIP is required to validate the MD-level prior to acting on the message. Any frames received with an incorrect MD-Level need to be dropped. Generally, a single operator manages each TRILL campus; hence, there is no risk of security exposure. However, in the event of multi- operator deployments, operators should be aware of possible exposure of device-specific information, and appropriate measures must be taken. It is also important to note that the MPLS OAM framework [RFC4379] does not include the concept of domains and OAM filtering based on operators. It is our opinion that the lack of OAM frame filtering based on domains does not introduce significant functional deficiency or security risk. It is possible to mandate requiring different credentials to use different OAM functions or capabilities within a specific OAM function. Implementations may consider grouping users to different security clearance levels and restricting functions and capabilities to different clearance levels. However, exact implementation details of such a framework are outside the scope of this document.
15. IANA Considerations
IANA has made the assignments described below.15.1. OAM Capability Flags
Two TRILL-VER sub-TLV Capability Flags (see Section 3.3) have been assigned as follows: Bit Description Reference --- ----------- --------- 2 OAM capable RFC 7455 3 Backwards-compatible OAM RFC 745515.2. CFM Code Points
Four OpCodes have been assigned from the "CFM OAM IETF OpCodes" sub- registry as follows: Value Assignment Reference ----- ---------- --------- 64 Path Trace Reply RFC 7455 65 Path Trace Message RFC 7455 66 Multi-destination Tree Verification Reply RFC 7455 67 Multi-destination Tree Verification Message RFC 7455 Eleven TLV Types have been assigned from the "CFM OAM IETF TLV Types" sub-registry as follows: Value Assignment Reference ----- ---------- --------- 64 TRILL OAM Application Identifier TLV RFC 7455 65 Out-of-Band Reply Address TLV RFC 7455 66 Diagnostic Label TLV RFC 7455 67 Original Data Payload TLV RFC 7455 68 RBridge Scope TLV RFC 7455 69 Previous RBridge Nickname TLV RFC 7455 70 Next-Hop RBridge List TLV RFC 7455 71 Multicast Receiver Port Count TLV RFC 7455 72 Flow Identifier TLV RFC 7455 73 Reflector Entropy TLV RFC 7455 74 Authentication TLV RFC 7455
15.3. MAC Addresses
IANA has assigned a unicast and a multicast MAC address under the IANA Organizationally Unique Identifier (OUI) for identification of OAM packets as discussed for the backwards-compatibility method (Appendix A.2) and based on the request template in Appendix C. The assigned addresses are 00-00-5E-90-01-00 (unicast) and 01-00-5E-90-01-00 (multicast).15.4. Return Codes and Sub-codes
IANA has created the "TRILL OAM Return Codes" registry within the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry and a separate sub-code sub-registry for each Return Code as shown below: Registry: TRILL OAM Return Codes Registration Procedure: Standards Action Return Code Assignment References ----------- ---------- ---------- 0 Request message RFC 7455 1 Reply message RFC 7455 2-255 Unassigned RFC 7455 Sub-Registry: Sub-codes for TRILL OAM Return Code 0 Registration Procedure: Standards Action Sub-code Assignment References -------- ---------- ---------- 0 Valid request RFC 7455 1-255 Unassigned RFC 7455 Sub-Registry: Sub-codes for TRILL OAM Return Code 1 Registration Procedure: Standards Action Sub-code Assignment References -------- ---------- ---------- 0 Valid response RFC 7455 1 Fragment limit exceeded RFC 7455 2 Intermediate RBridge RFC 7455 3-255 Unassigned RFC 7455
15.5. TRILL Nickname Address Family
IANA has allocated 16396 as the Address Family Number for TRILL nickname.16. References
16.1. Normative References
[8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q, December 2014. [IS-IS] ISO/IEC, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>. [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
16.2. Informative References
[KARPISIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", Work in Progress, draft-ietf-karp-isis- analysis-04, March 2015. [RFC4379] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>. [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011, <http://www.rfc-editor.org/info/rfc6291>. [RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>. [RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013, <http://www.rfc-editor.org/info/rfc6905>. [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>. [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>. [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>. [RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014, <http://www.rfc-editor.org/info/rfc7179>.
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>. [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", RFC 7456, March 2015, <http://www.rfc-editor.org/info/rfc7456>. [TRILLOAMMIB] Kumar, D., Salam, S., and T. Senevirathne, "TRILL OAM MIB", Work in Progress, draft-deepak-trill-oam-mib-01, October 2013. [Y1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2013.
Appendix A. Backwards Compatibility
The methodology presented in this document is in-line with the framework defined in [8021Q] for providing fault management coverage. However, in practice, some TRILL platforms may not have the capabilities to support some of the required techniques. In this appendix, we present a method that allows RBridges, which do not have the required hardware capabilities, to participate in the TRILL OAM solution. There are two broad areas to be considered: 1) the Maintenance Point (MEP/MIP) Model and 2) data-plane encoding and frame identification.A.1. Maintenance Point (MEP/MIP) Model
For backwards compatibility, MEPs and MIPs are located in the CPU. This will be referred to as the "central brain" model as opposed to "port brain" model. In the "central brain" model, an RBridge using either Access Control Lists (ACLs) or some other method forwards qualifying OAM messages to the CPU. The CPU then performs the required processing and multiplexing to the correct MP (Maintenance Point). Additionally, RBridges MUST have the capability to prevent the leaking of OAM packets, as specified in [RFC6905].A.2. Data-Plane Encoding and Frame Identification
The backwards-compatibility method presented in this section defines methods to identify OAM frames when implementations do not have capabilities to utilize the TRILL OAM Alert flag presented earlier in this document to identify OAM frames in the hardware. It is assumed that ECMP path selection of non-IP flows utilizes MAC DA, MAC SA, and VLAN; IP flows utilize IP DA, IP SA, TCP/UDP port numbers, and other Layer 3 and Layer 4 information. The well-known fields to identify OAM flows are chosen such that they mimic the ECMP selection of the actual data along the path. However, it is important to note that there may be implementations that would utilize these well-known fields for ECMP selections. Hence, implementations that support OAM SHOULD move to utilizing the TRILL Alert flag, as soon as possible, and methods presented here SHOULD be used only as an interim solution.
Identification methods are divided in to four broader groups: 1. Identification of Unicast non-IP OAM Flows, 2. Identification of Multicast non-IP OAM Flows, 3. Identification of Unicast IP OAM Flows, and 4. Identification of Multicast IP OAM Flows. As presented in Figure 24, based on the flow type (as defined above), implementations are required to use a well-known value in either the Inner.MacSA field or OAM Ethertype field to identify OAM flows. A receiving RBridge identifies OAM flows based on the presence of the well-known values in the specified fields. Additionally, for unicast flows, the egress RBridge nickname of the packet MUST match that of the local RBridge, or for multicast flows, the TRILL Header multicast ("M") flag MUST be set. Unicast OAM flows that qualify for local processing MUST be redirected to the OAM process and MUST NOT be forwarded (to prevent leaking of the packet out of the TRILL campus). A copy of multicast OAM flows that qualify for local processing MUST be sent to the OAM process, and the packets MUST be forwarded along the normal path. Additionally, methods MUST be in place to prevent multicast packets from leaking out of the TRILL campus. Figure 24 summarizes the identification of different OAM frames from data frames. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Flow Entropy |Inner.MacSA |OAM Ethertype |Egress | | | | |nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Unicast no IP | N/A |Match |Match | | | | | | |Multicast no IP| N/A |Match |N/A | | | | | | |Unicast IP | Match |N/A |Match | | | | | | |Multicast IP | Match |N/A |N/A | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 24: Identification of TRILL OAM Frames
The unicast and multicast Inner.MacSAs used for the unicast and multicast IP cases, respectively, are 00-00-5E-90-01-00 and 01-00-5E-90-01-00. These have been assigned per the request in Appendix C. It is important to note that all RBridges MUST generate OAM flows with the "A" flag set and CFM Ethertype "0x8902" at the Flow Entropy off-set. However, well-known values MUST be utilized as part of the flow-entropy when generating OAM messages destined for older RBridges that are compliant to the backwards-compatibility method defined in this appendix.Appendix B. Base Mode for TRILL OAM
CFM, as defined in [8021Q], requires configuration of several parameters before the protocol can be used. These parameters include MAID, Maintenance Domain Level (MD-Level), and MEP-IDs. The Base Mode for TRILL OAM defined here facilitates ease of use and provides out-of-the-box plug-and-play capabilities, supporting the operational and manageability considerations described in Section 6 of [RFC7174]. All RBridges that support TRILL OAM MUST support the Base Mode operation. All RBridges MUST create a default MA with MAID as specified herein. MAID [8021Q] has a flexible format and includes two parts: Maintenance Domain Name and Short MA Name. In the Base Mode operation, the value of the Maintenance Domain Name must be the character string "TrillBaseMode" (excluding the quotes). In the Base Mode operation, the Short MA Name format is set to a 2-octet integer format (value 3 in Short MA Format field) and Short MA Name set to 65532 (0xFFFC). The default MA belongs to MD-Level 3. In the Base Mode of operation, each RBridge creates a single UP MEP associated with a virtual OAM port with no physical layer (NULL PHY). The MEP-ID associated with this MEP is the 2-octet RBridge nickname. By default, all RBridges operating in Base Mode for TRILL OAM are able to initiate LBM, PTM, and other OAM tools with no configuration. Implementations MAY provide default flow-entropy to be included in OAM messages. Content of the default flow-entropy is outside the scope of this document.
Figure 25 depicts encoding of MAID within CCM messages. +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Field Name |Size | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Maintenance | 1 | |Domain Format | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Maintenance | 2 | |Domain Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Maintenance | variable| |Domain Name | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Short MA | 1 | |Name Format | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Short MA | 2 | |Name Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Short MA | variable| |Name | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ |Padding | Variable| +-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: MAID Structure as Defined in [8021Q] Maintenance Domain Name Format: set to value 4 Maintenance Domain Name Length: set to value 13 Maintenance Domain Name: set to TrillBaseMode Short MA Name Format: set to value 3 Short MA Name Length: set to value 2 Short MA Name: set to FFFC Padding: set of zero up to 48 octets of total length of the MAID Please refer to [8021Q] for details.
Appendix C. MAC Addresses Request
Applicant Name: IETF TRILL Working Group Applicant Email: tsenevir@cisco.com Applicant Telephone: +1-408-853-2291 Use Name: TRILL OAM Document: RFC 7455 Specify whether this is an application for EUI-48 or EUI-64 identifiers: EUI-48 Size of Block requested: 1 Specify multicast, unicast, or both: Both
Acknowledgments
Work on this document was largely inspired by the directions provided by Stewart Bryant in finding a common OAM solution between SDOs. Acknowledgments are due for many who volunteered to review this document, notably, Jari Arkko, Adrian Farrel, Pete Resnick, Stephen Farrell, Dan Romascanu, Gayle Nobel, and Tal Mizrahi. Special appreciation is due to Dinesh Dutt for his support and encouragement, especially during the initial discussion phase of TRILL OAM.Authors' Addresses
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose, CA 95134 United States Phone: +1 408-853-2291 EMail: tsenevir@cisco.com Norman Finn Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 United States EMail: nfinn@cisco.com Samer Salam Cisco Systems 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada EMail: ssalam@cisco.com
Deepak Kumar Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 United States Phone: +1 408-853-9760 EMail: dekumar@cisco.com Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 United States EMail: aldrin.ietf@gmail.com Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56625375 EMail: liyizhou@huawei.com