TRILL Working Group Radia Perlman INTERNET-DRAFT Intel Labs Updates: 6325 Donald Eastlake Intended status: Proposed Standard Yizhou Li Huawei Anoop Ghanwani Dell Expires: July 12, 2012 January 13, 2012 RBridges: TRILL Link Data Optimizations Abstract Under certain circumstances, it is possible to encode TRILL (TRansparent Interconnection of Lots of Links) Data frames so as to make more efficient use of communications links. This document specifies two such optional optimizations. One, called Compact Format, improves the compactness of encoding in the case where a TRILL link is a point-to-point Ethernet link. The other, called Specific Addressing, optionally decreases the burden on multi-access TRILL links for multi-destination TRILL Data frames under some circumstances. This document 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 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 R. Perlman, et al [Page 1] INTERNET-DRAFT TRILL: Link Data Optimizations Table of Contents 1. Introduction............................................3 1.1 Structure of This Document.............................3 1.2 Terminology Used in This Document......................4 2. The General TRILL Frame Format..........................5 2.1 The General TRILL Frame Format.........................5 2.2 Ethernet Link TRILL Data Frame General Encapsulation...6 3. Compact Format for Point-to-Point Ethernet Links........8 3.1 Conditions for Using Compact Format....................8 3.2 RBridge Originated and Terminated Native Frames.......10 3.3 Compact TRILL Data Reception and Transmission.........10 3.3.1 Compact TRILL Data Frame Reception..................10 3.3.2 Compact TRILL Data Frame Transmission...............12 3.4 Announcing Support for Compact Format.................12 4. Specific Addressing....................................13 4.1 Current Multi-Destination Addressing..................13 4.2 Specific Addressing Specification.....................13 4.3 Announcing Support for Specific Addressing............13 5. Interaction Between The Optimizations..................15 6. IANA Considerations....................................16 7. Security Considerations................................17 7.1 Compact Format Security Considerations................17 7.2 Specific Addressing Security Considerations...........17 7.3 Results of Frame Misinterpretation....................17 8. References.............................................18 8.1 Normative References..................................18 8.2 Informative References................................18 R. Perlman, et al [Page 2] INTERNET-DRAFT TRILL: Link Data Optimizations 1. Introduction RBridges (Routing Bridges) are devices that support the IETF TRILL (TRansparent Interconnection of Lots of Links) protocol [RFC6325] [RFC6327] [ClearCorrect]. They provide transparent forwarding of frames in multi-hop networks with arbitrary topology using least cost paths for unicast traffic and support VLANs (Virtual Local Area Networks) and the multipathing of both unicast and multi-destination traffic. They accomplish this by use of encapsulation with a hop count and IS-IS (Intermediate System to Intermediate System) link state routing [IS-IS] [RFC1195] [RFC6326bis]. A link between two RBridges in an RBridge campus can be any of a variety of technologies, ranging from a complex bridged LAN to PPP [RFC6361]. In the general case under the current TRILL standard, a TRILL Data frame consists of an inner payload formatted as an Ethernet frame, preceded by a TRILL Header, and then encapsulated by a link envelope as appropriate for the link technology. 1.1 Structure of This Document Section 2 discusses General Format TRILL Data frames without the enhancements specified in this document. In the case where the link is a point-to-point Ethernet link, an optional Compact Format is possible for TRILL Data frames that saves 16 bytes. Section 3 specifies that format, its processing, and the conditions for its safe use. In the case where a multi-destination TRILL Data frame is being forwarded over a multi-access link but there is only one (or perhaps a few) next hop RBridges of interest, optional Specific Addressing allows the TRILL Data frame to be link unicast. This can substantially reduce the burden that frame represents if, for example, the link is a bridged LAN through which the frame might otherwise be flooded. Section 4 specifies the Specific Addressing enhancement and the conditions for its safe use. Section 5 discusses potential interaction between these two enhancements. The remaining Sections after Section 5 provide IANA and Security Considerations, References, and the like. This document updates [RFC6325]. R. Perlman, et al [Page 3] INTERNET-DRAFT TRILL: Link Data Optimizations 1.2 Terminology Used in This Document Familiarity with [RFC6325] is assumed in this document. The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. In particular, the terms "campus", "native frame", "link", etc., are as defined [RFC6325]. "Point-to-point", as used herein, means a link which appears to be an isolated channel between exactly two RBridge ports. Such a link may not include customer bridges but may include hubs/repeaters, Two Port MAC Relays, Provider Bridges, Provider Back Bone Bridges [802.1Q], or other technology, provided that technology is configured to provide a transparent point-to-point path between the end point RBridge ports. References herein to "VLAN Tag" or the like are to customer VLANs (C- Tags, Ethertype 0x8100). Use of S-Tags, also known as Service Tags, or stacked VLAN or other tags is beyond the scope of this document but is an obvious extension of TRILL. 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]. R. Perlman, et al [Page 4] INTERNET-DRAFT TRILL: Link Data Optimizations 2. The General TRILL Frame Format The subsections below provide a description of the general format of TRILL Data frames. It then narrows in to describe the format of TRILL Data frames on Ethernet links. 2.1 The General TRILL Frame Format The general "on-the-wire" form of TRILL frames is illustrated below. The Link Headers and Trailers in the formats below depend on the specific link technology. The Link Header contains one or more fields that distinguish TRILL Data from TRILL IS-IS. For example, over Ethernet, the TRILL Data Link Header includes and ends with the TRILL Ethertype while the TRILL IS-IS frame Link Header includes and ends with the L2-IS-IS Ethertype; on the other hand, over PPP, there are no Ethertypes but PPP protocol codes perform that function [RFC6361]. A TRILL Data frame in transit between two neighboring RBridges is as shown below: +---------------+----------+----------------+---------------+ | TRILL Data | TRILL | Payload | TRILL Data | | Link Header | Header | Native Frame | Link Trailer | +---------------+----------+----------------+---------------+ Figure 1. Format of TRILL Data Frames In the above diagram, the Payload Native Frame is in Ethernet frame format with a VLAN tag but with no trailing Frame Check Sequence (FCS). The payload frame format is shown below, assuming the payload starts with an Ethertype (it might alternatively be LLC [802-2001] encoded or some other format): +-----------+------------+------+-----------+------------ | MAC Dest. | MAC Source | VLAN | Content | Content ... | Address | Address | Tag | Ethertype | ... +-----------+------------+------+-----------+------------ Figure 2. Format of the Payload Native Frame The encapsulated payload has the following fields in sequence: o A 6-byte destination MAC address (Inner.MacDA) o A 6-byte source MAC address (Inner.MacSA) o An Inner.VLAN tag giving the VLAN ID, Priority, and DEI (Drop R. Perlman, et al [Page 5] INTERNET-DRAFT TRILL: Link Data Optimizations Eligibility Indicator) [ClearCorrect] of the payload (use of an S- tag or stacked tags is beyond the scope of this document but is an obvious extension) o The payload frame's content (which usually starts with an Ethertype, such as the Ethertype for IPv4 or IPv6) TRILL IS-IS frames are also sent between neighboring RBridges and must be distinguished from TRILL Data frames. TRILL IS-IS frames are formatted as follows and cannot use the Compact Format specified herein: +--------------+---------------+--------------+ | TRILL IS-IS | TRILL IS-IS | TRILL IS-IS | | Link Header | Payload | Link Trailer | +--------------+---------------+--------------+ Figure 3. TRILL IS-IS Frame 2.2 Ethernet Link TRILL Data Frame General Encapsulation If the link between neighbor RBridges is Ethernet, then the general TRILL Data frame format has the following link encapsulation: Link Header: a 6-byte outer MAC destination address (Outer.MacDA) followed by a 6-byte outer MAC source address (Outer.MacSA) followed by an optional 4-byte outer VLAN tag Ethertype and value (Outer.VLAN), and finally the 2-byte TRILL Ethertype (0x22F3). Additional tags could be included based on Layer 2 Ethernet functions such a MACSEC [802.1AE]. Under the TRILL standard before this document, the Outer.MacDA was required to be the unicast MAC address of the destination RBridge port if the TRILL Data frame was a unicast frame to a known destination and was required to be the All-RBridges multicast address if it was a multi-destination frame. +-----------+------------+- - - - - +-----------+ | MAC Dest. | MAC Source | VLAN Tag | TRILL | | Address | Address | if Req. | Ethertype | +-----------+------------+ - - - - -+-----------+ Figure 4. TRILL Data Link Header on an Ethernet Link Link Trailer: the 32-bit IEEE [802.3] Frame Check Sequence (FCS). R. Perlman, et al [Page 6] INTERNET-DRAFT TRILL: Link Data Optimizations In the General Format for Ethernet links, the Outer.VLAN can be omitted when it is not required by VLAN sensitive equipment in the link. R. Perlman, et al [Page 7] INTERNET-DRAFT TRILL: Link Data Optimizations 3. Compact Format for Point-to-Point Ethernet Links TRILL Data frames may optionally be sent using a Compact Format if the link is a point-to-point Ethernet link, Compact Format is enabled by both RBridges on the link, and other conditions met as listed below. 16 bytes can be saved per frame as a result. The Compact Format is simple: the Outer.MacDA, Outer.MacSA, and Outer.VLAN are replaced by the Inner.MacDA, Inner.MacSA, and Inner.VLAN and the Inner fields are deleted. This saves 6 + 6 + 4 or 16 bytes. To avoid confusion, Compact Format MUST NOT be used if the Inner.MacDA is a multi-cast address assigned to TRILL (01-80-C2-00-00-40 through 01-80-C2-00-00-4F). Compact Format is not applicable to TRILL IS-IS frames because there is no inner Ethernet header. (And, of course, it has nothing to do with native data or Layer 2 control frames since those frames are not TRILL frames.) +---------------------+--------+-----------+---------+---------+ | Ethernet Header | TRILL | Content | Content | Link | | Header from Payload | Header | Ethertype | ... | Trailer | +---------------------+--------+-----------+---------+---------+ Figure 5. Compact Format TRILL Data Frame Compact Format is generally intended for use on physical point-to- point links between RBridges, a common arrangement in many LANs. However, if there are any transparent provider bridging devices in the point-to-point link, such as Provider Bridges or Provider Backbone Bridges, then the use of the Compact Format will increase the MAC address learning table stress on such Provider Bridges or Provider Edge Back Bone bridges. 3.1 Conditions for Using Compact Format Use of Compact Format is a hop-by-hop decision. In successive RBridge to RBridge hops, a TRILL Data frame might be sent alternately in Compact Format and General Format. There are a number of conditions for using Compact Format TRILL Data frames. Most of these boil down to maximizing the assurance that the RBridge-to-RBridge Ethernet link over which the Compact Format TRILL Data frame is to be sent is really point-to-point. Only the General Format for TRILL Data frames is safe to use on an RBridge Ethernet port that is to a multi-access link even if that port has been configured as point-to-point. The following conditions apply. (See also the frame reception process variations described in Section R. Perlman, et al [Page 8] INTERNET-DRAFT TRILL: Link Data Optimizations 3.3.1.) o The RBridge port over which Compact Format TRILL Data frames are to be sent MUST be configured as a point-to-point Ethernet port (see Section 4.9.1 of [RFC6325]). o The RBridge port through which the Compact Format TRILL Data frame is being transmitted MUST be configured to send VLAN tagged frames. Otherwise the VLAN of the payload may be lost. o The RBridge port at the other end of the point-to-point link MUST be announcing that it supports the Compact Format. See Section 3.4. o Receipt of a native frame indicates that the link is multi-access and has end stations on it. These are frames that are not Layer 2 control frames (see Section 1.4 of [RFC6325]) and have neither an Outer.MacDA in the block assigned to TRILL nor an outer payload EtherType assigned to/for TRILL (currently the TRILL and L2-IS-IS EtherTypes). On receipt of such a frame, the port MUST stop using Compact Format TRILL Data frames for at least ten seconds, unless it is reset by management or rebooted before that. o Receipt of a TRILL IS-IS Hello frame, other than a point-to-point Hello from the RBridge believed to be at the other end of the link, indicates that the link really isn't point-to-point or that the RBridge at the other end of that link is mis-behaving. In either case, the RBridge receiving such an unexpected Hello MUST stop using Compact Format TRILL Data frames on that port for at least twice the holding time in the unexpected Hello but not less than ten seconds, unless it is reset by management or rebooted before that. This is a change to [RFC6325] which states that an RBridge port configured as point-to-point ignores TRILL Hellos. o RBridge Ethernet ports are required to monitor ports for BPDUs received (Section 4.9.3 [RFC6325]). On receipt of a customer bridging BPDU at an RBridge port, the RBridge MUST stop using Compact Format on that port and revert to sending General Format TRILL Data frames for at least four times the Bridge Hello Time in the BPDU, but not less than ten seconds, unless the port or RBridge is reset by management or rebooted before that. o It is RECOMMENDED that RBridge ports intending to use Compact Format also use the Link Layer Discovery Protocol (LLDP) [802.1AB] to provide additional assurance that the link is actually point- to-point. For this use, LLDP should be run to the Nearest Customer Bridge MAC address (01-80-C2-00-00-00). Receipt by an RBridge port supporting LLDP of an LLDP message indicating the presence on the link of a MAC Bridge, Layer 3 Router, or End Station indicates that the link is not point-to-point and the RBridge MUST stop R. Perlman, et al [Page 9] INTERNET-DRAFT TRILL: Link Data Optimizations using Compact Format on the port for at least twice the TTL in the received LLDP frame but not less than ten second, unless the port or RBridge is reset by management or rebooted before that. 3.2 RBridge Originated and Terminated Native Frames There can be native frames originated by or intended for consumption by an RBridge. Examples include SNMP over IP frames or RBridge Channel frames [RFCchannel]. In many cases, such internal sinks and sources of native frames are treated as a virtual end-station internally attached to the RBridge. Such frames are converted to TRILL Data frames before being transmitted outside the originating RBridge. Because of the way that Compact Format TRILL Data frames are recognized, particularly the change in [RFC6325], Section 4.6.2, Point 3, made by Section 3.3.1 of this document, an RBridge MUST use a MAC address different from the address of any of its ports as the Inner.MacSA of frames it locally originates and as the Inner.MacDA it expects to see in unicast TRILL Data frames that it receives and decapsulates for locally processing. 3.3 Compact TRILL Data Reception and Transmission If an RBridge's Ethernet port has Compact Format enabled, frame reception and transmission are modified as described below. Section 4.6 of the TRILL base protocol standard [RFC6325] provides a specification of the processing of all possible types of received frames. There is no change in the definition of TRILL frames as specified in [RFC6325] Section 1.4, that is, TRILL frames are any frame starting with the TRILL or L2-IS-IS Ethertype or that has an Outer.MacDA that is any of the block of 16 multicast addresses assigned to TRILL ([RFC6325] Section 7.2). 3.3.1 Compact TRILL Data Frame Reception Section 4.6.2 of [RFC6325] specifies the processing of received TRILL frames. A complete replacement for Section 4.6.2 of [RFC6325] that supports Compact Format and incorporates the correction in Section 5.1.2 of [ClearCorrect] is provided in the quoted text below. Even when Compact Format is enabled, the sender is not required to compact all or any TRILL Data frames and a receiver MUST be prepared R. Perlman, et al [Page 10] INTERNET-DRAFT TRILL: Link Data Optimizations for an arbitrary mix of Compact Format and General Format TRILL Data frames arriving on a point-to-point link. NOTE: All of the Section references in the quoted text below are references to Sections in [RFC6325]. "A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a multicast Outer.MacDA allocated to TRILL (see Section 7.2). The following tests are performed sequentially, and the first that matches controls the handling of the frame:" "By default a frame is classified as General Format." "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All-IS-IS-RBridges or the unicast MAC address of the receiving RBridge port, the frame is handled as described in Section 4.6.2.1 on TRILL Control frames." "2. If the Outer.MacDA is a multicast address allocated to TRILL other than All-RBridges then the frame is discarded." "3. If the Outer.MacDA is a unicast address other than the address of the receiving Rbridge then (3a) if Compact Format TRILL Data frames are disabled, the frame is discarded or (3b) if Compact Format TRILL Data frames are enabled, the frame is classified as compact." "4. If the Ethertype is not TRILL, the frame is discarded." "5. If the Version field in the TRILL Header is greater than 0, the frame is discarded." "6. If the hop count is 0, the frame is discarded." "7. If the Outer.MacDA is multicast and the M bit is zero the frame is discarded. If the Outer.MacDA is unicast and M bit is one processing continues if Specific Addressing is enabled. If Specific Addressing is not enabled, the frame is discarded." "8. If the frame has been classified as Compact Format, skip the rest of this rule and go to Rule 9. By default, an RBridge MUST discard General Format TRILL Data frames from a Outer.MacSA that is not an adjacency on the port where the frame was received. RBridges MAY be configured per port to accept such frames in cases where it is known that a non- peering device (such as an end-station) is configured to originate general TRILL encapsulated data frames that can be safely accepted." R. Perlman, et al [Page 11] INTERNET-DRAFT TRILL: Link Data Optimizations "9. If a frame has been classified as a Compact Format TRILL Data frame but it was received untagged, that is, without an Outer.VLAN, discard the frame." "10. For all subsequent processing, including Rule 11, if the frame has been classified as Compact Format, all references to Inner.MacDA, Inner.MacSA, or Inner.VLAN are to be understood to actually refer to the Outer.MacDA, Outer.MacSA, and Outer.VLAN as the frame was received." "11. The Inner.MacDA is then tested. If it is the All-Egress- Rbridges (also known as All-ESADI-RBridges) multicast address and RBn implements the ESADI protocol, processing proceeds as in Section 4.6.2.2 for TRILL ESADI frames. If it is any other address or RBn does not implement ESADI, processing proceeds as in Section 4.6.2.3 for TRILL Data frames." 3.3.2 Compact TRILL Data Frame Transmission When a TRILL Data frame is being transmitted out an RBridge port, if the conditions listed in Section 3 above are met, the frame MAY be sent in Compact Format. 3.4 Announcing Support for Compact Format The Compact Format option is a hop-by-hop optional Ethernet link TRILL frame format and it is possible that an RBridge would support it on some ports and not others. Therefore, if Compact Format is enabled at a port, this is indicated in every Hello (Section 6) it sends out that port. R. Perlman, et al [Page 12] INTERNET-DRAFT TRILL: Link Data Optimizations 4. Specific Addressing Specific addressing optionally enables more efficient use of some types of multi-access links. 4.1 Current Multi-Destination Addressing When multiple RBridges are connected to an Ethernet link, the base TRILL protocol standard [RFC6325] requires that multi-destination TRILL Data frames be sent on the Ethernet link addressed to the All- RBridges multicast address. If the link is a multi-access link, such as a large bridged LAN, use of a multicast address may impose a significant burden, causing the frame to be flooded throughout the bridged LAN. In addition, every RBridge attached to the bridged LAN may received the frame using up some of their input bandwidth. Those RBridges that are not the next hop on the frame's distribution tree will discard the frame due to the Reverse Path Forwarding Check. 4.2 Specific Addressing Specification Multi-destination TRILL Data frames are sent on the distribution tree identified in the TRILL Header subject to optional pruning. The transmitting RBridge thus knows which next hop RBridge or RBridges on the link it needs to get the frame to. If the next hop RBridges on the multi-access link and the transmitting RBridge all have Specific Addressing enabled, then the frame MAY be link unicast to the next hop RBridge or RBridges. Use of Specific Addressing is a hop-by-hop optional decision. Successive TRILL Data frames received by an RBridge, even from the same sending RBridge on the same distribution tree, may be specifically (unicast) or multicast addressed. (The same frame is never sent both ways.) In successive RBridge to RBridge hops, a multi-destination TRILL Data frame might be sent alternately in specifically addressed and multicast addressed form. 4.3 Announcing Support for Specific Addressing The Specific Addressing option is a hop-by-hop optional format. It is possible that an RBridge would support it on some ports and not others. Therefore enablement of this option is indicated in every R. Perlman, et al [Page 13] INTERNET-DRAFT TRILL: Link Data Optimizations TRILL Hello (see Section 6) sent on the port. R. Perlman, et al [Page 14] INTERNET-DRAFT TRILL: Link Data Optimizations 5. Interaction Between The Optimizations Compact Format can only be used for TRILL Data frames on Ethernet links that are point-to-point. Compact Format works under the conditions specified above regardless of whether the frame is TRILL unicast (M=0) or TRILL multi-destination (M=1). It sets the Outer.MacDA, Outer.MacSA, and Outer.VLAN to the corresponding Inner fields and removes the Inner fields. Specific Addressing is only beneficial for frames that are TRILL multi-destination Data frames on multi-access links. Specific Addressing causes the frame to be link unicast by setting the Outer.MacDA to the unicast address of a next hop RBridge. Both optimizations change the Outer.MacDA from its value in the base TRILL protocol and thus they conflict. Specific Addressing MUST be suppressed on point-to-point Ethernet links. R. Perlman, et al [Page 15] INTERNET-DRAFT TRILL: Link Data Optimizations 6. IANA Considerations IANA is requested to allocate two capability bits in the TRILL-PORT- VER sub-TLV [RFC6326bis] as follows: Bit Description Reference ====== ============================== ================= tbd1 Compact Ethernet enabled. (This document) tbd2 Specific addressing enabled. (This document) R. Perlman, et al [Page 16] INTERNET-DRAFT TRILL: Link Data Optimizations 7. Security Considerations For general TRILL protocol security considerations, see [RFC6325]. See other security considerations below. 7.1 Compact Format Security Considerations An RBridge conformant to the TRILL standard that has Compact Format TRILL Data not implemented or not enabled on a port will, as part of its normal procedures, discard any Compact Format TRILL Data frame it receives on that port because the EtherType of the frame would be TRILL but (1) if the Compact Format resulted in a unicast Outer.MacDA, it would not be the address of the receiving RBridge port, and (2) if the Compact Format resulted in a multicast or broadcast Outer.MacDA, it would not be the All-RBridges multicast address. If the RBridge port failed to discard the frame and erroneously handled it as being in General Format, bad things will usually happen as described in Section 7.3. With a General Format TRILL Data frame, the VLAN of the data in somewhat protected in the Inner.VLAN field. With Compact Format, it is put in more exposed Outer.VLAN field. If it is stripped and the frame arrives untagged, the rules in this document require that it be discarded to avoid changing the VLAN labeling of the frame to the default of the receiving RBridge port. 7.2 Specific Addressing Security Considerations It is important not to apply both Compact Format optimization and Specific Addressing optimization to the same frame or else the frame may be misinterpreted as described in Section 7.3. 7.3 Results of Frame Misinterpretation For frames that are misinterpreted due to circumstances described in Sections 7.1 and 7.2, the first six bytes of the native frame content will be treated as the Inner.MacDA, the next six bytes of that oontnt as the Inner.MacSA, and the next four bytes as the Inner.VLAN. If the Ethertype or the Inner.VLAN is not checked or some of the payload data accidentally has the value of a VLAN tag Ethertype, the payload may be delivered in the wrong VLAN violating security policy. For this reason, the provisions of Sections 3 of this document should be scrupulously enforced. R. Perlman, et al [Page 17] INTERNET-DRAFT TRILL: Link Data Optimizations 8. References Normative and informative references for this document are given below. 8.1 Normative References [802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area networks / Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2009, 17 September 2009. [802.1Q] - IEEE, "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, May 2011. [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. [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis- rfc6326bis, work in progress. [ClearCorrect] - draft-eastlake-trill-rbridge-clear-correct, work in progress. 8.2 Informative References [802-2001] - IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks / Overview and Architecture", 802-2001, 6 December 2001. [802.1AE] - IEEE 802, "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006. R. Perlman, et al [Page 18] INTERNET-DRAFT TRILL: Link Data Optimizations [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-2008, 26 December 2008. [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011. [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011. [RFCchannel] - Eastlake, D., V. Manral, L. Yizhou, S. Aldrin, D. Ward, "RBridges: TRILL RBridge Channel Support", draft-ietf- trill-rbridge-channel, work in progress. R. Perlman, et al [Page 19] INTERNET-DRAFT TRILL: Link Data Optimizations Authors' Addresses Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549, USA Phone: +1-408-765-8080 Email: Radia@alum.mit.edu Donald E. Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757, USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012, China Phone: +86-25-56622310 Email: liyizhou@huawei.com Anoop Ghanwani Dell 350 Holger Way San Jose, CA 95134 USA Phone: +1-408-571-3500 Email: anoop@alumni.duke.edu R. Perlman, et al [Page 20] INTERNET-DRAFT TRILL: Link Data Optimizations Copyright and 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. R. Perlman, et al [Page 21]