Network Working Group Donald Eastlake INTERNET-DRAFT Huawei Updates: 6325 Anoop Ghanwani Intended status: Proposed Standard Dell Expires: March 11, 2012 September 12, 2012 Transparent Interconnection of Lots of Links (TRILL) Support of the Link Layer Discover Protocol (LLDP) Abstract RBridges are devices that implement the IETF TRILL (Transparent Interconnection of Lots of Links, RFC 6325) protocol. The Link Layer Discovery Protocol (LLDP, IEEE Std 802.1AB) is a one-way, unacknowledged protocol for the announcement of a station's capabilities to its peers. The set of peers that receive these frames and the scoping of the frame is primarily determined by the destination MAC address of the LLDP frame. This document specifies a Nearest-RBridge MAC address and other details of TRILL support of LLDP. It updates RFC 6325. 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 authors. 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 [Page 1] INTERNET-DRAFT LLDP Support in TRILL Table of Contents 1. Introduction............................................3 1.1 Terminology and Acronyms...............................3 2. LLDP on RBridge Ports...................................4 2.1 Use on Ethernet Ports..................................4 2.2 Use on Other RBridge Ports.............................5 3. Nearest-RBridge as Inner.MacDA..........................6 3.1 Transmission...........................................6 3.2 Receipt................................................6 4. Change in RFC 6325......................................8 5. IANA Considerations.....................................8 6. Security Considerations.................................8 Normative References.......................................9 Informative References.....................................9 D. Eastlake [Page 2] INTERNET-DRAFT LLDP Support in TRILL 1. Introduction The Link Layer Discovery Protocol (LLDP [802.1AB]) is a one-way, unacknowledged protocol for the announcement of a station's capabilities to its peers. The set of peers that receive these frames and the scoping of the frame is primarily determined by the destination address of the LLDP frame. This document specifies TRILL (Transparent Interconnection of Lots of Links, [RFC6325] [RFC6327]) support of LLDP. Such support is optional. This document updates [RFC6325]. Clause 7.1 of the IEEE [802.1AB] Standard provides that LLDP may be used with any unicast or group (multi-destination) destination address. This document specifies the Nearest-RBridge MAC destination address. 1.1 Terminology and Acronyms 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]. The following are used in this document: IEEE - Institute for Electronic and Electrical Engineers (www.ieee.org) LLDP - Link Layer Discovery Protocol [802.1AB] LLDPDU - LLDP Data Unit [802.1AB] MAC - Media Access Control [802] RBridge - Routing Bridge [RFC6325] TPMR - Two Port MAC Relay [802.1Q] TRILL - Transparent Interconnection of Lots of Links [RFC6325] D. Eastlake [Page 3] INTERNET-DRAFT LLDP Support in TRILL 2. LLDP on RBridge Ports LLDP [802.1AB] is explicitly specified to be usable with "Any group MAC address" and "Any individual MAC address" as the destination address. That standard also documents specific destination MAC addresses with different scope for propagation across various bridge types specified by IEEE 802.1 such as: o Nearest Customer Bridge: Propagation stops at the nearest Customer Bridge; i.e. such frames would pass through Provider Bridges and Two-port MAC Relays (TPMRs) [802.1Q]. (01-80-C2-00-00-00) o Nearest Non-TPMR Bridge: Propagation stops at the nearest Customer or Provider Bridge, but not at a TPMR. (01-80-C2-00-00-03) o Nearest Bridge: Propagation stops at the nearest bridge of any type, including a TPMR. (01-80-C2-00-00-02) Note that the devices that stop the propagation of LLDP frames are the only devices that process them; other devices forward them as if they were regular data frames. A new Nearest-RBridge multicast MAC address (see Section 4) is used as a destination MAC address with LLDPUs to send them to neighbor RBridges. There may in the future be other uses of the Nearest- RBridge multicast MAC address; in such applications, the Ethertype of those frames would be different than the LLDP EtherType (0x88CC). 2.1 Use on Ethernet Ports LLDPDUs sent with the Nearest-RBridge multicast address out an RBridge Ethernet port are not encapsulated with a TRILL Header and are sent natively. Intervening bridges, if any, will be transparent to frames using this multicast address. LLDPDUs using the Nearest-RBridge MAC destination address may be transmitted as permitted by [802.1AB] by an RBridge on any of its Ethernet ports regardless of the state of any adjacencies [IS-IS] [RFC6327] on that port. LLDPDUs may also be sent by an RBridge on Ethernet ports with the IEEE 802.1 provided destination MAC addresses listed above or other appropriate destination MAC addresses if other scopes are desired. D. Eastlake [Page 4] INTERNET-DRAFT LLDP Support in TRILL 2.2 Use on Other RBridge Ports If an RBridge port is a port on which an LLDPDU cannot be transmitted in native form, for example, a PPP TRILL port [RFC6361], the Nearest- RBridge destination MAC multicast address is still used but the LLDPDU appears inside a TRILL Data frame as specified in Section 3. The payload EtherType is the LLDP EtherType (0x88CC) with the subsequent portion of the frame following normal LLDP rules. This technique can be used to send an LLDPDU out any non-Ethernet RBridge port to RBridges that are one hop away. To assure than any required link initialization has occurred, TRILL Data frames containing LLDPDUs MUST NOT be transmitted out an RBridge port unless there is at least one adjacency [IS-IS] [RFC6327] on that port in a state other than Down. The rate of transmission of such frames is governed by the same rules as native LLDPDUs [802.1AB]. An LLDPDU received in a TRILL Data frame must pass the tests in Section 3.2 before being passed on to LLDP to be acted on. D. Eastlake [Page 5] INTERNET-DRAFT LLDP Support in TRILL 3. Nearest-RBridge as Inner.MacDA The Nearest-RBridge multicast MAC address is not intended to be forwarded by an Rbridge, and as a result the scope of a frame with this address as the MAC destination address would be all immediately adjacent RBridge neighbors on a link. The following sub-sections specify TRILL Data frame transmission and receipt where the Inner.MacDA is Nearest-RBridge. 3.1 Transmission When the Inner.MacDA of a TRILL Data frame is the Nearest-RBridge multicast MAC, then the following apply. Different uses of this MAC address are distinguished by the payload EtherType, for example 0x88CC for LLDP. 1. The originating RBridge MUST set the Inner.MacSA to a MAC address unique within the campus owned by that originating RBridge. This MAY be the same Inner.MacSA used for ESADI [ESADIdraft] and/or RBridge Channel [Channel] frames. 2. The Inner.VLAN defaults to 0x001 and is ignored on receipt unless otherwise specified. 3. TRILL Header fields MUST be set as follows: 3.a the hop count is initialized to the maximum value (0x3F), 3.b the M bit is set to zero, 3.c the ingress nickname is a nickname owned by the originating RBridge, 3.d the egress nickname is set to Any-RBridge. RBridges supporting the Nearest-RBridge MAC address MUST recognize the Any-RBridge egress nickname. 4. The link header/trailer are set as for a multi-destination TRILL Data frame [RFC6325]. 3.2 Receipt When a TRILL Data frame with an Inner.MacDA of Nearest-RBridge is egressed at an RBridge, it MUST be discarded unless it passes the following TRILL Header tests: D. Eastlake [Page 6] INTERNET-DRAFT LLDP Support in TRILL 1. The M bit is zero and the egress nickname is Any-RBridge. 2. The hop count confirms that it came from an immediate neighbor [RFC5082]; that is, the hop count is 0x3F before decrement or 0x3E if tested after decrement. If not discarded, it is assumed to be directed to the egress RBridge itself and is handled as appropriate for the payload protocol. D. Eastlake [Page 7] INTERNET-DRAFT LLDP Support in TRILL 4. Change in RFC 6325 A change in the behavior mandated by [RFC6325] is required to support the optional features specified in this document, as follows: An RBridge conformant to [RFC6325] will discard an Ethernet frame that it receives whose Outer MAC destination address is the Nearest-RBridge multicast address. To support LLDP to that address as described in Section 2.1 above, an RBridge must accept such frames and process them appropriately depending on their protocol type if the RBridge implements that protocol. For example, if the EtherType is the LLDP EtherType and LLDP is implemented at the receiving RBridge, it would be processed as an LLDPDU. 5. IANA Considerations IANA is requested to allocate a new TRILL multicast address [01-80-C2-00-00-44 suggested] for use as the Nearest-RBridge address and add this to the TRILL Multicast Addresses sub-registry. 6. Security Considerations This document specifies how to send LLDPDUs between adjacent RBridges. These techniques increase the span of the "link" over which LLDP can operate. This increased span may require use of additional security measures depending on the uses to which LLDP is put. If sensitive information is being transported, then appropriate link security should be used, depending on the link type, such as IEEE [802.1AE] for Ethernet links. Should an RBridge that does not understand the Any-RBridge egress nickname accept a frame with Outer.MacDA of All-RBridges but with the M bit zero in the TRILL Header it will simply discard the frame as having a reserved egress nickname value. D. Eastlake [Page 8] INTERNET-DRAFT LLDP Support in TRILL Normative References [802.1AB] - IEEE 802.1, "IEEE Standard for Local and metropolitan area networks / Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2009, 17 September 2009. [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002. [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., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011. [ESADIdraft] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, draft-ietf- trill-esadi, work in progress. Informative References [802] - IEEE 802, "IEEE Standard for Local and metropolitan area networks: Overview and Architecture", IEEE Std 802-2001, 8 March 2002. [802.1AE] - IEEE 802.1, "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Security", IEEE Std 802.1AE-2006, 18 August 2006. [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, 31 August 2011. [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011. [Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward, D. Eastlake [Page 9] INTERNET-DRAFT LLDP Support in TRILL draft-ietf-trill-rbridge-channel, work in progress. D. Eastlake [Page 10] INTERNET-DRAFT LLDP Support in TRILL Authors' Addresses Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Anoop Ghanwani Dell 350 Holger Way San Jose, CA 95134 USA Phone: +1-408-571-3500 Email: anoop@alumni.duke.edu D. Eastlake [Page 11] INTERNET-DRAFT LLDP Support in TRILL Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2012 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. 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 [Page 12]