TRILL Working Group Donald Eastlake 3rd INTERNET-DRAFT Stellar Switches Intended status: Proposed Standard Vishwas Manral Updates: RFCtrill IP Infusion Dave Ward Juniper Ayan Banerjee Cisco Expires: April 16, 2011 October 17, 2010 RBridges: OAM and BFD Support for TRILL Abstract This document specifies a general channel for sending OAM (Operations, Administration, and Maintenance) messages between RBridges in a campus through an extension to the TRILL (Transparent Interconnection of Lots of Links) protocol. It further specifies use of this channel for the BFD (Bidirectional Forwarding Detection) protocol. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html D. Eastlake, et al [Page 1] INTERNET-DRAFT RBridges: OAM and BFD Table of Contents 1. Introduction............................................3 1.1 Terminology............................................3 1.2 Additional Acronyms....................................3 1.3 Acknowledgements.......................................4 2. The TRILL OAM Message Channel...........................5 2.1 The OAM Message Inner Frame............................5 2.1.1 Inner Ethernet Header................................6 2.1.2 TRILL OAM Header.....................................7 2.2 The TRILL Header for OAM Messages......................8 2.3 OAM Message Ethernet Link Header.......................9 2.4 The TRILL OAM-Channel Bit Option.......................9 2.5 Processing TRILL OAM Messages.........................10 2.5.1 Processing the TRILL OAM Channel Header.............10 2.5.2 Native TRILL-OAM Frames.............................11 3. TRILL BFD..............................................12 3.1 Sessions and Initialization...........................12 3.2 TRILL BFD Control Protocol............................12 3.2.1 One-Hop TRILL BFD Control...........................13 3.2.2 BFD Control Frame Processing........................13 3.3 TRILL BFD Echo Protocol...............................14 3.3.1 BFD Echo Frame Processing...........................14 4. Management and Operations Considerations...............16 5. Allocations Considerations.............................17 5.1 IANA Considerations...................................17 5.2 IEEE Registration Authority Considerations............18 6. Security Considerations................................19 6.1 OAM Channel Security Considerations...................19 6.2 BFD Security Considerations...........................19 7. Normative References...................................21 8. Informative References.................................21 D. Eastlake, et al [Page 2] INTERNET-DRAFT RBridges: OAM and BFD 1. Introduction The TRILL IS-IS Hellos used between RBridges provide a basic neighbor and continuity check for TRILL links [RFCtrill]. However, failure detection by non-receipt of such Hellos is based on the holding time parameter which is typically set to a value over ten seconds and, in any case, has a minimum expressible value of one second. Many applications, including voice over IP, may wish, with very high probability, to detect interruptions in continuity within a much shorter time period. In some cases physical layer failures can be detected very rapidly but this is not always possible, such as when there is a failure between two devices that are in turn between two RBridges, and there are many subtle failures possible at higher levels. For example, some forms of failure could affect unicast frames while still letting multicast frames through and all TRILL IS- IS frames, including Hellos, are multicast. Thus, a method of frequently testing continuity for the TRILL Data between neighbor RBridges is necessary for some applications. Such continuity testing is one example of TRILL data plane Operations, Administration, and Maintenance (OAM) requirements. Various of such requirements can be met by a variety of protocols such as the Bidirectional Forwarding Detection (BFD) [RFC5880] [RFC5882] and [Y.1731]. This document specifies, in Section 2, a general channel for sending OAM messages between RBridges in a campus using extensions to the TRILL protocol and further specifies, in Section 3, use of this channel for the BFD protocol. TRILL BFD can be used to provide rapid detection of link continuity failure for TRILL Data frames. 1.1 Terminology The terminology and acronyms of [RFCtrill] are used in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Additional Acronyms The following acronyms are used in this document in addition to those defined in [RFCtrill]: BFD - Bidirectional Forwarding Detection D. Eastlake, et al [Page 3] INTERNET-DRAFT RBridges: OAM and BFD MH - Multi-Hop OAM - Operations, Administration, and Maintenance OV - OAM (Message Channel) Version SL - Silent 1.3 Acknowledgements The authors would like to particularly thank David Katz, co-author of [RFC5880] and [RFC5882]. Some of the text is this document was adapted from those RFCs. D. Eastlake, et al [Page 4] INTERNET-DRAFT RBridges: OAM and BFD 2. The TRILL OAM Message Channel TRILL OAM messages are transmitted as TRILL Data frames. They are primarily identified as OAM messages by their Inner.MacDA and Inner Ethertype. This Inner Ethertype is followed by a 32-bit TRILL OAM Header used to indicate the OAM protocol of the following OAM protocol specific data. A TRILL Header bit option is provided that may optionally be used to guarantee that frames sent over the TRILL OAM Message Channel cannot accidentally be forwarded to end stations, even by RBridges that are ignorant of the TRILL OAM Message Channel mechanism. The diagram below shows the overall structure of a TRILL OAM Message Channel frame on a link between two RBridges: Frame Structure Section of This Document ------------------------ +--------------------------------+ | Outer Link Header | Section 2.3 if Ethernet Link +--------------------------------+ | TRILL Header | Section 2.2 +--------------------------------+ | Inner Ethernet Header | Section 2.1.1 +--------------------------------+ | TRILL OAM Channel Header | Section 2.1.2 +--------------------------------+ | OAM Protocol Specific Payload | See specific OAM protocol +--------------------------------+ | Link Trailer (FCS if Ethernet) | +--------------------------------+ The Sections 2.1 and 2.2 below describe the Inner frame and TRILL Header for frames sent in the TRILL OAM Message Channel. As always, the Outer link header is whatever is needed to get a TRILL Data frame from one RBridge to the next, depends on link technology, and can change with each hop for multi-hop OAM messages. Section 2.3 describes the Outer link header for Ethernet. Section 2.4 goes into further detail on the OAM-Channel Bit Option. And Section 2.5 describes some details of TRILL OAM Message processing. 2.1 The OAM Message Inner Frame The encapsulated Inner frame within A TRILL OAM Message Channel frame is as shown below. D. Eastlake, et al [Page 5] INTERNET-DRAFT RBridges: OAM and BFD Inner Ethernet Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Inner.MacDA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Inner.MacDA cont. | Inner.MacSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner.MacSA cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = C-Tag (0x8100) | Priority, VLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TRILL OAM Channel Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL-OAM Ethertype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | OV | TRILL OAM Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OAM Protocol Specific Information: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + OAM Protocol Specific Data | ... 2.1.1 Inner Ethernet Header The special Inner.MacDA is one of two values: OAM-RBridge-MAC if the OAM message is unicast or All-OAM-RBridges if the OAM message is multi-destination (see Section 6). The Inner.MacSA is selected by the RBridge originating the OAM message. If it is a unicast MAC address, on decapsulation it will be learned as being attached to the ingress RBridge. If that learning is not desired, the Inner.MacSA MAY be set to All-OAM-RBridges. Address learning on decapsulation does not occur if the source MAC has the group bit on. As with all TRILL encapsulated frames, a VLAN tag MUST be present. Use of a VLAN tag Ethertype other than 0x8100 is beyond the scope of this document. Recommendations for the frame priority are as follows: - For one-hop known unicast OAM messages critical to network connectivity, such as one-hop BFD for rapid link failure detection in support of TRILL IS-IS, the RECOMMENDED priority is 7. - For multi-hop known unicast OAM messages, the RECOMMENDED priority is 6. - For multi-destination OAM messages, it is RECOMMENDED that the priority be no higher than 5. D. Eastlake, et al [Page 6] INTERNET-DRAFT RBridges: OAM and BFD Multi-destination TRILL OAM messages are VLAN scoped so the Inner.VLAN ID MUST be set to the VLAN of interest. To the extent that distribution tree pruning is in effect, such OAM messages will only reach RBridges advertising that they have appointed forwarder connectivity to that VLAN. For known unicast OAM messages, if the message is one-hop it is RECOMMENDED that the Inner.VLAN ID be the Designated VLAN on that hop. For multi-hop unicast OAM messages, it is RECOMMENDED that the Inner.VLAN ID be the default VLAN 1. 2.1.2 TRILL OAM Header After the TRILL OAM Ethertype (see Section 6) is a four-byte quantity with three sub-fields. The first, Flags, provides 16 bits of flags which, except as specified below, MUST be sent as zero, transparently copied by transit RBridges, and ignored on receipt. The next field, OV, gives the OAM Header version and MUST be zero. Lastly, a 12-bit field specified the particular TRILL OAM protocol to which the message applies. See Section 6 for IANA Considerations. The flag bits are numbered from 0 to 15 as shown below. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |SL|MH| Available Flags | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Bit 0, which is the high order bit in network order, is defined as the SL or Silent bit. If it is a one, it suppresses OAM Channel Error messages due to the use of an unknown version or OAM protocol (see Section 2.5.1). Bit 1 is the MH or Multi-Hop bit. It is used to inform the destination OAM protocol that the message was intended to be multi-hop (MH=1) or one-hop (MH=0). The TRILL OAM Protocol field specifies the OAM protocol that the OAM Channel message relates to. Initial defined values are as listed below. See Section 6 for IANA Considerations. Protocol Name - Section of this Document -------- ------------------------------- 0x0001 OAM Channel Error - Section 2.5 0x0002 TRILL BFD Control - Section 3.2 0x0003 TRILL BFD Echo - Section 3.3 D. Eastlake, et al [Page 7] INTERNET-DRAFT RBridges: OAM and BFD 2.2 The TRILL Header for OAM Messages After the Outer link header (which for Ethernet ends with the TRILL Ethertype) and before the encapsulated frame, the OAM message's TRILL Header appears as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|0 0|M| Op-Len | Hops=0x3F | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Nickname | Ingress Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TRILL Header version V, MUST be zero, the M bit is set appropriately as the OAM message is known unicast (M=0) or multi- destination (M=1), and Op-Len is set appropriately for the length of the options area, if any, all as specified in [RFCtrill]. When a TRILL OAM message is originated, the hop count field is always set to the maximum value, 0x3F. For messages sent a known number of hops, particularly one-hop messages or neighbor echo messages, checking the Hops (Hop Count) field provides an additional validity check as discussed in [RFC5082]. The RBridge originating a TRILL OAM message places a nickname that it holds into the ingress nickname field. There are several cases for the egress nickname field. If the OAM message is multi-destination, then the egress nickname designates the distribution tree to use. If the OAM message is a multi-hop unicast message, then the egress nickname is a nickname of the target RBridge; this includes the special case of an "echo" OAM message where the originator places its own nickname in both the ingress and egress nickname fields. If the OAM message is a one-hop unicast message, there are two possibilities for the egress nickname. o The egress nickname can bet set to a nickname of the target neighbor RBridge. This will usually work well but there is a small chance that, due to a nickname transient, the frame will actually be delivered to some other RBridge in the campus. Due to this possibility, both here and in the multi-hop unicast case, if a TRILL OAM message is intended for a specific RBridge in the campus topology, it is RECOMMENDED that the OAM protocol specific data include the IS-IS SystemID of the target RBridge for an added check. o The special nickname Any-RBridge may be used. This will guarantee decapsulation at the immediate neighbor RBridge regardless of the state of nickname assignments. RBridges supporting the TRILL OAM Channel facility MUST recognize the Any-RBridge special nickname and accept TRILL Data frames having that value in the egress D. Eastlake, et al [Page 8] INTERNET-DRAFT RBridges: OAM and BFD nickname field as being sent to them as the egress. 2.3 OAM Message Ethernet Link Header If the link on which a TRILL OAM frame is transmitted between neighbor RBridges is Ethernet, the link header follows the usual rules for a TRILL Data frame over Ethernet [RFCtrill]. In particular, the Outer.MacSA is the MAC address of the port from which the frame is sent. The Outer.MacDA is the MAC address of the next-hop RBridge port for unicast TRILL OAM messages or the All-RBridges multicast address for multi-destination TRILL OAM messages. If an Outer.VLAN tag is present, it must specify the Designated VLAN for that hop and the priority must be the same as in the Inner.VLAN tag. 2.4 The TRILL OAM-Channel Bit Option A critical ingress-to-egress TRILL Header bit option, OAM-Channel, is specified associated with the TRILL OAM Channel facility. This option is NOT REQUIRED to appear in the TRILL Header in TRILL OAM message frames. It serves two functions, as follows: o An RBridge indicates that it supports the TRILL OAM Channel facility by advertising, in the link state database, its support for this bit option. o If this bit option is present in a TRILL OAM message frame, it guarantees that, if the inner frame is decapsulated by an RBridge that does not implement the TRILL OAM Channel it will be discarded rather than being locally flooded as a native frame out all ports for which that RBridge is appointed forwarder for the Inner.VLAN. However, if it is certain that all RBridges in the campus implement the TRILL OAM Channel or if the possible local flooding of the inner frame as specified above is acceptable, there is NO REQUIREMENT to include an options area or to set this particular option bit in the TRILL Header options area even if an options area is included. As with any other critical ingress-to-egress option, if the bit options area is present and this bit option is set, then the summary CItE bit MUST be set at the top of the options area. D. Eastlake, et al [Page 9] INTERNET-DRAFT RBridges: OAM and BFD 2.5 Processing TRILL OAM Messages TRILL OAM messages are designed to look like and, to the extent practical, be processed as regular TRILL Data frames. On receiving a TRILL OAM frame, the initial tests on the Outer.MacDA, Outer Ethertype, TRILL Header V and Hop Count fields and the RPF check if the frame is multi-destination, are all performed as usual. The forwarding and/or decapsulation decisions are the same as for a regular TRILL Data frame with the exception that a RBridge implementing the TRILL OAM Channel MUST recognize the Any-RBridge egress nickname in unicast TRILL Data frames, decapsulating and not forwarding such frames if they meet other checks. If the OAM-Channel critical ingress-to-egress bit option is present and the egressing RBridge does not implement the TRILL OAM Channel, the frame is discarded. If other options are present, they may affect processing or cause the frame to be discarded. On decapsulation, the special Inner.MacDA values of OAM-RBridge-MAC (unicast) and All-OAM-RBridges (multicast) and/or the Inner Ethertype of TRILL-OAM MUST be recognized to trigger processing as a TRILL OAM message. If the decapsulating RBridge does not implement the TRILL OAM Channel, it will treat the frame as a regular TRILL Data frame and locally flood the decapsulated native frame out all ports where it is appointed forwarder for the Inner.VLAN. 2.5.1 Processing the TRILL OAM Channel Header Knowing that it has a TRILL OAM Channel message, the egress RBridge looks at the OV (OAM Message Header version) and OAM Protocol fields. If the OV field is non-zero or if the OAM Protocol field is a reserved value or a value unknown to the egress RBridge, the egress RBridge returns an OAM Channel Error frame unless the "SL" (Silent) flag is a one in the OAM message. An OAM Channel Error frame is a multi-hop unicast TRILL OAM Channel message with the ingress nickname set to the nickname of the RBridge detecting the error, and the egress nickname set to the value of the ingress nickname in the OAM message for which the error was detected. For the protocol specific data area, an OAM Channel Message Error frame has at least the first 256 bytes (or less if less are available) of the erroneous decapsulated OAM message starting with the Inner.MacDA. All RBridges implementing the TRILL OAM Message Channel MUST recognize the OAM Message Channel Error protocol value (0x001) and MUST NOT generate an OAM Message Channel Error message in response to a received OAM Message Channel Error frame, even if they always set the "SL" flag is all TRILL OAM messages they send so they would not normally expect to receive an OAM Channel Message Error frame. D. Eastlake, et al [Page 10] INTERNET-DRAFT RBridges: OAM and BFD If the OV field is zero and the processing RBridge recognizes the OAM Protocol value, it processes the message in accordance with that OAM protocol. Errors within a recognized OAM Protocol are handled within that protocol and do not produce OAM Message Channel Error frames. 2.5.2 Native TRILL-OAM Frames A TRILL OAM Message Channel frame MAY be generated, if provided for by the OAM protocol involved, as the result of the receipt by an RBridge of a native frame with the TRILL-OAM Ethertype. Such a native frame must met the usual VLAN restrictions to be accepted by the ingress RBridge generating the TRILL OAM Message Channel frame. If the native frame's destination MAC address is not one of the special MAC destination addresses All-OAM-RBridges or OAM-RBridge-MAC, it MUST be changed to one of those two addresses before the frame is encapsulated. The decapsulation and processing of a TRILL OAM Message Channel frame MAY, if provided for by the OAM protocol involved, result in the sending of a native frame with the TRILL-OAM Ethertype out one or more ports of the egress RBridge. The VLAN, and the MAC destination addres, of the frame MAY be set to appropriate values before it is transmitted. D. Eastlake, et al [Page 11] INTERNET-DRAFT RBridges: OAM and BFD 3. TRILL BFD Using the TRILL OAM Message Channel facility, described in Section 2, TRILL supports one-hop and multi-hop BFD Control and neighbor BFD Echo as detailed below. Multi-destination BFD is beyond the scope of this document. 3.1 Sessions and Initialization Within an RBridge campus, there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL. This BFD session must be bound to this interface. As such, both sides of a session MUST take the "Active" role (sending initial BFD Control packets with a zero value of Your Discriminator), and any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system and interface. Note that TRILL BFD provides OAM facilities for the TRILL Data plane. This is above whatever protocol is in use on a particular link, such as PPP [TrillPPP]. Link technology specific OAM protocols may be used on a link between neighbor RBridges, for example Continuity Fault Management [802.1ag] if the link is Ethernet. But such link layer OAM and coordination between it and TRILL data plan layer OAM, such as TRILL BFD, is beyond the scope of this document. If lower level mechanisms, such as link aggregation [802.1AX], are in use that present a single logical interface to TRILL IS-IS, only a single TRILL BFD session can be established to any other RBridge over this logical interface. However, link layer OAM could be run separately on each of the components of a link aggregation. 3.2 TRILL BFD Control Protocol TRILL BFD Control frames are unicast TRILL OAM Message Channel frames as described in Section 2 above supplemented by the specifications below. As a unicast message, the M bit in the TRILL Header is zero and the Inner.MacDA is OAM-RBridge-MAC. The TRILL OAM Protocol value is 0x002. The protocol specific data associated with the TRILL BFD Control protocol is as shown below. See [RFC5880] for further information on the fields after the initial SystemIDs. D. Eastlake, et al [Page 12] INTERNET-DRAFT RBridges: OAM and BFD TRILL BFD Control Protocol Data: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target RBridge SystemID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target RBridge SystemID | Orig. RBridge SystemID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating RBridge SystemID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optional Authentication Section: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.1 One-Hop TRILL BFD Control One-hop TRILL BFD Control is typically used in support of TRILL IS-IS to rapidly detect link failure. Such TRILL BFD frames SHOULD be sent with priority 7. For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL BFD Control frames to the other only if TRILL IS-IS has detected bi- directional connectivity and both RBridges indicate support of TRILL BFD is enabled. The BFD Enabled TLV is used to indicate this as specified in [RFCbfdtlv]. The indication of TRILL BFD support with the BFD Enabled TLV overrides any indication of lack of support through failure to advertise support of the OAM-Channel TRILL Header bit option in the link state database. 3.2.2 BFD Control Frame Processing The following tests SHOULD be performed on received TRILL BFD Control frames before generic BFD processing. (In some implementations, the TRILL Header may not be available to the TRILL BFD module in which case some of these check are not possible.) D. Eastlake, et al [Page 13] INTERNET-DRAFT RBridges: OAM and BFD Is the M bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Control is beyond the scope of this document. If the MH OAM Header flag is zero, indicating one-hop, test that the TRILL Header hop count received was 0x3F (i.e., is 0x3E if it has already been decremented) and if it is any other value discard the frame. If the MH OAM flag is one, indicating multi-hop, test that the TRILL Header hop count received was not less than a configurable value that defaults to 0x30. If it is less, discard the frame. Check that the target IS-IS SystemID in the OAM protocol data is your SystemID. If not, discard the frame. If the MH OAM Header flag is zero, test that the originating SystemID is that of a neighbor RBridge. If not, discard the frame. 3.3 TRILL BFD Echo Protocol A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame, as specified in Section 2, which should be bounced back by an immediate neighbor because both the ingress and egress nicknames are set to a nickname of the originating RBridge. Normal TRILL Data frame forwarding will cause the frame to be returned. TRILL BFD Echo frames SHOULD only be sent on a link if a TRILL BFD Control session has been established, TRILL BFD Echo support is indicated by the potentially echo responding RBridge, and the TRILL BFD Echo originating RBridge wishes to make use of this optional feature. Since the originating RBridge is the RBridge that will be processing a returned Echo frame, the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back. For example, it could include its own SystemID, the neighbor's SystemID, a session identifier and a sequence count as well as a Message Authentication Code. 3.3.1 BFD Echo Frame Processing The following tests SHOULD be performed on returned TRILL BFD Echo frames before other processing. (In some implementations, the TRILL D. Eastlake, et al [Page 14] INTERNET-DRAFT RBridges: OAM and BFD Header may not be available to the TRILL BFD Echo module in which case these check are not possible.) Is the M bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document. The TRILL BFD Echo frame should have gone exactly two hops so test that the TRILL Header hop count as received was 0x3E (i.e., 0x3D if it has already been decremented) and if it is any other value discard the frame. (The value of the MH flag is ignored for TRILL BFD Echo protocol.) D. Eastlake, et al [Page 15] INTERNET-DRAFT RBridges: OAM and BFD 4. Management and Operations Considerations The TRILL BFD parameters at an RBridge are configurable... The default values are ... TBD. It is required that the operator of an RBridge campus configure the rates at which TRILL BFD frames are transmitted on a link to avoid congestion (e.g., link, I/O, CPU) and false failure detection. D. Eastlake, et al [Page 16] INTERNET-DRAFT RBridges: OAM and BFD 5. Allocations Considerations The following subsection give IANA and IEEE Registration Authority Considerations. 5.1 IANA Considerations In this section, the allocation procedures "Standards Action", "IETF Review", and "RFC Publication" are as specified in [RFC5226]. IANA hereby allocates a previously unassigned TRILL Nickname as follows: Any-RBridge TBD (0xFFCO suggested) IANA hereby allocates a previously unassigned TRILL Multicast address as follows: All-OAM-RBridges TBD (01-80-C2-00-00-43 suggested) IANA hereby allocates a previously unassigned TRILL critical ingress- to-egress Bit Option as follows: TBD OAM-Option IANA allocates the following block of 16 globally unique unicast MAC addresses for use with the TRILL protocol and creates a sub-registry in the TRILL Parameter Registry for these addresses: 00-00-5E-xx-xx-x0 - OAM-RBridge-MAC 00-00-5E-xx-xx-x1 to 00-00-5E-xx-xx-xF - available for allocation (suggested 00-00-5E-00-03-00 through 00-00-5E-00-03-0F) Allocation of unicast MAC values from the above block for TRILL use is based on IETF Review. IANA creates an additional sub-registry in the TRILL Parameter Registry for TRILL OAM Protocols, with initial contents as follows: D. Eastlake, et al [Page 17] INTERNET-DRAFT RBridges: OAM and BFD Protocol Use -------- --- 0x000 Reserved 0x001 OAM Channel Error 0x002 BFD Control 0x003 BFD Echo 0x004-0x0FF Available for allocation (1) 0x100-0xFF7 Available for allocation (2) 0xFF8-0xFFE For Experimental use, will not be allocated 0xFFF Reserved (1) TRILL OAM protocol code points from 0x004 to 0x0FF require an IETF Standards Action for allocation. (2) TRILL OAM protocol code points from 0x100 to 0xFF7 require RFC Publication to allocate a single value or IETF Review to allocate multiple values. IANA creates an additional sub-registry in the TRILL Parameter Registry for TRILL OAM Header Flags with initial contents as follows: Flag Bit Mnemonic Allocation -------- -------- ---------- 0 SL Silent 1 MH Multi-hop 2-15 - Available for allocation Allocation of TRILL OAM Header Flags is based on IETF Standards Action [RFC5226]. 5.2 IEEE Registration Authority Considerations The Ethertype is assigned by the IEEE Registration Authority for TRILL-OAM. D. Eastlake, et al [Page 18] INTERNET-DRAFT RBridges: OAM and BFD 6. Security Considerations The following sections provide security considerations for the TRILL OAM Message Channel and for TRILL BFD. See [RFCtrill] for general RBridge Security Considerations. 6.1 OAM Channel Security Considerations -- TBD -- 6.2 BFD Security Considerations BFD Control frames can be secured by authentication mechanisms native to BFD [RFC5880]. If shared secret IS-IS authentication is not in effect for the Hellos exchanged by two neighbor RBridges then, by default, TRILL BFD between those RBridges is also unsecured. If shared secret IS-IS authentication is in effect for the Hellos exchanged by two neighbor RBridges then, by default, TRILL BFD Control frames sent between those RBridges use BFD Keyed SHA1 authentication with keying material derived as follows: HMAC-SHA1 ( ( "TRILL BFD Control" | smallerSystemID | largerSystemID ), IS-IS-key ) where HMAC-SHA1 is as specified in [RFC2104] (see also [RFC4634]), "TRILL BFD Control" is the seventeen byte US ASCII string indicated which is then concatenated with the SystemIDs of both of the neighbor RBridges sorted as unsigned 48-bit integers, and IS-IS-key is the secret keying material being used for IS-IS authentication on the link. In the Authentication Section of the BFD Control frame OAM protocol specific data, Auth Type would be 4, Auth Len would be 28, and Auth Key ID is zero. The RBridges MAY be configured to use other BFD security modes or keying material including configuration to use no security. Authentication for TRILL BFD Echo SHOULD be provided but is a local implementation issue as BFD Echo frames are only authenticated by their sender when received in the form of Echo responses. However, if TRILL IS-IS and BFD Control are being authenticated to a neighbor and BFD Echo is in use, BFD Echo frames to be returned by that neighbor SHOULD be authenticated and such authenticate SHOULD use different keying material from other types of authentication. For example, it D. Eastlake, et al [Page 19] INTERNET-DRAFT RBridges: OAM and BFD could use keying material derived as follows: HMAC-SHA1 ( ( "TRILL BFD Echo" | smallerSystemID | largerSystemID ), IS-IS-key ) D. Eastlake, et al [Page 20] INTERNET-DRAFT RBridges: OAM and BFD 7. Normative References [RFC2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection (BFD)", June 2010. [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", June 2010. [RFCtrill] - R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- trill-rbridge-protocol-16.txt, in RFC Editor queue. [RFCbfdtlv] - C. Hopps, L. Ginsberg, "IS-IS BFD Enabled TLV", draft- ietf-isis-bfd-tlv-02.txt, work in progress, 4 January 2010. 8. Informative References [802.1AX] - IEEE, "IEEE Standard for Local and metropolitan area networks / Link Aggregation", 802.1AX-2008, 1 January 2008. [802.1ag] - IEEE, "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks / Connectivity Fault Management", 802.1ag-2007, 17 December 2007. [RFC4634] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007 [TrillPPP] - Carlson, J., "PPP TRILL Protocol Control Protocol", draft-ietf-pppext-trill-protocol-01.txt, work in progress, May 2010. [Y.1731] - ITU-T Recommendation Y.1731 (02/08), "OAM functions and mechanisms for Ethernet based networks", February 2008 D. Eastlake, et al [Page 21] INTERNET-DRAFT RBridges: OAM and BFD Authors' Addresses Donald Eastlake 3rd Stellar Switches 155 Beaver Street Milford, MA 01757 USA Tel: +1-508-333-2270 EMail: d3e3e3@gmail.com Vishwas Manral IP Infusion Inc. 1188 E. Arques Ave. Sunnyvale, CA 94089 USA Tel: +1-408-400-1900 EMail: vishwas@ipinfusion.com Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA Phone: +1-408-745-2000 EMail: dward@juniper.net Ayan Banerjee Cisco Systems 170 W. Tasman Drive San Jose, CA 95138 USA Phone: +1-408-525-8781 EmMail: ayabaner@cisco.com D. Eastlake, et al [Page 22] INTERNET-DRAFT RBridges: OAM and BFD Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake, et al [Page 23]