IEEE 802.1 session notes. 96/07/08 thru 96/07/11 days are separated by @@@@@@ @@@@@@@@@@@@@@@@@@@@@@@ "pre-meeting" - started 9:00 96/07/08 Monday Mick Seaman: --------------------------------------------------------------------------------- Interworking Task Group Agenda Items: (These are the items to be worked on in this meeting:) . 802.1 PARs - Lidinsky, Mick 2. 802.5/FDDI vLAN Tagging, options A, B, Other -Anil, John Wakerly, Rosemary, Alan Chambers 3. Class of Service, vLAN ID priority - Norm, 4. MTU Size Liaison with .3, .12, .5 5. "Default" vLAN and consequences 6. Two-Level Tagging -Wakerly, Norm, Mick 7. Requirements for interoperability Interoperability between different styles of vLAN Switches. 8. Review of 802.1Q/D1 - Jeffree, Editors 9. 802.1p/D3 Ballot results Discussion & Resolution of comments Instructions to Editor - Tony 10. Implementing GARP - Mick 11. LLRMP _ Peter Kim 12. Arch & Organization of components for admission Control for time critical Services/Integrated Services & Relationship to IETF/ISSL 13. ISSLL/priority/traffic class mapping --- 802.1d-------- 14. 802.1D revisions - Jeffree 15. Too Old BPDUs - Mick, Trevor Warwick --- 802.1G ------------ 16. Sponsor ballot - Lidinsky, chambers --- 802.1j ------------ 17. Sponsor ballot - Lidinsky --- administration -------- 18. 802.1 Interim Meeting - Mick 19. -Tobagi --- 802.1Q ----------- 20. How Many Spanning Trees - Jeffree --------------------------------------------------------------------------------- 96/07/08, Tony Jeffree: Dealing with comments on 802.1p /D3 Document handed out: "disposition of ballot comments on 802.1p/D3:" The updated version of this document exists on the ftp server (host: nic.hep.net, user: p8021, password: go_wildcats), in the in the P-DRAFTS/DRAFT-3/BALLOT sub-directory. The disposition document is in two formats: P-D3-DIS.pdf and P-D3-DIS.ps, dated July 16. @@@@@@@@@@@@@@@@@@@@@@@ 7/9/96 9am FDDI/TR vlan tagging Anil Rijsinghani: (re-cap of method "A" and "B") ---------------------------------------------------------- Format A: FC DA SA AA-AA-03-00 00-00-vtype VLan ID PT/L (blue) Data (blue) CRC Within a switch: Ethernet to FDDI -tagging -no translation / 802.1H FDDI to FDDI -tagging -no translation to Ethernet format -generate 802.3 length/PT -Ethernet bit-order 1 ---------------------------------------------------------- Format A Pros: (picture...) Regular Enet-----tagged Enet-----Tagged FDDI-----Regular Enet LAN1 LAN2 LAN3 LAN4 1518 1522 1. Supports older bridges: -not max-size packets, only up to MTU-4 -not IP frag 2 ---------------------------------------------------------- Format A Cons: 1. FDDI-only, 802.5 - only switches must implement Ethernet translation. (Need PT/L) 2. 802.3 length field in an 802.5/FDDI packet causes following problems: a.length may be > 1518 -can't distinguish Enet from 802-3 b.cannot perform cut-through in FDDI-FDDI or or 802.5 - 802.5 switches. 3. vLAN- aware end-stations on FDDI & 802.5 must learn Ethernet translation as well. 4. 802.5 to 802.5 switches must do bit-order "hacks". 3 ---------------------------------------------------------- More on format A & length field: 3 possibilities examined: -set L=0 -set L=0 if packet > 64 bytes -set L=0 if packet > 1518 bytes -set L=0 when un-tagging, this needs to be corrected. switch cannot determine original length, may deliver bad data. -set L=0 if packet > 64 bytes Ethernet-to-Ethernet switch cannot do cut-through --> needs to wait until packet fully received to correct the length field. -set L=0 if packet > 1518 bytes FDDI-to-FDDI switch cannot do cut-through --> needs to wait for 1518 bytes. 4 ---------------------------------------------------------- Format B: FC DA SA AA-AA-03-00 00-00-vtype VLan ID LLC Data CRC Within a switch: Ethernet to FDDI -tagging -translation/802.1H FDDI to FDDI -tagging -no translation 5 ---------------------------------------------------------- Format B Pros: 1. Simple, packets stay in native format. How it works today Format B Cons: 1. Can't support Fig-1 topology. 6 ---------------------------------------------------------- (end of RE-CAP ...) ---------------------------------------------------------- Keith McCloghrie, 9:43am Considering Wider Implications of the Frame Format Choice -d96/d96n164.xxx ---------------------------------------------------------- Alan Chambers: 11am Mapping the Problem Space -d96/d96n165.txt ---------------------------------------------------------- John Wakerly: 11:20am Presentation: Two-level vLAN Tagging -d96/d96n166.xxx (paper, additional material) -d96\d96n170.pdf ---------------------------------------------------------- Mick Seaman: 1:30pm 96/07/09 Presentation: Implementing GARP -d96\d96n167.txt ---------------------------------------------------------- Norm Finn's presentation(s): 96/07/10 afternoon 2:30pm Presentation: Class of Service -d96\d96n168.pdf (paper, additional material) -d96\d96n169.pdf ---------------------------------------------------------- @@@@@@@@@@@@@@@@@@@@@@@ 96/07/10 8:30 am Technical plenary Agenda: (1) where we are with 802.1Q (2) MTU size ... issues ... ---------------------------------------- Tony Jeffree presented status of document (802.1Q) ---------------------------------------- Mick Seaman: vLAN Tagging & MTU size vLAN Tag ('Level 1') adds 4 bytes to 802.3 frames 10 bytes to FDDI/802.5 frames Fragmentation (Reassembly) in bridges/switches not an option - at least not in product. MTU size increase? End stations might send shorter frames (How do they know?) Are Bridges/switches which discard over length frames viable What about MTU size discovery? At 4500, (FDDI?) will corrupt frames, if even one byte added. Need more input from other dots. --------------------------------------------------------------------- IEEE 802.1 session Wed. 96/07/10 10:30am (discussion of technical (8:30am) plenary issues...) --------------------- Mick foil: Immediate Objectives at this meeting -Converge on 802.5/FDDI Tagging so Editor(s) can write up with Fair confidence -Settle where the priority/COS bits go. ---------------------------------------------- Tony, ... foil: Choices: -Packet Format - A vs B vs ? (Alan's analysis will help documentation) -Priority Signalling - Where ? # of bits ? .. etc. -How many spanning trees? -------------------------------------------------------------------- Peter Kim: 1:30pm, 96/07/10 LLRPM presentation (-paper copy only) d96n171 and hand-out... document on IETF drafts servers, Internet Engineering Task Force Internet Draft draft-kim-llrmp-00.ps ---------------------------------------------- Fouad A. Tobagi: 2:38pm Presentation: Performance Evaluation of LANs Implementing 802.1p (paper only) d96n172 Priority Function... ---------------------------------------------- after break, split out into a 802.1p edit group, and a group to discuss frame format @@@@@@@@@@@@@@@@@@@@@@@ Note From John Wakerly, presented 96/7/11 am. -------------------------------------------------------------- Date: Wed, 10 Jul 1996 17:47:08 -0800 To: p8021@nic.hep.net From: jfw@fore.com (John Wakerly) Reply-To: jfw@fore.com (John Wakerly) Subject: 7/10 Tagging Format Breakout CC: krishna@fore.com WHERE'S JOHN? First of all, my apologies to the group for putting in my 2 cents (or .033 Dfl) at the breakout, and then not showing to help report the discussion on Thursday. I decided to return home a day early because of a family matter (not life-threatening, thank you!). If you should read this message by Thursday morning, please relay my apologies, and perhaps even some of my thoughts below, to the group. Perhaps this e-mail could even be printed, copied, and distributed. In any case, I expect that Keith and perhaps others will make their best efforts to report the range of discussion that occurred. BREAKOUT REPORT No conclusions had been reached when I left the group at 5:30pm (and reaching conclusions was not our assignment), but I think we were getting close to asking the right questions. It was evident that there was not likely to be easy agreement on the answers to those questions. As in our full-committee meetings earlier this week, the breakout group quickly left the question of A vs. B (as defined in June) to a higher-level question, formulated in a number of ways, along the lines of Keith's presentation: -- Is the format of what's inside the frame implied by the medium on which the frame is received, or by something inside the frame? -- Should a VLAN be able to span different media types (we all agreed, yes!), and if so, should this be possible without requiring any frame-format translation at the boundary between the media? This quickly pushed us up to a higher-level question, which I believe is the crux of the disagreement: Which of the following two views should guide our choice of frame formats? 1) Frame-format translation at media boundaries is already a problem in bridged LANs, and it is already solved, thank you. This is not a VLAN problem, and VLANs should not try to solve it. 2) Evolving network topologies -- in particular, physically dispersed VLANs across backbones, facilitated by VLAN-capable edge devices and core devices, will only increase the amount of non-native traffic transported on different media types. VLANs contribute to the need for translation (or, efficient transport without translation), and can help to solve the problem by including an explicit indication of frame format in the VLAN tag. Maybe the group formulated this question better or differently after I left, or perhaps they moved on to a better question, but this is the question as best I could see it. Going down one more level of detail, there was discussion about how many different frame formats should be indicated if you agree with view #2. The only three formats that anyone wanted were Ethernet, FDDI, and Token Ring. Part of the group, who held view #2, felt that two were enough -- Ethernet and Token Ring. Another part of the group, who happened to hold view #1, seemed to indicate that if they're stuck with view #1, then FDDI format is also needed. A number of informal but useful aids to discussion, including definitions of "Ethernet," "FDDI," and "Token Ring" frame formats were developed, and I trust that Keith will report on these for the benefit of Thursday's discussion. There was also discussion VLAN tagging format on token ring, and the observation / strong assertion that the native TR tagging format need not / should not be tied to the Ethernet format or SNAP encoding now proposed to get us into the 16 bits of tag info. I.e., we could use a DSAP, FC bits, etc. to indicate that the tag info is present. PERSONAL VIEWS My personal view on the main question is as follows. I only get to say it once because I won't be (wasn't) there on Thursday! I agree with view #2. I'll stand by my characterization earlier this week of view #1 as saying that we can build ugly little VLANs inside of ugly bridged LANs. In view #2, we can use a bit or two of tag to ease the translation burden in VLAN-aware devices, and completely eliminate the need for translation in many common, useful topologies that use high-speed backbones to join VLANs whose end-stations are on a lower speed, dissimilar medium. The most extreme arguments for view #1 say that we might need to get a separate PAR to deal with translation questions. I strongly disagree with this view. Within the framework of our existing PAR, we can easily arrive at an architectural view (some of us already have) that requires the originating media type of a tagged frame to be indicated in the tag. In agreeing with view #2, I further believe that three (3) is the right number of frame formats, at least to start an investigation with. Having 3 formats -- Ethernet, FDDI, and TR -- makes it possible to easily build VLAN ingress and egress switches that operate simply and efficiently in homogeneous media environments, and also makes for easy tunnelling of VLANs across a dissimilar medium (carrying frames WITHOUT translation at media boundaries). Although 3 formats leaves us with more translation combinations, all of these are just POSSIBILITIES, and need only be implemented if customers require them. The committee also has the ability to "outlaw" some of the possibilities if that seemed desirable. Note that outlawing a certain set of possibilities takes us back to having just 2 formats. One of the proponents of having 2 formats asserts in a different context that if we don't provide a capability in a standard, and the market needs it, one or more suppliers will go off and provide it in proprietary ways. So, I ask, why should we outlaw a set of possibilities when some people think there is a market? We should have very good reasons for outlawing a possibility. And in the debate, we should have a starting point of inclusivity rather than exclusivity. OTHER WEIRD IDEAS Finally, I have a few off-line thoughts of my own to offer now on the subject of VLAN tag format. These ideas show some of the range of possibilities for encoding 3 (or 2 or even 1) frame formats. First is a way to pack everything into 16 bits, using just one new Ethertype value for 1-level VLANs. The 16-bit info portion of the tag could have the following layout: 3 1 12 --------------------------------------------------- | PRI | R=0 | VID | --------------------------------------------------- PRI = 3-bit priority field VID = VLAN #, 0<=VID<=2**12-1 R = RING/ETH, 0==>Ethernet, 1==>Ring 3 1 1 11 --------------------------------------------------- | PRI | R=1 | T | VID | --------------------------------------------------- PRI = 3-bit priority field R = RING/ETH, 0==>Ethernet, 1==>Ring T = TR/FDDI, 0=FDDI, 1=TR VID = VLAN #, 0<=VID<=2**11-1 Notes: VLAN #s 0 - 2^11-1 have "flexible" frame type -- may have any "internal" frame type on any medium R,T = 0,0 ==> Ethernet (Format A on FDDI; TR t.b.d.) R,T = 1,0 ==> FDDI (Format B on FDDI; Eth, TR t.b.d.) R,T = 1,1 ==> TR (formats t.b.d.) VLAN #s 2^11 - 2^12-1 MUST use Ethernet frame type on all media (Format A on FDDI; TR t.b.d.) This is a sort-of Huffman coding that gives us up to 4K VLANs on Ethernet, of which 2K can also exist (or exclusively exist) on Token Ring and/or FDDI. A second possibility is to encode the internal frame type in the VLAN type value, i.e., use three different Ethertypes. Gee, as long as we're asking for more than one Ethertype, why not a few spares too? Why not 256? 8 3 3 3 ---------------------------------------------------- | "Extended Services" | 0 0 0 | x x x | FF | ---------------------------------------------------- 0 0 0 = fixed value, must match for 802.1p/Q x x x = "don't care", not decoded for now (extension space for future p/Q features while retaining backward compatibility) FF = Frame Format, 00==>Eth, 01==>FDDI, 10==>TR, 11==>reserved The 16-bit extension word then has room for, for example, 13 bits of VLAN ID and 3 bits of priority info. J -------------------------------------------------------------- 97/7/11 - Keith McCloghrie Frame Format Breakout Group: -Not just a choice between formats -also, choice between levels of functionality -We started from my presentation: -one or more types (bits in frame) -or- -"inside" format always same as media type. -We recognized a relationship/a way of representing the two: (table) Type Bit(s) | Enet | FDDI | TR | |-------+-------+-------+ Enet | | | | on |-------+-------+-------+ media FDDI | | | | type |-------+-------+-------+ TR | | | | +-------+-------+-------+ -Extra functionality: -allowing TR frames to cross a non-TR backbone w/o xlational bridging -Two schools of thought: -vLANs: are a sub-division of exciting LAN infrastructure -multiplexing -access control -vLANs can span an existing backbone -the LANE model -more need for "tunnelling" in today's networks, with more from router-based backbones to high-speed, switch-based backbones. OTHER ITEMS 1.-frame format "inside": -the data format it would have if not tagged in the relevant media type -so, Ethernet type conversion to TR type require ARP translation, Ethernet type to FDDI type does not. 2.Why is TR tag's length 10 bytes? Could it be shorter? How about a DSAP, or a FC bit? ------------------------------------- 1) 2 types: Type Bit(s) | Enet | FDDI | TR | |-------+-------+-------+ Enet | 0 | x | 1 | 1=bit set on |-------+-------+-------+ 0=bit reset media FDDI | 0 | x | 1 | x=not allowed type |-------+-------+-------+ TR | 0 | x | 1 | +-------+-------+-------+ =>FDDI-FDDI bridge has to xlate bridge on ingress/egress 2) 3 types: Type Bit(s) | Enet | FDDI | TR | |-------+-------+-------+ Enet | 00 | 01 | 10 | on |-------+-------+-------+ media FDDI | 00 | 01 | 10 | type |-------+-------+-------+ TR | 00 | 01 | 10 | +-------+-------+-------+ =>must configure where xlate bridging done. 3) type matches media: Type Bit(s) | Enet | FDDI | TR | |-------+-------+-------+ Enet | 0 | x | x | (no need to on |-------+-------+-------+ carry the type) media FDDI | x | 0 | x | type |-------+-------+-------+ TR | x | x | 0 | +-------+-------+-------+ =>must xlate bridge at every change of media 4) Compromise Type Bit(s) proposed: | Enet | FDDI | TR | |-------+-------+-------+ Enet | 0 | x | 1 | 1=TR on |-------+-------+-------+ 0=Enet/FDDI media FDDI | x | 0 | 1 | type |-------+-------+-------+ TR | x | 0 | 1 | +-------+-------+-------+ =>must xlate bridge at every E - F change =>xlate bridge is configured for TR.