[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Hi,
Here is version 1c. Based on comments from Zacco and Abbie, I added
clarifications on returned uncompressed DAP messages and "need-feedback"
header field.
As planned, I would like to freeze this as the DAP version 1 for now.
At least it's good enough for the first SigComp interop.
(Of course, any questions related to the understanding of the document
are still welcome. I've been trying to be concise, but may not have
covered every fine details ...)
Thanks for Abbie, Adam and Zacco for their valuable comments.
BR,
Zhigang
A Dummy Application Protocol (DAP)
----------------------------------
1. Introduction
This document defines a simple dummy application protocol (DAP) that
can be used for SigComp interoperability test. This is handy for
SigComp implementations that are not integrated with SIP stack. It also
provides some features that facilitate the tests of SigComp internal
operations.
The message format is quite simple. Each message consists of a 8-line
message-header, an empty line, and an optional message-body. You can
see the style resembles that of SIP and HTTP.
The exact message format is given later in augmented Backus-Naur Form
(ABNF) (see RFC 2234). Here are a few notes:
- Each line of message-header must be terminated with CR LF.
- The empty line must be present even if the message-body is not.
- Body-length is the length of the message-body, excluding the CRLF
which separates the message-body from the message-header.
- All strings in message-header are case-insensitive.
- For implementation according to this document, the DAP-version
must be set to 1.
2. Processing a DAP message:
- A message with invalid format will be discarded by a DAP receiver
- For testing purpose, a message with valid format will be returned to
the original sender (IP address, port number) in clear text, i.e.,
without compression. This is the case even if the sender requests the
receiver to reject the message. Note that the entire DAP message
(message-header + CRLF + message-body) is returned. This allows the
sender to compare what it sent with what the receiver decompressed.
- Endpoint-ID is the global identifier of the sending endpoint. It can
be used to test the case where multiple SigComp endpoints communicate
with the same remote SigComp endpoint. For simplicity, IPv4 address is
used for this purpose.
- Compartment-ID is the identifier of the *compressor* compartment
that the *sending* endpoint used to compress this message. It is
assigned by the sender and therefore only unique per sending endpoint.
I.e., DAP messages sent by different endpoints may carry same
compartment-ID. Therefore, the receiver should use the (endpoint-ID,
compartment-ID) pair carried in a message to determine the decompressor
compartment identifier for that message. The exact local representation
of the derived compartment identifier is an implementation choice.
- To test SigComp feedback (RFC 3320, section 3.1), peer compartments
between two endpoints are defined in DAP as those with the same
compartment-ID. For example, (endpoint-A, 1) and (endpoint-B, 1) are
peer compartments. That means, SigComp feedback for a DAP message sent
from compartment 1 of endpoint-A to endpoint-B must be piggybacked on a
DAP message sent from compartment 1 of endpoint-B to endpoint-A.
- A DAP receiver will follow the instruction carried in header line-5
to either accept or reject a DAP message. Note: line-6 and line-7 will
be ignored if the message is rejected.
- A DAP receiver will follow the instruction in line-6 to create or
close the decompressor compartment that is associated with the received
DAP message (see above).
- If the header line-7 of a received DAP message carries "TRUE", the
receiver will send back a response message to the sender. This allows
the test of SigComp feedback. As mentioned above, the response message
must be compressed by, and sent from, the local compressor compartment
that is peer of the remote compressor compartment. Other than this
constraint, the response message is just a regular DAP message that
can carry arbitrary message-header and message-body. For example, the
"need-response" field of the response can also be set to TRUE, which
will trigger a response to response, and so on. Note that since either
endpoint has control over the "need-response" field of its own
messages, this does not lead to a dead loop. A sensible implementation
of a DAP sender must not blindly set this field to TRUE unless a
response is desired. For testing, the message-body of a response may
contain the message-header of the original message that triggered
the response.
- Message-seq can be used by a DAP sender to track each message it
sends, e.g., in case of losses. Message loss can happen either on the
path or at the receiving endpoint (i.e. due to decompression failure).
The assignment of message-seq is up to the sender. For example, it
could be either assigned per compartment or per endpoint. This has no
impact on the receiving side.
3. DAP message format in ABNF
(Note: see RFC 2234 for basic rules.)
DAP-message = message-header
CRLF
[ message-body ]
message-body = *OCTET
message-header = line-1 line-2 line-3 line-4 line-5 line-6 line-7 line-8
line-1 = "DAP-version" ":" 1*DIGIT CRLF
line-2 = "endpoint-ID" ":" IPv4address CRLF
line-3 = "compartment-ID" ":" 1*DIGIT CRLF
line-4 = "message-seq" ":" 1*DIGIT CRLF
line-5 = "message-auth" ":" ( "ACCEPT" / "REJECT" ) CRLF
line-6 = "compartment-op" ":" ( "CREATE" / "CLOSE" / "NONE" ) CRLF
line-7 = "need-response" ":" ( "TRUE" / "FALSE" )
line-8 = "body-length" ":" 1*DIGIT CRLF
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
4. An example of a DAP message
DAP-version: 1
endpoint-ID: 123.45.67.89
compartment-ID: 2
message-seq: 0
message-auth: ACCEPT
compartment-op: CREATE
need-response: TRUE
body-length: 228
This is a DAP message sent from SigComp endpoint at IP address
123.45.67.89. This is the first message sent from compartment 2.
Please accept the message, create the associated compartment,
and send back a response message.