| NG_SSCOP(4) | Device Drivers Manual | NG_SSCOP(4) |
ng_sscop —
netgraph SSCOP node type
#include
<netnatm/saal/sscopdef.h>
#include
<netgraph/atm/ng_sscop.h>
The sscop netgraph node type implements
the ITU-T standard Q.2110. This standard describes the so called Service
Specific Connection Oriented Protocol (SSCOP) that is used to carry
signalling messages over the private and public UNIs and the public NNI.
This protocol is a transport protocol with selective acknowledgements, and
can be tailored to the environment. This implementation is a full
implementation of that standard.
After creation of the node, the SSCOP instance must be created by sending an “enable” message to the node. If the node is enabled, the SSCOP parameters can be retrieved and modified and the protocol can be started.
The node is shut down either by a
NGM_SHUTDOWN message, or when all hooks are
disconnected.
Each sscop node has three hooks with fixed
names:
sscop node is able to work on any
packet-transporting layer, like, for example, IP or UDP. The node handles
flow control messages received on this hook: if it receives a
NGM_HIGH_WATER_PASSED message, it declares the
“lower layer busy” state. If a
NGM_LOW_WATER_PASSED message is received, the busy
state is cleared. Note that the node does not look at the message contents
of these flow control messages.struct sscop_arg {
uint32_t sig;
uint32_t arg; /* opt. sequence number or clear-buff */
u_char data[];
};
The sig field is one of the signals defined in the standard:
enum sscop_aasig {
SSCOP_ESTABLISH_request, /* <- UU, BR */
SSCOP_ESTABLISH_indication, /* -> UU */
SSCOP_ESTABLISH_response, /* <- UU, BR */
SSCOP_ESTABLISH_confirm, /* -> UU */
SSCOP_RELEASE_request, /* <- UU */
SSCOP_RELEASE_indication, /* -> UU, SRC */
SSCOP_RELEASE_confirm, /* -> */
SSCOP_DATA_request, /* <- MU */
SSCOP_DATA_indication, /* -> MU, SN */
SSCOP_UDATA_request, /* <- MU */
SSCOP_UDATA_indication, /* -> MU */
SSCOP_RECOVER_indication, /* -> */
SSCOP_RECOVER_response, /* <- */
SSCOP_RESYNC_request, /* <- UU */
SSCOP_RESYNC_indication, /* -> UU */
SSCOP_RESYNC_response, /* <- */
SSCOP_RESYNC_confirm, /* -> */
SSCOP_RETRIEVE_request, /* <- RN */
SSCOP_RETRIEVE_indication, /* -> MU */
SSCOP_RETRIEVE_COMPL_indication,/* -> */
};
The arrows in the comment show the direction of the signal,
whether it is a signal that comes out of the node
(‘->’), or is sent by the node
user to the node (‘<-’). The
arg field contains the argument to some of the
signals: it is either a PDU sequence number, or the
CLEAR-BUFFER flag. There are a number of special
sequence numbers for some operations:
SSCOP_MAXSEQNOSSCOP_RETRIEVE_UNKNOWNSSCOP_RETRIEVE_TOTALFor signals that carry user data (as, for example,
SSCOP_DATA_request) these two fields are
followed by the variable sized user data.
If the upper hook is disconnected and
the SSCOP instance is not in the idle state, and the
lower hook is still connected, an
SSCOP_RELEASE_request is executed to release the
SSCOP connection.
struct sscop_marg {
uint32_t sig;
u_char data[];
};
Here sig is one of
enum sscop_maasig {
SSCOP_MDATA_request, /* <- MU */
SSCOP_MDATA_indication, /* -> MU */
SSCOP_MERROR_indication, /* -> CODE, CNT */
};
The SSCOP_MDATA signals are followed
by the actual management data, where the
SSCOP_MERROR signal has the form:
struct sscop_merr {
uint32_t sig;
uint32_t err; /* error code */
uint32_t cnt; /* error count */
};
The sscop node understands the generic
control messages, plus the following:
NGM_SSCOP_SETPARAM
(setparam)struct ng_sscop_setparam {
uint32_t mask;
struct sscop_param param;
};
The sub-structure param contains the parameters to set, and the mask field contains a bit mask, telling which of the parameters to set, and which to ignore. If a bit is set, the corresponding parameter is set. The parameters are:
struct sscop_param {
uint32_t timer_cc; /* timer_cc in msec */
uint32_t timer_poll; /* timer_poll im msec */
uint32_t timer_keep_alive;/* timer_keep_alive in msec */
uint32_t timer_no_response;/*timer_no_response in msec */
uint32_t timer_idle; /* timer_idle in msec */
uint32_t maxk; /* maximum user data in bytes */
uint32_t maxj; /* maximum u-u info in bytes */
uint32_t maxcc; /* max. retransmissions for control packets */
uint32_t maxpd; /* max. vt(pd) before sending poll */
uint32_t maxstat; /* max. number of elements in stat list */
uint32_t mr; /* initial window */
uint32_t flags; /* flags */
};
The flags field contains the following flags influencing SSCOP operation:
SSCOP_ROBUSTSSCOP_POLLREXThe bitmap has the following bits:
SSCOP_SET_TCCSSCOP_SET_TPOLLSSCOP_SET_TKASSCOP_SET_TNRSSCOP_SET_TIDLESSCOP_SET_MAXKSSCOP_SET_MAXJSSCOP_SET_MAXCCSSCOP_SET_MAXPDSSCOP_SET_MAXSTATSSCOP_SET_MRSSCOP_SET_ROBUSTSSCOP_ROBUSTSSCOP_SET_POLLREXSSCOP_POLLREXThe node responds to the
NGM_SSCOP_SETPARAM message with the following
response:
struct ng_sscop_setparam_resp {
uint32_t mask;
int32_t error;
};
Here mask contains a bitmask of the parameters that the user requested to set, but that could not be set and error is an errno(2) code describing why the parameter could not be set.
NGM_SSCOP_GETPARAM
(getparam)NGM_SSCOP_ENABLE
(enable)NGM_SSCOP_DISABLE
(disable)NGM_SSCOP_SETDEBUG
(setdebug)NGM_SSCOP_GETDEBUG
(getdebug)NGM_SSCOP_GETSTATE
(getstate)Flow control works on the upper and on the lower layer interface.
At the lower layer interface, the two messages,
NGM_HIGH_WATER_PASSED and
NGM_LOW_WATER_PASSED, are used to declare or clear
the “lower layer busy” state of the protocol.
At the upper layer interface, the sscop
node handles three types of flow control messages:
NGM_HIGH_WATER_PASSEDNGM_LOW_WATER_PASSEDNGM_SYNC_QUEUE_STATEHarti Brandt <harti@FreeBSD.org>
| October 24, 2003 | Debian |