MTP : Multicast Trasport Protocol.

Contents

  1. Overview
  2. MTP Parameters
  3. Packet format
  4. Establishing a Web
  5. Joining a Web
  6. Sending Messages
  7. Web Master
  8. Data loss
  9. MTP and IPmulticast

Overview.

MTP provides reliable multicast delivery on an one to many and many to many basis. It may be used as the Transport layer of any network architecture provided the datalink layer includes some support for multicast. Clients of MTP need not be concerned with the geographical location and population of the web members. It uses only a small number of control packets with the bulk of syncronisation and control information being piggy backed onto client data packets.

Basic MTP parameters.

Heartbeat
A period of time measured in milliseconds. It may be adjusted to suite network conditions and desired quality of service.

Window
The number of packets a producer may multicast into the web during a single heartbeat.

Retention
The number of heartbeats a producer must retain transmitted packets in case they need to be resent.

These parameters may be changed while a web is in operation to reflect the network quality and the desired level of service.

Packet Format.

A transport packet consists of a fixed format transport header and a variable length data component.

There are 7 packet types, data, nak, empty, join, quit, token, isMember, each of which has several different type modifiers.

All transmitted packets contain information about the status of the last twelve messages, in the message acceptance vector. The status of a message may be pending, accepted or rejected. Only the master may set the status of a message. Messages are marked as accepted when the master has seen the whole message, pending when the master has not seen the whole message but suspects the producer is still active and rejected when the master suspects the producer has died or been partition away. As all packets carry this information all members of the web can see the state of messages and can disregard messages they received but where rejected by the master, or report failure if they have been unable to get a message that was accepted by the master.

Establishing a web.

The process that is first to establish at a particular NSAP will be the master of the web. It must make a robust effort to ensure that the NSAP is not already in service, by sending repeated join requests. If it receives no response it may assume the NSAP is not in use and may proceed with the creation of the web.

NSAP's are used to provide three logical ports called TSAP's. These are formed by concatenating the NSAP with a transport identifier. The TSAP's are unknown, individual, and multicast. The unknown TSAP is only used be clients requesting to join the web.

Joining a web.

After the master has established a web at a particular NSAP other clients may join the web be sending a join[request] to the unknown TSAP. The master may respond to this message with a join[accept] or join[deny] message. A join[accept] message includes the TSAP multicast address and the masters TSAP. A join accept should only be issued when no producers are in position of transmit tokens, so that the joining member will not observe partial messages and may receive application state information.

Sending Messages.

When a producer wishes to send a message it applies to the Master with a token[request] packet, this packet should be resent every heartbeat until the Master responds with a token[confirm] packet. The token[confirm] packet contains a message sequence number for the message the producer wishes to send. The data part of the packet contains a list of multicast TSAPs which are represented in the web. The producer may then send the data packets which constitute the message, attaching to each the message sequence number and an incremental packet sequence number. The network setup of heartbeat, window and retention govern how the message is sent. The producer must send at least one packet per heartbeat (measured in milliseconds) and up to a maximum of window packets. If the Producer has insufficient data to transmit a full data packet in a given heartbeat, it may transmit an empty[dally] message. The value of retention governs how long (in heartbeats) dispatched packets should be retained by the producer so that they may be resent if requested by consumers.

Web Master

Requests for tokens are directed to the master's individual TSAP. The master employs some fairness algorithm in responding to these requests with a token[confirm] packet. As a minimum it should use a FIFO ordering system. Note that the protocol allows for multiple transmit tokens. After issuing a token[confirm] packet and not seeing any data or empty[dally] packets from the intended recipient it must assume the token lost. It can query the status of the recipient with an isMember[request] to see if the recipient has died or become partitioned away from the web. In any case the token is reclaimed by the master.

In responding with a token[confirm] packet the master must increment the current message sequence number and shift the acceptance vector, so that the status of the oldest message is shifted out and a new pending status is shifted in to represent the new message. The status of pending may not be shifted out of the acceptance message, so the master may not confirm any token[request]s while a pending status is representing the oldest message.

Data Loss.

If a consumer sees an out of sequence Message Sequence Number, Packet Sequence Number pair, it applies to the producer to have the missing packet(s) resent, by issuing a nak[request] message containing a list of the missing packets. The producer will then resend (multicast) all the missing packets, resending these packets will reduce the number of new packets the producer may send in that window. Consumers must be able to cope with duplicate packets. If some of the packets have been discarded (because they were sent more than retention heartbeats ago) then the producer must respond with a nak[deny] message, if the consumer receives a nak[deny] it must report this loss to its client which may enter a failed state and have to withdraw from the web.

MTP over IPmulticast.

MTP on Internet Protocol uses the Internet Protocol multicast mechanisms defined in RFC 1112, "Host Extensions for IP Multicasting". MTP requires "Level 2" conformance described in that paper, for hosts which need to both send and receive multicast packets, both on the local net and on an internet. IP multicast does not provide the a port mechanism so a simple bridge protocol is needed to use encapsulate MTP packets within IP packets.