By
Brian Lantz, KO4KS (brian@lantz.com)
Tom Moulton, W2VY (w2vy@rats.org)
Date: February 2, 1996
Status: Initial Release
The document "AX25L2V2 Extensions for Q Bit Support" defines a technique that can be used to provide a secondary data path that can be used to send control information between the endpoints or between one endpoint and the intervening network in use.
There are a large number of possible control types that could be supported and the purpose of this document is to define the general format and provide references to additional documents describing each Control/Negotiation protocol implemented.
The first byte of the data field of a frame with the Q Bit Cleared is the Control Identifier Field (CIF) and is used to identify the protocol that defines the usage of the remainder of the frame. This format is taken directly from the CCITT X.29 specification, with additional protocols available.
CIF |
Description |
Document |
0x |
X.29 |
See Appendix 1 |
7x |
ROSE Network |
See Appendix 1 |
Cx |
Compression Negotiation |
See Appendix 2 |
F0 |
TNC Service Message |
See following section |
F1 |
CIF Query |
See following section |
F2 |
CIF Response |
See following section |
F3 |
CIF Error |
See following section |
FF |
CIF Extension |
See following section |
This can be used to send Service Messages to the TNC. This will likely be used by network software as a method to send informative messages in the clear. These messages could range from Call Progress indicators such as "Call being setup" or "Call Completed" to "*** Call Reset ***" or "Linked to" or "Reconnect to". The purpose is to provide a method to send messages that the User/Application might need to decode above and beyond any protocol or other high level facilities that may be active.
F0 |
Free Form Text up to paclen-1 bytes long |
There must be a simple mechanism for an endpoint to send a query to identify what CIF protocols are supported. This message will provide a general query as well as a specific query, depending upon how it is formatted.
The general query just consists of the CIF byte.
F1 |
The expected response will include a list of the CIF identifiers that are supported as listed in Table 1.
The specific query also contains the CIF identifier to provide a full list for.
F1 |
"CX" |
This query will return a list of all the CIF identifiers that are supported within the C0-CF range. If the identifier were a single value the response would either be that value or an error reporting CIF Not Supported.
The CIF Response provides a list of CIF identifiers that are supported, optionally followed by a Software ID string. The response is an ASCII string with each CIF identifier taking up two characters. The list is optionally followed by a space and a description of the software revision level or module name.
F2 |
"0XCX TNOS 2.xx Compression" |
The specific response provides more exact details about which CIF identifier bytes are supported. A "F1 CX" query could return.
2 |
C0C1C2C3C7C8CF TNOS 2.13 LZW 2K 12/23/95 |
When there is a major error that can not be reported through another means then the CIF Error packet should be generates. The most obvious reason is if a CIF identifier received in a packet is not supported. The error will include an error code and up to 64 bytes of the message received.
F3 |
Err |
Message (Up to 64 Bytes of original message) |
Error |
Meaning |
0 |
No Error |
1 |
Message Not Supported |
2 |
CIF Type Disabled |
3 |
Bad Formatting |
In the event all the CIF identifiers are allocated the CIF FF will denote extension and the following byte will be the extended CIF identifier, denoted by CIF' (CIF Prime).
FF |
CIF' |
(Additional Data as per extended CIF codes) |
Return to ROSE Home page.