| ng_uni.4 (123943) | ng_uni.4 (130857) |
|---|---|
| 1.\" 2.\" Copyright (c) 2001-2003 3.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus). 4.\" All rights reserved. 5.\" 6.\" Author: Hartmut Brandt <harti@freebsd.org> 7.\" 8.\" Redistribution and use in source and binary forms, with or without --- 12 unchanged lines hidden (view full) --- 21.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 22.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 23.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 24.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 25.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 26.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 27.\" SUCH DAMAGE. 28.\" | 1.\" 2.\" Copyright (c) 2001-2003 3.\" Fraunhofer Institute for Open Communication Systems (FhG Fokus). 4.\" All rights reserved. 5.\" 6.\" Author: Hartmut Brandt <harti@freebsd.org> 7.\" 8.\" Redistribution and use in source and binary forms, with or without --- 12 unchanged lines hidden (view full) --- 21.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 22.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 23.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 24.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 25.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 26.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 27.\" SUCH DAMAGE. 28.\" |
| 29.\" $FreeBSD: head/share/man/man4/ng_uni.4 123943 2003-12-28 22:34:47Z ru $ | 29.\" $FreeBSD: head/share/man/man4/ng_uni.4 130857 2004-06-21 17:42:49Z mpp $ |
| 30.\" 31.Dd October 6, 2003 32.Dt NG_UNI 4 33.Os FreeBSD 34.Sh NAME 35.Nm ng_uni 36.Nd netgraph UNI node type 37.Sh SYNOPSIS --- 15 unchanged lines hidden (view full) --- 53.Sh HOOKS 54Each 55.Nm 56node has three hooks with fixed names: 57.Bl -tag -width xxx 58.It Dv lower 59This hook is the interface of the UNI protocol to the transport layer of 60the ATM control plane. | 30.\" 31.Dd October 6, 2003 32.Dt NG_UNI 4 33.Os FreeBSD 34.Sh NAME 35.Nm ng_uni 36.Nd netgraph UNI node type 37.Sh SYNOPSIS --- 15 unchanged lines hidden (view full) --- 53.Sh HOOKS 54Each 55.Nm 56node has three hooks with fixed names: 57.Bl -tag -width xxx 58.It Dv lower 59This hook is the interface of the UNI protocol to the transport layer of 60the ATM control plane. |
| 61The node expectes the interface exported by | 61The node expects the interface exported by |
| 62.Xr ng_sscfu 4 63at this hook. 64.It Dv upper 65This hook is the 66.Ql user 67interface of the UNI protocol. 68Because there is no standardized interface 69at this point, this implementation follows more or less the interface --- 16 unchanged lines hidden (view full) --- 86.Nm 87node is loosely modelled after the interface specified in the ITU-T signalling 88standards. 89There is however one derivation from this: normally there exists 90four kinds of signals: requests, responses, indications and confirmations. 91These signals are usually triggered either by external events (receiving a 92message) or internal events (a timer or another signal). 93This scheme works | 62.Xr ng_sscfu 4 63at this hook. 64.It Dv upper 65This hook is the 66.Ql user 67interface of the UNI protocol. 68Because there is no standardized interface 69at this point, this implementation follows more or less the interface --- 16 unchanged lines hidden (view full) --- 86.Nm 87node is loosely modelled after the interface specified in the ITU-T signalling 88standards. 89There is however one derivation from this: normally there exists 90four kinds of signals: requests, responses, indications and confirmations. 91These signals are usually triggered either by external events (receiving a 92message) or internal events (a timer or another signal). 93This scheme works |
| 94fine for user APIs that are entirely asynchronuous and in cases, where | 94fine for user APIs that are entirely asynchronous and in cases, where |
| 95error handling is not taken into account. | 95error handling is not taken into account. |
| 96With synchronuous APIs and error | 96With synchronous APIs and error |
| 97handling, however there is a problem. 98If, for example, the application 99issues a request to setup a connection. 100It may do it by sending a 101.Dv SETUP.request 102signal to the UNI. 103Normally the UNI stack will send a SETUP message and 104receive a message from the switch (a RELEASE, CONNECT, CALL PROCEEDING or 105ALERTING) or a timer in the UNI stack will time out. 106In any of these cases 107the UNI stack is supposed to report an event back to the application and | 97handling, however there is a problem. 98If, for example, the application 99issues a request to setup a connection. 100It may do it by sending a 101.Dv SETUP.request 102signal to the UNI. 103Normally the UNI stack will send a SETUP message and 104receive a message from the switch (a RELEASE, CONNECT, CALL PROCEEDING or 105ALERTING) or a timer in the UNI stack will time out. 106In any of these cases 107the UNI stack is supposed to report an event back to the application and |
| 108the application will unblock (in the case of a synchronuous API) and handle | 108the application will unblock (in the case of a synchronous API) and handle |
| 109the event. 110The problem occurs, when an error happens. 111Suppose there is no 112memory to send the SETUP message and to start the timer. 113In this case the 114application will block forever, because no received message and no timer 115will wake it up. 116For this reason this implementation uses an additional message: 117for each signal sent from the application to the stack, the stack will 118respond with an error code. 119If this code is zero, the stack has accepted 120the signal and the application may block, if the code is non-zero, the signal | 109the event. 110The problem occurs, when an error happens. 111Suppose there is no 112memory to send the SETUP message and to start the timer. 113In this case the 114application will block forever, because no received message and no timer 115will wake it up. 116For this reason this implementation uses an additional message: 117for each signal sent from the application to the stack, the stack will 118respond with an error code. 119If this code is zero, the stack has accepted 120the signal and the application may block, if the code is non-zero, the signal |
| 121is effectivly ignored and the code describes, what was wrong. | 121is effectively ignored and the code describes, what was wrong. |
| 122This system 123makes it very easy to make a blocking interface out of the message based 124netgraph interface. 125.Pp 126The 127.Dv upper 128interface uses the following structure: 129.Bd -literal --- 270 unchanged lines hidden (view full) --- 400LIJ (leaf-initiated-join) is not implemented yet. 401.It 402GFP (generic functional protocol, Q.2932.1) is not yet implemented. 403.It 404More testing needed. 405.It 406PNNI not yet implemented. 407.It | 122This system 123makes it very easy to make a blocking interface out of the message based 124netgraph interface. 125.Pp 126The 127.Dv upper 128interface uses the following structure: 129.Bd -literal --- 270 unchanged lines hidden (view full) --- 400LIJ (leaf-initiated-join) is not implemented yet. 401.It 402GFP (generic functional protocol, Q.2932.1) is not yet implemented. 403.It 404More testing needed. 405.It 406PNNI not yet implemented. 407.It |
| 408Need to implement connection modification and the Q.2931 amandements. | 408Need to implement connection modification and the Q.2931 amendments. |
| 409.Sh AUTHORS 410The 411.Nm 412netgraph node 413and this manual page was written by 414.An Harti Brandt Aq harti@freebsd.org | 409.Sh AUTHORS 410The 411.Nm 412netgraph node 413and this manual page was written by 414.An Harti Brandt Aq harti@freebsd.org |