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]