This commit was generated by cvs2svn to compensate for changes in r156678,

which included commits to RCS files with non-trunk default branches.
This commit is contained in:
Hartmut Brandt 2006-03-13 09:37:22 +00:00
commit 62dd3397a8
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=156679
6 changed files with 109 additions and 74 deletions

View File

@ -1,10 +1,10 @@
.\"
.\" Copyright (c) 2004-2005
.\" Hartmut Brandt
.\" All rights reserved.
.\" Copyright (c) 2001-2003
.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
.\" All rights reserved.
.\" Copyright (c) 2004
.\" Hartmut Brandt
.\" All rights reserved.
.\"
.\" Author: Hartmut Brandt <harti@freebsd.org>
.\"
@ -29,7 +29,7 @@
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $Begemot: libunimsg/man/libngatm.3,v 1.5 2005/05/23 12:00:07 brandt_h Exp $
.\" $Begemot: libunimsg/man/libngatm.3,v 1.6 2005/06/15 11:37:07 brandt_h Exp $
.\"
.Dd May 23, 2005
.Dt LIBNGATM 3

View File

@ -1,4 +1,7 @@
.\"
.\" Copyright (c) 2004-2005
.\" Hartmut Brandt.
.\" All rights reserved.
.\" Copyright (c) 2001-2003
.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
.\" All rights reserved.
@ -26,9 +29,9 @@
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $Begemot: libunimsg/man/uniaddr.3,v 1.5 2005/05/23 12:04:55 brandt_h Exp $
.\" $Begemot: libunimsg/man/uniaddr.3,v 1.6 2005/06/15 11:37:08 brandt_h Exp $
.\"
.Dd May 23, 2005
.Dd June 14, 2005
.Dt UNIADDR 3
.Os
.Sh NAME
@ -111,7 +114,8 @@ The argument
specifies whether the NSAP address should be checked for correct syntax.
If
.Fa check
is 0 the last 11 bytes of the address are ignored. If
is 0 the last 11 bytes of the address are ignored.
If
.Fa check
is 1 the last 11 bytes except the selector byte must be zero.
If

View File

@ -1,4 +1,7 @@
.\"
.\" Copyright (c) 2004-2005
.\" Hartmut Brandt.
.\" All rights reserved.
.\" Copyright (c) 2001-2003
.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
.\" All rights reserved.
@ -26,9 +29,9 @@
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $Begemot: libunimsg/man/unifunc.3,v 1.5 2005/05/23 12:04:55 brandt_h Exp $
.\" $Begemot: libunimsg/man/unifunc.3,v 1.6 2005/06/15 11:37:09 brandt_h Exp $
.\"
.Dd May 23, 2005
.Dd June 14, 2005
.Dt UNIFUNC 3
.Os
.Sh NAME
@ -142,8 +145,8 @@ in the buffer left for a complete IE header.
.Pp
The function
.Fn uni_decode_ie_body
decodes the body of an information element. It is passed the buffer with the
message
decodes the body of an information element.
It is passed the buffer with the message
.Fa buf ,
the information element type
.Fa type
@ -215,7 +218,7 @@ a human readable form.
This is intended mainly for debugging.
Some fields of the library context are used to control how the printing is done
(see
.Xr unistruct 3 ).
.Xr unistruct 3 ) .
Each of the function takes a
.Fa buf
and a

View File

@ -1,4 +1,7 @@
.\"
.\" Copyright (c) 2004-2005
.\" Hartmut Brandt.
.\" All rights reserved.
.\" Copyright (c) 2001-2003
.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
.\" All rights reserved.
@ -26,9 +29,9 @@
.\"
.\" Author: Hartmut Brandt <harti@freebsd.org>
.\"
.\" $Begemot: libunimsg/man/unimsg.3,v 1.3 2005/05/23 12:00:09 brandt_h Exp $
.\" $Begemot: libunimsg/man/unimsg.3,v 1.4 2005/06/15 11:37:10 brandt_h Exp $
.\"
.Dd May 23, 2005
.Dd June 14, 2005
.Dt UNIMSG 3
.Os
.Sh NAME
@ -87,10 +90,11 @@ Begemot ATM signalling library
.Ft struct uni_msg *
.Fn uni_msg_dup "const struct uni_msg *msg"
.Sh DESCRIPTION
These functions are used to manipulate variable sized message. They are
These functions are used to manipulate variable sized message.
They are
inspired by BSD mbufs and SysV stream buffers, but somewhat simplified because
signalling generally is a low bandwidth task. All the functions operation on
a
signalling generally is a low bandwidth task.
All the functions operation on a
.Li uni_msg
data structure:
.Bd -literal -offset indent
@ -107,7 +111,8 @@ The field
points to the begin of a memory block that is used to store the actual message
and the field
.Fa b_lim
points just to the first byte behind that buffer. This buffer is allocated
points just to the first byte behind that buffer.
This buffer is allocated
separate from the structure itself and the user calling any of the above
functions with a non const
.Vt struct uni_msg
@ -124,8 +129,8 @@ the allocated buffer.
There are several functions and macros that return various sizes and lengths.
The macro
.Fn uni_msg_len
returns the actual size of the message (the number of used bytes). The
macro
returns the actual size of the message (the number of used bytes).
The macro
.Fn uni_msg_space
returns the number of bytes that are left unused behind the used space.
The macro
@ -140,20 +145,21 @@ Two functions may be used to create new messages: The function
.Fn uni_msg_alloc
allocates the message structure and a buffer to hold at least
.Ar space
bytes (In fact it allocates a couple of bytes more). If the allocation fails
NULL is returned. The pointers are setup so that there is no leading space
in the buffer.
bytes (In fact it allocates a couple of bytes more).
If the allocation fails NULL is returned.
The pointers are setup so that there is no leading space in the buffer.
The function
.Fn uni_msg_build
constructs a new message from a variable number of buffers. The arguments
are pairs of
constructs a new message from a variable number of buffers.
The arguments are pairs of
.Vt void *
pointers to buffers and
.Vt size_t
buffer sizes, terminated by a NULL pointer. The function computes the total
resulting message size, allocates a message and copies all the buffers
into the message. The message is built to have no leading space. If the
allocation fails, NULL is returned.
buffer sizes, terminated by a NULL pointer.
The function computes the total resulting message size, allocates a message
and copies all the buffers into the message.
The message is built to have no leading space.
If the allocation fails, NULL is returned.
.Pp
The function
.Fn uni_msg_destroy
@ -169,16 +175,20 @@ The function
.Fn uni_msg_extend
extends the message buffer to have space for at least
.Ar bytes
additional byte at the end. The leading space does not change. This function
may reallocate the message buffer. The function returns 0 on success and ENOMEM
if the reallocation fails. In this case the message buffer is not changed.
additional byte at the end.
The leading space does not change.
This function may reallocate the message buffer.
The function returns 0 on success and ENOMEM if the reallocation fails.
In this case the message buffer is not changed.
The macro
.Fn uni_msg_ensure
checks whether the message has space for additional
.Ar bytes
bytes. If not it calls
bytes.
If not it calls
.Fn uni_msg_extend
to make the message buffer larger. The macro returns 0 on success or ENOMEM
to make the message buffer larger.
The macro returns 0 on success or ENOMEM
if there is not enough space and the reallocation fails.
In this case the message buffer is not changed.
The function
@ -194,17 +204,20 @@ appends one byte to the message and the function
.Fn uni_msg_append32
appends a 32-bit value in network byte order to the message
.Fa ( b_wptr
needs not to be aligned). All three functions call
needs not to be aligned).
All three functions call
.Fn uni_msg_ensure
to make sure, that the buffer contents fit into the message. They
return 0 on success and ENOMEM if the buffer is too small and the reallocation
fails. In this case the message buffer is not changed.
to make sure, that the buffer contents fit into the message.
They return 0 on success and ENOMEM if the buffer is too small and
the reallocation fails.
In this case the message buffer is not changed.
.Pp
A number of functions can be used to retrieve parts of the message.
The function
.Fn uni_msg_strip32
returns the last four bytes of the message as a 32-bit integer assumed to
be in network byte order. It adjusts
be in network byte order.
It adjusts
.Fa b_wptr
to remove these four bytes from the message.
.Fa b_wptr
@ -212,7 +225,8 @@ does not need to be aligned.
The function
.Fn uni_msg_get32
returns the first four bytes of the message as a 32-bit integer assumed to
be in network byte order. It adjusts
be in network byte order.
It adjusts
.Fa b_rptr
to remove these four bytes from the message.
.Fa b_rptr
@ -221,12 +235,13 @@ The function
.Fn uni_msg_trail32
returns the
.Fa n 'th
32-bit integer from the buffer counted from the end of the buffer. The
integer is assumed to be in network byte order. A value of -1 for
32-bit integer from the buffer counted from the end of the buffer.
The integer is assumed to be in network byte order.
A value of -1 for
.Fa n
returns the last four bytes of the buffer, a value of -2 the four bytes
just before the last four bytes and so on. All three functions do not check
that the message is large enough.
just before the last four bytes and so on.
All three functions do not check that the message is large enough.
.Sh SEE ALSO
.Xr libunimsg 3 ,
.Xr mbuf 9

View File

@ -1,4 +1,7 @@
.\"
.\" Copyright (c) 2004-2005
.\" Hartmut Brandt.
.\" All rights reserved.
.\" Copyright (c) 2001-2003
.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
.\" All rights reserved.
@ -26,9 +29,9 @@
.\"
.\" Author: Hartmut Brandt <harti@freebsd.org>
.\"
.\" $Begemot: libunimsg/man/unisap.3,v 1.4 2005/05/23 12:00:10 brandt_h Exp $
.\" $Begemot: libunimsg/man/unisap.3,v 1.5 2005/06/15 11:37:11 brandt_h Exp $
.\"
.Dd May 23, 2005
.Dd June 14, 2005
.Dt UNISAP 3
.Os
.Sh NAME
@ -88,9 +91,10 @@ The
.Nm
library contains functions to handle Service Access Points (SAP) and SAP Vector
Elements (SVE) as specified in the ATM Forum ATM API Semantic Description.
SAPs are the analog of TCP and UDP ports in the ATM world. As usually in ATM
they are a couple of orders of magnitude more complex as their Internet
equivalent. See the ATM Forum document for a description.
SAPs are the analog of TCP and UDP ports in the ATM world.
As usually in ATM they are a couple of orders of magnitude more complex as
their Internet equivalent.
See the ATM Forum document for a description.
.Pp
A SAP is a data structure:
.Bd -literal -offset indent
@ -104,8 +108,10 @@ struct uni_sap {
.Ed
.Pp
that consists of 5 elements matching different information elements in
the SETUP message. Each of these elements has a tag that defines how
the SVE is to be matched with the information element. The tag is one of
the SETUP message.
Each of these elements has a tag that defines how the SVE is to be matched
with the information element.
The tag is one of
.Bl -tag -width ".Dv UNISVE_PRESENT"
.It Dv UNISVE_ABSENT
The information element has to absent from the SETUP message.
@ -123,7 +129,7 @@ struct unisve_addr {
enum unisve_tag tag;
enum uni_addr_type type;/* type of address */
enum uni_addr_plan plan;/* addressing plan */
u_int32_t len; /* length of address */
uint32_t len; /* length of address */
u_char addr[UNI_ADDR_MAXLEN];
};
.Ed
@ -142,7 +148,7 @@ In case of ATME addresses the selector byte is matched by a
.Bd -literal -offset indent
struct unisve_selector {
enum unisve_tag tag;
u_int8_t selector;
uint8_t selector;
};
.Ed
.Pp
@ -152,12 +158,13 @@ is the selector byte that must match the 20th byte of the ATME calling address
from the SETUP message.
.Pp
The BLLI information element is matched by two SVEs: one for layer 2 options
and one for layer 3 options. The layer 2 SVE is:
and one for layer 3 options.
The layer 2 SVE is:
.Bd -literal -offset indent
struct unisve_blli_id2 {
enum unisve_tag tag;
u_int8_t proto:5;/* the protocol */
u_int8_t user:7; /* user specific protocol */
uint8_t proto:5;/* the protocol */
uint8_t user:7; /* user specific protocol */
};
.Ed
.Pp
@ -171,12 +178,12 @@ The layer 3 SVE is:
.Bd -literal -offset indent
struct unisve_blli_id3 {
enum unisve_tag tag;
u_int8_t proto:5;/* L3 protocol */
u_int8_t user:7; /* user specific protocol */
u_int8_t ipi:8; /* ISO/IEC TR 9557 IPI */
u_int32_t oui:24; /* IEEE 802.1 OUI */
u_int32_t pid:16; /* IEEE 802.1 PID */
u_int32_t noipi; /* ISO/IEC TR 9557 per frame */
uint8_t proto:5;/* L3 protocol */
uint8_t user:7; /* user specific protocol */
uint8_t ipi:8; /* ISO/IEC TR 9557 IPI */
uint32_t oui:24; /* IEEE 802.1 OUI */
uint32_t pid:16; /* IEEE 802.1 PID */
uint32_t noipi; /* ISO/IEC TR 9557 per frame */
};
.Ed
For the exact rules how matching occures refer to the source code or the
@ -187,13 +194,14 @@ Finally the BHLI information element is matched with a
struct unisve_bhli {
enum unisve_tag tag;
enum uni_bhli type; /* type of info */
u_int32_t len; /* length of info */
u_int8_t info[8];/* info itself */
uint32_t len; /* length of info */
uint8_t info[8];/* info itself */
};
.Ed
.Pp
For each SVE type there is a function that checks whether the SVE is correct
specified. The functions
specified.
The functions
.Fn unisve_check_addr ,
.Fn unisve_check_selector ,
.Fn unisve_check_blli_id2 ,
@ -227,21 +235,23 @@ that evaluates to a comma separated list of strings that can be used
to initializes an array of char pointers to map the error codes into
human readable strings.
.Pp
The ATM Forum document defines the concept of overlaping SAPs. This basically
means, that an incoming SETUP could match more than one SAP (and more than
one application) to receive the SETUP. For each SVE type there is a function
that checks whether two SVEs overlap and there is a function that checks whether
two SAPs overlap. The functions
The ATM Forum document defines the concept of overlaping SAPs.
This basically means, that an incoming SETUP could match more than one SAP
(and more than one application) to receive the SETUP.
For each SVE type there is a function that checks whether two SVEs overlap
and there is a function that checks whether two SAPs overlap.
The functions
.Fn unisve_overlap_addr ,
.Fn unisve_overlap_selector ,
.Fn unisve_overlap_blli_id2 ,
.Fn unisve_overlap_blli_id3 ,
.Fn unisve_overlap_bhli , and
.Fn unisve_overlap_sap
return 1 if the SVEs or SAPs overlap and 0 if they do not. They assume, that
the SAPs are correct.
return 1 if the SVEs or SAPs overlap and 0 if they do not.
They assume, that the SAPs are correct.
.Pp
The ATM Forum document specifies a catch-all SAP. The function
The ATM Forum document specifies a catch-all SAP.
The function
.Fn unisve_is_catchall
returns 1 if the SAP is the catch-all SAP and 0 otherwise.
.Pp

View File

@ -1,4 +1,7 @@
.\"
.\" Copyright (c) 2004-2005
.\" Hartmut Brandt.
.\" All rights reserved.
.\" Copyright (c) 2001-2003
.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
.\" All rights reserved.
@ -26,7 +29,7 @@
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $Begemot: libunimsg/man/unistruct.3,v 1.4 2005/05/23 12:00:10 brandt_h Exp $
.\" $Begemot: libunimsg/man/unistruct.3,v 1.5 2005/06/15 11:37:12 brandt_h Exp $
.\"
.Dd May 23, 2005
.Dt UNISTRUCT 3