RBridges: TRILL Link Data Optimizations
draft-perlman-trill-rbridge-data-encoding-08

TRILL Working Group                                        Radia Perlman
INTERNET-DRAFT                                                Intel Labs
Updates: RFCtrill                                        Donald Eastlake
Intended status: Proposed Standard                             Yizhou Li
                                                                  Huawei
                                                          Anoop Ghanwani
                                                                 Brocade
Expires: January 1, 2012                                    July 2, 2011


              RBridges: TRILL Data Encoding Optimizations
           <draft-perlman-trill-rbridge-data-encoding-00.txt>


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. TRILL is implemented
   by devices called RBridges (Routing Bridges) that implement the IETF
   TRILL standard.

   This document specifies two such optional optimizations.  One, called
   Compact Format, improves the compactness of encoding in the case
   where the link between two RBridges is a point-to-point Ethernet
   link.  The other, called Specific Addressing, optionally decreases
   the burden on multi-access links between RBridges, such as links
   consisting of a complex bridged LAN, when forwarding multi-
   destination TRILL Data frames and there is only one or a few next hop
   RBridges of interest.


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 <rbridge@postel.org>.

   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



R. Perlman, et al                                               [Page 1]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


















































R. Perlman, et al                                               [Page 2]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


Table of Contents

      1. Introduction............................................4
      1.1 Structure of This Document.............................4
      1.2 Terminology Used in This Document......................5

      2. The General TRILL Frame Format..........................6
      2.1 The General TRILL Frame Format.........................6
      2.2 Ethernet Link TRILL Data Frame General Encapsulation...7

      3. Compact Format for Point-to-Point Ethernet Links........9
      3.1 Conditions for Using Compact Format....................9
      3.2 Locally Originated and Terminated Native Frames.......10

      3.3 Compact TRILL Data Reception and Transmission.........12
      3.3.1 Compact TRILL Data Frame Reception..................12
      3.3.2 Compact TRILL Data Frame Transmission...............13
      3.4 Advertising Support for Compact Format................14

      4. Specific Addressing....................................15
      4.1 Current Multi-Destination Addressing..................15
      4.2 Specific Addressing Specification.....................15
      4.3 Advertising Support for Specific Addressing...........15

      5. Interaction Between The Optimizations..................17

      6. IANA Considerations....................................18
      7. Security Considerations................................18
      7.1 Compact Format Security Considerations................18
      7.2 Specific Addressing Security Considerations...........18

      8. References.............................................19
      8.1 Normative References..................................19
      8.2 Informative References................................19


















R. Perlman, et al                                               [Page 3]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


1. Introduction

   RBridges (Routing Bridges) are devices that support the IETF TRILL
   (TRansparent Interconnection of Lots of Links) standard [RFCtrill]
   [RFCtisis]. 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].

   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
   [RFCtppp]. In the general case under the current TRILL standard, a
   TRILL Data frame consists of an inner encapsulated frame 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 specified 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 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.







R. Perlman, et al                                               [Page 4]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


1.2 Terminology Used in This Document

   Familiarity with [RFCtrill] is assumed in this document. The
   terminology and acronyms defined in [RFCtrill] are used herein with
   the same meaning. In particular, the terms "campus", "native" frame,
   link, etc., are as defined [RFCtrill].

   "Point-to-point", as used herein, means a link which appears to be a
   single isolated channel between exactly two RBridge ports. Such a
   link may not include customer bridges but may include 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 tunnel 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 5]


INTERNET-DRAFT                         TRILL Data Encoding 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 usually 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 [RFCtppp].

   A TRILL Data frame in transit between two neighboring RBridges is as
   shown below:

       +---------------+----------+----------------+---------------+
       | TRILL Data    |  TRILL   |  Encapsulated  | TRILL Data    |
       | Link  Header  |  Header  |  Native Frame  | Link Trailer  |
       +---------------+----------+----------------+---------------+

                   Figure 1. Format of TRILL Data Frames

   In the above diagram, the Encapsulated Native Frame is in Ethernet
   frame format with a VLAN tag but with no trailing Frame Check
   Sequence (FCS). The encapsulated 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 | Payload   | Payload ...
         |   Address |    Address | Tag  | Ethertype |         ...
         +-----------+------------+------+-----------+------------

             Figure 2. Format of the Encapsulated Native Frame

   The encapsulated frame has the following fields in sequence:

   o  A 6-byte destination MAC address (Inner.MacDA)

   o  A 6-byte source MAC address (Inner.MacSA)



R. Perlman, et al                                               [Page 6]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


   o  An Inner.VLAN tag giving the VLAN ID and Priority of the payload
      (use of stacked tags is beyond the scope of this document but is
      an obvious extension)

   o  The encapsulated frame's payload (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, if required, by a 4-byte outer VLAN tag Ethertype and
         value (Outer.VLAN), and finally the 2-byte TRILL Ethertype
         (0x22F3).

         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 the Outer.MacDA 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).

   In the General Format for Ethernet links, the Outer.VLAN can be
   omitted when it is not required by VLAN sensitive equipment in the


R. Perlman, et al                                               [Page 7]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


   link.



















































R. Perlman, et al                                               [Page 8]


INTERNET-DRAFT                         TRILL Data Encoding 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 and Compact Format is
   supported by both RBridges on the link. 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 frames or Layer 2 control frames.)

     +---------------------+--------+-----------+---------+---------+
     | Ethernet Header     | TRILL  | Payload   | Payload | Link    |
     | Header from Payload | Header | Ethertype | ...     | Trailer |
     +---------------------+--------+-----------+---------+---------+

                 Figure 5. Compact Format TRILL Data Frame

   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 edge Provider 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 encapsulation for TRILL Data frames is safe to use for an
   RBridge that is misconfigured to believe a port is connected to a
   point-to-point link when the link really isn't point-to-point.)  The
   following conditions apply. See also the frame reception process
   variations described in Section 3.3.1.

   o  The RBridge port over which Compact Format TRILL Data frames are


R. Perlman, et al                                               [Page 9]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


      to be sent MUST be configured as a point-to-point.

   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 at the other end of the point-to-point link MUST have
      advertised that it supports the Compact Format. See Section 3.4.

   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 [RFCtrill] which states that an
      RBridge port configured as point-to-point ignores TRILL Hellos.

   o  RBridges are required to monitor ports for BPDUs received. 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 five 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 RBridges 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 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 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 Locally 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.

   Because of the way that Compact Format TRILL Data frames are


R. Perlman, et al                                              [Page 10]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


   recognized, particularly the change in [RFCtrill], 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.














































R. Perlman, et al                                              [Page 11]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


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 [RFCtrill] 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 [RFCtrill] 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 ([RFCtrill] Section 7.2).



3.3.1 Compact TRILL Data Frame Reception

   Section 4.6.2 of [RFCtrill] specifies the processing of received
   TRILL frames. A complete replacement for Section 4.6.2 of [RFCtrill]
   that supports Compact Format 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
   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 [RFCtrill].

      "A TRILL frame has either the TRILL or L2-IS-IS Ethertype or has a
      multicast Outer.MacDA allocated to TRILL (see Section 7.2). The
      following rules are applied sequentially to TRILL frames. Each
      rule which matches is applied except for those rules after the
      first matching rule that either directs you to discard the frame
      or directs you to transfer to another Section. If the rules says
      'discard with error', then an error frame SHOULD be generated as
      specified in [TRILLoam]."

      "By default a frame is classified as General Format."

       "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is All-IS-
          IS-RBridges, 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)


R. Perlman, et al                                              [Page 12]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


          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 with error."

       "6. If the hop count is 0 , the frame is discarded with error."

       "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
          implemented and enabled. If Specific Addressing is either not
          implemented or 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."

       "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-ESADI-
          RBridges / All-Egress-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
   all of the conditions listed in Section 3 above are met, the frame
   MAY be sent in Compact Format.


R. Perlman, et al                                              [Page 13]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


3.4 Advertising Support for Compact Format

   The Compact Format option is a hop-by-hop optional format and it is
   possible that an RBridge would support it on some ports and not
   others. Therefore support or lack thereof is indicated in every Hello
   (Section 6) it sends on each port.














































R. Perlman, et al                                              [Page 14]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


4. Specific Addressing

   Specific addressing, as described below, 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 [RFCtrill] 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 is 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. 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 implemented and
   enabled, then the frame MAY be link unicast to the next hop RBridge
   or serially unicast to the next hop 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 Advertising 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


R. Perlman, et al                                              [Page 15]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


   others. Therefore support or lack thereof is indicated in every Hello
   (see Section 6) it sends on each port. Support implies that the
   option is both implemented and enabled.

















































R. Perlman, et al                                              [Page 16]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


5. Interaction Between The Optimizations

   Compact Format can only used on 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 can only be used for frames that are TRILL multi-
   destination. It causes the frame to be link unicast by setting the
   Outer.MacDA to the unicast address of a next hop RBridge. Since
   Specific Addressing does not result in any gain on a point-to-point
   link, there will probably be few cases in which both optimizations
   are applicable.

   Since both optimization set the Outer.MacDA, they is a potential
   conflict. Either Specific Addressing should be suppressed when
   Compact Format is used or Specific Addressing should be performed
   first. If a frame was transformed for Compact Format and then
   Specific Addressing was applied, the original MAC destination address
   would be overwritten and lost and the frame would be misinterpreted
   by the next hop RBridge.





























R. Perlman, et al                                              [Page 17]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


6. IANA Considerations

   TBD



7. Security Considerations

   For general TRILL protocol security considerations, see [RFCtrill].



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.  If it failed to discard the frame and
   erroneously handled it as being in General Format, bad things will
   usually happen. The first six bytes of the encapsulated native frame
   payload will be treated as the Inner.MacDA, the next six bytes of
   that payload 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 and
   6.1 of this document should be scrupulously enforced.



7.2 Specific Addressing Security Considerations

   As described in Section 5, it is important not to apply the Compact
   Format optimization and then the Specific Addressing optimization or
   else the frame will be misinterpreted as described in Section 7.1 for
   an RBridge that mistakenly accepts a Compact Format frame even though
   it does not implement Compact Format.















R. Perlman, et al                                              [Page 18]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


8. References

   Normative and informative references for this document are given
   below.



8.1 Normative References

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

   [RFCtisis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A.
         Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill, in RFC
         Editor's queue.

   [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
         Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
         trill-rbridge-protocol-16.txt, in RFC Editor's queue.



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.1AB] - IEEE 802.1, "IEEE Standard for Local and metropolitan
         area networks / Station and Media Access Control Connectivity
         Discovery", 802.1AB-2009, 17 September 2009.

   [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
         networks / Virtual Bridged Local Area Networks", 802.1Q-2011,
         May 2011.

   [802.3] - IEEE 802.3, "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",
         802.3-2008, 26 December 2008.


R. Perlman, et al                                              [Page 19]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


   [RFCtppp] - Carlson, J., and D. Eastlake, "PPP TRILL Protocol Control
         Protocol", draft-ietf-pppext-trill-protocol-08.txt, in RFC
         Editor's queue.

   [RFCchannel] - Eastlake, D., V. Manral, L. Yizhou, S. Aldrin, D.
         Ward, "RBridges: TRILL RBridge Channel Support", draft-ietf-
         trill-rbridge-channel-01.txt, work in progress.













































R. Perlman, et al                                              [Page 20]


INTERNET-DRAFT                         TRILL Data Encoding 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 Technologies
   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
   Brocade Communications Systems
   130 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-333-7149
   Email: anoop@brocade.com
















R. Perlman, et al                                              [Page 21]


INTERNET-DRAFT                         TRILL Data Encoding Optimizations


Copyright and IPR Provisions

   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.  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 22]