Introduction to LLC Layer | Orientation To Logical Link Control (LLC)

Orientation To Logical Link Control (LLC)

In Version II Ethernet a protocol developer was expected to register a new Ethertype identifier with Xerox. In 1982 (the year 802.3 was finalized) there were over 150 different Ethertypes. The IEEE wanted to create an open, international standard and the idea of registering with Xerox didn’t fit into that model. Instead of using a registered Ethertype the IEEE opened up the standard by conceiving of a service access point (SAP) identifier.

In one sense, the SAP performed much the same function as the Version II Ethertype value. They both identify a layer three processing agent that is able to understand the incoming frame. The LLC layer would look at the destination service access point (DSAP) value to determine where to place the frame for further processing; just like an Ethernet Version II data link layer agent looked at the Ethertype. Because source and destination stations could select their own service access point identifiers there would be no need for a standard registry.

There is one confusing point in this logic, however. You see, if I can pick my own service access point identifier for, say, Novell NetWare then I need some way to communicate that SAP number to you. This could have been done using an exchange identification (XID) frame. The problem is that we both would still have to agree on a code number to indicate that we were making reference to ‘Novell NetWare’ and not some other protocol stack. Let’s consider an example to bring this confusion to light..

I decide the use SAP E0 (hex) to refer to Novell NetWare. Now I’m going to construct an XID frame to communicate that fact to you. Do I use a text string to say, “NOVELL NETWARE”? Should I assign protocol type #1234 as the representation for ‘Novell’? You see, we still have to have a previously standardized agreement on a representation for each protocol processing agent. Xerox already had these; the Ethertype value.

Consequently, what we see in most frames on networks today is that the destination service access point (DSAP) number and the source service access point number (SSAP) are the same number! There has been general agreement to use the following ‘standard’ numbers:

• IBM gets every even multiple of 4 for SNA (i.e.: SAP=04, SAP=08, and so on.)
• Novell NetWare uses SAP=F0
• NetBIOS uses SAP=E0
• Banyan Vines uses SAP=BA
• And IP? Well, that’s another story…
  • IP was designed closely around the Ethertype value and it requires a special service access point, reserved by the IEEE, in order to access an IP subnet using an 802 frame. The issue of Sub-Network Access Protocol (SNAP) will be discussed in the next workshop session.

Topics In This Discussion

• Introduction to LLC Layer
• Defining “Connection-less” and “Connection-Oriented”
• Type 1 Logical Link Control
• Setting Up a Type II LLC Connection
• Transmitting and Acknowledging
• Data in Type II LLC
• Protocol Analysis Techniques for Type II LLC
• The Bits in the LLC Header
• Type 2 LLC Commands and Responses
• Type II LLC Commands and Responses
• Viewing LLC with your Protocol Analyzer
• The Rationale for Using a Reliable Data Link