svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ng_sscop(4)
The 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 mes‐
sages 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 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 message, or when all hooks are discon‐
nected. Each node has three hooks with fixed names: This hook
must be connected to a node that ensures transport of packets to
and from the remote peer node. Normally this is a node with an
AAL5 hook, but the node is able to work on any packet-transport‐
ing layer, like, for example, IP or UDP. The node handles flow
control messages received on this hook: if it receives a message,
it declares the state. If a message is received, the busy state
is cleared. Note that the node does not look at the message con‐
tents of these flow control messages. This is the interface to
the SSCOP user. This interface uses the following message for‐
mat: struct sscop_arg { uint32_t sig; uint32_t
arg; /* opt. sequence number or clear-buff */ u_char
data[]; }; The field is one of the signals defined in the stan‐
dard: 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 field contains the argument to some of the signals: it
is either a PDU sequence number, or the flag. There are a number
of special sequence numbers for some operations: maximum legal
sequence number retrieve transmission queue retrieve transmission
buffer and queue For signals that carry user data (as, for exam‐
ple, these two fields are followed by the variable sized user
data. If the hook is disconnected and the SSCOP instance is not
in the idle state, and the hook is still connected, an is exe‐
cuted to release the SSCOP connection. This is the management
interface defined in the standard. The data structure used here
is: struct sscop_marg { uint32_t sig; u_char
data[]; }; Here is one of enum sscop_maasig {
SSCOP_MDATA_request, /* <- MU */
SSCOP_MDATA_indication, /* -> MU */
SSCOP_MERROR_indication, /* -> CODE, CNT */ }; The signals
are followed by the actual management data, where the signal has
the form: struct sscop_merr { uint32_t sig;
uint32_t err; /* error code */ uint32_t
cnt; /* error count */ }; The node understands the generic con‐
trol messages, plus the following: Sets operational parameters of
the SSCOP instance and takes the following structure: struct
ng_sscop_setparam { uint32_t mask;
struct sscop_param param; }; The sub-structure con‐
tains the parameters to set, and the 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 field contains the following
flags influencing SSCOP operation: enable atmf/97-0216 robustness
enhancement send POLL after each retransmission The bitmap has
the following bits: set set set set set set set set set set set
the initial window set or clear set or clear The node responds to
the message with the following response: struct ng_sscop_set‐
param_resp { uint32_t mask; int32_t error; };
Here contains a bitmask of the parameters that the user requested
to set, but that could not be set and is an code describing why
the parameter could not be set. This message returns the current
operational parameters of the SSCOP instance in a structure.
This message creates the actual SSCOP instance and initializes
it. Until this is done, parameters may neither be retrieved nor
set, and all messages received on any hook are discarded. De‐
stroy the SSCOP instance. After this, all messages on any hooks
are discarded. Set debugging flags. The argument is a Retrieve
the actual debugging flags. Needs no arguments and responds with
a Responds with the current state of the SSCOP instance in a If
the node is not enabled, the retrieved state is 0. Flow control
works on the upper and on the lower layer interface. At the
lower layer interface, the two messages, and are used to declare
or clear the state of the protocol. At the upper layer inter‐
face, the node handles three types of flow control messages: If
this message is received, the SSCOP stops moving the receive win‐
dow. Each time a data message is handed over to the upper layer,
the receive window is moved by one message. Stopping these up‐
dates means that the window will start to close and if the peer
has sent all messages allowed by the current window, it stops
transmission. This means that the upper layer must be able to
still receive a full window amount of messages. This will re-en‐
able the automatic window updates, and if the space indicated in
the message is larger than the current window, the window will be
opened by that amount. The space is computed as the difference
of the and members of the structure. If the upper layer buffer
filling state, as indicated by is equal to or greater than then
the message is ignored. If this is not the case, the amount of
receiver space is computed as the difference of and if automatic
window updates are currently allowed, and as the difference of
and if window updates are disabled. If the resulting value is
larger than the current window, the current window is opened up
to this value. Automatic window updates are enabled if they were
disabled.