*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->FreeBSD man pages -> ng_sscop (4)              



NAME    [Toc]    [Back]

     ng_sscop -- netgraph SSCOP node type

SYNOPSIS    [Toc]    [Back]

     #include <netnatm/saal/sscopdef.h>
     #include <netgraph/atm/ng_sscop.h>

DESCIPTION    [Toc]    [Back]

     The ng_sscop netgraph node 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 shutdown either by a NGM_SHUTDOWN message or when all hooks
     are disconnected.

HOOKS    [Toc]    [Back]

     Each ng_sscop node has three hooks with fixed names:

     lower   This hook is the hook that must be connected to a node that
	     ensures transport of packets to and from the remote peer node.
	     Normally this is a ng_atm(4) node with an AAL5 hook, but the
	     ng_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.

     upper   This is the interface to the SSCOP user.  This interface uses the
	     following message format:

	     struct sscop_arg {
		     uint32_t sig;
		     uint32_t arg;   /* opt. sequence number or clear-buff */
		     u_char   data[];

	     sig 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_MAXSEQNO	     maximum legal sequence number
		   SSCOP_RETRIEVE_UNKNOWN    retrieve transmission queue
		   SSCOP_RETRIEVE_TOTAL      retrieve transmission buffer and

	     For 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.

     manage  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 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 */

CONTROL MESSAGES    [Toc]    [Back]

     The ng_sscop node understands the generic messages plus the following:

	  Set operational parameters of the SSCOP instance and takes the following

	  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_ROBUST	 enable atmf/97-0216 robustness enhancement
		SSCOP_POLLREX	 send POLL after each retransmission

	  The bitmap has the following bits:

		SSCOP_SET_TCC	  set timer_cc
		SSCOP_SET_TPOLL   set timer_poll
		SSCOP_SET_TKA	  set timer_keep_alive
		SSCOP_SET_TNR	  set timer_no_response
		SSCOP_SET_TIDLE   set timer_idle
		SSCOP_SET_MAXK	  set maxk
		SSCOP_SET_MAXJ	  set maxj
		SSCOP_SET_MAXCC   set maxcc
		SSCOP_SET_MAXPD   set maxpd
		SSCOP_SET_MAXSTAT set maxstat
		SSCOP_SET_MR	  set the initial window

	  The node responds to the NGM_SSCOP_SETPARAM message with the following

	  struct ng_sscop_setparam_resp {
		  uint32_t mask;
		  int32_t  error;

	  Here mask contains the a bitmask of the parameters that the user
	  requested to set, but that could not be set and error is an errno(3)
	  code describing why the parameter could not be set.

	  This message returns the current operational parameters of the SSCOP
	  instance in a sscop_param structure.

	  This message creates the actual SSCOP instance and initializes it.
	  Until this is done, parameters may neither be retrieved not set and
	  all message received on any hook are discarded.

	  Destroy the SSCOP instance. After this all messages on any hooks are

	  Set debugging flags. The argument is an uint32_t.

	  Retrieve the actual debugging flags.	Needs no arguments and
	  responds with an uint32_t.

	  Responds with the current state of the SSCOP instance in an
	  uint32_t.  If the node is not enabled the retrieved state is 0.

FLOW CONTROL    [Toc]    [Back]

     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 ng_sscop node handles three types of
     flow control messages:

	  If this message is received the SSCOP stops moving the receive window.
	Each time a data message is handed over to the upper layer the
	  receive window is moved by one message.  Stopping these updates
	  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 receive still a
	  full window amount of messages.

	  This will re-enable 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 max_queuelen_packets and current members of the
	  ngm_queue_state structure.

	  If the upper layer buffer filling state as indicated by current is
	  equal too or higher than high_watermark than the message is ignored.
	  If this is not the case the amount of receiver space is computed as
	  the difference of max_queuelen_packets and current, if automatic
	  window updates are currently allowed and as the difference of
	  high_water_mark and current, 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.

SEE ALSO    [Toc]    [Back]

     netgraph(4), ng_atm(4), ng_sscfu(4), ngctl(8)

AUTHORS    [Toc]    [Back]

     Harti Brandt <harti@freebsd.org>

FreeBSD 		       October 24, 2003 		       FreeBSD
[ Back ]
 Similar pages
Name OS Title
ng_uni FreeBSD netgraph UNI node type
ng_UI FreeBSD UI netgraph node type
ng_atm FreeBSD netgraph ATM node type
ng_hole FreeBSD netgraph discard node type
ng_socket FreeBSD netgraph socket node type
ng_sscfu FreeBSD netgraph SSCF at the UNI node type
ng_tee FreeBSD netgraph ``tee'' node type
ng_rfc1490 FreeBSD RFC 1490 netgraph node type
ng_ppp FreeBSD PPP protocol netgraph node type
ng_ether FreeBSD Ethernet netgraph node type
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service