[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
TRILL Working Group                                  Donald Eastlake 3rd
INTERNET-DRAFT                                                  Motorola
Expires: August 2007                                       February 2007



               Interaction of RBridges and 802 Protocols
               ----------- -- -------- --- --- ---------
              <draft-eastlake-trill-802-protocols-00.txt>


Status of This Document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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


Abstract

   This is a working document discussing the relationship of RBridges,
   that is, devices implementing the protocol being developed by the
   IETF TRILL working group, and various IEEE 802.1 amd 802.3 protocols.












Donald Eastlake 3rd                                             [Page 1]


INTERNET-DRAFT                                  RBridges & 802 Protocols


Table of Contents

      Status of This Document....................................1
      Abstract...................................................1

      Table of Contents..........................................2

      1. Introduction............................................3
      1.1 802 Document Designation Conventions...................3
      1.2 IEEE 802 Standards Prcoess.............................3

      2. IEEE 802.1 Protocols....................................6
      2.1 802.1D MAC Bridges.....................................6
      2.2 802.1Q Virtual Bridged Local Area Networks.............6
      2.2.1 802.1ad Provder Bridges..............................6
      2.2.2 802.1ag Connectivity Fault Management................7
      2.2.3 802.1ah Provder Backbone Bridges.....................7
      2.2.5 802.1au Congestion Management........................7
      2.3 802.1X Port Based Network Access Control...............8
      2.3.1 802.1af Authenticated Key Agreeement.................8
      2.4 802.1AB Connectivity Discovery.........................8
      2.5 802.1AE MAC Security...................................9

      3. IEEE 802.3 Protocols...................................10
      3.1 802.3as...............................................10

      4. Multicast Addresses....................................12

      5. IANA Considerations....................................13
      6. Security Considerations................................13
      7. References.............................................13
      7.1 Normative References..................................13
      7.2 Informative References................................13

      Copyright, Disclaimer, and Additional IPR Provisions......15

      Author's Address..........................................16
      Expiration and File Name..................................16














Donald Eastlake 3rd                                             [Page 2]


INTERNET-DRAFT                                  RBridges & 802 Protocols


1. Introduction

   The IETF TRILL Working Group is developing the protocol for RBridges.
   RBridges are somewhere between being routers and being bridges.
   Simplifying a lot, RBridges are like Bridges in that they act
   transparently, form a broadcast domain, and forward primarily based
   on layer 2 MAC addresses. But they are like routers in that they swap
   the outer MAC addresses on each RBridge hop, incorporate a hop count,
   use a link state algorithm traditionally associated with routing, and
   deal with some layer 3 issues such as optimizing IP multicast and
   ARP/ND.

   The purpose of this document is to briefly survey the relationship of
   RBridges to some of the myriad 802.1 and 802.3 standards, amendments
   to those stardards, and work in progress to amend those standards
   which might be relevant. In its present form, it is only intended for
   interal use in the TRILL Working Group. However, it is possible that
   some material in this document could end up being appended to the
   RBridges protocol specification and/or some later version of this
   document might be published as an informational RFC.

   Comments and suggests for improvement are welcome



1.1 802 Document Designation Conventions

   IEEE 802 document designations ending with an upper case letter or
   letters, such as 802.1D, are stand alone standards. Those ending with
   a lower case letter or letters, such ad 802.1ad, are admendments
   which are intended to be incorporated into a later rollup of the base
   standard document they amend.  If a hyphen and a year are appended to
   a document, such as 802.1D-2004, it indicates an adopted standard
   whose final approval occured in the year given.



1.2 IEEE 802 Standards Prcoess

   Below is a high level description of the IEEE 802 standards process
   intended to make comments on the standards status of particular 802
   efforts more understandable from an IETF perspective. Some details
   and possible branches are omitted.

   The first official stage is when a PAR and 5 Criterion document are
   drafted and approved by an 802 working group, such as 802.1. A PAR,
   or Project Authorization Request, is similar to a Charter and the 5
   Criterion is a document justifying the need for and reasonableness of
   expecting success for the effort. In some cases a Study Group,
   somewhat akin to a BoF, is formed to explore the topic and draft the


Donald Eastlake 3rd                                             [Page 3]


INTERNET-DRAFT                                  RBridges & 802 Protocols


   PAR and 5 Criterion if the Study Group believes an effort should be
   chartered.

   These documents must then be approved by the 802 Executive Committee.

   After that the PAR only goes up to the New Standards Committee
   (NESCOM) of the IEEE Standards Board and after NESCOM approval the
   PAR must finally be approved by the entire Standards Board (which
   normally meets the day after NESCOM meetings).

   With an approved PAR, similar to an approved working group Charter in
   the IETF, the 802 working group holding the PAR can proceed with the
   work itself but, in 802.1 and 802.3, it usually creates a subsidiary
   Task Group for the PAR or assignes it to an existing Task Group such
   as the Interworking Task Group in 802.1 that handles bridging.

   The body working on the PAR comes up with a Draft, initially version
   0.01, perhaps equivalent to a -00 protocol draft in the IETF. It
   ususally continues to work on the this Draft through multiple
   resivions (0.02, 0.03, ...) until it believes it is ready for Working
   Group Letter Ballot at which point the latest draft is re-numbered
   1.0.

   A Letter Ballot is its own process which involves the members of the
   ballot pool submitting yes, no, or abstain votes.  At least 50% of
   the pool must vote yes or no and 75% of those voting yes or no must
   vote yes to pass Letter Ballot.  Votes can be accompanied by comments
   and all valid no votes must be accompanied by comments including a
   description of what change would satisfy the commenter.

   If a Draft fails Letter Ballot, the group works on it some more until
   it again thinks it is ready and then reballots it with the next
   highest integer version number. Thus, if you see, say, as draft D3.5
   you know it has gone through 3 Letter Ballots, the most recent on
   D3.0, and been modified 5 times since that Letter Ballot, but you
   don't know if it passed any of these Letter Ballots.

   But getting 75% in a letter ballot is not the end of the story. All
   comments that were submitted with no votes then must be resolved
   (rejected, accepted, or accepted but with a counter proposal for a
   satisfying change in the draft) by a 3/4 vote. And when all comments
   have been resolved, the draft is "recirculated" to the same voting
   pool. This iterates until certain criterion are met and working group
   votes to advance to the next step. This does not usually occur until
   recirculation approval is over 95%.

   After getting through Working Group Letter Ballot, the draft then
   advances to "Sponsor" Letter Ballot where the balloting pool is a
   group selected by the IEEE to balance the constituencies of interest
   in the standard. The whole Letter Ballot process then repeats for


Donald Eastlake 3rd                                             [Page 4]


INTERNET-DRAFT                                  RBridges & 802 Protocols


   this new pool, although the draft numbers don't reset but just keep
   going up.

   Finally, when the standard meets sufficinet criteria in Sponsor
   Letter Ballot, it is forwarded for approval to the Standards Revision
   Committee (REVCOM) of the Standards Board and then to the whole
   Standards Board.













































Donald Eastlake 3rd                                             [Page 5]


INTERNET-DRAFT                                  RBridges & 802 Protocols


2. IEEE 802.1 Protocols

   802.1 stand alone protocols are listed as second level headings below
   and amendments to those standards appear as third level headings. in
   each case, they are ordered by standards labeling order (A to Z then
   AA, AB, ...).

   Note: 802-2001 ("IEEE Standard for Local and Metropolitan Area
   Networks: Overview and Architecture") and its two adopted amendments,
   802a-2003 and 802b-2004, define the basic 48 bit address formats,
   OUIs (oprganizationally unique identifiers), Ethertypes, and similar
   basic arichtectural quantities and formats.



2.1 802.1D MAC Bridges

   - "IEEE Standard for Local and metropolitan area networks / Media
   Access Control (MAC) Bridges"

   802.1D-2004 is the basic 802 bridging description and includes
   spanning tree. The Rbridges charter implies that unconfigured (plug-
   and-play) Rbridges provide essentially the same service and that for
   almost all purposes, a network can be converted from 802.1D bridges
   to Rbridges by incremental replacement.

   Of necessity, 802.1D must be fully accounted for in the specification
   of Rbridges.



2.2 802.1Q Virtual Bridged Local Area Networks

   - "IEEE Standard for Local and metropolitan area networks / Virtual
   Bridged Local Area Networks"

   VLANs are added to bridging by 802.1Q-2005. VLAN support is included
   in RBridges.



2.2.1 802.1ad Provder Bridges

   - "IEEE Standard for Local and metropolitan area networks / Virtual
   Bridged Local Area Networks / Amendment 4: Provider Bridges"
   amendment to 802.1Q

   To support arbitrary VLANs in a bridged service provider cloud which
   is providing paths between arbitrary customer clouds, 802.1ad
   provides for provider VLAN tags that have the identical structure to


Donald Eastlake 3rd                                             [Page 6]


INTERNET-DRAFT                                  RBridges & 802 Protocols


   customer VLAN tags but a different Ethertype. Presumably the
   different Ethertype is for robustness or error detection in case of
   misconfiguration or the like.

   This is aimed at solving a problem which is not currently being
   considered in the RBridge specification.



2.2.2 802.1ag Connectivity Fault Management

   - "Draft Standard for Local and Metropolitan Area Networks / Virtual
   Bridged Local Area Networks / Amendment 5: Connectivity Fault
   Management" amendment to 802.1Q

   TBD



2.2.3 802.1ah Provder Backbone Bridges

   - "Draft Standard for Local and Metropolitan Area Networks / Virtual
   Bridged Local Area Networks / Amendment 6: Provider Backbone Bridges"
   amendment to 802.1Q

   The problem with expanding to a two level system with customer and
   provider bridges just using 802.1ad is presumably that the provider
   bridges see too many different customer MAC addresses.  802.1ah
   encapsulates the ultimate MAC addresses so the provider backbone
   bridges only see the MAC addresses of the devices at the border
   between the customer clouds and the provider cloud.

   This is aimed at solving provider services problems which are not
   currently being considered in the RBridge specification.



2.2.5 802.1au Congestion Management

   - "Draft Standard for Local and Metropolitan Area Networks / Virtual
   Bridged Local Area Networks / Amendment 7: Congestion Management"
   amendment to 802.1Q

   The 802.1au draft is in a very early stange (version D0.01,
   equivalent to an IETF -00 draft).

   Congestion Management (BCN, "Backward Congestion Notification") is a
   method of reducing or elminating dropped frames within a subnet of
   bounded delay bandwidth product.  The idea is that 802.1au aware
   devices which experience congestion based on frame queues backing up


Donald Eastlake 3rd                                             [Page 7]


INTERNET-DRAFT                                  RBridges & 802 Protocols


   send messages back to frame sources, generally identified by MAC
   addresses and within MAC address by flow, specifying the maximum rate
   at which that source should trasmit frames.  Future frames, from that
   source, which are tagged to indicate that they conform to such a rate
   limit are given higher priority.

   Bridges have to be congestion aware to support BCN and so would
   Rbridges.  This has been discussed on the TRILL working group mailing
   list and at TRILL meetings.



2.3 802.1X Port Based Network Access Control

   - "IEEE Standard for Local and metropolitan area networks / Virtual
   Bridged Local Area Networks / Amendment 4: Provider Bridges"

   IEEE 802.1X-2004 is a standard for authenticating devices before
   permitting access. It is logically unrelated to bridging but is
   listed here because the 802.1af amendment to 802.1X is relevant to
   802.1AE.



2.3.1 802.1af Authenticated Key Agreeement

   - "Draft Standard for Local and Metropolitan Area NetworksPort-Based
   Network Access Control / Amendment 1: Authenticated Key Agreement for
   Media Access Control (MAC) Security" amendment to 802.1X

   The 802.1af (sometimes called MacKey) amendment to 802.1X extends it
   to provided keying for use by 802.1AE (see section 2.5 below).



2.4 802.1AB Connectivity Discovery

   - "IEEE Standard for Local and metropolitan area networks / Station
   and Media Access Control / Connectivity Discovery"

   This standard specifies frames that can be emitted by devices to
   announce themselves to other devices on the same link.  Possibly the
   RBridge specifciation could contain advance as to the 802.1AB
   announcements sent by RBridges which choose emit such announcements.








Donald Eastlake 3rd                                             [Page 8]


INTERNET-DRAFT                                  RBridges & 802 Protocols


2.5 802.1AE MAC Security

   - "IEEE Standard for Local and metropolitan area networks / Media
   Access Control (MAC) Security"

   802.1AE-2006 (sometimes called MacSec) is a completed standard but
   has no provisions for keying. One set of such provisions is in
   802.1af which, as described above in section 2.3.1, is under
   development as an amendment to 802.1X.

   With one exception, 802.1AE simply provides security over one hop
   between 802.1AE conformant points of attachment.  As such, 802.1AE
   seems equially applicable to such points of attachment on bridges,
   routers, Rbridges, and end equipment such as non-routing hosts.

   This exception being where a pieced of customer equipment is
   connected to provider backbone equipement as described in 802.1ah.

   It is not clear how successful 802.1AE will be. The various wireless
   protocols under 802 (802.11 (Wi-Fi), 802.15.1 (Blue Tooth), 802.15.4
   (ZigBee), 802.16 (WiMax), etc.) have all adopted their own security
   protocols. In the wired world, connections are increasingly point-to-
   point and for such links you would want security closer to the
   physical layer so as to provide protection against taffic analysis
   and avoid leaving the frame structure/size, MAC addresses, etc.,
   visible as plain text the way 802.1AE does.  Note that there was a
   previous general 802 link security protocol, 802.10, which received
   little deployment and has been withdrawn.
























Donald Eastlake 3rd                                             [Page 9]


INTERNET-DRAFT                                  RBridges & 802 Protocols


3. IEEE 802.3 Protocols

   - "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-2005 is a completed link standard.  The ideas in Rbridges can
   be applied to a variety of link protocols so, for the most part, the
   Rbridge architecture is link independent.  Nevertheless, it is first
   being specified for 802.3.

   802.3-2005 Clause 31 "MAC Control" defines a low level facility for
   control on 802.3 links. Subclause 31.4 "MAC Control Frames" gives
   some further format details while Annex 31A "MAC Control opcode
   assignments" lists the current opcodes available. There are actually
   six but the only one I had ever heard of before looking into this
   document was opcode 1, PAUSE, which is further explaine in Annex 31B
   "MAC Control PAUSE operation".

   I expect that PAUSE will eventually be deprecated in most
   circumstances because 802.1au, Congestion Notification, is superior.



3.1 802.3as

   - 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 / Amendment: Frame format extensions" amendment
   to 802.3

   You may have been wondering why no one seems particularly worried
   about exceeding MTUs when frames are lengthened by the RBridge
   encapsulation. In fact, 802.3 and similar hardware has long been able
   to handle frames that were longer than those specified in the
   standards to accomodate such things.

   Apparently, when Ethernet was first specified, the idea was that data
   would be limited to 1024 bytes and the maximum frame size was set to
   1500 to leave lots of room for things like headers and encapsulation.
   But vendors crammed in as much data as they could so that, when Q-
   tags (VLAN) were added, even though it was only 4 more bytes, it was
   thought necessary to define a higher limit for Q-tagged frames. Now
   that lots of things are considering additional tags, such as security
   tags with 802.1AE, BCN related tags with 802.1au, provider things
   like 802.1ad and 802.1ah, and RBridges, a further extension has been


Donald Eastlake 3rd                                            [Page 10]


INTERNET-DRAFT                                  RBridges & 802 Protocols


   defined along with more stringent words saying not to use up the
   extra space with data.

   The current 802.3as draft defines three frame types for conformance
   purposes:

         1500 octets - basic frames
         1504 octets - Q-tagged frames
         1982 octets - envelope frames











































Donald Eastlake 3rd                                            [Page 11]


INTERNET-DRAFT                                  RBridges & 802 Protocols


4. Multicast Addresses

   A block of 16 multicast MAC addresses is reserved for use by
   802.1/802.3 protocols (officially 802.1 and media specific
   protocols). These are in the range from 0180C2000000 to 0180C200000F
   in hexadecimal.

   The general behavior of bridges is to flood multicast on a spanning
   tree so that multicast frames reach all stations.  However, for
   multicast addresses in this block, the general behaviour of bridges,
   routers, etc., is specified as discarding the frame unless they "know
   what to do with it". This usually involves processing the contents of
   the frame and that processing may cause frames, including frames
   addressed to the same multicast destination MAC address, to be
   originated by the device.

   The current uses or anticipated future uses for these addresses are
   shown below:

     0180C2000000 - All Bridges: Used for BPDUs. Must be recongized by
         RBridges due to RBridge port participation in spanning tree as
         a leaf.

     0180C2000001 - 802.3 Clause 31 use, i.e. Full Duplex PAUSE
         operation

     0180C2000002 - 802.3 Clause 43 (Link Aggregation) and Clause 57
         (OAM) use, aka "Slow Protocols" Multicast address

     0180C2000003 - 802.1X Port Authenticator Entity (PAE) address

     0180C2000004-5 - Reserved for future media access specific method
         standardization

     0180C2000006-7 - Reserved for future standardization

     0180C2000008 - All Provider Bridges

     0180C2000009-C - Reserved for future standardization

     0180C200000D - Provider Bridge GVRP Address

     0180C200000E - 802.1AB Link Layer Discovery Protocol address

     0180C200000F - Reserved for future standardization







Donald Eastlake 3rd                                            [Page 12]


INTERNET-DRAFT                                  RBridges & 802 Protocols


5. IANA Considerations

   None.



6. Security Considerations

   TBD.



7. References

   Many of the completed 802 standards are available for free download
   through the "Get 802" program. See
   http://standards.ieee.org/getieee802/.



7.1 Normative References

   None?



7.2 Informative References

   [802.1] "IEEE Standard for Local and Metropolitan Area Networks:
   Overview and Architecture", IEEE 802-2001, 8 March 2002.

   [802.1D] "IEEE Standard for Local and metropolitan area networks /
   Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004.

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

   [802.1X] "IEEE Standard for Local and metropolitan area networks /
   Virtual Bridged Local Area Networks", 802.1X-2004, 13 December 2004.

   [802.1AB] "IEEE Standard for Local and metropolitan area networks /
   Station and Media Access Control Connectivity Discovery",
   802.1AB-2005, 6 May 2005.

   [802.1ad] "IEEE Standard for Local and metropolitan area networks /
   Virtual Bridged Local Area Networks / Amendment 4: Provider Bridges",
   802.1ad-2005 (amendment to 802.1Q), 26 May 1006.

   [802.1AE] "IEEE Standard for Local and metropolitan area networks /
   Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006.


Donald Eastlake 3rd                                            [Page 13]


INTERNET-DRAFT                                  RBridges & 802 Protocols


   [802.1af] "Draft Standard for Local and Metropolitan Area
   NetworksPort-Based Network Access Control / Amendment 1:
   Authenticated Key Agreement for Media Access Control (MAC) Security",
   Draft D1.2, 20 January 2007.

   [802.1ag] "Draft Standard for Local and Metropolitan Area Networks /
   Virtual Bridged Local Area Networks / Amendment 5: Connectivity Fault
   Management", Draft D7.1, 7 November 2006.

   [802.1ah] "Draft Standard for Local and Metropolitan Area Networks /
   Virtual Bridged Local Area Networks / Amendment 6: Provider Backbone
   Bridges", Draft D3.3, 13 December 2006.

   [802.1ak] "Draft Standard for Local and Metropolitan Area Networks /
   Virtual Bridged Local Area Networks / Amendment 07: Multiple
   Registration Protocol", Draft D6.0, 10 June 2006.

   [802.1au] "Draft Standard for Local and Metropolitan Area Networks /
   Virtual Bridged Local Area Networks / Amendment 7: Congestion
   Management", Draft D0.01, 29 September 2006.

   [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-2005, 9
   December 2005.

   [802.3as] "Draft Amendment of 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 /
   Amendment: Frame format extensions", Draft D3.1, 24 April 2006.


















Donald Eastlake 3rd                                            [Page 14]


INTERNET-DRAFT                                  RBridges & 802 Protocols


Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (C) The IETF Trust (2007).  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
















Donald Eastlake 3rd                                            [Page 15]


INTERNET-DRAFT                                  RBridges & 802 Protocols


Author's Address

   Author's Addresses

   Donald Eastlake 3rd
   Motorola Laboratories
   111 Locke Drive
   Marlborough, MA 01752

   Tel:   +1-508-786-7554
   Email: Donald.Eastlake@motorola.com



Expiration and File Name

   This draft expires in August 2007.

   Its file name is draft-eastlake-trill-802-protocols-00.txt.

































Donald Eastlake 3rd                                            [Page 16]