Network Working Group V. Manral Internet-Draft HP Networking Intended status: Standards Track D. Eastlake Expires: April 30, 2012 Huawei D. Ward Juniper Networks A. Banerjee Cisco Systems October 31, 2011 Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL (TRansparent Interconnection of Lots of Links) draft-ietf-trill-rbridge-bfd-01 Abstract This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed (Operations, Administration and Maintenance) OAM mechanism in IP and MPLS networks. However, in the present form a BFD packet cannot be sent over a TRILL network as it is either IP/ UDP encapsulated or encapsulated directly over Multi Protocol Label Switching (MPLS) or using Associated Channel Header (ACH) encapsulation. This document defines BFD encapsulation over TRILL to address this shortcoming. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 Manral, et al. Expires April 30, 2012 [Page 1] Internet-Draft BFD TRILL Encapsulation May 2011 material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2012. Copyright Notice Copyright (c) 2011 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 Simplified BSD License. Manral, et al. Expires April 30, 2012 [Page 2] Internet-Draft BFD TRILL Encapsulation May 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. BFD over TRILL . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Sessions and Initialization . . . . . . . . . . . . . . . . . . 5 5. Relationship to MPLS OAM . . . . . . . . . . . . . . . . . . . 6 6. TRILL BFD Control Protocol . . . . . . . . . . . . . . . . . . 6 6.1. One-Hop TRILL BFD Control . . . . . . . . . . . . . . . . . 7 6.2. BFD Control Frame Processing . . . . . . . . . . . . . . . 7 7. TRILL BFD Echo Protocol . . . . . . . . . . . . . . . . . . . . 8 7.1. BFD Echo Frame Processing . . . . . . . . . . . . . . . . . 8 8. Management and Operations Considerations . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 12.1. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Manral, et al. Expires April 30, 2012 [Page 3] Internet-Draft BFD TRILL Encapsulation May 2011 1. Introduction Faster convergence is a very critical feature of TRILL [RFC6325]. The TRILL IS-IS Hellos [RFC6327] used between RBridges provide a basic neighbor and continuity check for TRILL links. However, failure detection by non-receipt of such Hellos is based on the holding time parameter which is commonly set to a value of tens of seconds and, in any case, has a minimum expressible value of one second. Some applications, including Voice over IP, may wish, with 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 bridges that are in turn between two RBridges. There are also many subtle failures possible at higher levels. For example, some forms of failure could affect unicast frames while still letting multicast frames through; since all TRILL IS-IS Hellos are multicast such a failure cannot be detected with Hellos. Thus, a low overhead method for frequently testing continuity for the TRILL Data between neighbor RBridges is necessary for some applications. BFD protocol provides a low-overhead, short- duration detection of failures in the path between forwarding engines. This document describes a TRILL encapsulation for BFD packets between Rbridges using the Rbridge Channel facility [TRILLChannel]. 2. Terminology ACH: Assiciated Channel Header BFD: Bi-directional Forwarding Detection GTSM: Generalized TTL Security Mechanism IP: Internet Protocol IS-IS: Intermediate-System to Intermediate-System MPLS: Multi Protocol Label Switching OAM: Operations, Administration, and Maintenance PPP: Point-to-Point Protocol TRILL: Transparent Interconnection of Lots of Links Manral, et al. Expires April 30, 2012 [Page 4] Internet-Draft BFD TRILL Encapsulation May 2011 TTL: Time To Live UDP: User Datagram Protocol 3. BFD over TRILL TRILL supports neighbor BFD Echo and one-hop and multi-hop BFD Control, as specified below, over the TRILL Rbridge Channel facility. Multi-destination BFD is beyond the scope of this document. The Rbridge Channel facility is specified in [TRILLChannel]. BFD over TRILL support is similar to BFD over IP support except where it is explicitly so mentioned. When running BFD over TRILL both Single Hop as well as in Multi Hop sessions are supported. Asynchronous mode is supported, and the demand mode is not supported for TRILL. BFD over TRILL supports the Echo function, however this can be used for only Single hop sessions. The TRILL Header Hop Count in the BFD packets is sent out with a value of 63. To reduce spoofing attacks, the TRILL Hop Count of a received frame is checked. For a Single Hop session if the Hop count is less than 63 the packet is discarded if the GTSM mode [RFC5082] is set. For Multi Hop sessions the Hop count check can be disabled or the bfdTrillAcceptedHopCount value can be configured. If a packet is received with a hop count of less than bfdTrillAcceptedHopCount, the packet is discarded. Like in BFD for IP the format of the Echo Packet is not defined. A new Rbridge Channel type for the BFD TRILL Control frame as well as for BFD Echo packet is defined. Authentication mechanisms as supported in BFD are also supported for BFD running over TRILL. 4. Sessions and Initialization Within an RBridge campus, there will be only a single TRILL BFD Control session between two RBridges over a given link visible to TRILL. This BFD session must be bound to this link. 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 link. 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 Manral, et al. Expires April 30, 2012 [Page 5] Internet-Draft BFD TRILL Encapsulation May 2011 as a Point-to-Point Protocol (PPP) [RFC6361] link or an Ethernet link. 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 plane 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, lower layer OAM could be aware of and/or run separately on each of the components of an aggregation. 5. Relationship to MPLS OAM TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] in the same way that MPLS OAM protocols use the MPLS Generic Associated Channel [RFC5586]. However, the RBridges that implement TRILL are IS-IS [IS-IS] based routers, not label switched routers; thus TRILL BFD is closer to IPv4/IPv6 BFD than to MPLS BFD. TRILL BFD optionally includes support of BFD Echo which is not specified for MPLS BFD. 6. TRILL BFD Control Protocol TRILL BFD Control frames are unicast TRILL OAM Message Channel frames [TRILLChannel]. The TRILL Rbridge Protocol value is given in Section 10. The protocol specific data associated with the TRILL BFD Control protocol is as shown below. See [RFC5880] for further information on these fields. Manral, et al. Expires April 30, 2012 [Page 6] Internet-Draft BFD TRILL Encapsulation May 2011 TRILL BFD Control Protocol Data: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1. One-Hop TRILL BFD Control One-hop TRILL BFD Control is typically used to rapidly detect link and RBridge failures. TRILL BFD frames over one hop for such purposes 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, that is, the adjacency is in the Two-Way or report states [RFC6327] and both RBridges indicate support of TRILL BFD is enabled. The BFD Enabled TLV is used to indicate this as specified in [RFC6213]. 6.2. BFD Control Frame Processing The following tests MUST be performed on received TRILL BFD Control frames before generic BFD processing. If the M bit in the TRILL Header is non-zero, discard the frame. TRILL support of multi-destination BFD Control is beyond the scope of this document. If the OAM Header MH 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 (bfdTrillAcceptedHopCount) that defaults to 0x30. If it is less, discard the frame. Manral, et al. Expires April 30, 2012 [Page 7] Internet-Draft BFD TRILL Encapsulation May 2011 7. TRILL BFD Echo Protocol A TRILL BFD Echo frame is a unicast TRILL Rbridge Channel frame, as specified in [TRILLChannel], 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. The Rbridge Channel protocol number for BFD Echo is given in Section 10. TRILL BFD Echo frames SHOULD only be sent on a link if 1. A TRILL BFD Control session has been established, 2. TRILL BFD Echo support is indicated by the potentially echo responding RBridge, and 3. The adjacency is in the Report state [RFC6327], and 4. 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. 7.1. BFD Echo Frame Processing The following tests MUST be performed on returned TRILL BFD Echo frames before other processing. The RBridge Channel document now requires that the information in the TRILL Header be given to the OAM protocol. If the M-bit in the TRILL Header is non-zero, 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 TRILL Rbridge Channel Header in the frame should have the MH bit equal to one and if it is zero, the frame is discarded. Manral, et al. Expires April 30, 2012 [Page 8] Internet-Draft BFD TRILL Encapsulation May 2011 8. Management and Operations Considerations The TRILL BFD parameters on an RBridge are configurable. The default values are the same as in the IP BFD case, except where specified in this document i.e. Hop Count. 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. 9. Security Considerations This draft raises no new security considerations than those already mentioned in the BFD [RFC5880]. By keeping a seperate flag for Single Hop and Multihop sessions it allows the TTL check to be performed thus making harder the spoofing of BFD packets. However the same is possible even without the changes mentioned in this document. A device should rate limit the BFD packets redirected to the CPU so that the CPU is not overwhelmed. 10. IANA Considerations IANA is request to allocate two TRILL Rbridge Channel numbers from the range allocated by Standards Actions, as follows: Protocol Number -------- ------ BFD Control TBD (2 suggested) BFD Echo TBD (3 suggested) 11. Acknowledgements The authors would like to thank a lot of folks. Names will be disclosed soon. Manral, et al. Expires April 30, 2012 [Page 9] Internet-Draft BFD TRILL Encapsulation May 2011 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, April 2011. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6327] Eastlake, D., R. Perlman, A. Ghanwani, D. Dutt, V. Manral, "RBridges: Adjacency", dRFC 6325, July 2011. [TRILLChannel] Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward, "RBridges: RBridge Channel Support in TRILL", draft-ietf-trill-rbridge-channel, work in progress. 12.2. 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. [RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011. [IS-IS] ISO/IEC 10589:2002, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode NetworkService (ISO 8473)," ISO/IEC 10589:2002. Manral, et al. Expires April 30, 2012 [Page 10] Internet-Draft BFD TRILL Encapsulation May 2011 Authors' Addresses Vishwas Manral HP Networking 19111 Pruneridge Ave. Cupertino, CA 95014 USA Phone: 408-777-0693 Fax: Email: vishwas.manral@hp.com URI: Donald Eastlake 3rd Huawei 155 Beaver Street Milford, MA 01757 USA Phone: 508-333-2270 Email: d3e3e3@gmail.com Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA Phone: 408-745-2000 Email: dward@juniper.net Ayan Banerjee Cisco Systems 170 W. Tasman Drive San Jose, CA 95138 USA Phone: 408-525-8781 Email: ayabaner@cisco.com Manral, et al. Expires April 30, 2012 [Page 11]