Telecommunications - Configuration of X.25 Hunt Group

 

Subscription Option - Hunt Group

This facility distributes incoming calls with an address associated with the hunt group across a designated grouping of lines.

Selection is performed for an incoming virtual call if there is at least one idle logical channel, excluding one-way outgoing channels, available for virtual calls on any of the lines in the group. Once a virtual call is assigned to a line, it is treated as a regular call.

Each line can have its own address in addition to the hunt group address associated with that line. When virtual calls are placed to a hunt group address in the case where specific addresses have also been assigned to the individual lines, the call connected packet (or the clear indication packet) transferred to the calling DTE will contain the called DTE address of the selected line and the Called line address modified notification (CLAMN) facility will indicate the reason why the called DTE address is different from the one originally requested.

UK Hunt group support:

X.2 LEVEL 3 PER USER SUBSCRIPTION X.2 (1984) UK(a) UK(b) interworking
OPTIONS REF CLASS now now R5a R5b R6
Hunt group (multiline).............. 1.24 A p
with adr replacement..... . . . p

| Hunt group (multiline)..............| 1.24 A |

|

|

|

|

| | | # | with adr replacement.....| | . | . | . |

|

| | | #

UK(a) UK(b)
Hunt Group (also known as multiline)
Address replacement from rel 5
CLAMN from rel 5b
CRN from rel 5b
limitations cannot be spread over more than one PSE
load sharing only within lines on the same node call will be sent over least cost route. This will depend on Line speeds,etc also depends on ROTATE and LINKBI parameters.
max number of lines 6 on any node
upto 6 nodes within PSE
redirect on hunt not recommended
group hunt group takes priority over redirect but only if hunt groups are all on one node

UK(b) - Hunt group can be provided in the following ways:

* Shared host number:

upto 15 lines can share the same host number. This provides very powerful load sharing capabilities. However it has a major drawback, that is, all the lines must be based on the same software slot (on the same node), this limits the throughput and the resilience of the hunt group. The loadsharing options are as follows:

ROTATE ON:

incoming calls are sent to each link on a round-robin rotation, each link is selected the number of times specified in the Link Bias macro.

ROTATE OFF:

incoming calls are sent to the link with the lowest number of channels in use (weighted by the LINKBIAS value).

The link used can also be selected by subaddress.

* multitargeting:

Each line has its own host number, the lines can be spread over the whole UK(b) UK network. All these hosts are put in a HOSTLIST which has an alphanumeric name which is known globally on the network. The destination will be selected on a least cost basis, the link selected will depend on:

* The speed of the link.

* The number of free logical channels.

* The number of internal network hops to each alternative link.

* The network loading.


I don't know how (or if) a HOSTLIST can be specified in an X.25 NUA. We need to check this with UKb.


UKa already provide a facility known as 'multiline'. Hunt Group is the CCITT version of multiline which has the additional ability to give each line a unique address.

UKa claim that release 4 supports the full hunt group functionality.

The hunt group is implemented in the same way as multiline and it has the same limitations, ie,

a) all lines must be connected to the same PSE.

b) load sharing is only done if all lines are on same switch

c) maximum of 6 lines per switch (or 8 if limited to one switch)

d) maximum of 6 switches

If both HUNT group (multiline) and redirection are subscribed to the priority of these two facilities will depend on whether the multiline is spread over several switches.

UKa Answers

Question :-

How is hunt group with address replacement built using Autorouter (without manual routes)?

ANSWER :- Hunt Groups can only be setup using manual routes.

table build question:

TNDTED Q130(was Q11 ) Hunt Group address replacement (YES/NO)

|TNDTED Q130| Q11 | Hunt Group address replacement......#default NO

The hunt group replacement option allows a DCE to replace the hunt group common address with a DTE specific address. The addresses are replaced in the incoming call packet. (if the DCE does not perform hunt group address replacement, the called DTE may replace the hunt group common address with a specific address, and provide the CLAMN facility (Q119). In this case the addresses are replaced in the call accept or the clear request packet.

If multiple address assignment (MAA) is enabled on a member of a hunt group, and the DTE does not subscribe to the hunt group replacement option, make sure that the DTE is required to send the CLAMN facility when it changes the called address.

TNDTED Q119(was Q12 ) sending CLAMN facility (YES/NO)

|TNDTED Q119| Q12 | sending CLAMN facility..............#default NO

This question determines whether a DTE that receives a call is required to notify the network when and why it has changed the destination DTE address in the response to the call request packet. The called line address modified notification (CLAMN) facility, which provides the information about the change, is included in the call connected or clear indication packet sent to the originating DTE if the DTE subscribes to receipt of CLAMN. The reason given why the called address was changed is "DTE originated".

You can choose this option for any DTE that may change the called address. However, to ensure successful DTE-to-DTE communication, always answer YES if the DTE: has a MAA entry and does not subscribe to Hunt group address replacement.

TNDTED Q120(was Q13 ) receipt of CLAMN facility (YES/NO)

|TNDTED Q120| Q13 | receipt of CLAMN facility...........#default NO

A DTE that subscribes to this facility is notified whenever one of its calls has been routed to an alternate DTE. The notification includes the address of the alternate called DTE in the address field, and the reason why the called address was changed. This facility is included in the call connected or clear indication packet.

Possible reasons why the called address is changed are:

call distribution within a hunt group

original called DTE was out of order

original called DTE was busy

original called DTE subscribes to systematic redirection

called DTE changed address

DTE originated

A CLAMN facility can be originated by:

A DTE that subscribes to CLAMN

A source TP4 using CCITT 1984 protocol, if the destination DTE changes the called address and is not required to send the CLAMN facility

The destination TP4, if the called DTE changes the called address and does not send the facility

&UKb& = yUKb support

v 4.03

SVC: partial support

does not generate the Called Line Address Modified Notification (CLAMN) facility but is capable of receiving the facility from either DTE.

Macroes:

LINKHO

ROTATE

LINKBI

HOST MACROS

The following macros specify options on a per-host basis. The macros in this section assign origination and destination host numbers to the XCOM interface's links (the Link Host Number [LINKHO] and Host Links [HOSTLI] macros) and define the method(s) that the XCOM interface uses to select a link over which to route an incoming call when several possible links to the host exist (the Rotate Links [ROTATE] macro). Also included in this section are macros that implement additional features for a host; features such as the multibasing and load-levelling of any of the hosts assigned to the interface (the Host Key [HOSTKE], Host Cost [HOSTCO], and Host Port Availability [HOSTPO] macros) and additional link selection methods (the Address Position [ADRPOS], Address Links [ADRLIN], and to RPOA [TORPOA] macros). Although the HOSTLI macro is the only host macro that must be specified in the Tymfile, the default values for the LINKHO and ROTATE macros cause specific interface action and should be reviewed even if the default values are left unchanged.

LINK HOST NUMBER MACRO

Syntax: LINKHOstnumber({ln,hn})

Default: none

Range: ln is 0 to 31;

hn is any valid network host number

This macro assiUK an origination host number to a link. When the XCOM interface receives an outgoing call from the link, the interface can then identify the source of the call for accounting purposes. The parameter hn specifies the origination host number; the parameter ln specifies the link number.

Because each link can be assigned only one origination host, only one LINKHO macro should be specified for each interface link. There can, however, be several links to the same host; the same origination host number can therefore be specified in more than one LINKHO macro.

Although this macro is optional, the function it performs is not. Therefore, if a LINKHO macro is not specified for a particular link, the interface uses the value specified for the hn parameter of the first Host Links (HOSTLI) macro referring to that link as the origination host number for that link.

NOTE

If multiple links are assigned to a host and the Called Address (CLDADR), Call User Data String (CUDSTR), or Call User Data Username (CUDUSE) macro, or the TADR switch option of the UKa (TELENE) macro is specified for one of these links, the macro or switch option must also be specified for all of the other links assigned to the host.

Example:

LINKHO(1.999)

Any outgoing calls that the XCOM interface receives on link 1 are from host 999.

HOST LINKS MACRO

Syntax: HOSTLInks ({hn,ln[,...,ln14]})

Default: none

Range: any valid network host number for hn;

0 to 31 for ln

This macro assiUK a link number or a set of link numbers to a destination host number. When the XCOM interface receives an incoming call destined for a particular host, the interface can then select a valid link over which to route a call. Because each link ultimately maps to a hardware port (or in the case of FML, two hardware ports), this macro, in effect, identifies the logical host number(s) of the physical device at the end of the link. A HOSTLI macro must be specified for each host attached to the interface. Any one of these host numbers can be used to address the interface.

The parameter hn specifies the network destination host number assigned to the link parameters that follow hn. Although this macro can be repeated for up to 256 different hosts, or the maximum defined in the Maximum Number of Hosts (MAXHOS) macro, only one HOSTLI macro should be specified for each network host number.

The ln parameters specify the link number or range of link numbers assigned to the host. A range of links can be specified individually separated by commas (in the form ln0, lnl,...,ln14), or separated by a hyphen (in the form ln0-ln14). Thus, if links 2, 3, and 4 were to be assigned to the host, the links could be specified as either 2,3,4 or 2-4. A maximum of 32 link assignments) can be specified per macro. A link number can be specified in more than one HOSTLI macro for different host numbers.

When the interface receives a call for a destination host with more than one link assigned to it, the interface selects one of the links according to the criteria specified in the Rotate Links (ROTATE) and Link Bias (LINKBI) macros.

Example:

HOSTLI(999,1,3)

The XCOM interface can route incoming calls destined for host 999 over either link 1 or link 3.

HOST COST MACRO

Syntax: HOSTCOst([mincost] [,maxcost] [,mincostchan]

[,maxcostchan] [,numsteps] [,maxsteps])

Default: mincost is 0;

maxcost is 18;

mincostchan is maximum available channels * 3/4

maxcostchan is maximum available channels/4;

numsteps is 4;

maxsteps is 4

Range: mincost is 0 to maxcost but less than 255;

maxcost is greater than mincost but less than 255;

mincostchan is less than or equal to maximum available

channels;

maxcostchan is greater than or equal to 0;

numsteps is 2 or less than or equal to 128, or 0 if

mincostchan is equal to maxcostchan;

maxsteps is greater than or equal to numsteps and less

than or equal to 128

This optional macro specifies that the XCOM interface generates and sends Host Cost reports to the network Supervisor, and allows the user to modify values in the formula used to calculate the host cost values reported. Because the Supervisor uses the information in these Host Cost reports to determine the lowest-cost path through the network only when more than one possible destination host exists, this macro is useful only for hosts that are multitargeted or multibased.

A host is multibased when one host number is assigned to one or more nodes. A host is multitargeted when it is one of a group of hosts targeted to a single username. When the Supervisor receives a call destined for a multitargeted or multibased host, the Supervisor determines the host to which the circuit will be built based on the route with the lowest cost. The Supervisor bases this calculation on a variety of factors, including the link speed, link usage, and (if the Host Cost macro is specified) the host cost reported by the interface.

The Supervisor assiUK a cost to each network link based on the speed and usage of the link. Table 5-4 lists the cost for links of different speeds that are not overloaded. Heavily used links are assigned a higher cost.

Table 5-4. Link Costs

LINK SPEED* LINK COST
100 kbps 1
56 kbps 2
9.6 kbps 5
4.8 kbps 9
2.4 kbps 32

* Indicates Serial Input/Output (SIO) link speeds in kilobits per second (kbps)

__________________________________

The interface bases each host cost calculation on a comparison of the total number of hostbound channels configured for the host, to the number of these hostbound channels currently available.

A hostbound channel is a channel over which Incoming Call packets can be routed to a host; only channels configured as incoming and two-way can be hostbound. Thus, the total number of hostbound channels is equal to the smaller of the following numbers:

total number of two-way and incoming-only channels of all the links belonging to the host

total number of dispatcher ports available to the interface.

The total number of channels available at any given time to a host at an interface is equal to the smaller of the following numbers:

total of the unused two-way and incoming-only channels of all those links belonging to the host that are not down

total number of unused dispatcher ports available to the interface

Host cost values are calculated in incremental steps so that the relationship of available channels to the total number of channels can vary considerably and still be considered to have the same host cost. If the different between the number of available channels and the total number of channels exceeds a certain range, the host cost is incremented to the next step.

The parameters of the HOSTCO macro specify values with which the interface calculates the host cost it reports to the Supervisor.

The parameters are defined as follows:

mincost Specifies the minimum host cost that the interface

this cost whenever the number of channels available for building circuits to the host is at least the mincostchan parameter.

maxcost Specifies the maximum host cost that the

reports this cost whenever there are fewer than the maxcostchan parameter number of channels available for building circuits to the host.

mincostchan Specifies the lowest number (or lower limit) of available channels at which the interface sends the minimum Host Cost (mincost) report to the Supervisor. When the number of available interface channels is the value specified by the mincostchan parameter or greater, the interface sends the minimum Host Cost (mincost) report to the Supervisor.

maxcostchan Specifies the highest number (or upper limit) of

Cost (maxcost) report to the Supervisor. When the number of available interface channels is less than the value specified by the maxcostchan parameter, the interface sends the maximum Host Cost (maxcost) report to the Supervisor.

numsteps Specifies the number of different host cost values

Figure 5-1, for example, numsteps is equal to 4).

maxsteps Specifies the maximum value that can be

through the X.25/X.75 Interface Operation Manager

(XOM)). A system generation is necessary if more steps than maxsteps are necessary.

The lowest-cost step has a width equal to the number of available channels greater than the mincostchan parameter. The cost for this step is mincost.

There are "numsteps - 2" middle steps. These steps start with mincostchan ports in use and stop when there are maxcostchan ports in use. Each step is

(mincostchan - maxcostchan)/(numsteps - 2)

channels wide with the remainder distributed over several steps so that the width of any middle step is at most 1 greater than the width of any other middle step. Thus, if mincostchan is 21, maxcostchan is 5, and numsteps is 8, the number of middle steps is 8 - 2 = 6, and the basic step width is (21 - 5)/(8 - 2) = 2 with a remainder of 4. The middle step widths are therefore 2, 2, 3, 3, 3, and 3.

The interface calculates the host cost increment from one step to the next using the following formula:

maxcost - ((maxcost - mincost) * current step)/(numsteps - 1)

in which the interface calculates the current step from the numsteps parameter; the current step increases from 1 to (numsteps - 2). The change in host cost from step to step is approximately the same.

The width of the highest-cost step is the value of the maxostchan parameter. The cost for this step is maxcost.

The interface checks the number of available interface ports every 15 seconds. Each time the number of available interface ports increases or decreases, the interface recalculates the current host cost for each host. The interface sends a revised Host Cost report to the Supervisor only when the number of available interface ports increases or decreases from one step to another and the host cost jumps to the next step. This restriction limits the number of Host Cost reports sent to the Supervisor when interface traffic increases or decreases suddenly.

If the HOSTCO macro is specified without any parameter values, the interface sends Host Cost reports to the Supervisor based on the default parameter values. The default values are, however, designed to approach a link cost of 18 in 4 steps. Figure 5-1 illustrates the default values, assuming that the interface is configured for 32 hostbound channels.

Suppose the link cost for a 9.6 kbps link were 5 and the link cost for a 4.8 kbps were 9. The figure shows that a cost of 0 is associated with the host as long as the number of channels available for the host is greater than or equal to 24. If the number of available channels falls below 24, the interface reports a cost of 6 and this host is not selected unless it is more than one 9.6 kbps link closer to the origination (assuming the other hosts have a cost of 0). The interface does not report a cost of 0 again until the number of available channels is at least 24.

If the number of available channels is between 8 and 15, the interface reports a host cost of 12. This cost is greater than 18 when there are fewer than 8 available channels. In this case the cost of the host is the same as two additional 4.8 kbps links.

If the HOSTCO macro is not specified, the XCOM interface does not send Host Cost reports to the Supervisor.

Example:

HOSTCO(4,32,33,8,6,8)

This macro specifies the following:

If the number of available channels is 40, the lowest step has the width of the number of available channels greater than the mincostchan parameter, or 40 - 33 = 0 to 7 channels available with a width of 8.

There are 6 - 2 = 4 middle steps with a width of (33 - 8)/ (6 - 2) = 6 and a remainder of 1. The middle step widths are therefore 6, 6, 6, and 7.

The host cost increment from one step to the next is

32 - ((32 - 4) * current step)/(6 - 1)

as shown in Table 5-5.

Table 5-5. Host Cost Increment

CURRENT STEP CHANNELS AVAILABLE WIDTH HOST COST
0 0 - 7 8 32
1 8 - 13 6 27
2 14 - 19 6 21
3 20 - 25 6 16
4 26 - 32 7 10
5 33 - 40 8 4

The highest-cost step has the width of the value of the maxcostchan parameter, or 8. The host cost for this step is the maxcost parameter, or 4.

The interface sends a Host Cost report to the Supervisor when the number of available channels increases or decreases from one step to another and the host cost jumps to the next step; in this example, the interface sends Host Cost reports to the Supervisor when the number of available channels increases from 7 to 8, 13 to 14, 19 to 20, 25 to 26, and 32 to 33.

HOST PORT AVAILABILITY MACRO

Syntax: HOSTPOrtavailability([availableabove]

[,unavailablebelow])

Default: availableabove is 1;

unavailablebelow is 1

Range: availableabove is greater than or equal to unavailable-

below and less than the maximum number of usable

channels for the host;

unavailablebelow is 0 to availableabove

This optional macro specifies that the XCOM interface generates and sends Host Port Availability messages to the Supervisor when the number of available hostbound channels (channels over which Incoming Call packets can be routed to a host) is outside a specified range. This macro allows a host to limit the number of simultaneous calls it receives.

If this macro is specified for a host, when the number of available hostbound channels drops below the value specified for the unavailablebelow parameter, the interface sends to the Supervisor a NO HOST PORTS AVAILABILITY message for this host. The interface sends a HOST PORTS AVAILABLE message to the Supervisor when the number of available hostbound channels exceeds the value specified for the availableabove parameter.

If the HOSTPO macro is specified without parameter values, when there are no hostbound channels available (the unavailablebelow parameter equals 1) the interface sends a NO HOST PORTS AVAILABILITY message to the Supervisor. The interface sends the HOST PORTS AVAILABLE message to the Supervisor as soon as one hostbound channel becomes available (the availableabove parameter equals 1).

Thus, in a configuration in which the number of dispatcher ports is equally divided among the different types of channels, the total number of available hostbound channels at any given moment equals the sum of the channels configured as incoming and two-way minus the number of these channels currently in use.

However, in a configuration in which the number of configured channels exceeds the number of configured dispatcher ports, the total number of available hostbound channels at any given moment is also dependent on the number of dispatcher ports available at that moment. In this type of configuration, the number of available hostbound channels at any given time is equal to the smaller of the following numbers:

* sum of the channels configured as incoming and two-way

minus the number of those channels currently in use

* number of dispatcher ports available

To specify the availablebelow and unavailablebelow parameters for this macro, use the following formulas:

unavailableabove = maxchanavail - L - 1

unavailablebelow = maxchanavail - U + 1

in which maxchanavail is the maximum number of channels available

L is the highest number of users connected

to the interface at which the interface

first has ports available (the point at which the interface is to become available)

U is the maximum number of users that can

be connected to the interface (the number at which the interface is to become available)

If the HOSTPO macro is not specified, the XCOM interface does not generate Host Port Availability messages.

Example:

HOSTPO(17,9)

In this example, a maximum of 48 users can connect to the host. The XCOM interface reports that the host is out of ports when the number of users reaches 40, and the host becomes available again when the number of users drops to 30. The following formulas demonstrate how the parameters were determined:

availableabove = 48 - 30 - 1 = 17

unavailablebelow = 48 - 40 + 1 = 9

HOST KEY MACRO

Syntax: HOSTKEy({key})

Default: key is Host Links (HOSTLI) macro position number

Range: key is 0 to 255

This macro assiUK to the host number defined in the last Host Links (HOSTLI) macro a host key value in the range 1 to 255. Typically, once a host number reports up on interface, the Supervisor rejects any attempts to bring up that same host number on another interface. The HOSTKE macro bypasses this restriction by allowing the last HOSTLI host number to be multibased (that is, simultaneously associated with more than one XCOM interface) and thus offers redundancy in host accessibility.

This host key is reported as an extension to its host number each time the host makes a status report to the Supervisor; the key indicates to the Supervisor that this host number can be reported up on more than one interface, if the other interface reporting this host number also reports this same host key. Thus, XCOM interfaces reporting the same host number to the Supervisor must use the same host key in order for the host to be authenticated and accepted by the Supervisor.

If this macro is specified without a key parameter value, the default value is determined by the number of HOSTLI macros prior to this HOSTKE macro; for example, if the HOSTKE macro that follows the third HOSTLI macro in the Tymfile is specified without a key parameter value, the default host key for that host is three.

If this macro is not specified, a host key value of zero is assigned. A host key value of zero indicates that the host number is not multibased; the Supervisor rejects all future hosts with the same number.

Example:

HOSTKE(73)

The host number defined in the preceding HOSTLI macro can be associated with more than one XCOM interface, but each time the host reports up, the host must report a host key of 73.

ROTATE LINKS MACRO

Syntax: ROTATElinks({ON|OFF})

Default: none

When the XCOM interface receives a call from the network that is destined for a host to which the interface has more than one link, the interface must select one link over which to route the call. This macro specifies the selection method to be used when this occurs for the host defined in the preceding Host Links (HOSTLI) macro, and implements the Hunt Group facility of X.25 by distributing incoming calls across a series of links.

If this macro is set ON, link selection is based on round-robin rotation and each link (with an available incoming or two-way channel) is selected the number of times specified in the Link Bias (LINKBI) macro before rotating to the next link.

If this macro is set OFF, link selection is not based on rotation. Instead, all of the links to the host with an available (ready) incoming or two-way channel are weighted by multiplying the number of channels in use by the bias value specified in the LINKBI macro. The interface selects the link with the lowest product.

Regardless of which link selection method is chosen, the set of available links is determined by the following process:

1 All links associated with the host number in a HOSTLI macro are placed in a working set.

2 Any links in the working set that are not up or have no available incoming or two-way channels are removed from the working set.

3 If a Recognised Private Operating Agency (RPOA) facility request is present in the call, any links that are not specified in the To (TORPOA) macro for the requested RPOA are removed from the working set. Because any RPOA selection information entered by the CONSAT user is not currently used by the XCOM interface, this link selection criterion applies only to packet-mode DTE calls (see the TORPOA macro).

4 If subaddress routing is specified for his host number with the Address Links (ADRLIN) and Address Position (ARDPOS) macros, the interface examines one to four digits of the called address; any links that are not specified for the called address are removed from the working set.

The ROTATE macro specifies the final link selection method for those links remaining the working set. If this macro is not specified, link selection defaults to the OFF procedure.

Example:

ROTATE(ON)

The XCOM interface routes each incoming call (destined for the host defined in the preceding HOSTLI macro) to one link based on the link rotation method.

ADDRESS POSITION MACRO

Syntax: ADRPOS({len})

Default: none

Range: len is -4 to -1 or 1 to 4

This macro, when specified with at least one Address Links (ARDLIN) macro, indicates that subaddress routing is to be implemented for the host defined in the preceding Host Links (HOSTLI) macro.

Subaddress routing permits incoming calls destined for a specific host to be routed to a subset of the links assigned to the host based on a one- to four-digit subfield extracted from the called address.

This macro specifies the position and length of the subfield that the interface extracts from the called address. The specific sub-field-value link assignments are defined in Address Links (ARDLIN) macros.

The parameter len indicates the number of digits that the interface extracts from the called address. If the value of len is less than zero, digits are taken from the end of the address. If the value of len is greater than zero, digits are taken from the start of the address.

In general, when the link is to another network, the interface uses the first four digits of the address (the DNIC of the destination network). In general, when the link is to a host, the last one to four subaddressing digits are used.

If the ADRPOS macro is not specified, the number of digits that the interface extracts from the called address defaults to four.

Example:

ADRPOS(-2)

The interface routes each incoming call (destined for the host defined in the preceding HOSTLI macro) to a set of links based on the last two digits of its called address. The specific link assignments are specified in the ADRLIN macros that follow.

ADDRESS LINKS MACRO

Syntax: ADRLINks({adr|ANY,ln[,...,ln9]})

Default: none

Range: adr is 0 to 9999;

ln is 0 to 31

This macro, when specified with an Address Position (ADRPOS) macro, indicates that subaddress routing is to be implemented for the host defined in the preceding Host Links (HOSTLI) macro.

Subaddress routing permits incoming calls destined for a specific host to be routed to a subset of the links assigned to the host based on a one- to four-digit subfield extracted from the called address.

This macro defines the specific subfield-value link assignments. The ADRPOS macro specifies the position and length of the subfield that the interface extracts from the called address.

The parameter adr specifies the actual subfield value or range of subfield values (in the form adr1-adr2) upon which the link assignments are made. In general, when the link is to another network, the interface uses the first four digits of the address (the DNIC of the destination network). In general, when the link is to a host, the interface uses the last one to four subaddressing digits.

Multiple ADRLIN macros can be specified per host, but the total number of ADRLIN macros specified for the interface must not exceed the value specified in the Maximum Number of Address Links Assignments (MAXADR) macro. If the MAXADR macro is not defined in the interface Tymfield, the default is the number of ADRLIN macros explicitly defined for the interface.

The specification of the ANY option instead of a specific adr value or range of values indicates that any subfield value can be assigned to the links that follow. If no ADRLIN macro is specified with the ANY option, each time the interface receives a call in which the subfield called address does not match any of the subfield values specified in the ADRLIN macros, the interface clears the call.

The ln parameters specify the link number or range of link numbers to be assigned to the specified subfield. Only links assigned to the host in the preceding HOSTLI macro should be specified for each link parameter. Links can be specified individually separated by commas (in the form ln0, ln1,...,ln9) or in a range separated by hyphens (in the form ln0-ln9). Although only 10 link parameters can be specified in a single ADRLIN macro, the same adr value can be repeated in more than one ADRLIN macro per host, to indicate additional links. However, when multiple ADRLIN macros are specified with the same adr value for the same host, the following selection process occurs:

1 The interface searches ADRLIN macros in the order they appear in the Tymfile.

2 If the interface finds a matching ADRLIN macro, but none of the links are available, the interface continues to search the next ADRLIN macro.

When the interface finds an available match, the interface selects one of the specified links according to the criteria specified in the Rotate Links (ROTATE) and Link Bias (LINKBI) macros.

Example:

ADRLIN(03,1,3-4)

The XCOM interface can route each call (destined for the host defined in the preceding HOSTLI macro) that contains a called address beginning or ending with the digits 03 only to link 1, 3, or 4. The position of the two digits is determined by the sign (positive or negative) of the value specified for the len parameter of the ADRPos macro.


Test plan and implementation issues

The specific address feature is not practical to implement on Public Network because it can only built using manual routes.

We cannot build the hunt group address replacement using autorouter without manual routes.

This is a tricky one to test - we need to try all combinations of -

hunt group

CRN

CLAMN

enhanced DTE

call originator 1980

call receiver 1980

+ all facility options that could be generated by either end

+ mixing with other options such as redirect


metadata block
see also:

 

Correspondence about this page

Book Shop - Further reading.

Where I can, I have put links to Amazon for books that are relevant to the subject, click on the appropriate country flag to get more details of the book or to buy it from them.

cover The Essential Guide to Telecommunications (Essential Guide).

Commercial Software Shop

Where I can, I have put links to Amazon for commercial software, not directly related to the software project, but related to the subject being discussed, click on the appropriate country flag to get more details of the software or to buy it from them.

 

This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2023 Martin John Baker - All rights reserved - privacy policy.