RLP is open, but it's in one of those copyrighted industry standards. :-(
The latest version is in TIA IS-707.
Here's a thumbnail sketch of RLP. It's a pure-NAK protocol; there are no
positive ACKs.
The input is assumed to be a byte stream. This byte stream can be a
PPP-framed series of packets, but the protocol doesn't directly assume this.
The physical layer carries frames at a synchronous 50 Hz (20ms) rate,
with the clock derived from GPS. The sender can choose one of four
fixed sizes for each frame. The gross frame sizes have the ratio
1:1/2:1/4:1/8, and are implemented by puncturing a convolutional code.
The usable frame sizes are smaller and not exactly in these ratios
because of non-constant per-frame physical layer overhead.
The incoming byte stream is segmented into frames, a sequence number
is stuck on the front, and sent over the channel. The receiver
quietly passes these frames to the upper layer unless it sees a gap in
the incoming sequence space. If a gap is seen, subsequent frames are
put on a reassembly list and a NAK control frame is returned giving
the range of missing sequence numbers.
The link is full duplex, so the receiver can be sending data of its
own, each side muxing in NAKs as appropriate for the other side's data.
When the sender gets a NAK, it inserts the requested frames into the
transmitted stream ahead of any new data. If the receiver does not get
the missing frames after a round trip interval + epsilon, it repeats
the NAK twice and waits another round trip interval + epsilon. If this
still doesn't work, the receiver gives up and passes the data on the
reassembly list to the upper layer minus the missing data. Because the
next upper layer is typically PPP, this will cause the PPP frame
containing the missing piece to fail CRC.
Note that duplicate data can appear on the second cycle if both NAKs
get through and both copies of the requested data get back; the
receiver drops one as a duplicate.
When the link is up but idle, idle frames at 1/8 rate are sent with
just the next sequence number, which does not increment. This avoids
the deadlock that would otherwise occur if a frame were lost right
before the link went idle, as the idle frame(s) will trigger any
necessary NAKs.
There's a lot of complexity having to do with simultaneous voice/data
on the same channel, but the basic principles of the RLP are the same.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST