It should be clear that the x-kernel was defined to allow a great deal of flexibility in how protocols are composed together; to avoid situations where protocol A must be composed on top of protocol B because A contains hard-coded dependencies on B. Being able to configure the protocol graph explicitly is one mechanism that advances this goal. The address stack mechanism just described is another. We now describe a third mechanism---how protocols specify their demux key.
In most conventional protocols, a low-level protocol uses a relative protocol number to identify the protocols above it. For example, IP identifies UDP with protocol number 17 and TCP with protocol number 6. It looks for these numbers in the header of an arriving packet to decide which high level protocol the packet should be passed to. These numbers are relative in that they only make sense to IP; if we were to configure a protocol graph in which UDP and TCP were above some other protocol, it could use some different set of numbers to decide which protocol should receive arriving packets.
The downside of relative addressing is that the low-level protocol needs to know about all the protocols that might be configured above it so that it can give them distinct relative protocol numbers. To circumvent this, protocols that have been especially designed to use the x-kernel use an absolute addressing scheme. The protocol number by which a given protocol is addressed is independent of which protocol is doing the addressing.
The x-kernel reconciles these two approaches by maintaining a table of relative protocol numbers. Rather than embed protocol numbers in the protocol source code, protocols learn the protocol numbers of protocols above them by querying this table using the following operation:
ProtId relProtNum(Prot hlp, Prot llp)
This operation returns the protocol number of the high-level protocol relative to the low-level protocol. This number will have to be cast into the appropriate type before it can be used.
The table of relative protocol numbers can then be configured with information that allows protocols to identify themselves according to the standard specifications, as well as to be more freely composed in non-standard ways. For example, the relative protocol number table might be configured as follows:
#
# prottbl
#
# This file describes absolute protocol id's
# and gives relative protocol numbers for those
# protocols which use them
#
eth 1
{
ip x0800
arp x0806
rarp x8035
#
# ethernet types x3*** are not reserved
#
blast x3001
}
ip 2
{
icmp 1
tcp 6
udp 17
#
# IP protocol numbers n, 91 < n < 255, are unassigned
#
blast 101
}
arp 3
rarp 4
udp 5
tcp 6
icmp 7
blast 8
rpc 9
This table specifies, for example, that IP is known by protocol number x0800 in the context of (relative to) protocol ETH, and that UDP is known by protocol number 17 relative to IP. Both of these examples are valid according to the standard specifications for ETH, IP, and UDP. Since the relative protocol numbers are carried in the packets, it is important to use the standard values if you want your implementation to interoperate with someone else's. Protocol BLAST is a non-standard protocol that one might want to configure on top of either ETH or IP; it is given protocol numbers x3001 and 101, respectively, in these two contexts.
Notice that in addition to giving certain relative protocol numbers, this table also assigns each protocol an absolute identifier; e.g., IP is given id 2 and BLAST is given id 8. For example, when protocol BLAST uses partRelProtNum to learn what protocol number to use to identify RPC, the operation returns 9; RPC's absolute protocol number. Unlike relative protocol numbers, absolute numbers are not transmitted in packets, so they need only be locally consistent.