Commands 0-2 must be implemented by all EDL,MDL and FDL entities. The description of these commands follows. For information on the QoS fields please refer to the MSQoS document.
This datagram is sent to establish a virtual circuit. Its delivery is not guaranteed, so the connect request must be retransmitted if no acknowledgement is received within a time-limit. The retransmissions should be separated by a sane time limit. The Wanda policy is one retry within about 20ms followed by one every 4s until the requested timeout is reached. It is considered permissible to broadcast a connection request where necessary.
The following fields contain valid information in a Connect Request message:
The Connect Confirm datagram is used to confirm a Connect Request, and hence accept a virtual circuit. If the requested circuit cannot be established, a Disconnect Request should be sent instead of Connect Confirm. There is no justification for broadcasting a reply since the sender must know who the recipient is.
The following fields are used in a Connect Confirm message:
This is used in two cases, it can close an existing connection, or it is sent if a cell arrives on an invalid connection. In the former case it can be sent directed and should not be broadcast. In the latter case it is necessary to broadcast it.
The following fields are used in a Disconnect Request message:
Commands 3-4 have never been implemented and so at present there is no description for these commands. No representation or semantics should be adopted without consulting an authority.
The address lookup or ``Rarp'' procedure is used to allow a stateless entity to discover its MSNL address using some local hardware feature. There is one reply which includes the address of the entity and the location of its boot server. There are three different types of request depending on whether an 802.2 Address, an MDL Station address, or a Port Controller Serial Number is being lookup up.
Note that any entity sending a reply must guarantee that the specified boot-server is reachable by the requesting machine on the interface which the reply is sent on. This stipulation is required because the receiver of a reply will set its only routeing information to use the interface on which it received the reply for its boot-server.
The following fields are used:
There is an additional weirdness in that the associd is not set correctly in this request and must be set to all ones to reply correctly.
The following fields are used:
The origAddress field contains two MSNL Addresses. The first one is the address being allocated to the requesting host. The second one is address of the entity sending the reply. It is recommended that a host receiving any reply whether requested or not should print out or log all these fields so that the correctness of tables may be ensured.
The following fields are used:
Care should be taken to send the reply to the correct place.
The following fields are used:
Additionally the VCI for returning the reply is sent in the manner appropriate for the data link.
Commands 12 and 13 are defined for the purposes of topology determination. At the time of writing they have been implemented on FDL networks only.
Nota Bene: The topology determination mechanisms are defined for the purpose of router-router discovery and for cases of flat ``bridge-type'' routeing within a MSNA subnetwork which is unsuitable for conventional routeing due to small host to data link ratios (point to point switch environments). It is not acceptable to use topology gathering mechanisms for situations which ought to be solved using correct subnet routeing tables.
The exact use of this MSDL command is as yet not precisely specified for the case of topology searching entities which react with each other. The definition here given is for the interaction between a topology searching entity and entities which are not involved in such topology determination.
The following fields are used:
This is the response to the above command of an MSNL entity which cannot become involved in topology discussions. It is forbidden for a MSNL entity to send this command except in response to a topology beacon. It is forbidden for a MSNL entity to send this command if it is capable of being involved in topology discussions.
The following fields are used:
Although the commands have been allocated to ORL no exact semantics or behavioural documentation has been received from them and so is not included here. As a result these commands are not considered valid on the general MSNA internet and may only be used at ORL.