I'm really confused - TCP-IP

This is a discussion on I'm really confused - TCP-IP ; hello I'm trying to learn about Networking, but some stuff is really confusing. Could you please help me? 1) Internet protocol suite implemented on ehernet LAN uses DIX Ethernet frame format. According to article: http://pclt.cis.yale.edu/pclt/COMM/ETHER.HTM ************************************************** *** However, the 802.2 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: I'm really confused

  1. I'm really confused

    hello

    I'm trying to learn about Networking, but some stuff is really
    confusing. Could you please help me?


    1)
    Internet protocol suite implemented on ehernet LAN uses DIX Ethernet
    frame format. According to article:

    http://pclt.cis.yale.edu/pclt/COMM/ETHER.HTM


    ************************************************** ***
    However, the 802.2 standard would require a change to the network
    architecture >of all existing Ethernet users.

    The TCP/IP protocol used by the Internet refused to change. Internet
    standards >are managed by the IETF group, and they decided to stick
    with the old DIX >message format indefinitely. This produced a
    deadlock between two standards >organizations that has not been
    resolved.
    ************************************************** ****


    To my question:
    The Internet protocol suite only supports DIX Ethernet frame format,
    and thus it doesn't support 802.3 frame format. I'm confused, since if
    Internet suite doesn't support frame format defined by 802.3, then it
    probably also doesn't support other IEEE Ethernet specifications ?!

    I'm assuming this, cos interface between layer 1 (physical) and
    layer2(data link layer) must be different if frame format is not
    defined by IEEE 802 ( and thus if interface is different then NIC (and
    maybe other hardware) on which Internet protocol suite runs must also
    be built a bit differently ).


    If it does support other IEEE ethernet specifications, how does
    Internet protocol suite get around the fact that it has different
    Ethernet frame format?


    2)
    Layers should operate in such way that one layer doesn't know how the
    other layer works. If that is the case, then why does IP layer of
    Internet protocol suite care what type of frame format does data link
    layer use?


    thank you very much


  2. Re: I'm really confused

    kaja_love160@yahoo.com writes:
    > The TCP/IP protocol used by the Internet refused to change. Internet
    > standards >are managed by the IETF group, and they decided to stick
    > with the old DIX >message format indefinitely. This produced a
    > deadlock between two standards >organizations that has not been
    > resolved.


    Ha!

    > The Internet protocol suite only supports DIX Ethernet frame format,


    Nonsense. IP works fine on 802.3 LLC/SNAP and DIX. There are still a
    few pockets of users who insist on running IP that way for some odd
    reason.

    The vast majority use DIX, and many systems support only DIX (or
    support 802.3 only with _great_ difficulty).

    > and thus it doesn't support 802.3 frame format. I'm confused, since if
    > Internet suite doesn't support frame format defined by 802.3, then it
    > probably also doesn't support other IEEE Ethernet specifications ?!


    How do you figure that?

    > I'm assuming this, cos interface between layer 1 (physical) and
    > layer2(data link layer) must be different if frame format is not
    > defined by IEEE 802 ( and thus if interface is different then NIC (and
    > maybe other hardware) on which Internet protocol suite runs must also
    > be built a bit differently ).


    The "dispute" (really, long-settled and now irrelevant issue) is far
    more narrow than you're supposing.

    It's really about the use of the type/length field. For DIX, that's a
    type value (the "Ethertype;" a network layer protocol identifier), and
    the values are chosen so that they cannot conflict with any valid
    length. For 802.3 LLC/SNAP, that's a length field.

    That's basically it. The rest of the framing remains the same. No
    conflict.

    > If it does support other IEEE ethernet specifications, how does
    > Internet protocol suite get around the fact that it has different
    > Ethernet frame format?


    There's nothing to get around.

    > 2)
    > Layers should operate in such way that one layer doesn't know how the
    > other layer works. If that is the case, then why does IP layer of
    > Internet protocol suite care what type of frame format does data link
    > layer use?


    It's actually a deployment issue. IP itself doesn't care a whit. But
    to get systems to interoperate, you must choose which frame format
    you're going to use, and most users (choosy users?) choose DIX.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: I'm really confused

    In article ,
    James Carlson wrote:

    >It's really about the use of the type/length field. For DIX, that's a
    >type value (the "Ethertype;" a network layer protocol identifier), and
    >the values are chosen so that they cannot conflict with any valid
    >length. For 802.3 LLC/SNAP, that's a length field.
    >
    >That's basically it. The rest of the framing remains the same. No
    >conflict.


    except for the minor issue of the MTU


    >> Layers should operate in such way that one layer doesn't know how the
    >> other layer works. If that is the case, then why does IP layer of
    >> Internet protocol suite care what type of frame format does data link
    >> layer use?


    That's what the layering priests chant, but it has never been entirely
    true. A good case study of that is that DLPI was developed by layering
    priests and required upper layers to know the bit orders (not to mention
    lengths) of the addresses of lower layers. For example, an upper layer
    needed to know whether a lower layer date link provider was FDDI or
    Ethernet not just for the MTU but also for the bit order of the MAC
    address.


    >It's actually a deployment issue. IP itself doesn't care a whit.


    except for the MTU, which you might include in the list of available
    operations that the lower layer advertises to the upper layers, as in
    "function frame_tx() sends frames between 1 and X octets long".

    > But
    >to get systems to interoperate, you must choose which frame format
    >you're going to use, and most users (choosy users?) choose DIX.


    The proof of that is that the layering sky has not fallen and
    systems do interoperate just fine.

    As the saying goes, "Layering is a good tool but a bad master."


    Vernon Schryver vjs@rhyolite.com

  4. Re: I'm really confused

    kaja_love160@yahoo.com writes:

    > ************************************************** ***
    > However, the 802.2 standard would require a change to the network
    > architecture >of all existing Ethernet users.
    >
    > The TCP/IP protocol used by the Internet refused to change. Internet
    > standards >are managed by the IETF group, and they decided to stick
    > with the old DIX >message format indefinitely. This produced a
    > deadlock between two standards >organizations that has not been
    > resolved.
    > ************************************************** ****


    1. 802.3/802.2 did NOT require "a change to the network architecture
    of all existing Ethernet users." The problem was not one of
    changing code; the problem was the deployed base. Many, many
    networks were already running quite contentedly with IP over
    Ethernet. Changing to 802.3/802.2 would have been a huge effort for
    developers, net admins, sys admins, and users.

    2. 802.3/802.2 was NOT an improvement. (One could argue it was
    *inferior*, although not really enough to worry about.) For TCP/IP
    networks, that huge effort I just mentioned *would have resulted in
    no improvement whatsoever*.

    3. I'm not sure the IETF even existed when the 802.3/802.2 vs.
    Ethernet issue hit the fans, but if the IETF did exist already, it
    was just getting started. The real decision to support Ethernet and
    ignore 802.3/802.2 was made by network administrators, not by any
    standards body or protocol developers.

    4. The TCP/IP standard process -- informal though it was at the time
    -- *did* immediately "resolve" the problem. There were some minor
    but specific ways that IP could not be carried on 802.2, and 802.2
    also introduced some inefficiencies. All of these issues were
    resolved with an 802.2 extension called "SNAP", developed entirely
    by people working on TCP/IP. SNAP was used to carry IP on other
    802.x protocols such as Token Ring (802.5/802.2) that didn't
    already have deployed base yet, although those protocols have now
    themselves slipped into obscurity.

    So it's silly to suggest that the TCP/IP side of the standard
    development world was the problem to begin with, there are no
    grounds whatsoever to suggest the problem wasn't resolved at the
    standards level by the TCP/IP side.

    As I said, that standard was ignored in practice because people had
    real work to do. (A year or two after this, I found myself
    implementing TCP/IP for NetWare. Having been peripherially involved
    in all this, I made sure the NetWare TCP/IP could support IP over
    802.3/802.2/SNAP. In the 10 years that I worked at Novell
    supporting NetWare's TCP/IP after that, I never heard of a single
    Novell customer using it.)

    802.3/802.2 was spawned by the OSI protocol effort, and it serves as
    an excellent case study in what went wrong with OSI. Of course, 802.3
    and 802.2 are technically IEEE standards, and I can't actually address
    their actual relation with OSI, but they were definitely both examples
    of an idea that swept the network protocol world at the time: that
    protocols could be developed simply by thinking about them. The fact
    that our current world is networked with TCP/IP, whose developers
    always insisted on experience before standardization, tells us how
    successful the "standardization by groupthink" process turned out to
    be.

    -don provan

  5. Re: I'm really confused

    hiya


    >>2)
    >>Layers should operate in such way that one layer doesn't know how the
    >>other layer works. If that is the case, then why does IP layer of
    >>Internet protocol suite care what type of frame format does data link
    >>layer use?

    >
    >It's actually a deployment issue. IP itself doesn't care a whit. But
    >to get systems to interoperate, you must choose which frame format
    >you're going to use, and most users (choosy users?) choose DIX.



    Token Ring frame format is different than Ethernet frame format and
    yet two computers (one residing inside Token ring and other inside
    Ethernet LAN) can still comunicate with each other using TCP/IP
    protocols. So why couldn't two PCs, one on ethernet LAN using DIX
    frame format and other on Ethernet LAN using 802.3 frame format, be
    able to talk to each other using TCP/IP? Because their Ethernet frame
    formats differ? But token ring frame is also different from ethernet
    frame, and yet communication is still possible?!

    BTW - I could be way off with my response/quoestion since I'm not sure
    what you meant by "deployment issue"



    Anyhow, to further explain what's confusing me:
    I guess I'm picturing protocols as program functions running at each
    layer as pieces of software that demand that input data ( frame
    format ) must have exact structure. And as such, if we have functions
    working at Data link layer that take ethernet 802.3 as input data, and
    if then suddenly we introduce new frame format as input data ( DIX
    ethernet or even SNAP inside 802.3 ), then functions taking ethernet
    frame as an input value won't act correctly unless we change the code
    of these functions in order for them to handle different ethernet
    frame format.
    Same goes for functions acting as interface between Data link layer
    and IP layer.
    I'm assuming even when SNAP was introduced into frame format that
    these functions were rewritten a bit

    thank you for helping me


  6. Re: I'm really confused

    In article <1180299062.067084.323270@k79g2000hse.googlegroups. com>,
    wrote:

    >Token Ring frame format is different than Ethernet frame format and
    >yet two computers (one residing inside Token ring and other inside
    >Ethernet LAN) can still comunicate with each other using TCP/IP
    >protocols.


    That works because a router forwards IP packets between the Ethernet
    IP network and the token ring IP network.

    > So why couldn't two PCs, one on ethernet LAN using DIX
    >frame format and other on Ethernet LAN using 802.3 frame format, be
    >able to talk to each other using TCP/IP? Because their Ethernet frame
    >formats differ? But token ring frame is also different from ethernet
    >frame, and yet communication is still possible?!


    An Etherent DIX computer and Ethernet 802.3 SNAP computer could if a
    router forwarded packets between the 802.3 SNAP Ethernet and the DIX
    Ethernet. Those two Ethernets might sare the same hubs and wires, but
    they would need different IP network numbers.

    Perhaps another common case was that either one of the two computers
    was able to talk both DIX and 802.3 SNAP and did the right thing
    when it discovered with ARP that the other computer was a strange
    802.3 SNAP box.

    I wrote "computer" instead of "PC" because I know many and suspect most
    computers that talked IP/802.3 SNAP on Ethernets were not IBM-style
    personal computers.


    Vernon Schryver vjs@rhyolite.com

  7. Re: I'm really confused

    In article ,
    vjs@calcite.rhyolite.com (Vernon Schryver) wrote:

    > In article <1180299062.067084.323270@k79g2000hse.googlegroups. com>,
    > wrote:
    >
    > >Token Ring frame format is different than Ethernet frame format and
    > >yet two computers (one residing inside Token ring and other inside
    > >Ethernet LAN) can still comunicate with each other using TCP/IP
    > >protocols.

    >
    > That works because a router forwards IP packets between the Ethernet
    > IP network and the token ring IP network.
    >
    > > So why couldn't two PCs, one on ethernet LAN using DIX
    > >frame format and other on Ethernet LAN using 802.3 frame format, be
    > >able to talk to each other using TCP/IP? Because their Ethernet frame
    > >formats differ? But token ring frame is also different from ethernet
    > >frame, and yet communication is still possible?!

    >
    > An Etherent DIX computer and Ethernet 802.3 SNAP computer could if a
    > router forwarded packets between the 802.3 SNAP Ethernet and the DIX
    > Ethernet. Those two Ethernets might sare the same hubs and wires, but
    > they would need different IP network numbers.


    Could a sufficiently intelligent switch also do this?

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread