🚀 go-pugleaf

In article <139433@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>Can anyone out there in netland give me a correct description of the Datapac
>Priority Calling facility? As I have it in some existing code, it appears to
>be a facility 0x01 0x01 following the national marker, and its presense forces
>the packet size to 128. I don't know if this is correct, or if it invokes more
>things that I need to be aware of. For example, should my Call Accept daemon
>give it special preference?
>

I assume you are talking about the Datapac network in Canada even though your
organization line indicates that you are in California (there are lots of data
networks around the world called Datapac).

Datapac (Canada) uses Northern Telecom's DPN packet switching equipment. The DPN
equipment does not force 128 byte packets for priority calls. The default
packet size and allowable packet size for priority calls is programmable. 
Datapac has choosen to default priority calls to 128 byte.

Priority calls in the system get preference over normal calls:

   - priority traffic skips over normal traffic when transmitted across the
     network.
   - all traffic is subject to congestion/flow control. The thresholds for
     priority traffic are higher than normal traffic so that priority traffic
     is given preference in high load situations.
   - call setup is subject to thresholds based on system resources. Priority
     call threshold are again higher which allows priority calls to be 
     originated in high load situations.

Should your call accept daemon give priority calls special attention? That's
up to you. Once the call has reached you, it has already made it all the way
through the network. If you accept calls based on local resource usage, I 
would give priority calls a slightly better chance of getting accepted in
high utilization situations.

Should anything else be different? I hope not. X.25 is X.25 and I would hope
that the data transfer would be transparent to priority/normal (other than
priority being faster).
--
-------------------------------------------------------------------------------
Gary Mussar  |Bitnet:  mussar@bnr.ca                  |  Phone: (613) 763-4937
BNR Ltd.     |  UUCP:  ..uunet!bnrgate!bcars53!mussar |  FAX:   (613) 763-2626

In article <139433@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>Can anyone out there in netland give me a correct description of the Datapac
>Priority Calling facility? As I have it in some existing code, it appears to
>be a facility 0x01 0x01 following the national marker, and its presense forces
>the packet size to 128. I don't know if this is correct, or if it invokes more
>things that I need to be aware of. For example, should my Call Accept daemon
>give it special preference?
>
Some of the old X.25 hacks seem to be getting lost in antiquity.
There are two encodings, depending on the plenary year of the
implementation.   

In the 1976 plenary year, it is encoded as part of the Fast
Select/Reverse Charge facility parameter, which was _not_ a CCITT X.2
defined facility at the time, although reverse charging was defined as
a facility 'for further study for inclusion in Recommendation X.2'.
The facility code is 0x01. 

The facility parameter is parsed in the following manner.  Using CCITT
bit numbering, where bit 8 is MSB, bit 8 indicates fast select, bit 7
indicates restricted response to a fast select call, bit 2 is Datapac
specific and indicates priority class (packet size of 128) when set,
and bit 1 indicates reverse charging.

In the 1980 plenary year, traffic class is treated as a Datapac
national facility, and follows the national options marker which is
0x00 if Datapac is the calling PDN, and 0xFF if Datapac is the called
PDN.

The facility code for traffic class is 0x01.  The parameter value is
0x01 if Priority class (packet size of 128) is requested, and 0x00 if
not requested.