1.\"
2.\" Copyright (c) 2001-2003
3.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
--- 11 unchanged lines hidden (view full) ---
21.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
22.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
23.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
24.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
25.\" SUCH DAMAGE.
26.\"
27.\" Author: Hartmut Brandt <harti@freebsd.org>
28.\"
29.\" $Begemot: libunimsg/man/unisap.3,v 1.4 2005/05/23 12:00:10 brandt_h Exp $
30.\"
31.Dd May 23, 2005
32.Dt UNISAP 3
33.Os
34.Sh NAME
35.Nm unimsg ,
36.Nm unisve_check_addr ,
37.Nm unisve_check_selector ,
38.Nm unisve_check_blli_id2 ,
39.Nm unisve_check_blli_id3 ,
--- 43 unchanged lines hidden (view full) ---
83.Fn unisve_match "const struct uni_sap *sap" \
84"const struct uni_ie_called *called" "const struct uni_ie_blli *blli" \
85"const struct uni_ie_bhli *bhli"
86.Sh DESCRIPTION
87The
88.Nm
89library contains functions to handle Service Access Points (SAP) and SAP Vector
90Elements (SVE) as specified in the ATM Forum ATM API Semantic Description.
91SAPs are the analog of TCP and UDP ports in the ATM world. As usually in ATM
92they are a couple of orders of magnitude more complex as their Internet
93equivalent. See the ATM Forum document for a description.
94.Pp
95A SAP is a data structure:
96.Bd -literal -offset indent
97struct uni_sap {
98 struct unisve_addr addr;
99 struct unisve_selector selector;
100 struct unisve_blli_id2 blli_id2;
101 struct unisve_blli_id3 blli_id3;
102 struct unisve_bhli bhli;
103};
104.Ed
105.Pp
106that consists of 5 elements matching different information elements in
107the SETUP message. Each of these elements has a tag that defines how
108the SVE is to be matched with the information element. The tag is one of
109.Bl -tag -width ".Dv UNISVE_PRESENT"
110.It Dv UNISVE_ABSENT
111The information element has to absent from the SETUP message.
112.It Dv UNISVE_PRESENT
113The information element has to be present in the SETUP message and must
114match the SVE.
115.It Dv UNISVE_ANY
116The information element may be absent from the SETUP message or may
117have any value.
118.El
119.Pp
120The called address is matched by a
121.Bd -literal -offset indent
122struct unisve_addr {
123 enum unisve_tag tag;
124 enum uni_addr_type type;/* type of address */
125 enum uni_addr_plan plan;/* addressing plan */
126 u_int32_t len; /* length of address */
127 u_char addr[UNI_ADDR_MAXLEN];
128};
129.Ed
130.Pp
131Here
132.Fa type
133is the type of address and
134.Fa plan
135is the address plan.
136.Fa len
137is the length of the address (for ATME addresses not counting the selector byte)
138and
139.Fa addr is the address itself.
140.Pp
141In case of ATME addresses the selector byte is matched by a
142.Bd -literal -offset indent
143struct unisve_selector {
144 enum unisve_tag tag;
145 u_int8_t selector;
146};
147.Ed
148.Pp
149Here
150.Fa selector
151is the selector byte that must match the 20th byte of the ATME calling address
152from the SETUP message.
153.Pp
154The BLLI information element is matched by two SVEs: one for layer 2 options
155and one for layer 3 options. The layer 2 SVE is:
156.Bd -literal -offset indent
157struct unisve_blli_id2 {
158 enum unisve_tag tag;
159 u_int8_t proto:5;/* the protocol */
160 u_int8_t user:7; /* user specific protocol */
161};
162.Ed
163.Pp
164Where the
165.Fa user
166fields is matched only if the
167.Fa proto
168field specifies
169.Dv UNI_BLLI_L2_USER .
170The layer 3 SVE is:
171.Bd -literal -offset indent
172struct unisve_blli_id3 {
173 enum unisve_tag tag;
174 u_int8_t proto:5;/* L3 protocol */
175 u_int8_t user:7; /* user specific protocol */
176 u_int8_t ipi:8; /* ISO/IEC TR 9557 IPI */
177 u_int32_t oui:24; /* IEEE 802.1 OUI */
178 u_int32_t pid:16; /* IEEE 802.1 PID */
179 u_int32_t noipi; /* ISO/IEC TR 9557 per frame */
180};
181.Ed
182For the exact rules how matching occures refer to the source code or the
183ATM Forum document.
184.Pp
185Finally the BHLI information element is matched with a
186.Bd -literal -offset indent
187struct unisve_bhli {
188 enum unisve_tag tag;
189 enum uni_bhli type; /* type of info */
190 u_int32_t len; /* length of info */
191 u_int8_t info[8];/* info itself */
192};
193.Ed
194.Pp
195For each SVE type there is a function that checks whether the SVE is correct
196specified. The functions
197.Fn unisve_check_addr ,
198.Fn unisve_check_selector ,
199.Fn unisve_check_blli_id2 ,
200.Fn unisve_check_blli_id3 ,
201and
202.Fn unisve_check_bhli
203return one of the following error codes:
204.Bd -literal -offset indent
--- 17 unchanged lines hidden (view full) ---
222checks a complete SAP and returns one of the above codes.
223.Pp
224There is a definition
225.Dv UNISVE_ERRSTR
226that evaluates to a comma separated list of strings that can be used
227to initializes an array of char pointers to map the error codes into
228human readable strings.
229.Pp
230The ATM Forum document defines the concept of overlaping SAPs. This basically
231means, that an incoming SETUP could match more than one SAP (and more than
232one application) to receive the SETUP. For each SVE type there is a function
233that checks whether two SVEs overlap and there is a function that checks whether
234two SAPs overlap. The functions
235.Fn unisve_overlap_addr ,
236.Fn unisve_overlap_selector ,
237.Fn unisve_overlap_blli_id2 ,
238.Fn unisve_overlap_blli_id3 ,
239.Fn unisve_overlap_bhli , and
240.Fn unisve_overlap_sap
241return 1 if the SVEs or SAPs overlap and 0 if they do not. They assume, that
242the SAPs are correct.
243.Pp
244The ATM Forum document specifies a catch-all SAP. The function
245.Fn unisve_is_catchall
246returns 1 if the SAP is the catch-all SAP and 0 otherwise.
247.Pp
248Finally the function
249.Fn unisve_match
250is used to match a SAP against the information elements from a SETUP message.
251It returns 1 if they match and 0 otherwise.
252.Sh SEE ALSO
253.Xr libunimsg 3
254.Sh AUTHORS
255.An Hartmut Brandt Aq harti@freebsd.org
2.\" Copyright (c) 2001-2003
3.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus).
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
--- 11 unchanged lines hidden (view full) ---
21.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
22.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
23.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
24.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
25.\" SUCH DAMAGE.
26.\"
27.\" Author: Hartmut Brandt <harti@freebsd.org>
28.\"
29.\" $Begemot: libunimsg/man/unisap.3,v 1.4 2005/05/23 12:00:10 brandt_h Exp $
30.\"
31.Dd May 23, 2005
32.Dt UNISAP 3
33.Os
34.Sh NAME
35.Nm unimsg ,
36.Nm unisve_check_addr ,
37.Nm unisve_check_selector ,
38.Nm unisve_check_blli_id2 ,
39.Nm unisve_check_blli_id3 ,
--- 43 unchanged lines hidden (view full) ---
83.Fn unisve_match "const struct uni_sap *sap" \
84"const struct uni_ie_called *called" "const struct uni_ie_blli *blli" \
85"const struct uni_ie_bhli *bhli"
86.Sh DESCRIPTION
87The
88.Nm
89library contains functions to handle Service Access Points (SAP) and SAP Vector
90Elements (SVE) as specified in the ATM Forum ATM API Semantic Description.
91SAPs are the analog of TCP and UDP ports in the ATM world. As usually in ATM
92they are a couple of orders of magnitude more complex as their Internet
93equivalent. See the ATM Forum document for a description.
94.Pp
95A SAP is a data structure:
96.Bd -literal -offset indent
97struct uni_sap {
98 struct unisve_addr addr;
99 struct unisve_selector selector;
100 struct unisve_blli_id2 blli_id2;
101 struct unisve_blli_id3 blli_id3;
102 struct unisve_bhli bhli;
103};
104.Ed
105.Pp
106that consists of 5 elements matching different information elements in
107the SETUP message. Each of these elements has a tag that defines how
108the SVE is to be matched with the information element. The tag is one of
109.Bl -tag -width ".Dv UNISVE_PRESENT"
110.It Dv UNISVE_ABSENT
111The information element has to absent from the SETUP message.
112.It Dv UNISVE_PRESENT
113The information element has to be present in the SETUP message and must
114match the SVE.
115.It Dv UNISVE_ANY
116The information element may be absent from the SETUP message or may
117have any value.
118.El
119.Pp
120The called address is matched by a
121.Bd -literal -offset indent
122struct unisve_addr {
123 enum unisve_tag tag;
124 enum uni_addr_type type;/* type of address */
125 enum uni_addr_plan plan;/* addressing plan */
126 u_int32_t len; /* length of address */
127 u_char addr[UNI_ADDR_MAXLEN];
128};
129.Ed
130.Pp
131Here
132.Fa type
133is the type of address and
134.Fa plan
135is the address plan.
136.Fa len
137is the length of the address (for ATME addresses not counting the selector byte)
138and
139.Fa addr is the address itself.
140.Pp
141In case of ATME addresses the selector byte is matched by a
142.Bd -literal -offset indent
143struct unisve_selector {
144 enum unisve_tag tag;
145 u_int8_t selector;
146};
147.Ed
148.Pp
149Here
150.Fa selector
151is the selector byte that must match the 20th byte of the ATME calling address
152from the SETUP message.
153.Pp
154The BLLI information element is matched by two SVEs: one for layer 2 options
155and one for layer 3 options. The layer 2 SVE is:
156.Bd -literal -offset indent
157struct unisve_blli_id2 {
158 enum unisve_tag tag;
159 u_int8_t proto:5;/* the protocol */
160 u_int8_t user:7; /* user specific protocol */
161};
162.Ed
163.Pp
164Where the
165.Fa user
166fields is matched only if the
167.Fa proto
168field specifies
169.Dv UNI_BLLI_L2_USER .
170The layer 3 SVE is:
171.Bd -literal -offset indent
172struct unisve_blli_id3 {
173 enum unisve_tag tag;
174 u_int8_t proto:5;/* L3 protocol */
175 u_int8_t user:7; /* user specific protocol */
176 u_int8_t ipi:8; /* ISO/IEC TR 9557 IPI */
177 u_int32_t oui:24; /* IEEE 802.1 OUI */
178 u_int32_t pid:16; /* IEEE 802.1 PID */
179 u_int32_t noipi; /* ISO/IEC TR 9557 per frame */
180};
181.Ed
182For the exact rules how matching occures refer to the source code or the
183ATM Forum document.
184.Pp
185Finally the BHLI information element is matched with a
186.Bd -literal -offset indent
187struct unisve_bhli {
188 enum unisve_tag tag;
189 enum uni_bhli type; /* type of info */
190 u_int32_t len; /* length of info */
191 u_int8_t info[8];/* info itself */
192};
193.Ed
194.Pp
195For each SVE type there is a function that checks whether the SVE is correct
196specified. The functions
197.Fn unisve_check_addr ,
198.Fn unisve_check_selector ,
199.Fn unisve_check_blli_id2 ,
200.Fn unisve_check_blli_id3 ,
201and
202.Fn unisve_check_bhli
203return one of the following error codes:
204.Bd -literal -offset indent
--- 17 unchanged lines hidden (view full) ---
222checks a complete SAP and returns one of the above codes.
223.Pp
224There is a definition
225.Dv UNISVE_ERRSTR
226that evaluates to a comma separated list of strings that can be used
227to initializes an array of char pointers to map the error codes into
228human readable strings.
229.Pp
230The ATM Forum document defines the concept of overlaping SAPs. This basically
231means, that an incoming SETUP could match more than one SAP (and more than
232one application) to receive the SETUP. For each SVE type there is a function
233that checks whether two SVEs overlap and there is a function that checks whether
234two SAPs overlap. The functions
235.Fn unisve_overlap_addr ,
236.Fn unisve_overlap_selector ,
237.Fn unisve_overlap_blli_id2 ,
238.Fn unisve_overlap_blli_id3 ,
239.Fn unisve_overlap_bhli , and
240.Fn unisve_overlap_sap
241return 1 if the SVEs or SAPs overlap and 0 if they do not. They assume, that
242the SAPs are correct.
243.Pp
244The ATM Forum document specifies a catch-all SAP. The function
245.Fn unisve_is_catchall
246returns 1 if the SAP is the catch-all SAP and 0 otherwise.
247.Pp
248Finally the function
249.Fn unisve_match
250is used to match a SAP against the information elements from a SETUP message.
251It returns 1 if they match and 0 otherwise.
252.Sh SEE ALSO
253.Xr libunimsg 3
254.Sh AUTHORS
255.An Hartmut Brandt Aq harti@freebsd.org