- Simplicity versus Flexibility versus Optimality
- Knowing the Problem You're Trying to Solve
- Overhead and Scaling
- Operation Above Capacity
- Compact IDs versus Object Identifiers
- Optimizing for the Most Common or Important Case
- Forward Compatibility
- Migration: Routing Algorithms and Addressing
- Parameters
- Making Multiprotocol Operation Possible
- Running over Layer 3 versus Layer 2
- Robustness
- Determinism versus Stability
- Performance for Correctness
- In Closing
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
18.10 Making Multiprotocol Operation Possible
Unfortunately, there is not just one protocol or protocol suite in the world. There are computers that want to be able to receive packets in multiple "languages." Unfortunately, the protocol designers do not in general coordinate with each other to make their protocols self-describing, so it is necessary to figure out a way to ensure that a computer can receive a message in your protocol and not confuse it with another protocol the computer may also be capable of handling.
Real-World-Protocol
False economy protocol. At one company, in order to "save money" they periodically banned buying supplies. People got used to expecting periods of "famine" and hoarded supplies, wildly overstocking when the ban was lifted. After a few weeks of a ban, the various groups spent a great deal of time and energy bartering supplies. For example, a group with a surplus of toner might be able to exchange toner for printer paper.
Because there are several methods of doing this, it can be confusing. There is no single "right" way even though the world would be simpler if everyone did it the same way. I will attempt to explain the various approaches.
-
Protocol type at layer n–1: This is a field administered by the owner of the layer n–1 specification. Each layer n protocol that wishes to be carried in a layer n–1 envelope is given a unique value. The Ethernet standard has a protocol type field assigned.
-
Socket, port, or SAP at layer n–1: This consists of two fields at layer n–1: one applies to the source, and the other applies to the destination. This makes sense when these fields must be applied dynamically. However, almost always when this approach is taken, there are some predefined well-known sockets. A process tends to listen on the well-known socket and wait for a dynamically assigned socket from another machine to connect. In practice, although the IEEE 802.2 header is defined as using SAPs, in reality the field is used as a protocol type. The SAP values are either well known (and therefore the destination and source SAP values are the same), or they are set to the "SNAP SAP" and multiplexing is done with a protocol type later in the header.
-
Protocol type at layer n: This consists of a field in the layer n header that allows multiple different protocol n protocols to distinguish themselves from each other. This technique is usually used when multiple protocols defined by a particular standards body share the same layer n–1 protocol type. The ISO layer 3 protocols start with a value known as NLPID to distinguish between CLNP, ES-IS, IS-IS, and so on, all of which use the same layer n–1 protocol type.
One could argue that the version number field in IP is actually a layer n protocol type, especially because "version" = 5 is clearly not intended as the next "version" of IP. The intention for IPv6 was that the version number allow IPv6 to be distinguished from IPv4 and that they could share the same layer 2 multiplexing value. However, some components assumed, based solely on the layer 2 protocol type field, that they were dealing with an IPv4 packet, and so would misparse an IPv6 packet. So IPv4 and IPv6 are actually distinguished by having different layer 2 protocol types. So the multiplexing information might be one field or two (one for source, one for destination), and the multiplexing information might be dynamically assigned or well known.
Multiplexing based on dynamically assigned sockets does not work well with n-party protocols or connectionless protocols. In particular, IEEE made the wrong choice when it changed the Ethernet protocol to have sockets (SAPs), especially with the destination and source sockets being only 8 bits long. Furthermore, it defined two of the bits, so there were only 64 possible values to assign to well-known sockets and only 64 possible values to be assigned dynamically. Because of this mistake, the cumbersome and confusing SNAP encoding was invented.
Dynamically assigned sockets are useful at layer 4. How can you do that using something such as Ethernet that has only a protocol type field? The answer is to define one protocol type to be dynamically assignable sockets layer, which would be something similar to UDP. Let's call that L2UDP (for "layer 2 UDP"). The layer 2 protocol would indicate L2UDP. The next layer would contain the sockets indicating the source and destination processes. This is really how protocols such as AppleTalk and IPX, which contain both a packet type and destination/source socket numbers, should be used.