Ethernet addressing

Introduction: Ethernet Header fields An ethernet packet has a header which contains three fields

1. A six byte destination address
2. A six byte source address
3. A two byte "protocol type" field

The source and destination addresses define the physical ethernet interface which recieve or sent the packet, respectively. These addresses are not, in general, modifiable by the user. Therefore, in order to distinguish packets intended for different logical destinations within the same machine, the protocol type field is all that remains. Normally, this field is used to select a higher level protocol, such as UDP, TCP, or TP4, which then interprets part of the rest of the packet as further subaddressing information in some format or other. The user of raw ethernet packets, however, must use different protocol types to distinuguish packets which would otherwise have identical headers. Most drivers which allow access to raw ethernet packets allow one to specify the partner address and/or the protocol type one wishes to use.

Address format In the RPC address format, the peer address and protocol type are specified in hexadecimal, with a medium name of "ETHERNET". <rpc_address> ::= <peer_address> [ <protocol_type> ] .ETHERNET <peer_address> ::= * | <byte><byte><byte><byte><byte><byte> <protocol_type> ::= <byte><byte> <byte> ::= [ _ ] <hex_digit> <hex_digit> Example: AA_00_04_00_2F_58_5050.ETHERNET This refers to ethernet node AA_00_04_00_2F_58 (which might be a particular VAX, for example) and protocol type 5050. The default protocol type used by the RPC system is is 5050 hex. This is assumed if none is given. Example: AA_00_04_00_2F_58.ETHERNET

Wildcard address In all cases, one must specify a protocol type (or the default is assumed). Normally, one also specifies the peer (partner) node address. An exception to this is when a server listens to any other node, in which case the peer address is replaced with a "*" ("$" is used under OS9, to prevent conflict with special meaning of "*") ..us Example ..bf MONO *.ETHERNET ..pf This refers to any ethernet node, protocol type 5050. It is known as a wildcard address. ..us Example ..bf MONO *_5055.ETHERNET ..pf This refers to any ethernet node, protocol type 5055.

Rules The following rules are necessary to prevent conflict:

• At CERN, RPC users should not use protocol types outside the range 5000 to 51FF hexadecimal (or a range allocated to their group), as other values may conflict with other traffic on the Ethernet and cause widespread chaos. Type 5052 should also be avoided, as that is used for Valet&hyphen.Plus bootstrap broadcast messages.
• Two processes in one node which talk to the same partner node must use different protocol types.
• Under OS9 (with the driver written by Tim Charity), no two tasks may use the same protocol type, even if they are talking to different nodes.
• No user should use a wildcard ethernet address on a multiuser machine without ensuring that noone else on that node is using the protocol type at all.

It is clear that in a complex system, some thought is necessary for the allocation of protocol types. Two simple ways of allocating types are as follows.

1. For one&hyphen.to&hyphen.one communication between tasks, specify both the protocol type and the ethernet address of the partner. The protocol type need only be unique within the process (or node, for OS9). Example ..fo off Server refers to client as: AA0004002F58_5050.ETHERNET Client refers to server as: AA0004004558_5050.ETHERNET
2. For a server handling many clients, specify only the protocol type, and leave the address wildcard. Example Server refers to client as: *_5050.ETHERNET Client refers to server as: AA0004004558_5050.ETHERNET ..fo on In this case, check that the server is the only process using that protocol type on the node in question.

The RPC system runs its own protocol over ethernet in order to ensure reliable transmission. Note: When ethernet is used, the package number should not be given explicitly in the RPC address: rather, the name should be given. This forces the RPC system to make an initial call to discover the package number. If it is not done, the first call (only) may be executed twice.