The x-kernel runtime environment always includes a protocol table that defines the number space protocols use to identify each other. The x-kernel builds a table of protocol numbers by reading configuration files at runtime, and provides an operation for protocols to query this table to determine the protocol corresponding to a protocol number. This frees protocol developers from having to embed explicit protocol numbers in the protocol code itself.
The reason that the protocol table is needed may not be obvious. After an x-kernel protocol receives an incoming data message and finishes processing it, the message must be passed up to the appropriate higher-level protocol. To do this, the protocol must determine the high level protocol to which the message belongs; for example, the IP protocol must decide if a received message should be passed up to UDP or TCP. Each x-kernel message carries in its message headers fields containing the numbers of the protocols that sent it, and these determine which protocols should process the message on the receiving host. Thus, the protocol holding the message extracts the protocol number of the next high level protocol from the message header, queries the protocol table, and passes the message on to the indicated protocol.
If the graph.comp file does not include any non-standard protocols, one of the default protocol tables in /usr/xkernel/etc may safely be used.
The following is an example protocol table file.
#
# prottbl
#
# This file describes absolute protocol id's and gives relative
# protocol numbers for those protocols that 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
Each protocol has an entry of the form:
name idNumber [ { hlp1 relNum1 hlp2 relNum2 ... } ]
where idNumber uniquely identifies each protocol.
There are two ways for a protocol to define its protocol number space. The first technique uses an explicit numbering scheme; the protocol explicitly indicates which protocols may be configured above it and the relative number that should be used for each higher-level protocol. Use of this numbering scheme is indicated by the presence of the optional hlp list after the protocol's idNumber.
The second technique uses an implicit numbering scheme; the protocol does not explicitly name its allowed upper protocols, but will implicitly use each protocol's unique idNumber as its relative protocol number. BLAST, for example, employs this technique and would use SUNRPC's idNumber 9 as its protocol number relative to BLAST. Protocol ID numbers are 4-byte quantities in the x-kernel , so protocols using implicit numbering have a 4-byte field in their headers for the upper protocol number.
Implicit numbering clearly allows more flexibility in how protocols may be composed. As flexible composability is one of the goals of the x-kernel , all new protocols written in the x-kernel should use this implicit numbering scheme.
The x-kernel is distributed with two useful protocol table files: prottbl.std and prottbl.nonstd. These files are located in /usr/xkernel/etc. The first of these two files, prottbl.std, contains the standard protocol numbers; e.g., TCP is known as protocol ``6'' relative to IP, IP is known as protocol ``x0800'' relative to the ethernet, and so on. This file should be used when there is no danger of interfering with the standard protocol suite on the platform you are using. The second file, prottbl.nonstd, uses non-standard protocol numbers. You will want to use this file when there is a danger of interfering with the platform's native protocol stack; e.g., when both the x-kernel and the native stack are running and getting packets diverted their way by a packet filter.
All x-kernel s must load at least one protocol table, and all protocols configured in a kernel must have an entry in the protocol table. If you are writing a new protocol, you will probably want to define an auxiliary protocol table which assigns a temporary idNumber to your new protocol and then configure your kernel to read in both the system table and your auxiliary table. If you need to configure your new protocol above an existing protocol which uses explicit numbering, you can augment the table for the existing protocol as in this example.
#
# Auxiliary protocol table
#
asp 1000
ip 2 {
asp 200
}
Here, we define our new protocol ASP and indicate that it has protocol number 200 relative to IP. Note that when augmenting the tables of other protocols, the idNumber of the other protocol must match its number in the system file.
The x-kernel runs consistency checks on the protocol tables and will give error messages and abort in the presence of inconsistencies.
The protocol table files used by a particular instance of the x-kernel can be specified in either the graph.comp file (Section 12.2), or in a ROM file (see Section 12.4). The ROM file format is:
prottbl FILENAME1
prottbl FILENAME2
...
In both cases, the named protocol tables are loaded at runtime.
By default, the protocol table allows multiple upper protocols to use the same protocol number relative to a single lower protocol. To restrict this behavior, so that each upper protocol must have a unique relative protocol number, the unique_hlps ROM option may be used.
prottbl unique_hlps on