RFC 7174

Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework

📅 published May 2014, from ietf

Okay bestie, this is RFC 7174 ✨, and the Request for Comments number is 7174. It's Category: Informational 🎀, with ISSN: 2070-1721, published May 2014 by the Internet Engineering Task Force (IETF). The authors are S. Salam, T. Senevirathne, S. Aldrin, and D. Eastlake 3rd, and the header lists Cisco and Huawei as their affiliations. It doesn't say it obsoletes or updates anything 💅.

Abstract ✨

This doc lays out a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks 🌸. The main focus is on the fault and performance management side of TRILL OAM 💖.

Status of This Memo 📜

Real talk, this is not an Internet Standards Track spec. It's published for informational purposes 🧚.

It's a product of the IETF, so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🙈.

You can find info about the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7174 🔥.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved ✨.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are at http://trustee.ietf.org/license-info and apply on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💀.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. Relationship to Other OAM Work .............................5
   2. TRILL OAM Model .................................................6
      2.1. OAM Layering ...............................................6
           2.1.1. Relationship to CFM .................................7
           2.1.2. Relationship to BFD .................................8
           2.1.3. Relationship to Link OAM ............................8
      2.2. TRILL OAM in the RBridge Port Model ........................8
      2.3. Network, Service, and Flow OAM ............................10
      2.4. Maintenance Domains .......................................10
      2.5. Maintenance Entity and Maintenance Entity Group ...........11
      2.6. MEPs and MIPs .............................................12
      2.7. Maintenance Point Addressing ..............................13
   3. OAM Frame Format ...............................................14
      3.1. Motivation ................................................14
      3.2. Determination of Flow Entropy .............................16
           3.2.1. Address Learning and Flow Entropy ..................16
      3.3. OAM Message Channel .......................................17
      3.4. Identification of OAM Messages ............................17
   4. Fault Management ...............................................18
      4.1. Proactive Fault Management Functions ......................18
           4.1.1. Fault Detection (Continuity Check) .................18
           4.1.2. Defect Indication ..................................19
                  4.1.2.1. Forward Defect Indication .................19
                  4.1.2.2. Reverse Defect Indication (RDI) ...........19
      4.2. On-Demand Fault Management Functions ......................20
           4.2.1. Connectivity Verification ..........................20
                  4.2.1.1. Unicast ...................................20
                  4.2.1.2. Multicast .................................21
           4.2.2. Fault Isolation ....................................21
   5. Performance Monitoring .........................................22
      5.1. Packet Loss ...............................................22
      5.2. Packet Delay ..............................................23
   6. Operational and Manageability Considerations ...................23
      6.1. TRILL OAM Configuration ...................................23
           6.1.1. Maintenance Domain Parameters ......................24
           6.1.2. Maintenance Association Parameters .................24
           6.1.3. Maintenance Endpoint Parameters ....................24
           6.1.4. Continuity Check Parameters (Applicable per MA) ....25
           6.1.5. Connectivity Verification Parameters
                  (Applicable per Operation) .........................25

           6.1.6. Fault Isolation Parameters (Applicable per
                  Operation) .........................................26
           6.1.7. Packet Loss Monitoring .............................27
           6.1.8. Packet Delay Monitoring ............................27
      6.2. TRILL OAM Notifications ...................................28
      6.3. Collecting Performance Monitoring Metrics .................28
   7. Security Considerations ........................................29
   8. Acknowledgments ................................................29
   9. References .....................................................30
      9.1. Normative References ......................................30
      9.2. Informative References ....................................31

1. Introduction ✨

This doc gives a reference framework for Operations, Administration, and Maintenance (OAM) [RFC6291] in Transparent Interconnection of Lots of Links (TRILL) networks 💖.

TRILL [RFC6325] is a protocol for shortest-path frame routing in multi-hop networks with arbitrary topologies and link technologies, and it uses the IS-IS routing protocol 🦋. TRILL-capable devices are called TRILL Switches or RBridges (Routing Bridges) 👑. RBridges give you an optimized, transparent Layer 2 delivery service for Ethernet unicast and multicast traffic 🌈. A few things make TRILL networks different from IEEE 802.1 bridging, and they're giving main character energy:

  • TRILL networks support arbitrary link technology between TRILL Switches. So a TRILL Switch port might not have a 48-bit Media Access Control (MAC) address [802]. Instead it could have, for example, an IP address as its identifier [TRILL-IP], or no unique identifier at all (e.g., PPP [RFC6361]) 🧚.
  • TRILL networks do not enforce congruence of unicast and multicast paths between a given pair of RBridges 🙈.
  • TRILL networks do not impose symmetry of the forward and reverse paths between a given pair of RBridges 🔥.
  • TRILL Switches terminate spanning tree protocols instead of propagating them 💅.

In this document, we use the term "OAM" as defined in [RFC6291] 🎀. The Operations aspect is about finding problems that stop the network from working properly. It also includes monitoring the network so you can spot potential problems before they happen 👀. Administration means keeping track of network resources 📋. Maintenance is about facilitating repairs and upgrades, plus corrective and preventive measures 🛠️. [ISO/IEC7498-4] defines 5 functional areas in the OSI model for network management, which people usually call FCAPS 🌸:

  • Fault Management
  • Configuration Management
  • Accounting Management
  • Performance Management
  • Security Management

This doc focuses on the first and fourth areas, Fault Management and Performance Management, in TRILL networks 💜. Those mostly map to the Operations and Maintenance parts of OAM ✨.

This document provides a generic framework for a comprehensive solution that meets the requirements outlined in [RFC6905]. However, specific mechanisms to address those requirements are outside the scope of this document 🙃. Also, future document(s) will specify the optional reporting of errors in TRILL user traffic, like using a reserved or unknown egress nickname, etc. 🔮

1.1. Terminology 📖

Definitions of lots of OAM terms can be found in [RFC7087] 🧠.

The following acronyms are used in this document 💅:

      BFD - Bidirectional Forwarding Detection [RFC5880]

      CFM - Connectivity Fault Management [802.1Q]

      ECMP - Equal-Cost Multipath

      FGL  - Fine-Grained Label(ing) [RFC7172]

      IEEE - Institute for Electrical and Electronic Engineers

      IP - Internet Protocol (includes both IPv4 and IPv6)

      LAN - Local Area Network

      MA - Maintenance Association
      MAC - Media Access Control [802]

      ME  - Maintenance Entity

      MEP - Maintenance End Point

      MIP - Maintenance Intermediate Point

      MP  - Maintenance Point (MEP or MIP)

      OAM - Operations, Administration, and Maintenance [RFC6291]

      PPP - Point-to-Point Protocol [RFC1661]

      RBridge - Routing Bridge, a device implementing TRILL [RFC6325]

      RDI - Reverse Defect Indication

      TRILL - Transparent Interconnection of Lots of Links [RFC6325]

      TRILL Switch - an alternate name for an RBridge

      VLAN - Virtual LAN [802.1Q]

1.2. Relationship to Other OAM Work 🤝

OAM is a technology area with a whole lot of prior art 🏆. This doc borrows concepts and pulls elements that are defined and/or used in the following documents, so let's tag them:

  • [RFC6905] defines the requirements for TRILL OAM that serve as the basis for this framework 🎯. It also defines terminology that gets used all over this document 📚.
  • [802.1Q] specifies the Connectivity Fault Management (CFM) protocol 🔗. It defines the concepts of Maintenance Domains, Maintenance End Points, and Maintenance Intermediate Points 🧩.
  • [Y.1731] extends Connectivity Fault Management in some areas 💫. It defines fault notification and alarm suppression functions for Ethernet 🚨. It also specifies mechanisms for Ethernet performance management, including loss, delay, jitter, and throughput measurement 📈.
  • [RFC7175] defines a TRILL encapsulation for BFD, which enables using BFD for network fast failure detection ⚡.
  • [RFC5860] and [RFC6371] specify requirements and a framework for OAM in MPLS-based networks 🌐.

2. TRILL OAM Model 🦋

2.1. OAM Layering

okay bestie, so the TRILL layer doesn't care what link tech is underneath it 🫶 It can run over any transport that can carry TRILL packets, like Ethernet [RFC6325], PPP [RFC6361], or IP [TRILL-IP]. And TRILL gives you a virtual Ethernet connectivity service that's totally transparent to anything at Layer 3 and up 💅 TRILL OAM keeps that strict layering too, no cap 🔒

Here are the big ones TRILL OAM needs to be layered with:

  • BFD, which is typically used for fast failure detection ⚡
  • Ethernet CFM [802.1Q] on paths from an external device, over a TRILL campus, to another external device, especially since TRILL Switches are likely to be deployed where existing 802.1 bridges can be such external devices 🌸
  • Link OAM, on links interior to a TRILL campus, which is link-technology-specific 🔧

Check out this example network in Figure 1, where a TRILL network is hooked up via Ethernet links 👀

                   LAN                LAN
   +---+   +---+  ======  +---+  =============  +---+
+--+   |   |   |   | | +--+ | |   | | +--+   +--+ | |   |   +--+
|B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5|
+--+   |   |   |   | | +--+ | |   | | +--+   +--+ | |   |   +--+
   +---+   +---+  ======  +---+  =============  +---+

a. Ethernet CFM (Client Layer) on path over the TRILL campus
   >---o------------------------------------------------o---<


b. TRILL OAM (Network Layer)
           >------o-----------o---------------------<


c. Ethernet CFM (Transport Layer) on interior Ethernet LANs
                  >---o--o---<    >---o--o---o--o---<


d. BFD (Media Independent Link Layer)
           #---#   #----------#   #-----------------#


e. Link OAM (Media Dependent Link Layer)
   *---*   *---*   *---*  *---*   *---*  *---*  *---*   *---*


Legend:  >, < MEP    o MIP    # BFD Endpoint    * Link OAM Endpoint

                 Figure 1: OAM Layering in TRILL

Where Bn and RBn (n= 1,2,3, ...) denote IEEE 802.1Q bridges and TRILL RBridges, respectively. Yep, B is the bridge and RB is the RBridge, easy peasy 🦋

2.1.1. Relationship to CFM

okay so CFM can show up in TRILL land as either a client-layer OAM or a transport-layer OAM mechanism 💖

When it's acting as a client-layer OAM (see Figure 1a), CFM gives the user fault management on an end-to-end basis over the TRILL network 🎀 The edge ports of the TRILL network can be visible to CFM operations if there's an optional CFM Maintenance Intermediate Point (MIP) in the TRILL Switches' edge Ethernet ports ✨

When it's acting as a transport-layer OAM (see Figure 1c), CFM handles fault management for the IEEE 802.1Q bridged LANs that might interconnect RBridges. Those bridged LANs can be used as TRILL level links between RBridges, which is lowkey iconic 🌈 RBridges directly connected to the intervening 802.1Q bridges may host CFM Down Maintenance End Points (MEPs) 💜

2.1.2. Relationship to BFD

One-hop BFD (see Figure 1d) runs between adjacent RBridges and gives you fast link as well as node failure detection capability [RFC7175] ⚡ Note that TRILL BFD also does some testing of the TRILL protocol stack, so it sits a layer above Link OAM, which is media specific 🧚 BFD's fast failure detection helps support rapid convergence in TRILL networks, which is so important 🫶 The requirements for BFD are different from those of the TRILL OAM mechanisms that are the prime focus of this document. Also, BFD does not use the frame format described in Section 3.1 🙈

TRILL BFD is different from TRILL OAM in two significant ways 👑

  1. A TRILL BFD transmitter is always bound to a specific TRILL output port.
  2. TRILL BFD messages can be transmitted by the originator out of a port to a neighbor RBridge when the adjacency is in the Detect or 2-Way states as well as when the adjacency is in the Report (Up) state [RFC7177].

TRILL OAM messages, on the other hand, are typically transmitted by appearing to have been received on a TRILL input port (refer to Section 2.2 for details) 🦋 In that case, the output ports where TRILL OAM messages go out are determined by the TRILL routing function. The TRILL routing function will only send on links that are in the Report state and have been incorporated into the local view of the campus topology. Main character energy for the routing function, honestly 💅

Link OAM (see Figure 1e) depends on the technology used in the links interconnecting RBridges 🔧 For example, for Ethernet links, the OAM described in Clause 57 of [802.3] may be used 🌸

2.2. TRILL OAM in the RBridge Port Model

TRILL OAM processing can be represented as a layer sitting between the port's TRILL encapsulation/decapsulation function and the TRILL forwarding engine function on any RBridge port 🎀 TRILL OAM needs the services of the RBridge forwarding engine and uses information from the IS-IS control plane 🧠 Figure 2 below shows TRILL OAM processing in the context of the RBridge Port Model defined in [RFC6325]. In this figure, double lines represent flow of both frames and information 💜

This figure is a conceptual model. Implementations don't need to mirror this exact model, as long as the intended OAM requirements and functionality are preserved ✨

        +-----------------------------------------------+----
        |            (Flow of OAM Messages)       RBridge
        |         +----------------------+
        |         |+-------------------+||  Forwarding Engine,
        |         ||                    ||  IS-IS, etc.
        |         ||                    ||  Processing of
        |         V                      V  TRILL packets
        +---------------------------------------------+-----
                  ||                     ||          ...other ports
            +------------+             +------------+
UP MEP   /\ | TRILL OAM  |             | TRILL OAM  | /\ UP MEP
MIP      () |   Layer    |             |   Layer    | () MIP
DOWN MEP \/ +------------+             +------------+ \/ DOWN MEP
            |   TRILL    |             |   TRILL    |
            | Encap/Decap|             | Encap/Decap|
            +------------+             +------------+
            |End-Station |             |End-Station |
            |VLAN &      |             |VLAN &      |
            |Priority    |             |Priority    |
            |Processing  |             |Processing  |
            +------------+             +------------+ <-- ISS
            |802.1/802.3 |             |802.1/802.3 |
            |Low-Level   |             |Low-Level   |
            |Control     |             |Control     |
            |Frame       |             |Frame       |
            |Processing, |             |Processing, |
            |Port/Link   |             |Port/Link   |
            |Control     |             |Control     |
            |Logic       |             |Logic       |
            +------------+             +------------+
            | 802.3PHY   |             | 802.3PHY   |
            |(Physical   |             |(Physical   |
            | interface) |             | interface) |
            +------------+             +------------+
              ||                         ||
             Link                       Link

            Figure 2: TRILL OAM in RBridge Port Model

Quick heads up: the terms "MEP" and "MIP" in the above figure get explained in detail in Section 2.6 below 👀

2.3. Network, Service, and Flow OAM

OAM functions in a TRILL network can happen at different granularities 🔍 That gives us 'Network', 'Service', and 'Flow' OAM, listed from coarsest to finest granularity 🌈

Network OAM gives fault and performance management in the context of a 'test' VLAN or fine-grained label [RFC7172] 🧪 The test VLAN can be thought of as a management or diagnostics VLAN that extends to all RBridges in a TRILL network 💖 To account for multipathing, Network OAM functions also use test flows (both unicast and multicast) to cover the various paths in the network 🦋

Service OAM gives fault and performance management in the context of the actual VLAN or fine-grained label set for which end-station service is enabled 🎀 Test flows are used here too, to provide coverage in the case of multipathing ✨

Flow OAM gives the most fine-grained fault and performance management capabilities, where OAM functions run in the context of end-station flows within VLANs or fine-grained labels 💅 While Flow OAM gives the most granular control, it clearly poses scalability challenges if attempted on large numbers of flows 💀

2.4. Maintenance Domains 🌸

Okay bestie, so Maintenance Domains (or OAM Domains, same thing) are super well known in the industry 💅. IEEE [802.1Q] describes a Maintenance Domain as a collection of devices (like network elements) that get grouped together for administrative and/or management purposes 🎀. They usually mark out trust relationships, different addressing schemes, what the network gear can do, and stuff like that ✨.

Now for TRILL 🦋. Here, a Maintenance Domain is a bunch of RBridges in a network where connectivity faults and performance degradation are managed by one single operator 👑. Every RBridge in a given Maintenance Domain is, by definition, managed by one entity (like an enterprise or a data center operator, etc.) 🫶. [RFC6325] defines TRILL running in a single IS-IS area, assuming a single operator manages the network 💜. So in that setup, one (default) Maintenance Domain is enough for TRILL OAM 💖.

But when different TRILL networks need to be interconnected, like in [TRILL-ML], that's where multiple Maintenance Domains (and Maintenance Domain hierarchies) become super useful for mapping and enforcing administrative boundaries 🧚. Here's the big rule set for multi-domain scenarios 🔥:

TRILL OAM Domains MUST NOT partially intersect, but they MUST either be disjoint or nest to form a hierarchy (that is, a higher Maintenance Domain MAY completely enclose a lower domain). Nesting is not optional vibes, bestie, so pay attention 💀.

A Maintenance Domain is typically identified by a Domain Name and a Maintenance Level (a numeric identifier) 🌈. If two domains are nested, the encompassing domain MUST be assigned a higher Maintenance Level number than the enclosed domain. That's why the encompassing domain is commonly called the 'higher' domain, and the enclosed one is called the 'lower' domain 🍓. OAM functions in the lower domain are completely transparent to the higher domain ✨. Meanwhile, OAM functions in the higher domain only see the boundary of the lower domain. For example, if you trace the path in the higher domain, the entire lower domain shows up as a single hop between the RBridges on that lower domain's boundary 🦋. By the same token, OAM functions in the higher domain are transparent to RBridges that sit inside the lower domain 🙈. The nesting is set up through operator configuration of the RBridges 🎀.

  +-------------------+  +---------------+  +-------------------+
  |                   |  |     TRILL     |  |                   |
  |       Site 1     +----+Interconnect +----+    Site 2        |
  |       TRILL      | RB |  Network    | RB |    TRILL         |
  |      (Level 1)   +----+  (Level 2)  +----+   (Level 1)      |
  |                   |  |               |  |                   |
  +-------------------+  +---------------+  +-------------------+

  <------------------------End-to-End Domain-------------------->

  <----Site Domain----> <--Interconnect --> <----Site Domain---->
                             Domain

                 Figure 3: TRILL OAM Maintenance Domains

2.5. Maintenance Entity and Maintenance Entity Group 🧸

Okay so TRILL OAM functions happen in the context of logical endpoint pairs called Maintenance Entities (ME) 💜. A Maintenance Entity is a relationship between two points in a TRILL network where OAM functions (like monitoring operations) get applied ✨. Those two points are called Maintenance End Points (MEPs) (more on those in Section 2.6 below) 🦋. The set of Maintenance End Points that belong to the same Maintenance Domain is called a Maintenance Association (MA) 🫶. Out on the network path between MEPs, there can be zero or more intermediate points, called Maintenance Intermediate Points (MIPs) 🌸. And MEPs can be part of more than one ME in a given MA, which is lowkey iconic 👑.

2.6. MEPs and MIPs 🎀

OAM capabilities on RBridges can be described as logical groupings of functions, which sort into two functional objects: Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs) 🧚. Together, they're called Maintenance Points (MPs) 💖.

MEPs are the active components of TRILL OAM 🔥. They source TRILL OAM messages periodically or on-demand, based on operator configuration actions 💅. MEPs also make sure TRILL OAM messages don't leak outside a given Maintenance Domain (like out of the TRILL network and into end stations) 🙈. MIPs, on the other hand, are internal to a Maintenance Domain. They're the more passive components of TRILL OAM, mainly in charge of forwarding TRILL OAM messages and selectively responding to a subset of them 🌈.

The following figure shows the MEP and MIP placement for the Maintenance Domains from Figure 3 above 🍓.

     TRILL Site 1          Interconnect       TRILL Site 2
  +-----------------+ +------------------+ +-----------------+
  |                 | |                  | |                 |
  |  +---+  +---+  +---+  +---+  +---+  +---+  +---+  +---+  |
  |  |RB1|--|RB2|--|RB3|--|RB4|--|RB5|--|RB6|--|RB7|--|RB8|  |
  |  +---+  +---+  +---+  +---+  +---+  +---+  +---+  +---+  |
  |                 | |                  | |                 |
  +-----------------+ +------------------+ +-----------------+

      <E------------I--------------------I-------------E>

      <E------I----E><E----I-------I----E><E-----I-----E>

   Legend E: MEP      I: MIP

                        Figure 4: MEPs and MIPs

A single RBridge MAY host multiple MEPs of different technologies, like TRILL OAM MEP(s) and [802.1Q] MEP(s) ✨. That doesn't mean the protocol operation is necessarily squished into one single functional entity on those ports 🦋. Each MEP's protocol functions stay independent and live in different shims in the RBridge Port Model of Figure 2. The TRILL OAM MEP lives in the "TRILL OAM Layer" block, while a CFM MEP lives in the "End-Station VLAN & Priority Processing" block 💜.

In the model from Section 2.2, a single MEP and/or MIP per MA can be instantiated per RBridge port 🎀. A MEP also gets an administratively set direction, either UP or DOWN, and it works like this 👑:

  • An UP MEP sends and receives OAM messages through the RBridge forwarding engine. This means an UP MEP effectively talks to MEPs on other RBridges through TRILL interfaces other than the one it's configured on 🌸.
  • A DOWN MEP sends and receives OAM messages through the link connected to the interface it's configured on 🧚.

Now for the virtual port vibes 🌈. To support TRILL OAM functions on sections (as described in [RFC6905]) while keeping the simplicity of a single TRILL OAM Maintenance Domain, the TRILL OAM layer MAY be implemented on a virtual port with no physical layer (Null PHY) 🫶. In that case, the Down MEP function isn't supported, because the virtual port doesn't attach to a link. So a Down MEP on a virtual port wouldn't be capable of sending or receiving OAM messages 😭.

A TRILL OAM solution that conforms to this framework 💖:

  • MUST support the MIP function on TRILL ports (to support Fault Isolation).
  • MUST support the UP MEP function on a TRILL virtual port (to support OAM functions on sections, as defined in [RFC6905]).
  • MAY support the UP MEP function on TRILL ports.
  • MAY support the DOWN MEP function on TRILL ports.

2.7. Maintenance Point Addressing 🦋

TRILL OAM functions MUST provide the capability to address a specific Maintenance Point, or a set of one or more Maintenance Points, in an MA 🎀. To do that, RBridges need to recognize two sets of addresses 👑:

  • Individual MP addresses
  • Group MP addresses

TRILL OAM will support the Shared MP address model, where all MPs on an RBridge share the same Individual MP address ✨. In other words, TRILL OAM messages can be addressed to a specific RBridge, but not to a specific port on an RBridge 💅.

Here's the tea 🍵: you can't tell, just by watching an RBridge from the outside, whether TRILL OAM messages are actually delivered to a certain MP or to some other entity inside the RBridge 🙈. The Shared MP address model takes advantage of this by letting MPs on different RBridge ports share the same Individual MP address 💜. The MPs may still be implemented as residing on different RBridge ports, and for the most part they have distinct identities 🌸.

The Group MP addresses let the OAM mechanism reach all the MPs in a given MA 🌈. Certain OAM functions, like pruned tree verification, need to address a subset of the MPs in an MA 🧚. Group MP addresses aren't defined for those subsets, though. Instead, the OAM function in question MUST use the Group MP addresses combined with an indication of the scope of the MP subset, encoded in the OAM Message Channel 🫶. That way you don't get an unwieldy pile of responses to Group MP addresses 🍓.

3. OAM Frame Format ✨

3.1. Motivation 💖

okay so the whole point of TRILL OAM is testing the actual data path 🔍, which means the OAM messages have to be transparent to transit RBridges. a TRILL OAM message must be indistinguishable from a TRILL Data packet going through normal transit RBridge processing 🦋. only the target RBridge (the one that actually needs to handle the message) should spot it and trap it as a control message. methods must also be provided to stop OAM packets from getting sent out as native frames 🚫.

the TRILL OAM packet format below gives you the flexibility to test the data path as closely as possible to real data packets ✨, and it's giving precision 💅.

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        .      Link Header              . Variable
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Initial 6-byte fixed part of  |
        +      TRILL Header             + 6 bytes
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    TRILL Header Extensions    |
        .         (if any)              .  Variable
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
        |         DA   /   SA           |  \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   \
        |          Data Label           |    | Flow Entropy
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +  Fixed Size
        .                               .    |
        .                               .   /
        |                               |  /
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
        |       OAM Ethertype           | 2 bytes
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        .   OAM Message Channel         . Variable
        .                               .
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        .    Link Trailer               . Variable
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: OAM Frame Format

the TRILL Header plus the Link Header and Trailer need to be as similar as practical to the TRILL Header and the Link Header and Trailer of the normal TRILL Data packet that corresponds to the traffic OAM is testing 🎀.

the OAM Ethertype marks the boundary between the Flow Entropy field and the OAM Message Channel 🧚. it's expected at a deterministic offset from the TRILL Header, which lets applications clearly find where the OAM Message Channel starts. bonus: it also makes it easier for the same OAM frame structure to be used by different Ethernet technologies 🌈.

the Link Trailer is usually a checksum, like the Ethernet Frame Check Sequence 🧮. it gets checked super low-level, really early in the frame input process, and gets generated automatically during low-level frame output. if the checksum fails, the frame is normally discarded with no higher-level processing 💀.

3.2. Determination of Flow Entropy 🌸

the Flow Entropy field is fixed-length and gets filled with either real packet data or synthetic data that copies the intended flow 🪞. it always starts with a destination and source MAC address area, followed by a Data Label area (either a VLAN or a fine-grained label) 🏷️.

for a Layer 2 flow (aka non-IP), the Flow Entropy field must specify the desired Ethernet header, including the MAC destination and source addresses as well as a VLAN tag or fine-grained label 💜.

for a Layer 3 flow, the Flow Entropy field must specify the desired Ethernet header, the IP header, and UDP or TCP header fields. the Ethernet-layer header fields are still there too 🫶.

not every field in the Flow Entropy field has to match the data flow that the OAM message is mimicking 🙈. the only real requirement is that the selected flow entropy follows the same path as the data flow it's copying. so the selected flow entropy must result in the same ECMP selection or multicast pruning behavior, or whatever other forwarding paradigm applies 🔥.

when you're diagnosing user flows, the OAM mechanisms must let the network operator configure the flow entropy parameters (for example, Layer 2 and/or 3) on the RBridge where the diagnostic operations get triggered. main character energy for the operator 👑.

when you're running OAM functions over test flows, TRILL OAM may provide a mechanism that discovers the flow entropy parameters by querying the RBridges dynamically. or it may let the network operator configure the flow entropy parameters instead 🦋.

3.2.1. Address Learning and Flow Entropy 🧠

Edge TRILL Switches, like traditional 802.1 bridges, are required to learn MAC address associations 📚. learning happens by snooping data packets or through other methods. the thing is, the Flow Entropy field of TRILL OAM messages mimics real packets, so it can mess with the address-learning process of the TRILL data plane 😭.

so TRILL OAM is required to provide methods that stop any learning of addresses from the Flow Entropy field of OAM messages that would interfere with normal TRILL operation 🛡️. one way to do that, for example, is suppressing or preventing MAC address learning from OAM messages 🚫.

3.3. OAM Message Channel 📡

the OAM Message Channel provides methods to communicate OAM-specific details between RBridges 💬. CFM [802.1Q] and [RFC4379] have already implemented OAM message channels. it's smart to pick an appropriate technology and reuse it, instead of redesigning yet another OAM channel ♻️.

TRILL is a transport layer that carries Ethernet frames, so the TRILL OAM model specified earlier is based on the CFM [802.1Q] model 🧩. using the CFM [802.1Q] encoding format for the OAM Message Channel is one possible choice. [TRILL-OAM] presents a proposal for using the CFM [802.1Q] payload as the OAM Message Channel 🍓.

3.4. Identification of OAM Messages 🔎

RBridges must be able to identify OAM messages destined for them, either individually or as a group, so they can process those messages properly 🎯.

TRILL, as defined in [RFC6325], doesn't specify a method to identify OAM messages 🤷‍♀️. the most reliable way to do it, without putting restrictions on the Flow Entropy field, is to modify the definition of the TRILL Header to include an "Alert" flag. this flag signals that the content of the TRILL packet is a control message rather than user data 🚨. the flag wouldn't be limited to TRILL OAM either. any other TRILL control protocol that needs in-band behavior could use it too 💖.

the TRILL Header currently has two reserved bits that aren't being used, and one of those bits may be used as the Alert flag ✨. to guarantee accurate in-band forwarding behavior, RBridges must not use the Alert flag in ECMP hashing decisions 🚫. also, to keep this flag protocol agnostic, TRILL OAM mechanisms must not rely solely on the Alert flag to identify OAM messages. instead, these solutions must identify OAM messages based on the combination of the Alert flag and the OAM Ethertype 🫶.

since the above mechanism requires modifying the TRILL Header, it is not backward compatible 😬. TRILL OAM solutions should provide alternate methods to identify OAM messages that work on existing RBridge implementations, so backward compatibility is kept 🌈.

4. Fault Management ✨

Section 4.1 below discusses proactive fault management, and Section 4.2 discusses on-demand fault management 🦋.

4.1. Proactive Fault Management Functions 🔁

proactive fault management functions are configured by the network operator to run periodically with no time bound, or they're configured to trigger certain actions when specific events happen ⏰.

4.1.1. Fault Detection (Continuity Check) 💓

proactive fault detection works by periodically monitoring reachability between service endpoints (aka MEPs in a given MA) through the exchange of Continuity Check messages 💌. the reachability between any two arbitrary MEPs can be monitored for a specified path, all paths, or any representative path 🛤️.

here's the tea ☕: TRILL networks don't enforce congruence between unicast and multicast paths. so the proactive fault detection mechanism must provide procedures to monitor the unicast paths independently of the multicast paths 👯. and where the network has ECMP, the mechanism must be capable of exercising the equal-cost paths individually 🔬.

the set of MEPs exchanging Continuity Check messages in a given domain, for a specific monitored entity (flow, network, or service), must use the same transmission period ⏱️. as long as the fault detection mechanism has MEPs transmitting periodic heartbeat messages independently, this OAM procedure isn't affected by the lack of forward/reverse path symmetry in TRILL 💗.

the proactive fault detection function must detect the following types of defects 🚨:

  • Loss of continuity to one or more remote MEPs 💔
  • Unexpected connectivity between isolated VLANs or fine-grained labels (mismerge) 🙀
  • Unexpected connectivity to one or more remote MEPs 👀
  • Mismatch of the Continuity Check transmission period between MEPs ⏳

4.1.2. Defect Indication 📢

TRILL OAM must support event-driven defect indication when a connectivity defect is detected 🫨. defect indications fall into two types, which the following subsections cover 🍰.

4.1.2.1. Forward Defect Indication ➡️

forward defect indication is used to signal a failure that a lower-layer OAM mechanism detected 🧨. a forward defect indication gets transmitted away from the direction of the failure 🏃‍♀️.

for example, picture a simple network of four RBridges connected in series: RB1, RB2, RB3, and RB4 🧚‍♀️. both RB1 and RB4 host TRILL OAM MEPs, while RB2 and RB3 have MIPs. if the link between RB2 and RB3 fails, RB2 can send a forward defect indication towards RB1, and RB3 sends a forward defect indication towards RB4 🎀.

forward defect indication may be used for alarm suppression, and/or for interworking with other layer OAM protocols 🤝. alarm suppression is super useful when a transport or network-level fault turns into multiple service- or flow-level faults 🙌. in that situation, it's enough to alert a network management station (NMS) about the single transport/network-level fault, instead of flooding the NMS with a pile of Service or Flow granularity alarms 🥹💅.

4.1.2.2. Reverse Defect Indication (RDI) 🔥

okay so RDI is how the advertising MEP says "hey, I've detected a loss-of-continuity defect" 💅 It goes in the direction of the failure, which is kind of the whole point 🦋 Picture the same series network from Section 4.1.2.1 (same squad, bestie 🧚). If RB1 notices it has lost connectivity to RB4 because it's no longer getting Continuity Check messages from the MEP on RB4 😭, then RB1 can send an RDI toward RB4 so RB4 knows something's up. And if the failure is unidirectional (it's hitting the path from RB4 to RB1), the RDI lets RB4 realize there's a unidirectional connectivity anomaly 🙈

In the presence of equal-cost paths between MEPs, RDI must be able to identify on which equal-cost path the failure was detected. Like, RDI has to be able to figure out which equal-cost path the failure happened on 🗺️✨

RDI also gives you single-sided management 🎀 The network operator can check the state of just one MEP and figure out the overall health of a monitored entity (network, flow, or service). Main character energy, honestly 👑

4.2. On-Demand Fault Management Functions

okay so on-demand fault management functions are the ones the network operator starts manually 🫶 They can be a one-time thing, or an action/test that keeps going for a time-bound period ⏰ These are basically the diagnostic toolkit for digging into a defect condition 🔍

4.2.1. Connectivity Verification

As specified in [RFC6905], TRILL OAM must support on-demand Connectivity Verification for unicast and multicast. The Connectivity-Verification mechanism must provide a means for specifying and carrying the following in the messages:

  • variable-length payload/padding to test MTU-related connectivity problems.
  • test message formats as defined in [RFC2544].

4.2.1.1. Unicast

A unicast Connectivity Verification operation must be initiated from a MEP and may target either a MIP or another MEP. For unicast, Connectivity Verification can be performed at either Network or Flow granularity 💖

Connectivity verification at the Network granularity tests connectivity between a MEP on a source RBridge and a MIP or MEP on a target RBridge over a test flow in a test VLAN or fine-grained label. The operator must supply the source and target RBridges for the operation, and the test VLAN/flow information uses pre-set values or defaults 🍓

Connectivity Verification at the Flow granularity tests connectivity between a MEP on a source RBridge and a MIP or MEP on a target RBridge over an operator-specified VLAN or fine-grained label with operator-specified flow parameters ✨

The above functions must be supported on sections, as defined in [RFC6905]. When Connectivity Verification is triggered over a section, and the initiating MEP does not coincide with the edge (ingress) RBridge, the MEP must use the edge RBridge nickname instead of the local RBridge nickname on the associated Connectivity Verification messages. The operator must supply the edge RBridge nickname as part of the operation parameters 🦋

4.2.1.2. Multicast

For multicast, the Connectivity Verification function tests all branches and leaf nodes of a multi-destination distribution tree for reachability. This function should include mechanisms to prevent reply storms from overwhelming the initiating RBridge 😭 This may be done, for example, by staggering the replies through the introduction of a random delay timer, with a preset upper bound, on the responding RBridge (CFM [802.1Q] uses similar mechanisms for Linktrace Reply messages to mitigate the load on the originating MEP). The upper bound on the timer value should be selected by the OAM solution to be long enough to accommodate large distribution trees, while allowing the Connectivity Verification operation to conclude within a reasonable time ⏰

To further prevent reply storms, the Connectivity Verification operation is initiated from a MEP and must target MEPs only. MIPs are transparent to multicast Connectivity Verification 🙈

Per [RFC6905], multicast Connectivity Verification must provide the following granularity of operation:

A. Un-pruned Tree

  • Connectivity Verification for un-pruned multi-destination distribution tree. The operator in this case supplies the tree identifier (root nickname) and campus-wide diagnostic VLAN or fine-grained label.

B. Pruned Tree

  • Connectivity Verification for a VLAN or fine-grain label in a given multi-destination distribution tree. The operator in this case supplies the tree identifier and VLAN or fine-grained label.
  • Connectivity Verification for an IP multicast group in a given multi-destination distribution tree. The operator in this case supplies the tree identifier, VLAN or fine-grained label, and IP (S,G) or (*,G) 🌈

4.2.2. Fault Isolation

TRILL OAM must support an on-demand connectivity fault localization function. This is the capability to trace the path of a flow on a hop-by-hop (RBridge-by-RBridge) basis to isolate failures 🔍 It involves narrowing down the locality of a fault to a particular port, link, or node.

The characteristic of forward/reverse path asymmetry, in TRILL, makes Fault Isolation a direction-sensitive operation 💀 That means that given two RBridges, A and B, localizing connectivity faults between them requires running Fault Isolation procedures from RBridge A to RBridge B as well as from RBridge B to RBridge A. Generally speaking, single-sided Fault Isolation is not possible in TRILL OAM 🙅‍♀️

Furthermore, TRILL OAM should support Fault Isolation over distribution trees for both un-pruned as well as pruned trees. The former allows the tracing of all active branches of a tree, whereas the latter allows tracing of the active subset of branches associated with a given flow 🌸

5. Performance Monitoring ✨

Performance monitoring functions are optional in TRILL OAM, per [RFC6905]. These functions can be performed both proactively and on-demand. Proactive management involves a scheduling function, where the performance monitoring probes can be triggered on a recurring basis. Since the basic performance monitoring functions involved are the same, we make no distinction between proactive and on-demand functions in this section 💅

5.1. Packet Loss

Given that TRILL provides inherent support for multipoint-to-multipoint connectivity, packet loss cannot be accurately measured by means of counting user data packets 😭 That's because user packets can be delivered to more RBridges or more ports than are necessary (for example, due to broadcast, un-pruned multicast, or unknown unicast flooding). So a statistical means of approximating packet loss rate is required 📊 This can be achieved by sending "synthetic" (TRILL OAM) packets that are counted only by those ports (MEPs) that are required to receive them. This gives a statistical approximation of the number of data frames lost, even with multipoint-to-multipoint connectivity 🧚 TRILL OAM mechanisms for synthetic packet loss measurement should follow the statistical considerations specified in [MEF35], especially with regard to the volume/frequency of synthetic traffic generation and associated impact on packet loss count accuracy.

Packet loss probes must be initiated from a MEP and must target a MEP. This function should be supported on sections, as defined in [RFC6905]. When packet loss is measured over a section, and the initiating MEP does not coincide with the edge (ingress) RBridge, the MEP must use the edge RBridge nickname instead of the local RBridge nickname on the associated loss measurement messages. The user must supply the edge RBridge nickname as part of the operation parameters 🎀

TRILL OAM mechanisms should support one-way and two-way Packet Loss Monitoring. In one-way monitoring, a source RBridge triggers Packet Loss Monitoring messages to a target RBridge, and the latter is responsible for calculating the loss in the direction from the source RBridge towards the target RBridge. In two-way monitoring, a source RBridge triggers Packet Loss Monitoring messages to a target RBridge, and the latter replies to the source with response messages. The source RBridge can then monitor packet loss in both directions (source to target and target to source) 🫶

5.2. Packet Delay

Packet delay is measured by inserting timestamps in TRILL OAM packets ⏱️ For high accuracy of measurement, TRILL OAM must specify the timestamp location at fixed offsets within the OAM packet, so that hardware-based timestamping is possible. Hardware implementations must implement the timestamping function as close to the wire as practical in order to maintain high accuracy 🔥

TRILL OAM mechanisms should support one-way and two-way Packet Delay Monitoring. In one-way monitoring, a source RBridge triggers Packet Delay Monitoring messages to a target RBridge, and the latter is responsible for calculating the delay in the direction from the source RBridge towards the target RBridge. This requires synchronization of the clocks between the two RBridges. In two-way monitoring, a source RBridge triggers Packet Delay Monitoring messages to a target RBridge, and the latter replies to the source with response messages. The source RBridge can then monitor packet delay in both directions (source to target and target to source) as well as the cumulative round-trip delay. In this case as well, monitoring the delay in a single direction requires clock synchronization between the two RBridges, whereas monitoring the round-trip delay does not require clock synchronization 🌈 Mechanisms for clock synchronization between RBridges are outside the scope of this document.

6. Operational and Manageability Considerations 🎀

6.1. TRILL OAM Configuration

RBridges may be configured to enable TRILL OAM functions via the device Command Line Interface (CLI) or through one of the defined management protocols, such as the Simple Network Management Protocol (SNMP) [RFC3410] or the Network Configuration Protocol (NETCONF) [RFC6241] 💻

In order to maintain the plug-and-play characteristics of TRILL, the number of parameters that need to be configured on RBridges, in order to activate TRILL OAM, should be kept to a minimum. To that end, TRILL OAM mechanisms should rely on default values and auto-discovery mechanisms (for example, leveraging IS-IS) where applicable 🧚 The following is a non-exhaustive list of configuration parameters that apply to TRILL OAM.

6.1.1. Maintenance Domain Parameters

  • Maintenance Domain Name: An alphanumeric name for the Maintenance Domain. This is an IETF [RFC2579] DisplayString, with the exception that character codes 0-31 (decimal) are not used. The recommended default value is the character string "DEFAULT" 🍓
  • Maintenance Domain Level: An integer in the range 0 to 7 indicating the level at which the Maintenance Domain is to be created. Default value is 0 💖

6.1.2. Maintenance Association Parameters 🎀

  • MA Name: okay so this is the alphanumeric name that uniquely identifies the Maintenance Association 💅. It's an IETF [RFC2579] DisplayString, with the exception that character codes 0-31 (decimal) are not used 🙅. The recommended default value is a character string set to the value of the VLAN or fine-grained label as "vl" or "fgl" concatenated with the VLAN ID or FGL ID as an unsigned decimal integer, for example, "vl42" ✨
  • List of MEP Identifiers: this is the list of the identifiers of the MEPs that belong to the MA 🫶. It's optional, and only required if the operator wants to detect missing MEPs as part of the Continuity Check function 🔍.

6.1.3. Maintenance Endpoint Parameters 🧚

  • MEP Identifier: an integer that's unique over a given Maintenance Association and identifies a specific MEP 🪪. CFM [802.1Q] limits this to the range 1 to 8191. This document recommends expanding the range from 1 to 65535 so that the RBridge nickname can be used as a default value 🍓. This will help keep TRILL OAM low-touch in terms of configuration overhead 🌸.
  • Direction: indicates whether this is an UP MEP or DOWN MEP ⬆️.
  • Associated Interface: specifies the interface on which the MEP is configured 🔌.
  • MA Context: specifies the Maintenance Association that the MEP belongs to 💜.

6.1.4. Continuity Check Parameters (Applicable per MA) 💖

  • Transmission Interval: the interval at which Continuity Check messages are sent by a MEP ⏰.
  • Loss Threshold: the number of consecutive Continuity Check messages that a MEP must not receive from any one of the other MEPs in its MA before it indicates either a MEP failure or a network failure 🚨. Recommended default value is 3 ✨.
  • VLAN, Fine-Grained Label, and Flow Parameters: the VLAN or fine-grained label and flow parameters to be used in the Continuity Check messages 🎀.
  • Hop Count: the hop count to be used in the Continuity Check messages 🦋.

6.1.5. Connectivity Verification Parameters (Applicable per Operation) 🌈

  • MA context: specifies the Maintenance Association in which the Connectivity Verification operation is to be performed 🗺️.
  • Target RBridge Nickname (unicast), Tree Identifier (multicast), and IP Multicast Group: for unicast, this is the nickname of the RBridge that's the target of the Connectivity Verification operation 🎯. For multicast, it's the target Tree Identifier for un-pruned tree verification, or the Tree Identifier and IP multicast group (S, G) or (*, G) for pruned tree verification 🌳.
  • VLAN, Fine-Grained Label, and Flow Parameters: the VLAN or fine-grained label and flow parameters to be used in the Connectivity Verification message 🧁.
  • Operation Timeout Value: the timeout on the initiating MEP before the Connectivity Verification operation is declared to have failed ⏱️. The recommended default value is 5 seconds 💅.
  • Repeat Count: the number of Connectivity Verification messages that must be transmitted per operation 🔁. The recommended default value is 1.
  • Hop Count: the hop count to be used in the Connectivity Verification messages 🦋.
  • Reply Mode: indicates whether the response to the Connectivity Verification operation should be sent in-band or out-of-band 📬.
  • Scope List (Multicast): the list of MEP Identifiers that must respond to the message 🙋.

6.1.6. Fault Isolation Parameters (Applicable per Operation) 🔍

  • MA Context: specifies the Maintenance Association in which the Fault Isolation operation is to be performed 🗺️.
  • Target RBridge Nickname (unicast), Tree Identifier (multicast), and IP Multicast Group: for unicast, this is the nickname of the RBridge that's the target of the Fault Isolation operation 🎯. For multicast, it's the target Tree Identifier for un-pruned tree tracing, or the Tree Identifier and IP multicast group (S, G) or (*, G) for pruned tree tracing 🌳.
  • VLAN, Fine-Grained Label, and Flow Parameters: the VLAN or fine-grain label and flow parameters to be used in the Fault Isolation messages 🧁.
  • Operation Timeout Value: the timeout on the initiating MEP before the Fault Isolation operation is declared to have failed ⏱️. The recommended default value is 5 seconds 💖.
  • Hop Count: the hop count to be used in the Fault Isolation messages 🦋.
  • Reply Mode: indicates whether the response to the Fault Isolation operation should be sent in-band or out-of-band 📬.
  • Scope List (Multicast): the list of MEP Identifiers that must respond to the message 🙋.

6.1.7. Packet Loss Monitoring 📉

  • MA Context: specifies the Maintenance Association in which the Packet Loss Monitoring operation is to be performed 🗺️.
  • Target RBridge Nickname: the nickname of the RBridge that's the target of the Packet Loss Monitoring operation 🎯.
  • VLAN, Fine-Grained Label, and Flow Parameters: the VLAN or fine-grained label and flow parameters to be used in the Packet Loss Monitoring messages 🎀.
  • Transmission Rate: the rate at which the Packet Loss Monitoring messages are to be sent 🚀.
  • Monitoring Interval: the total duration of time for which a single Packet Loss Monitoring probe is to continue ⌛.
  • Repeat Count: the number of probe operations to be performed 🔁. For on-demand monitoring, this is typically set to 1. For proactive monitoring, this may be set to allow for infinite monitoring ♾️.
  • Hop Count: the hop count to be used in the Packet Loss Monitoring messages 🦋.
  • Mode: indicates whether one-way or two-way loss measurement is required 🔀.

6.1.8. Packet Delay Monitoring ⏳

  • MA Context: specifies the Maintenance Association in which the Packet Delay Monitoring operation is to be performed 🗺️
  • Target RBridge Nickname: the nickname of the RBridge that's the target of the Packet Delay Monitoring operation 🎯.
  • VLAN, Fine-Grained Label, and Flow Parameters: the VLAN or fine-grained label and flow parameters to be used in the Packet Delay Monitoring messages 🎀.
  • Transmission Rate: the rate at which the Packet Delay Monitoring messages are to be sent 🚀.
  • Monitoring Interval: the total duration of time for which a single Packet Delay Monitoring probe is to continue ⌛.
  • Repeat Count: the number of probe operations to be performed 🔁. For on-demand monitoring, this is typically set to 1. For proactive monitoring this may be set to allow for infinite monitoring ♾️.
  • Hop Count: the hop count to be used in the Packet Delay Monitoring messages 🦋.
  • Mode: indicates whether one-way or two-way delay measurement is required 🔀.

6.2. TRILL OAM Notifications 🔔

TRILL OAM mechanisms should trigger notifications to alert operators to certain conditions 🚨. Such conditions include but are not limited to:

  • Faults detected by proactive mechanisms.
  • Reception of event-driven defect indications.
  • Logged security incidents pertaining to the OAM Message Channel.
  • Protocol errors (for example, as caused by misconfiguration).

Notifications generated by TRILL OAM mechanisms may be via SNMP, Syslog messages [RFC5424], or any other standard management protocol that supports asynchronous notifications 📣.

6.3. Collecting Performance Monitoring Metrics 📊

When performing the optional TRILL OAM performance monitoring functions, two RBridge designations are involved: a source RBridge and a target RBridge 👯. The source RBridge is the one from which the performance monitoring probe is initiated, and the target RBridge is the destination of the probe 🚀. The goal is to monitor performance characteristics between the two RBridges 🎯. The RBridge from which the network operator can extract the results of the probe (the performance monitoring metrics) depends on whether one-way or two-way performance monitoring functions are performed 🤔:

  • In the case of one-way performance monitoring functions, the metrics will be available at the target RBridge.
  • In the case of two-way performance monitoring functions, all the metrics will be available at the source RBridge, and a subset will be available at the target RBridge. More specifically, metrics in the direction from source to target as well as the direction from target to source will be available at the source RBridge. Metrics in the direction from source to target will be available at the target RBridge.

7. Security Considerations 🔒

TRILL OAM must provide mechanisms for:

  • Preventing denial-of-service attacks caused by exploitation of the OAM Message Channel, where a rogue device may overload the RBridges and the network with OAM messages 🚫. This could lead to interruption of the OAM services and, in the extreme case, disrupt network connectivity 💀. Mechanisms such as control-plane policing combined with shaping or rate limiting of OAM messaging can be employed to mitigate this 🛡️.
  • Optionally authenticating at communicating endpoints (MEPs and MIPs) that an OAM message has originated at an appropriate communicating endpoint 🪪.
  • Preventing TRILL OAM packets from leaking outside of the TRILL network or outside their corresponding Maintenance Domain 🚧. This can be done by having MEPs implement a filtering function based on the Maintenance Level associated with received OAM packets.
For general TRILL Security Considerations, see [RFC6325] 📖.

8. Acknowledgments 💌

We thank Gayle Noble, Dan Romascanu, Olen Stokes, Susan Hares, Ali Karimi, and Prabhu Raj for their thorough review of this work and their comments 🫶.

9. References 📚

9.1. Normative References

[802]       IEEE, "IEEE Standard for Local and Metropolitan Area
            Networks - Overview and Architecture", IEEE Std 802-2001,
            8 March 2002.

[802.1Q]    IEEE, "IEEE Standard for Local and metropolitan area
            networks - Media Access Control (MAC) Bridges and Virtual
            Bridge Local Area Networks", IEEE Std 802.1Q-2011, 31
            August 2011.

[RFC2544]   Bradner, S. and J. McQuaid, "Benchmarking Methodology for
            Network Interconnect Devices", RFC 2544, March 1999.

[RFC2579]   McCloghrie, K., Ed., Perkins, D., Ed., and J.
            Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
            58, RFC 2579, April 1999.

[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.

[RFC6325]   Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
            Ghanwani, "Routing Bridges (RBridges): Base Protocol
            Specification", RFC 6325, July 2011.

[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.

[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.

[RFC7177]   Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H.,
            and V. Manral, "Transparent Interconnection of Lots of
            Links (TRILL): Adjacency", RFC 7177, May 2014.

9.2. Informative References ✨

okay so these are the "if you want more context, go read this" sources, bestie 📚💜 Nothing here is required reading, but they're the vibe-check for everything the spec references in the background 🫶

  • [802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3-2012, December 2012.
  • [ISO/IEC7498-4] ISO/IEC, "Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 4: Management framework", ISO/IEC 7498-4, 1989.
  • [MEF35] Metro Ethernet Forum, "MEF 35 - Service OAM Performance Monitoring Implementation Agreement", April 2012.
  • [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
  • [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
  • [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
  • [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
  • [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
  • [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
  • [RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
  • [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
  • [RFC7087] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations", RFC 7087, December 2013.
  • [RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014.
  • [TRILL-IP] Wasserman, M, Eastlake 3rd, D., and D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", Work in Progress, March 2014.
  • [TRILL-ML] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
  • [TRILL-OAM] Senevirathne, T., Salam, S., Kumar, D, Eastlake 3rd, D., Aldrin, S., and Y. Li, "TRILL Fault Management", Work in Progress, February 2014.
  • [Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation Y.1731, February 2008.

Authors' Addresses 💅

The squad behind this doc, with their contact info 🎀

Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1
Canada

EMail: ssalam@cisco.com


Tissa Senevirathne
Cisco
375 East Tasman Drive
San Jose, CA 95134
USA

EMail: tsenevir@cisco.com


Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA

EMail: sam.aldrin@gmail.com


Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA

Phone: 1-508-333-2270
EMail: d3e3e3@gmail.com
📦 where this page comes from