Conference 7.286::fddi

>>I urgently need information about work done or planned to support our tagging
>>scheme (implemented in new DECswitch 900EF switching software) on DEFPA.

    Hi Alex.  I'm the SW team leader for the DEFPA and DEFEA FDDI
    controllers.  I'm in the process of determining what exactly is
    expected of an end-node supporting VLAN tagging.

>>The problem is how to handle tagged frames and how to represent VLANs to OS.
>>Obviously, there should be a driver for FDDI adapter which wouldn't discard
>>tagged frames but rather process them and redirect data to network pseudo-
>>devices (corresponding to the VLANs) instead, and, of course, something like a
>>VLAN configurator on the server. In the case OS could "think" that there are
>>multiple cards on the server, one per VLAN (much like eLANs in ATM).

    There are a number of issues.  Here are a few of them:

    	1. Most device drivers and/or upper layer SW drop and refuse to
    	   transmit greater than maximum sized frames.  VLAN tagging
    	   would cause maximum sized FDDI frames to be 4 bytes larger.
    	2. Most device drivers and/or upper layer SW drop and refuse to
    	   pass up received frames that are greater than maximum sized,
    	   with the possible exception of a monitoring type function.
    	3. VLAN tagging may present the frame in a frame format that
    	   is not presently configured.
    	4. No commercial operating system that I'm aware of has the
    	   support to transmit or except these tagged frames.  There
    	   are no "VLAN aware" protocol stacks that I'm familiar with.

    A lot can be done in the device driver, but it's always within the
    context of what's allowed by the driver specification and operating
    system.  Of primary importance is that normal non-tagged traffic be
    handled properly since for now, VLAN tagged frames is an anomaly and
    not the norm.

>>Windows NT support would be preferrable in a "first wave".

    I'm presently responsible for the NDIS 3 drivers for Windows NT.  I'm
    not aware of Microsoft support VLAN tagging on NT 3.51 or the upcoming
    4.0 release.  If you have information to the contrary, please let me
    know.

    I don't know exactly what an FDDI VLAN-tagged LLC frame looks like, but
    since the NDIS 3 driver simply passes up received traffic to the NDIS
    layer, it would be the operating system's responsibility to parse the
    tagged frame properly with the current driver, and I don't believe that
    would happen today.  Also, maximum sized VLAN-tagged LLC frames would
    be dropped in the current driver.
    
    Regards,
       Larry

Hi Larry,

I understand all the problems that will arise pretty much. I'm confident also
that some sort of work must be done anyway just to sinchronize efforts of
DECswitch, VNswitch, GIGAswitch/FDDI, FDDI NICs and clearVISN teams and create
the transparent Digital VLAN specification (there is no standard yet). It
could be proprietary at the beginning (nobody blames Cisco for their ISL -
InterSwitch Link - and 802.10 VLAN games) but working across Digital platforms.
Otherwise, we can bury FDDI uplink concept and whole switched FDDI technology
as well and pray on so long awaited Fast Ethernet switches from Digital or sell
Cisco Catalysts.

>       1. Most device drivers and/or upper layer SW drop and refuse to
>          transmit greater than maximum sized frames.  VLAN tagging
>          would cause maximum sized FDDI frames to be 4 bytes larger.
>       2. Most device drivers and/or upper layer SW drop and refuse to
>          pass up received frames that are greater than maximum sized,
>          with the possible exception of a monitoring type function.

No station goes from Ethernet (V)LAN to FDDI with frames larger than 1500.
In this particular VLAN environment maximum frame size could also be limited
to 1500 on the FDDI-attached servers.

>       3. VLAN tagging may present the frame in a frame format that
>          is not presently configured.

Drop such a frame. It is a configuration problem.

>       4. No commercial operating system that I'm aware of has the
>          support to transmit or except these tagged frames.  There
>          are no "VLAN aware" protocol stacks that I'm familiar with.

Cisco and Intel are currently working on hardware implementation of Cisco's
ISL in Intel's Fast Ethernet adapters. I'm confident that software support will
come very soon for all the most popular OS's (NetWare, WNT etc.)

>    I don't know exactly what an FDDI VLAN-tagged LLC frame looks like, but

Sorry, I don't know exactly, too. It looks like this: Protocol Type=VLAN, next
14(?) bits=VLAN stamp and something else... You'd better ask DECswitch 900EF
people who developed V1.6 firmware.

Regards,
Alex

>>I understand all the problems that will arise pretty much. I'm confident also
>>that some sort of work must be done anyway just to sinchronize efforts of
>>DECswitch, VNswitch, GIGAswitch/FDDI, FDDI NICs and clearVISN teams and create
>>the transparent Digital VLAN specification (there is no standard yet). It
    
    THAT's an understatement!  :-)
    
    Just as an FYI, the Adapter (Ethernet, Fast Ethernet, FDDI) group has
    not been included in the enVISN/clearVISN strategy.  The
    enVISN/clearVISN strategy relates to internetworking devices (hub,
    switches, routers) and not NICs.  This was an intentional move by the
    powers-that-be.
    
>>No station goes from Ethernet (V)LAN to FDDI with frames larger than 1500.
>>In this particular VLAN environment maximum frame size could also be limited
>>to 1500 on the FDDI-attached servers.
    
    That's true for Ethernet/Fast Ethernet to FDDI traffic, only.  Most
    FDDI end nodes are configured for max frame size support and it's the
    protocol stacks responsibility to either rely on fragmentation or MTU
    discovery in building the properly sized frames.  On its own, however,
    the max frame size support IS an issue on both Ethernet and FDDI
    nodes.
    
>>Cisco and Intel are currently working on hardware implementation of Cisco's
>>ISL in Intel's Fast Ethernet adapters. I'm confident that software support will
>>come very soon for all the most popular OS's (NetWare, WNT etc.)
    
    I don't know how closely you watch the commercial operating system
    vendors, but I'm not as optimistic that software support will come very
    soon.  I've seen Novell and Microsoft delay native ATM support for
    some time now and although this seems like a trivial (by comparison)
    issue in terms of development time, I'm positive it's not high on their
    priority queue.
                                                                      
    If, on the other hand, Cisco and Intel are looking for a way to
    insert/remove tags in the driver, that's a different story.
    
>>Sorry, I don't know exactly, too. It looks like this: Protocol Type=VLAN, next
>>14(?) bits=VLAN stamp and something else... You'd better ask DECswitch 900EF
>>people who developed V1.6 firmware.
    
    I am.  However, before you sell this solution to your customer, you had
    better get assurances from senior technical folks here that what you're
    proposing will work and is supported.
    
    - Larry
                   

OK, I give up.

Anyway, there could be a solution above NDIS layer. Say, some application which
is closely integrated with OS (like our NT Cluster) could process tagged
frames...

>    However, before you sell this solution to your customer, you had
>    better get assurances from senior technical folks here that what you're
>    proposing will work and is supported.

You know, a typical serious project lasts ~one year (from very early proposal
and tender up to the implementation). And if you base your proposal on what the
company currently has got and don't mind any perspective or forecast for at
least one year you will never win. That concerns Digital's network products
more than the others' ones because NPB is a relatively new player on the modern
switching market, and it's very difficult to convince people to invest in our
products. We have to have trumps and five aces to win still having only FDDI
as a high speed backbone. Just grumbling...

Alex

>>OK, I give up.

    Alex, I'm not suggesting that you "give up".  I think what you're
    suggesting DOES require some consideration.  I also think that we've
    done very well in building a core competency in Ethernet, Fast
    Ethernet, and FDDI networking products, including NICs, and I can see
    how it can benefit everyone to see a tighter integration between the
    groups and a focused solutions-oriented strategy that includes the
    internetworking devices AND the end node devices.

    I can't directly impact NPB's global development strategy, but here are
    some folks who can:
    
    	Bill Hawe (NACTO::HAWE)      - NPB Technical Director
    	Bill Maro (DELNI::MARO)      - NPB VP Network Product Engineering
        Avi Fogel (DELNI::FOGEL)     - NPB VP Global Marketing
    	Larry Walker (DELNI::WALKER) - NPB VP and General Manager
    
    You should strongly consider making your case for this work to these
    folks.  Properly motivated, they can ensure that the funding and
    resources are there to make this happen.
    
>>Anyway, there could be a solution above NDIS layer. Say, some application which
>>is closely integrated with OS (like our NT Cluster) could process tagged
>>frames...
    
    Definitely a possibility.  Today it would likely be a proprietary
    solution that may need to be tightly coupled with the driver.  Ideally,
    Microsoft would update their NDIS layer to support this.
    
    - Larry

Larry,

Thanks. Just some info. A few days ago I checked the clearVISN presentation
and found what I was looking for. It probably will be done by the end of CY.
No details how.

Regards,
Alex

    Alex,
    
    I spoke with Carol Iturralde who is part of the VLAN definition team
    here at NPB.  The current strategy is that end nodes *IGNORE* the
    encapsulated frames.  That includes Windows NT systems using DEFPAs.
    
    Perhaps someday, end nodes would participate in this, but it would
    require a lot of "smarts" on the part of the operating system and
    protocol stacks to not only support the tagging, but to manage it.
    It cannot be supported by updating device drivers alone.
    
    Regards,
       Larry

Larry,

It seems, only GIGAswitch/FDDI could be elected as a smart enough guy to perform
VLANning over FDDI. But it is subject for another conference...

Thanks for all your replies.

Regards,
Alex