|
NAMEunimsg , unisve_check_addr ,
unisve_check_selector ,
unisve_check_blli_id2 ,
unisve_check_blli_id3 ,
unisve_check_bhli ,
unisve_check_sap ,
unisve_overlap_addr ,
unisve_overlap_selector ,
unisve_overlap_blli_id2 ,
unisve_overlap_blli_id3 ,
unisve_overlap_bhli ,
unisve_overlap_sap ,
unisve_is_catchall ,
unisve_match —
ATM signalling library - ATM SAP handling
LIBRARYBegemot ATM signalling library (libunimsg, -lunimsg)SYNOPSIS#include <uni4/unisap.h>
int
int
int
int
int
int
int
int
int
int
int
int
int
int
DESCRIPTIONTheunimsg 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.
A SAP is a data structure: struct uni_sap { struct unisve_addr addr; struct unisve_selector selector; struct unisve_blli_id2 blli_id2; struct unisve_blli_id3 blli_id3; struct unisve_bhli bhli; }; 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 called address is matched by a struct unisve_addr { enum unisve_tag tag; enum uni_addr_type type;/* type of address */ enum uni_addr_plan plan;/* addressing plan */ uint32_t len; /* length of address */ u_char addr[UNI_ADDR_MAXLEN]; }; Here type is the type of address and plan is the address plan. len is the length of the address (for ATME addresses not counting the selector byte) and addr is the address itself. In case of ATME addresses the selector byte is matched by a struct unisve_selector { enum unisve_tag tag; uint8_t selector; }; Here selector is the selector byte that must match the 20th byte of the ATME calling address from the SETUP message. 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: struct unisve_blli_id2 { enum unisve_tag tag; uint8_t proto:5;/* the protocol */ uint8_t user:7; /* user specific protocol */ }; Where the user fields is matched only if the
proto field specifies
struct unisve_blli_id3 { enum unisve_tag tag; 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 */ }; Finally the BHLI information element is matched with a struct unisve_bhli { enum unisve_tag tag; enum uni_bhli type; /* type of info */ uint32_t len; /* length of info */ uint8_t info[8];/* info itself */ }; For each SVE type there is a function that checks whether the SVE
is correct specified. The functions
enum { UNISVE_OK = 0, UNISVE_ERROR_BAD_TAG, UNISVE_ERROR_TYPE_PLAN_CONFLICT, UNISVE_ERROR_ADDR_SEL_CONFLICT, UNISVE_ERROR_ADDR_LEN, UNISVE_ERROR_BAD_ADDR_TYPE, UNISVE_ERROR_BAD_BHLI_TYPE, UNISVE_ERROR_BAD_BHLI_LEN, }; A code of There is a definition 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 specifies a catch-all SAP. The function
Finally the function SEE ALSOlibunimsg(3)AUTHORSHartmut Brandt ⟨harti@FreeBSD.org⟩
Visit the GSP FreeBSD Man Page Interface. |