DSAP and SSAP in LLC (link logic control)

[sheepuking wu]

Hello,

Recently I have studied IEEE 802.2 standard, and I have some problems as follow:

1.IEEE 802.2 standard has desceribes that DSAP address can be "FF" or "00" .

If address is "FF", this is broadcast DSAP address; if address is "00", this is null DSAP address.

But actually, I found that LLC packet which captured from Internet, its DSAP address is always unicast address (ex, 0x42, 0xE0...), instead of  broadcast address or null address.

In what situation the switch or other network devices can send LLC packet which DSAP address is "FF" or "00" ?

2.  In ethernet II frame, the length of ethertype is 16 bits so that it can identify many different protocolswhich is  in high layer. But in IEEE 802.2, the length of DSAP and SSAP address is only 8 bits, in other words, it can identify fewer different protocols than ethernet II, why the length of DSAP and SSAP address was not instituted to 16 bits ?  If these address is 16 bits, LLC can't identify ferwer different protocols than ethernet II .

Thank you.

[Peter Paluch · Accepted solution]

Hello,

IEEE 802.2 standard has desceribes that DSAP address can be "FF" or "00" .

Hmm, I think the 802.2 is not that strict as to limit the DSAP to only these two values. I have went over it briefly and I see no such requirement. What I see, and that is absolutely natural, is that both the DSAP and SSAP are 1B fields and therefore they can hold a value in the range of 0 to 255 inclusive, i.e 0x00 till 0xFF. The 802.2 standard itself defines these two values; other standards or recommendations add their own DSAP/SSAP codepoints.

The public listing of all SAP assignments is available on this page:

http://standards.ieee.org/develop/regauth/llc/public.html

But actually, I found that LLC packet which captured from Internet, its  DSAP address is always unicast address (ex, 0x42, 0xE0...), instead of   broadcast address or null address. 

Absolutely correctly. The 0x42 SAP designates the Spanning Tree Protocol. I am not sure about the 0xE0 value - in an older document, I have found that it could designate the ancient Novell IPX protocol encapsulated in 802.2 LLC frames.

In what situation the switch or other network devices can send LLC packet which DSAP address is "FF" or "00" ? 

I do not believe you would see such occurence in modern networks. The 802.2 states that the Null SAP addresses the MAC layer of the receiver itself, without speaking to any higher protocol on the higher layer. On the page 63 of the 802.2-1998, the following usage of Null SAP is suggested:

1) The XID command PDU with a null DSAP and a null SSAP is a way to solicit a response from any station (i.e., any DA). As such it represents a basic “Are You There?” test capability.
...
5) An XID exchange with a null DSAP and a null SSAP can identify the class of each LLC.

You could find even more references to using the Null SAP in the 802.2. However, all this usage suggestion refers to using HDLC-style communication over Ethernet which is, to my best knowledge, not used at all today.

The Global SAP would be used if you wanted all higher protocols on the receiving station to process your datagram. However, that would require that the datagram is universally understandable to all those higher-layer protocols which is not the case in modern networks (an IPv4 driver cannot process IPv6 or IPX packets and vice versa).

The page 63 of the 802.2-1998 suggests:

2) The XID command PDU with a group DA or group DSAP address can be used to determine the group membership. In particular, the XID command PDU with a global DA address can identify all active stations.

Once again, however, as neither pure 802.2+IP nor HDLC/LAPB type of communication is being used on IP-over-Ethernet networks, these SAP values currently not commonly used.

2.  In ethernet II frame, the length of ethertype is 16 bits so that it  can identify many different protocolswhich is  in high layer. But in  IEEE 802.2, the length of DSAP and SSAP address is only 8 bits

Yes, you are right here. This is related to the history of Ethernet evolution and its subsequent standardization in IEEE. Originally, the Ethernet was invented in Xerox and put forward by Digital, Intel and Xerox (hence the name DIX Ethernet). The Ethernet frame as proposed by DIX contained the EtherType field which was 2 bytes long.

According to Radia Perlman's book Interconnections, Second Edition, when IEEE started to standardize Ethernet afterwards, they felt that it would be more flexible (for whatever reason) to have the EtherType field split to the sending and receiving part, in order to allow two different protocols to communicate, or to allow two identical protocols to have different numbers on different stations. So they split the EtherType field into two halves and created the DSAP and SSAP fields. Keep in mind that it happened in early 1980s when it was thought that having 64 available values in a single SAP field (as 2 bits are reserved for other purposes) would be sufficient.

They soon realized, however, that the number or protocols is quickly growing and the DSAP/SSAP fields are too narrow to allow their unambiguous enumeration. So they first thought that they will register a special DSAP/SSAP value and follow the DSAP/SSAP/Control fields with the original EtherType header.

However, somebody pointed out that that would make the Ethernet header length an odd number - 12B in DMAC/SMAC addresses, 2B length, and 3+2B DSAP/SSAP/Control/EtherType. For 16-bit computers of that era that liked to have arrays aligned to 2B boundaries, this could lead to inefficient memory operations. So somebody came in with an "ingenious" idea: to put another 3B field along with the EtherType to the frame that would identify the OUI of the protocol author and to allow that author to essentially have its own unique namespace of EtherTypes, without requiring him to officially register them individually. And, of course, by adding a field with odd number of bytes to a header whose length is already an odd number, the new total header length would be an even number: 6+6+2+3+3+2=22B (DMAC/SMAC/LEN/DSAP+SSAP+Control/OUI/EtherType). Hence, the SNAP Ethernet format was born: DSAP/SSAP are set to 0xAA, then the Control field comes in, and then the 3B OUI of the protocol author, and then the protocol number itself in the form of EtherType.

All this hassle just because IEEE was strongly inspired by the HDLC/LAPB frame formats and tried to bring the same semantics to Ethernet, also including the unfortunate idea of separate source and destination SAPs...

For IP-over-Ethernet communication, all these SAP-formatted frames were never popular. As a curiosity, IP is unusable over pure 802.2 (no SNAP) networks because while IP has its SAP value, the ARP was not assigned any. Hence, you can not perform IP-to-MAC resolution because there is no standardized SAP value for ARP.

Does this help a bit?

Best regards,

Peter

[sheepuking wu]

Dear Peter ,

Thanks for your help.

Sorry I still has two problems as follow:

1.  The Global SAP would be used if you wanted all higher protocols on the receiving station to process your datagram. However, that would require that the datagram is universally understandable to all those higher-layer protocols which is not the case in modern networks (an IPv4 driver cannot process IPv6 or IPX packets and vice versa).

For example:

There are two network devices, which are named as host A and host B, and host A can only support IPv4. If host B sends IPv6 packets which DSAP is global SAP to host A , all higher protocols in host A will process these IPv6 packets. But these higher protocols can't understand the content of IPv6 header so they drop these IPv6 packets. In this example i can't think Global SAP is userful.

Is there any case in modern networks which can describe that the use of Global SAP?

2. They felt that it would be more flexible (for whatever reason) to have the EtherType field split to the sending and receiving part, in order to allow two different protocols to communicate, or to allow two identical protocols to have different numbers on different stations.

I think now in network moderns, many DSAP is unified in all network devices ,and may higher protocols whose DSAP address is same as SSAP address. For example, the DSAP and SSAP of spanning tree are 0x42 in all network devices, the DSAP and SSAP of Novell IPX protocol are 0xE0 in all network devices. 

In what situation the switch or other network devices can send LLC packet which DSAP is different from SSAP ?

3.  If two identical protocols which have different SAP address on different stations, can the station drop the LLC packets because it doesn't understand the SAP address although it supports this protocol ?

Thank you.

Best regards,

Wu.

[Peter Paluch · Accepted solution]

Hello Wu,

I understand your confusion, and I would like very much to bring a real-life example but the fact is that in our IP networks, the LLC/SNAP encapsulation is not used for IP communication at all. What you see encapulated in LLC/SNAP even in today's networks are mostly Layer2 management protocols like STP/RSTP/MSTP that were created in times when IP was not as common as today, or vendor's proprietary protocols, like Cisco's PAgP, DTP, CDP, PV(R)ST+, UDLD etc. that benefit from the SNAP encapulation and their own protocol namespace. It is also worth mentioning that the IS-IS routing protocol which is still extensively used is encapulated direcly into 802.2 LLC Ethernet frames. However, the common IP communication is encapsulated into Ethernet_II frames without DSAP/SSAP.

In what situation the switch or other network devices can send LLC packet which DSAP is different from SSAP ?

Perhaps we are looking at the SAP fields in a too much IP-oriented sense. The SAP stands for Service Access Point, i.e. a conceptual point where a particular service can be contacted. Now, let us think not in terms of protocols (i.e. languages, procedures and data structures) but in terms of services, i.e. activities offered and provided to the neighbors. I am now constructing an artificial scenario but think of this: Computer A is a server that accepts remote logins via some access service (like Telnet or SSH but let us not be limited to any of those). However, when authenticating a user that is logging in, the computer A needs to contact another computer B that runs some kind of authentication service (similar to RADIUS).

So when the computer A needs to authenticate a user, it will send a frame to computer B. The author of this frame will be the remote login service (the source SAP) on A, the intended recipient of this frame is the authentication service on B (the destination SAP). Here, the SAPs would certainly differ. A response would be sent from B to A so that the SSAP would be the authentication service on B, and DSAP would be the remote login service on A. Note that I am not talking now about protocols. I am talking about one service requesting an assistance of a second service. It is silently assumed that when A starts speaking to authentication service on B, it already knows the protocol (i.e. the language, procedures and data structures) that is used by the authentication server so that they can understand each other.

This scenario is hugely simplified (for example, it would require that both A and B are located in the same broadcast domain because I have not used any network protocol to allow communication over different networks), but I believe you get the point.

So, the SAP codepoints should not be considered as enumerating individual protocols - even though their are commonly used in this sense. Better, they should be considered as enumerating different services on the receiving hosts. The individual protocols spoken by these services are not really related to the DSAP/SSAP, and it may be assumed that there is another mechanism that the services use to find out which protocol they should speak in order to understand each other.

Is there any case in modern networks which can describe that the use of Global SAP?

None that I am aware of. However, a global SAP could be used, for example, to find out which services ar running on the remote host (similar to a broadcast "ping"). But once more, that is just an illustration. I have never seen Global SAPs being used - because the SAPs in general are limited to a very, very small set of protocols.

3.  If two identical protocols which have different SAP address on  different stations, can the station drop the LLC packets because it  doesn't understand the SAP address although it supports this protocol ?

Yes, such scenario is possible and the message could indeed be dropped. The DSAP is used as the demultiplexing field, and if there is no service or driver associated with a particular DSAP value, the message will be dropped even if its contents were understandable by the receiving host - because there is no service that would take care of handling that request.

Best regards,

Peter

[sheepuking wu]

Hello Peter,

Thanks for your help.

I have one opinion as follow:

According to your example:

So when the computer A needs to authenticate a user, it will send a frame to computer B. The author of this frame will be the remote login service (the source SAP) on A, the intended recipient of this frame is the authentication service on B (the destination SAP). Here, the SAPs would certainly differ. A response would be sent from B to A so that the SSAP would be the authentication service on B, and DSAP would be the remote login service on A.

I think when the people instituted LLC, they may think about  sender and receiver devices want to communicate with different higher layer services, so they described DSAP and SSAP can be different. But afterward  there is no mechanism using this feature currently, because the network scholar want to institute a uncomplex higher layer protocol .

Like as the above example, if the address of remote login service and authentication service are different, even there is a "login timeout service" or "port shutdown service" which has different address, the authentication mechanism will be complex because there are many different address in a authentication mechanism.  And if there are many different services exist in one computer, this will spend many memory space and affect  the effect of this computer.

So network scholar will institute a uncomplex higher layer authentication protocol which only has one service, and this service can do many different jobs. Since there is only one service in one computer,  this may spend fewer memory space and computer can work this mechanism effectively.

Do you think my opinion is correct or needed to be modified ?

Thank you.

Best regards,

Wu.

[Giuseppe Larosa · Accepted solution]

Hello Wu,

for point 2 a retrofitting of LLC has been introduced to allow use/re-use of a wider space for protocol type

I'm referring to LLC + SNAP

when LLC = 0xAA 0xAA 0x03 the following 5 bytes are seen as a 3 bytes OUI and a 2 byte protocol type

the 3 bytes OUI is similar to MAC OUI but it is used to provide a context (= which organization has published  the protocol type that follows).

LLC SNAP iss used for example in ATM networks when you configure an interface with aal5snap encapsulation you are referring to an LLC + SNAP encapsulation.

This kind of solution has no wide use in LAN environments as it uses 8 octets where Eth II uses 2.

However, an important exception is relative to several OSI L2 protocols like CDP, DTP, VTP and so on that actually use this encapsulation.

see

http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml

I agree that SSAP = DSAP in real world

Hope to help

Giuseppe

[sheepuking wu]

Hello Giuseppe,

Thanks for your information about LLC+SNAP.

Additionally, do you think the opinion which I took yesterday is correct or should be modified ?

Or do you have another opinion about this issue ?

Thank you.

Best regards,

Wu.

[Peter Paluch · Accepted solution]

Hello Wu and Giuseppe,

Giuseppe, thank you very much for joining the discussion!

Wu, regarding your idea about complexity versus simplicity: that can perhaps be an explanation. However, I somehow feel that the difference between the SAP and the EtherType approaches is more fundamental: it is based on a different approach, a different philosophy, a different understanding of inter-node communication. In our IP world, we are accustomed to talk about protocols, and we like very much to see a 1:1 relation between a service and a protocol providing that service. The authors of the SAP approach were most probably thinking more about services than about protocols, and wanted the principle to be more general, more flexible. Do not forget that both IP and Ethernet were created either by particular companies or at academic institutions with their practical approach to making things work. SAP approach is backed up by large standardization bodies that generally have a tendency towards creating very abstract, widely applicable and necessarily complex solutions.

I do not know if this helps. I guess that there is no great overwhelming logic behind the SAP vs. EtherType evolution. They were simply two approaches how to make these things run, as happens quite often in a real life, and one of those approaches became more popular.

Best regards,

Peter

[sheepuking wu]

Hello Peter,

Thank for your help.

Now I know  the origin of SAP more clearly.

I appreciate your help very much.

Best regards,

Wu.

[Giuseppe Larosa · Accepted solution]

Hello Wu,

in an IP world I would agree, however I suspect that in IBM networking that uses LLC encapsulation we might encounter cases where DSAP and SSAP may be different.

I had some exposure to DLSW+ in a banking network in the past, but the point is that what DLSW+ does is to carry these source bridged frames over IP tunnels. So I cannot say this for sure without looking at documentation

In that cases as there is no upper layer protocols DSAP and SSAP may play a role similar to a TCP socket as suggested by Peter.

Hope to help

Giuseppe

[sheepuking wu]

Hello Guiseppe,

Thank for your help.

I appreciate that you join this discussion and provide this case that there is no upper layer protocols DSAP and SSAP.

Best regards,

Wu.