The SAP transmits the announcements in IP UDP datagamms. They are periodically retransmitted, aproximately between every 5 and 10 minutes, depending on the scope of the announcement (refer to [Hand9611:SAP]. When trying to give computers access to such announcements using slow links, like PPP links over a modem line, the bandwidth occupied by the announcements will be very high. Each announcement transmitted will contain the SDP announcement, which is usually between 400 and 1000 bytes, plus the overhead for the IP/UDP/SAP protocols (at least 36 bytes). When sending such announcements uncompressed, it can happen that the link is unusable for other traffic for more than a second. This is too long when transfering multimedia data over the same link.
The major idea in this document is to transmit changes to the global session description database only. While doing so, we can reduce the needed bandwidth for transmitting such announcements. Because such announcements will be retransmitted after some time, the amount of saved bandwidth can be expected to be very high.
Today, only a few number of session announcements are online at a given time (less than 100). But one can expect that the number will increase significantly in the near future. Bacause of this, and because of the need to brind the mbone into the home, this compression technique was designed.
In order to keep the occupied bandwidth low, we will only send changes for a given context. On startup, each client and server has an empty set of contexts. Each context is identified by a context identifier (context-ID). This context-ID is maintained by the server, and the client has to allocate a new context if the server asks the client to do so.
When the client receives such an ASSIGN packet, it allocates a new context for the given context-ID, and stores all the information about the announement in the context. After the client has stored the data in the context, it sends out the received announement. This SHOULD BE done with the destination address and portnumber supported by the server. If the context-ID was in use by another announcement, the client assumes that this announement has been invalidated by the server and frees the context.
When the client receives the RETRANSMIT packet, he looks into it's set of contexts to find the one with the same context-ID. After he has found it, he transmitts the announement on it's side of the network.
The client has also the option to maintain a timer for each context. The timer will be restarted every time the client receives a RETRANSMIT packet. When the time has been esapsed, the client assumes that the announement has been deleted and frees the context and context-ID. There are two resulting possibilites:
At this point we get a serious problem, because the client receives the RETRANSMIT packet and transmits the old and wrong announcement which was stored in the given context. So the announcement received at the server will never be sended by the client; it get's lost.
To minimize this possible error, we also assign a generation-ID for each context-ID. Whenever the server assigns a new announcement to a context-ID, it HAS TO change this generation-ID, best by incrementing it by one. This generation-ID will be transmitted in every packet belonging to this context.
When the client receives a RETRANSMIT packet, it compares the generation-ID of the context with the one in the packet. If it is the same then the packet realy belongs to this announcement. Otherwise a packet has been lost and the context is out-of-date with the one in the server. So the client frees the context and context-ID, and sends a DELETED packet back to the server. Doing so informs the server that the client has no such context any more and the server HAS TO send a new ASSIGN packet to the client. Doing so results in a new assignment of the context and context-ID with the announcement. After the client has received this ASSIGN packet, both are now resynchronized.
Another possible problem can occur, when the very first ASSIGN packet for a context was lost. In this case, the client receives a RETRANSMIT packet after some time, but is not able to find the context-ID in it's list. The client HAS TO do exactly the same as described above, he has to send back a DELETED message to force the server to retansmit the assignment.
Whenever a new link will be established between two peers, each client normaly HAS TO send a global DELETED packet to the peer client and has to free each context. Each server receiving this global DELETED packet HAS TO free all its contexts. This ensures a consistent state on both sides.
However, if the link was interrupted for a short time only, each client has the oportunity not to send the global DELETED packet. This SHOULD BE done only when the client is sure that he has talked with this server directly before. The server then keep it's current set of contexts and therefore only needs to send RETRANSMIT packets, when the announement is known. If the server is not sure that he has talked with this client directly before, he has to oportunity to ignore this global DELETE packet. Doing to results in a server which has currently no assigned contexts.
The procedure described above enables a further kind of saving bandwidth. Even if the server has been crashed and the client accidently assumes that the server still knows it's context, no further overhead arrises. The server has an empty set of contexts and send ASSIGN packets for each announement. This results in overwriting the old context entries in the client without any problem. Because of the timeout timer the client HAS TO maintain, very old entries in it's context will also freed after some time automatically.
The global context-Id is a context-Id with all bits set to 1. So when
using a ....
0 1 2 3 4 5 6 7 octets +---+---+---+---+---+---+---+---+ | genId | c | op | 1 +---+---+---+---+---+---+---+---+ : context-Id : 1..2 +---+---+---+---+---+---+---+---+ : additional-data : 0..n +---+---+---+---+---+---+---+---+
The genId ist the generation-ID of the context, to which this packet belongs. This gives the client some kind of error detection in the case of packet loss due to an error. When the server assigns a new announement to a previously used context, it HAS TO change the generation-ID of the context by incrementing by 1. When this ASSIGN packet gets lost, and the client only reveives the RETRANSMIT packet, it detects an error, because the generation-ID is different. Having three bits, resulting in 8 different generation-IDs, the possibility of accidently receiving the save generation-ID is very small.
The operation code defines the type of the packet. Currently only three different packet types are defined, so 2 bits are enough to code them. But to let the room for further extensions, the operation code field was extended to 4 bits.
Today there the number of available announements is very small, less than 100 (received in Germany), so 1 octet, resulting in 256 possible contexts should be enough. But one can expect that the number will increase in the next time. Because of this, we extended the contest-ID up to 2 octets, resulting in 65536 different active announcements for a given time.
To minimize the overhead to send the context-ID, the context-ID can de transmitted with 1 or 2 octets. To let the client determine, who long the context-ID is, the C bit is used. If it is 0, then 1 octet is used for the context-ID, otherwide 2 octets.
In section [csap-err-handling] we introduced the use global DELETE packet. Ro reduce the number of packet types, we decided to reserve a special bit combination of the context-ID. So, when all bits in the 1 or 2 octet long context-ID are set to 1, we say that this is the global context-ID. This context-ID HAS NEVER to be used for a normal context-ID. It HAS ONLY to be used for the globel DELETE packet.
Depending of the operation code in the packet, additional data can follow the context ID.
Whenever the client or server receives an packet with an unknown op-code, it SHOULD silently discard this packet. There is no kind of an error indication available.
The next sections describes the detailed format of each packet type defined.
The ASSIGN packet is used to assign a session announcement to a given context-ID. The desciption of the announcement consists of the following fields:
Knowing these parameters, the client is able to handle the announcement and can transmit it in it's side of the network. If he does not understand the session announcement protocol or the session description protocol, it SHOULD never transmit a packet for this announcement. No error indication HAS TO be send back to the server.
- The IPv4 source and destination addresses of the announcement.
- The UDP source and destination port numbers. Together with the addresses, they give the client a hint, how to handle this packet and what to do with it. The client also needs this to retransmit the announcement on it's side of the network.
- An identifier for the session announcement protocol used for this announcement.
- An identifier for the session description protocol used. This can also be used to indicate the used compression.
- The announcement itself.
If the client knows both formats, it HAVE TO copy these fields into the context specified by the server. If the context was allready in use by another (or even the same) announement, it HAS TO BE silently overwritten (the server kows the context of the client, so he knows what he does). After the announement has been stored in the context, the client SHOULD tranmit the announcement using the right protocol on it's side of the network.
The server HAS TO change the generation-ID field for this announcement on every time he makes a new assignment for this context. The client needs this context-ID to perform some kind of packet loss checks. It is recommended that the server increments this generation-ID by one.
This packet can only be sent from the server to the client.
Packet format
0 1 2 3 4 5 6 7 octets +---+---+---+---+---+---+---+---+ | genId | c | 0 | 0 | 0 | 0 | 1 +---+---+---+---+---+---+---+---+ : context-Id : 1..2 +---+---+---+---+---+---+---+---+ : IPv4 source address : 4 +---+---+---+---+---+---+---+---+ : IPv4 destination address : 4 +---+---+---+---+---+---+---+---+ : UDP source port : 2 +---+---+---+---+---+---+---+---+ : UDP destination port : 2 +---+---+---+---+---+---+---+---+ | sap | sdp | 1 +---+---+---+---+---+---+---+---+ : announcement data : 0..n +---+---+---+---+---+---+---+---+
GenId
Specifies the generation ID for this context. The client HAVE to store this generation ID in it's context. The server HAVE to maintain the last generation ID for this context-ID and HAVE to use a different value than the one stored. The server SHOULD increment the generation ID by 1 on each time it makes a new assignment for this context-iD.
C-bit and Context-id
The C-bit specifies, if the following context-Id is 1 or 2 octets long (see [csap-c-bit]).
IPv4 Source Address
Specifies the IPv4 address of the host, from which the server received this announcement.
IPv4 Destination Address
Specifies the IPv4 address of the destination address. Usually, this is a IPv4 class D address (IP multicast). The client SHOULD send the announcement to this specified address.
UDP source port
Specifies the port of the originating host.
UDP destination port
Specifies the port for the destination address. In the case of an IPv4 multicast address, this will (normally) also specify the type of the announcement, but is not restricted to. The client HAVE to send the announement to this specified port.
Sap
Specifies the protocol, which is used to transmit this announcement. The header and tralier for the given protocol is still included in the Announcement-data. The function of this field is to allow some kind of compression to the specific announcement protocol, before it will be sent to the client. Before the compressed announcement protocol can be send, it HAVE to be uncompressed, so the client must be noticed of the type of compression used. Whenever an announcement is transmitted in it's original form, it SHOULD be marked as transparent.
Currently, the following session announcement protocols are defined:
When the receiving client does not understand the protocol used, it DON'T HAVE to transmit any outgoing packets for this context, until it has been assigned to another announcement.0000 transparent (i.e. don't care about the contents, simply use it)
Sdp
Specifies the session description protocol used. Like the Sap, the major use of this field is to indicate the kind of compression used.
Currently, the following values have been defined:
The same rules as for the Sap field applies here.0000 transparent (i.e. use it as is) 0001 gzip'd 0010 cSDP (currently work-in-progress)
Packet formatWhenever the server receives an announcement which has allready a assigned context on the client, it HAVE TO send the RETRANSMIT packet. When the client receives this packet, it HAS TO use the data stored in the context and SHOULD retransmit the stored announcement to the given address. Prior to sending, it HAVE TO check if the context is up to date. This is done by comparing the received generation-ID with the one stored in the context. If they are not the same, the client DO NOT HAVE to send out the announcement. Instead, it HAVE TO send a DELETED packet back to the server. The same has to be done if the client don't have a context with the given context-ID.
This packet can only be sent from the server to the client.
0 1 2 3 4 5 6 7 octets +---+---+---+---+---+---+---+---+ | genId | c | 0 | 0 | 0 | 1 | 1 +---+---+---+---+---+---+---+---+ : context-Id : 1..2 +---+---+---+---+---+---+---+---+
GenId
Specifies the generation ID for this context. If the generation ID in the context specified is different to the one received, the client HAVE TO invalidate the context and HAVE TO send a DELETED packet back to the server. It NEVER HAVE TO send any more announcements for this context, until it receives an ASSIGN packet.
C-bit and Context-id
The C-bit specifies the length of the following context-Id (see [csap-c-bit]).
... This packet can only be sent by a client to a server.
Packet format
0 1 2 3 4 5 6 7 octets +---+---+---+---+---+---+---+---+ | genId | c | 0 | 0 | 1 | 0 | 1 +---+---+---+---+---+---+---+---+ | Context-Id | 1..2 +---+---+---+---+---+---+---+---+
Gen-Id
Specifies the generation-ID, which has caused the client to invalidate the context. Generally, this is the same as the one received from the server in the previous RETRANSMIT packet.
Whenever the server receives a DELETED packet, it HAS TO reply with an ASSIGN packet to resynchronize the context with the client. If the context does no longer exists on the server, he HAS TO silently discard this packet.
C-bit and Context-id
The C-bit specifies the length of the following context-Id (see [csap-c-bit]).
The client can use the special encoded context-ID, known as the global context-ID to force the server to clear all its contexts. The server DON'T HAVE to send ASSIGN packets directly to the receipt of this packet.