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:
- the minimum host cost is 4
- the maximum host cost is 32
- the interface reports the minimum host cost when there are 33 or more available channels
- the XCOM interface reports the maximum host cost when there are 7 available channels or fewer
- the interface can report up to 6 different host cost values to the Supervisor
- the maximum value that can be assigned (by XOM) to the number of different
host cost values reported is 8
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