I'm a beginner and already very lost - LLC and SNAP - TCP-IP

This is a discussion on I'm a beginner and already very lost - LLC and SNAP - TCP-IP ; I recently started learning about network protocols, but I got stuck very quickly. I'm hoping you guys could help me a bit, since I would really need some help with the following questions. BTW - I apologise for my questions ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: I'm a beginner and already very lost - LLC and SNAP

  1. I'm a beginner and already very lost - LLC and SNAP

    I recently started learning about network protocols, but I got stuck
    very quickly. I'm hoping you guys could help me a bit, since I would
    really need some help with the following questions.

    BTW - I apologise for my questions not being short and to the point,
    but I can't ask any better and still make much sense.

    Here is how packets travels from and to data link layer ( I know much
    more happens to packet at data link layer, but only the following is
    related to my questions )

    1) When one of upper layers sends down a packet to the data link
    layer, it is first received by LLC sublayer, which adds LLC header to
    it.
    2) LLC then passes this packet down to MAC layer, where MAC sublayer
    adds another header and tail and sends it to other PC
    3) At the receiving end this frame first goes to MAC sublayer, where
    its header and tail are removed
    4) Then it is send to LLC sublayer where LLC header is removed, and
    then up

    1)
    According to definition of LLC sublayer, among other things LLC
    allows upper layer protocols to operate without specific knowledge of
    lower layer protocols. If I understood this correctly, LLC sublayer
    provides common interface for all upper layer protocols .

    Why is that such a big deal? Couldn't interface between data link and
    higher layers be uniform even if there would be no LLC sublayer, but
    instead just MAC sublayer ( with some extra functionality of
    course )?
    Afterall, data link header is always removed prior to packet being
    send from data link to higher layers, so no matter whether frame was
    of Ethernet type or token ring type, upper layers won't care or know
    about it due to datalink headers being removed before being send to
    upper layers. Point being, LLC or no LLC, if data link header is
    removed before being passed to upper layers, then there is no reason
    why interface between upper and data link layer can't be uniform. I
    hope I'm making some sense.

    2)
    I found one LLC definition saying:"SAPs are Service Access Ports. A
    SAP is a port (logical link) to the Network layer protocol. If we were
    operating a multi protocol LAN, each Network Layer protocol would have
    its own SAP. This is the method that the LLC uses to identify which
    protocol is talking to which other protocol. For example, Unix's TCP/
    IP, Novell's SPX/IPX and IBM's Netbios would all have different SAPs
    (to identify which was which)."
    Meaning each upper protocol is identified by some kind of number
    inside SAP field

    But some other definitions claim that SAP fields don't directly
    identify upper layers, but instead contain pointers to memory
    locations where, depending on the upper layer protocol, packets should
    be stored and this location specific upper layer protocol will find
    its packet.

    a) If the latter is true: For this to work, then every time any two
    PCs are talking using TCP/IP protocols, packets at data link layer
    should always be placed at the same memory location and th?

    So if memory location for TCP/IP packets is 100, then when A and B
    are communicating using TCP/IP, packets are stored at memory location
    100. And if C and D are communicating using TCP/IP, then packets are
    also stored at memory location 100?

    b) why didn't folks at IEEE instead use numbers inside LLC field to
    identify upper layer protocols ( 1 for IP, two for IPX ... or something
    to that effect)? Why complicate the matter by specifying memory
    locations?

    3)
    Now if SAP identifies which upper layer protocols should receive a
    packet, then why the need for SNAP? Can't SAP identify TCP/IP protocol
    ( BTW - I know official reasoning is that SNAP is used for backwards
    compatibility with Ethernet 2, but that makes no sense since that
    would suggest that if one was to create NIC drivers just for DIX
    version, they would automatically understand 802.3 SNAP frame type,
    which isn't the case at all )?

    I hope someone can help me figure this out

    thank you very much

    Why does TCP/IP over Ethernet still uses DIX frame format, but TCP/IP
    over token ring uses 802.3 SNAP frame format?

    Since TCP/IP uses DIX frame format, I'm assuming that if two computers
    ( one using Dix format and other 802.3 SNAP format ) communicating via
    TCP protocol are to understand each other ( assuming there are no
    routers performing the conversion for them ), then their NIC drivers
    must be able to recognize both 802.3 and DIX format and be able to
    convert (or something) between the two frame formats?

  2. Re: I'm a beginner and already very lost - LLC and SNAP

    hello

    My first post and I already screwed it up. The questions at the bottom
    of the first post are not for this thread, so I will post my questions
    again to avoid the confusion:


    Here is how packets travels from and to data link layer ( I know much
    more happens to packet at data link layer, but only the following is
    related to my questions )

    1- When one of upper layers sends down a packet to the data link
    layer, it is first received by LLC sublayer, which adds LLC header to
    it.
    2 - LLC then passes this packet down to MAC layer, where MAC sublayer
    adds another header and tail and sends it to other PC
    3 - At the receiving end this frame first goes to MAC sublayer, where
    its header and tail are removed
    4 - Then it is send to LLC sublayer where LLC header is removed, and
    then up




    Now to my questions:

    1)
    According to definition of LLC sublayer, among other things LLC
    allows upper layer protocols to operate without specific knowledge of
    lower layer protocols. If I understood this correctly, LLC sublayer
    provides common interface for all upper layer protocols .

    Why is that such a big deal? Couldn't interface between data link and
    higher layers be uniform even if there would be no LLC sublayer, but
    instead just MAC sublayer ( with some extra functionality of
    course )?
    Afterall, data link header is always removed prior to packet being
    send from data link to higher layers, so no matter whether frame was
    of Ethernet type or token ring type, upper layers won't care or know
    about it due to datalink headers being removed before being send to
    upper layers. Point being, LLC or no LLC, if data link header is
    removed before being passed to upper layers, then there is no reason
    why interface between upper and data link layer can't be uniform. I
    hope I'm making some sense.



    2)
    I found one LLC definition saying:"SAPs are Service Access Ports. A
    SAP is a port (logical link) to the Network layer protocol. If we were
    operating a multi protocol LAN, each Network Layer protocol would have
    its own SAP. This is the method that the LLC uses to identify which
    protocol is talking to which other protocol. For example, Unix's TCP/
    IP, Novell's SPX/IPX and IBM's Netbios would all have different SAPs
    (to identify which was which)."
    Meaning each upper protocol is identified by some kind of number
    inside SAP field

    But some other definitions claim that SAP fields don't directly
    identify upper layers, but instead contain pointers to memory
    locations where, depending on the upper layer protocol, packets should
    be stored and this location specific upper layer protocol will find
    its packet.



    a) If the latter is true: For this to work, then every time any two
    PCs are talking using TCP/IP protocols, packets at data link layer
    should always be placed at the same memory location and th?

    So if memory location for TCP/IP packets is 100, then when A and B
    are communicating using TCP/IP, packets are stored at memory location
    100. And if C and D are communicating using TCP/IP, then packets are
    also stored at memory location 100?



    b) why didn't folks at IEEE instead use numbers inside LLC field to
    identify upper layer protocols ( 1 for IP, two for IPX ... or
    something
    to that effect)? Why complicate the matter by specifying memory
    locations?



    3)
    Now if SAP identifies which upper layer protocols should receive a
    packet, then why the need for SNAP? Can't SAP identify TCP/IP protocol
    ( BTW - I know official reasoning is that SNAP is used for backwards
    compatibility with Ethernet 2, but that makes no sense since that
    would suggest that if one was to create NIC drivers just for DIX
    version, they would automatically understand 802.3 SNAP frame type,
    which isn't the case at all )?

    uh, I apologise for that

  3. Re: I'm a beginner and already very lost - LLC and SNAP

    On Dec 14, 8:19 pm, failure...@yahoo.co.uk wrote:
    > Now to my questions:
    >
    > 1)
    > According to definition of LLC sublayer, among other things LLC
    > allows upper layer protocols to operate without specific knowledge of
    > lower layer protocols. If I understood this correctly, LLC sublayer
    > provides common interface for all upper layer protocols .
    >
    > Why is that such a big deal? Couldn't interface between data link and
    > higher layers be uniform even if there would be no LLC sublayer, but
    > instead just MAC sublayer ( with some extra functionality of
    > course )?


    Yes, in fact. You simply need to identify the upper level protocol
    being encapsulated within the Ethernet, or other L2, frame. If you
    think of the MAC layer and the LLC layer as being the lower and upper
    half of the Link Layer, then most of the time the LLC layer itself is
    almost nothing. It consists usually of just the Ethertype field in the
    "type" format of an Ethernet frame. When IP is transmitted over
    Ethernet, that's what you'll almost always see.

    However, other LANs, such as Token Ring and FDDI, always use the LSAP
    and SSAP fields, so you have to make that scheme work. Somehow, you
    need to indicate to the receiver what protocol type is encapsulated in
    the frame.

    > 2)
    > I found one LLC definition saying:"SAPs are Service Access Ports. A
    > SAP is a port (logical link) to the Network layer protocol. If we were
    > operating a multi protocol LAN, each Network Layer protocol would have
    > its own SAP.


    The whole SAP concept didn't work out. After all the IEEE 802.2
    participants had their say, there weren't enough bits left to identify
    enough protocols to make it viable. Essentially, you have 6 bits
    available to identify protocols, using the SAP format. I think you are
    putting too much weight on this. And in addition, all the extra
    capability promised by this scheme, for example connection-oriented
    communications at the link layer, did not prove necessary. The most
    important thing to take away is that the scheme, if used at all, is
    most used with 0xAA-AA-03 as source and destination SAP and CTL
    fields, followed by the SNAP header, which incorporates a proper 16-
    bit Protocol ID field.

    > 3)
    > Now if SAP identifies which upper layer protocols should receive a
    > packet, then why the need for SNAP?


    Not enough bits in SAP. The SNAP header allows any company to define
    its own protocols without having to register them with the IEEE (once
    they have an OUI assigned, of course). In nets like Token Ring or
    FDDI, you usually end up using the 0x00-00-00 OUI followed by same 2-
    byte protocol ID as you would in the "type" format of Ethernet.

    Bert

  4. Re: I'm a beginner and already very lost - LLC and SNAP

    hello

    Sorry for asking so many questions, but I really really need to know
    this

    >> 1)
    >> According to definition of LLC sublayer, among other things LLC
    >>allows upper layer protocols to operate without specific knowledge of
    >>lower layer protocols. If I understood this correctly, LLC sublayer
    >>provides common interface for all upper layer protocols .
    >>Why is that such a big deal? Couldn't interface between data link and
    >>higher layers be uniform even if there would be no LLC sublayer, but
    >>instead just MAC sublayer ( with some extra functionality of
    >>course )?

    >
    >Yes, in fact. You simply need to identify the upper level protocol
    >being encapsulated within the Ethernet, or other L2, frame. If you
    >think of the MAC layer and the LLC layer as being the lower and upper
    >half of the Link Layer, then most of the time the LLC layer itself is
    >almost nothing. It consists usually of just the Ethertype field in the
    >"type" format of an Ethernet frame. When IP is transmitted over
    >Ethernet, that's what you'll almost always see.
    >However, other LANs, such as Token Ring and FDDI, always use the LSAP
    >and SSAP fields, so you have to make that scheme work. Somehow, you
    >need to indicate to the receiver what protocol type is encapsulated in
    >the frame.


    So at LLC sublayer there isn't yet Ethernet frame constructed, right?
    Only thing that exists at LLC layer is packet ( which higher protocol
    levels created ) to which LLC attaches its header. Only after packet
    arrives at MAC layer, is Ethernet frame created?

    Anyhow, instead of making two sublayers, we could just have MAC layer
    when packet arrives from higher layers, this packet would be
    encapsulated in a standardized frame ( meaning it would be the same no
    matter if LAN is of type Ethernet, or token ring or... ). And this frame
    would also have two byte field identifying upper layer protocols. Thus
    frame could be made of the following fields:

    * preamble
    * destination address
    * source address
    * Type_field ( identifying upper level protocols; could be of whatever
    length )
    * Data
    * CRC

    a) Now wouldn't the above frame also enable uniform interface between
    data link and higher levels, no matter what LAN type is?

    b) Since that would be the simplest things to do, and yet people at
    IEEE choose to complicate the matters with LLC sublayer and SNAP and
    what not, I'm thinking that I must be missing something very obvious
    here.

    >> 2)
    >> I found one LLC definition saying:"SAPs are Service Access Ports. A
    >> SAP is a port (logical link) to the Network layer protocol. If we were
    >> operating a multi protocol LAN, each Network Layer protocol would have
    >> its own SAP.

    >
    >The whole SAP concept didn't work out. After all the IEEE 802.2
    >participants had their say, there weren't enough bits left to identify
    >enough protocols to make it viable.


    But still, as you've said it yourself, token ring and FDDI use RSAP
    and LSAP to identify certain protocols?

    > Essentially, you have 6 bits available to identify protocols, using the SAP
    > format. And in addition, all the extra capability promised by this scheme,for
    > example connection-oriented communications at the link layer, did not prove
    > necessary. The most important thing to take away is that the scheme, if used
    > at all, is most used with 0xAA-AA-03 as source and destination SAP and CTL
    > fields, followed by the SNAP header, which incorporates a proper 16- bit
    > Protocol ID field.


    Since protocol ID field inside SNAP header is also used with other
    types of LAN and not just ethernet, then which upper layer protocols
    do LSAP and DSAP identify?


    >> 3)
    >> Now if SAP identifies which upper layer protocols should receive a
    >> packet, then why the need for SNAP?

    >
    > Not enough bits in SAP. The SNAP header allows any company to define
    > its own protocols without having to register them with the IEEE (once
    > they have an OUI assigned, of course). In nets like Token Ring or
    > FDDI, you usually end up using the 0x00-00-00 OUI followed by same 2-
    > byte protocol ID as you would in the "type" format of Ethernet.
    >Bert
    >


    a) Why is OUI equal to 0000 for Ethernet LANs, but for other LAN
    ( token ring etc ) types OUI identifies specific vendors?
    Why don't we need to know OUI when running Ethernet LANs, but have to
    know OUI with token rings etc?


    b) So if I build my own token ring network and run TCP/IP on top of
    it, then on my token ring network OUI field inside SNAP header will
    identify certain vendor Which one ?
    And if I run TCP/IP, then what is the point knowing OUI of a vendor
    ( truth be told, I have no idea what this vendor might be ... is it NIC
    manufacturing company, or software company, or ... )?


    thank you for helping me



  5. Re: I'm a beginner and already very lost - LLC and SNAP

    On Dec 16, 9:04 pm, failure...@yahoo.co.uk wrote:

    > So at LLC sublayer there isn't yet Ethernet frame constructed, right?
    > Only thing that exists at LLC layer is packet ( which higher protocol
    > levels created ) to which LLC attaches its header. Only after packet
    > arrives at MAC layer, is Ethernet frame created?


    True. For example, at LLC sublayer, you don't know yet whether you'll
    be constructing an Ethernet "length" format frame, and FDDI frame,
    Token Ring, ATM LANE, or other.

    > Anyhow, instead of making two sublayers, we could just have MAC layer
    > when packet arrives from higher layers, this packet would be
    > encapsulated in a standardized frame ( meaning it would be the same no
    > matter if LAN is of type Ethernet, or token ring or... ). And this frame
    > would also have two byte field identifying upper layer protocols. Thus
    > frame could be made of the following fields:
    >
    > * preamble
    > * destination address
    > * source address
    > * Type_field ( identifying upper level protocols; could be of whatever
    > length )
    > * Data
    > * CRC
    >
    > a) Now wouldn't the above frame also enable uniform interface between
    > data link and higher levels, no matter what LAN type is?


    Yes, and that's the Ethernet "type" format. Which in practice is the
    one that survived and is thriving today.

    > b) Since that would be the simplest things to do, and yet people at
    > IEEE choose to complicate the matters with LLC sublayer and SNAP and
    > what not, I'm thinking that I must be missing something very obvious
    > here.


    I don't know that you're missing anything, actually. The IEEE tried to
    add bells and whistles to the orignal Xerox version of the Ethernet
    frame, to add features at the Link Layer, but those bells and whistles
    did not prove interesting. So at some point in the late 1990s, the
    IEEE went ahead and adopted the original Ethernet "type" frame format
    and incorporated it into IEEE 802.3, along with the IEEE's original
    concept of the specific LLC sublayer. You have to understand that in
    the early days, many people were putting a lot of importance on the L2
    network itself, not assuming that some higher Layer 3 protocol would
    necessarily be used as well.

    > >The whole SAP concept didn't work out. After all the IEEE 802.2
    > >participants had their say, there weren't enough bits left to identify
    > >enough protocols to make it viable.

    >
    > But still, as you've said it yourself, token ring and FDDI use RSAP
    > and LSAP to identify certain protocols?


    DSAP and SSAP. Most of the time, what these other L2 nets do is simply
    set DSAP and SSAP to 0xAA-AA, then CTL 0x03 and OUI 0x00-00-00. It's
    just that they don't have the simple "type" format as an option,
    that's all. Besides, Token Ring and FDDI are more or less legacy LAN
    types these days, fading away in the sunset.

    > Since protocol ID field inside SNAP header is also used with other
    > types of LAN and not just ethernet, then which upper layer protocols
    > do LSAP and DSAP identify?


    Read this:

    http://en.wikipedia.org/wiki/SSAP

    Examples of SSAP and DSAP use are to create connection-oriented as
    well as acknowledged forms of links at the Link Layer, without having
    to depend on upper protocol layers as we typically do today. Back in
    the early days, people involved in creating these standards did not
    necessarily go in assuming that whenever an L2 network type was
    specified for some system, there would always have to be a Network
    Layer involved as well. For example, you are assuming that with
    Ethernet, one must always use IP as well, right? Why? Why can't I
    instead create a network that works at the Link Layer WITHOUT having
    to layer IP over Ethernet?

    > a) Why is OUI equal to 0000 for Ethernet LANs, but for other LAN
    > ( token ring etc ) types OUI identifies specific vendors?


    The OUI has nothing to do with what type of L2 net you're using. I
    simply said that IF the 0x00-00-00 OUI is used, THEN Protocol ID that
    follows is the same as the "type" value in an Ethernet 2-byte "type"
    field.

    > Why don't we need to know OUI when running Ethernet LANs, but have to
    > know OUI with token rings etc?


    You do need to know the OUI if you use Ethernet "length" format and
    LLC/SNAP encapsulation. But it's not MANDATORY to use LLC/SNAP with
    Ethernet. When IP is layered over Ethernet, no one ever uses LLC/SNAP.
    But in principle, you could do so. With Token Ring and FDDI, you HAVE
    TO use the LLC/SNAP format.

    > b) So if I build my own token ring network and run TCP/IP on top of
    > it, then on my token ring network OUI field inside SNAP header will
    > identify certain vendor Which one ?
    > And if I run TCP/IP, then what is the point knowing OUI of a vendor
    > ( truth be told, I have no idea what this vendor might be ... is it NIC
    > manufacturing company, or software company, or ... )?


    If you want to run IPv4 over Token Ring or FDDI, set OUI to
    0x00-00-00, CTL to 0x03, and the Protocol ID to 0x0800.

    If you want to create some special protocol for some special
    application, then you can use the OUI that belongs to your company and
    create a new 16-bit Protocol ID of your own. And the only people you
    need to consult are folks in your own company, to agree on the
    Protocol ID value for your special protocol and make sure it doesn't
    conflict with other Protocol ID values your company might have out
    there. This is why you might want to use LLC/SNAP encapsulation also
    over Ethernet. It gives you that flexibility.

    Bert

  6. Re: I'm a beginner and already very lost - LLC and SNAP

    hello

    things make much more sense now. Just these three questions if I may:

    Must token ring and FDDI always use 802.3 SNAP frame type or can they
    also use 802.3 frame type without the SNAP header?
    What kind of LANs are using 802.3 frame without SNAP header?


    I'm assuming that if upper layer protocol ( this protocol may very
    well be one we'd identify inside LLC header by specifying vendor's
    OUI ) wants to communicate with some other PC, then NIC driver must
    be aware of existance of such protocol?


    Are there any protocols from specific vendors ( which are identified
    in LLC header by specifying OUI of a vendor) that are very popular and
    as such most of NICs in personal PCs over the world are aware of them
    and thus can recognize them?

    thank you

  7. Re: I'm a beginner and already very lost - LLC and SNAP

    On Dec 17, 6:31 pm, failure...@yahoo.co.uk wrote:


    > Must token ring and FDDI always use 802.3 SNAP frame type or can they
    > also use 802.3 frame type without the SNAP header?


    Token Ring is IEEE 802.5, not 802.3. It always uses LLC/SNAP
    encapsulation. FDDI is an ANSI standard X3T9.5, also not IEEE 802.3.
    FDDI also always uses the LLC/SNAP encapsulation. In those years, I'm
    talking 1980s and even early 1990s, the general feeling was that LLC/
    SNAP encapsulation is what all LANs would migrate to.

    > What kind of LANs are using 802.3 frame without SNAP header?


    Well, 802.3 *is* Ethernet, right? I'm sure you can find tons of
    references to that fact online. So 802.3 is the main one that does not
    have to use LLC/SNAP. But there are also ways of sending IP or other
    layer 3 and above protocols over ATM that do not require the use of
    LLC/SNAP.

    > I'm assuming that if upper layer protocol ( this protocol may very
    > well be one we'd identify inside LLC header by specifying vendor's
    > OUI ) wants to communicate with some other PC, then NIC driver must
    > be aware of existance of such protocol?


    Well, for sure something has to be able to shuttle that frame over to
    some protocol stack other than IP and ARP.

    > Are there any protocols from specific vendors ( which are identified
    > in LLC header by specifying OUI of a vendor) that are very popular and
    > as such most of NICs in personal PCs over the world are aware of them
    > and thus can recognize them?


    Not "very popular" that I know of. But, for example, we use that
    feature for stuff we do.

    Bert

  8. Re: I'm a beginner and already very lost - LLC and SNAP

    hello

    On Dec 18, 2:29 am, Albert Manfredi wrote:
    > On Dec 17, 6:31 pm, failure...@yahoo.co.uk wrote:
    >
    > > Must token ring and FDDI always use 802.3 SNAP frame type or can they
    > > also use 802.3 frame type without the SNAP header?

    >
    > Token Ring is IEEE 802.5, not 802.3.


    ups, I'm sorry about that. I meant 802 frames in general

    thank you for your kind help. I really appreciate it

    bye






+ Reply to Thread