In the SVC routings table are stored the information needed to identify the incoming call and to route it to the wished port. Moreover every SVC routing contains data of the outgoing call and information on the compression protocol to be used.
The functions realized through SVC routing are:
If the call, selected by the routing, fails to reach its destination, it is possible to repeat the routing search procedure.
The functionality of alternative routing must be expected by the routing previously used.
The SVC routings table contains by default four routings: two routings for being able itself to connect to the Control Port and two routings in order to allow the calls "to pass" the Abilis CPX in transparent way.
Routings can be added, modified, deleted while the Abilis CPX works, without needing to restart it.
Calls, incoming after the changes, will use the new table, while those in course will remain active with the previous parameters values, until their closing.
All the commands for the SVC routings management are described in the section SVC Routing of the chapter Commands relating to the Connection Oriented Router.
The available commands are the following:
A RExample of displaying all the SVC routings:
[18:14:08] ABILIS_CPX: D R
- Not Saved (SAVE CONF) -------------------------------------------------------
---+----+----+----+---------------+---------------+------------+--------------
PR |COMP|POI |POO |CDI |CDO |UDI |UDO
|NEXT| |CGI |CGO |PIDI |PIDO
| |IPSRC |IPDEST |FFO
------------------------------------------------------------------------------
0 NO * 0 * * CP *
NO * * * *
*
------------------------------------------------------------------------------
1 NO 301 302 * * * *
NO * * * *
*
------------------------------------------------------------------------------
2 NO 302 301 * * * *
NO * * * *
*
------------------------------------------------------------------------------
3 NO 907 NONE 007 * * *
NO * * * *
'ipsrc_list' *
------------------------------------------------------------------------------
4 NO NONE 907 * 007 * *
NO * * * *
192.168.000.007 *
------------------------------------------------------------------------------
The "Not Saved (SAVE CONF)" message is displayed every time the table is modified but not saved with the SAVE CONF command.
Example of displaying, using an extended format, of all the SVC routings:
[18:14:08] ABILIS_CPX: D RE
PR:0 POI:* POO:0 COMP:NO
NEXT:N CGI:* CDI:* UDI:CP PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
PR:1 POI:301 POO:302 COMP:NO
NEXT:N CGI:* CDI:* UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
PR:2 POI:302 POO:301 COMP:NO
NEXT:N CGI:* CDI:* UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
PR:3 POI:907 POO:* COMP:NO IPSRC:'ipsrc_list'
NEXT:N CGI:* CDI:007 UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
PR:4 POI:* POO:907 COMP:NO IPDEST:192.168.000.007
NEXT:N CGI:* CDI:* UDI:* PIDI:*
CGO:* CDO:007 UDO:* PIDO:*
FFO:*
Example of displaying, in an extended format, a single routing. Values are examples of a particular SVC routing that allows receiving/placing X.25 calls from/to TCP/IP using XTP port type.
[18:14:08] ABILIS_CPX: D RE PR:3
PR:3 POI:907 POO:907 COMP:NO IPSRC:'ipsrc_list' IPDEST:192.168.000.007
NEXT:N CGI:* CDI:007 UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
The optional parameter IPSRC: is also shown. It can be configured only if the input port (POI: ) type is XTP.
The optional parameter IPDEST: is shown, it can only be configured if the output port (POO:) type is XTP.
For more detailed information about management of X.25 traffic over TCP/IP refer to the section The X.25 ports, session tunnelling protocol (XTP).
| PR: | Routing priority (Priority 0 is the highest) |
| no value | from 0 up to 99 |
The routing priority index sets the routing verification order for each incoming call.
The verification starts from the routing with priority 0 and continues until a routing is found matching the incoming call or the end of the table is reached.
The routing priority index is also used like reference for the operations of insertion, modification and deleting.
The SVC routings table is automatically maintained with consecutive indexes of priority, that is without "empty" places. Therefore every action of deleting or insertion makes the system to reorder all the indexes succeeding the referred one.
If an incoming call does not match any routing, the Abilis CPX will refuse the call with the codes F0,A0 (Customer not Configured. No routing matches the call).
| POI: | Input port of the call |
| NONE | 0 - 999, *, NONE |
It sets the port from wich the call has to come-in for matching the routing. The number must correspond to an active port inside the system.
The value "NONE", that indicates "no port", can be used for deactivating the routing without cancelling it.
The value "*" is used in order to specify "any port". It is usually used for routings accessing the Control Port.
| POO: | Output port of the call |
| NONE | 0 - 999, NONE |
It sets the output port to which the call that matched the routing will be routed.
The number must correspond to an active port inside the system.
The value "NONE" indicates "no port" and can be used in order to refuse, through this routing, undesired calls.
| CGI: | CALLING address of the incoming call |
| * | from 1 up to 15 decimal digits 0 - 9, *, #, ?, 'ListName' |
It sets the calling address that satisfies the routing.
If "CGI:" contains only the character "*", any calling address satisfies the routing.
The character "*" can be used at the beginning or at the end of a sequence of digits with the meaning of "any digit or character and any number of digits and characters" (E.g.: "*123" or "321*").
If "CGI:" contains only the character "#", no calling address must be present in the incoming call in order to satisfy the routing.
If "CGI:" contains only the character "?", any calling address made of only one digit satisfies the routing. The character "?" can be used in a sequence of digits with the meaning of "any digit" (E.g.: "f?654f" or "1234???").
As it has already pointed out previously, one or more characters "?" can be used in a sequence of digits together with the character "*". As an example it is allowed the following value: "*2??35".
Keep in mind that the character "*" can only appear at the beginning or at the end of a sequence; it is not allowed to write: "0123*23". Moreover the character "*" can only appear once in a given sequence of digits. As an example this writing is not allowed: "*23*".
The name of an element list is also accepted, for checking the calling address of the incoming call in a set of defined X.25 NUAs. The accepted types of list are: list of X.25 NUA (XN) or Rule (RU) type or Rule Master (MR) type. The name of the element list must always be indicated between apexes and must correspond to an element list already existing when the routing has be configured.
| CDI: | CALLED address of the incoming call |
| 00 | from 1 up to 15 decimal digits 0 - 9, *, #, ?, 'ListName' |
It sets the called address that satisfies the routing.
If "CDI:" contains only the character "*";, any called address satisfies the routing.
The character "*" can be used at the beginning or at the end of a sequence of digits with the meaning of "any digit or character and any number of digits and characters" (E.g.: "*123" or "321*").
If "CDI:" contains only the character "#", no called address must be present in the incoming call in order to satisfy the routing.
If "CDI:" contains only the character "?", any called address made of only one digit satisfies the routing. The character "?" can be used in a sequence of digits with the meaning of "any digit" (E.g.: "?654" or "1234???").
As it has already pointed out previously, one or more characters "?" can be used in a sequence of digits together with the character "*". As an example it is allowed the following value: "*2??35".
Keep in mind that the character "*" can only appear at the beginning or at the end of a sequence; it is not allowed to write: "0123*23". Moreover the character "*" can only appear once in a given sequence of digits. As an example this writing is not allowed: "*23*".
The name of an element list is also accepted, for checking the called address of the incoming call in a set of defined X.25 NUAs. The accepted types of list are: list of X.25 NUA (XN) or Rule (RU) type or Rule Master (MR) type. The name of the element list must always be indicated between apexes and must correspond to an element list already existing when the routing has be configured.
| UDI: | USER DATA of the incoming call |
| * | from 1 up to 12 alphanumerical characters 0 - 9, a - z, A - Z, *, #, ?, 'ListName' |
It sets the user data that satisfies the routing.
If "UDI:" contains only the character "*", any content of the user data satisfies the routing.
If "UDI:" contains only the character "#", the user data field of the incoming call must be empty in order to satisfy the routing.
If "UDI:" contains only the character "?", any use data field made of a single digit satisfies the routing.
The character "?" can be used like a sequence of characters with the meaning of "every character" (E.g.: "f?654f" or "1234???").
As it has already pointed out previously, one or more characters "?" can be used in a sequence of digits together with the character "*" (E.g.: "*2??ab").
Keep in mind that the character "*" can only appear at the beginning or at the end of a sequence; it is not allowed to write: "ABCD*23". Moreover the character "*" can only appear once in a given sequence of digits. As an example this writing is not allowed: "*ABC*".
The name of an element list is also accepted, for checking the called address of the incoming call in a set of defined X.25 UDFs. The accepted types of list are: list of X.25 User Data Fields (XU) or Rule (RU) type or Rule Master (MR) type. The name of the element list must always be indicated between apexes and must correspond to an element list already existing when the routing has be configured.
The X.25 protocol defines the possibility of inserting in the call packet 16 bytes for user data (Facility FAST-SELECT
not subscribed), however the first four bytes are normally used in order to identify the DTE-DTE protocols and the remaining
12 are normally used for all the other scopes.
Parameter PIDI: always refers to the first four bytes.
Parameter UDI: always refers to the user data, starting from the fifth byte.
| PIDI: | PID of the incoming call |
| * | 4 hexadecimal digits, *, # |
It sets the first four bytes of the user data that satisfies the routing.
If "PIDO:" contains only the character "*", the PID field of the incoming call is passed without changes to the outgoing call.
If "PIDO:" contains only the character "#", the PID field of the incoming call is not passed to the outgoing one.
If "PIDO:" contains some values, the first four bytes of the user data field of the outgoing call will be set to them.
The character "?" can't be used and the character "*" can be used only alone.
The X.25 protocol defines the possibility of inserting in the call packet 16 bytes for user data (Facility FAST-SELECT
not subscribed), however the first four bytes are normally used in order to identify the DTE-DTE protocols and the remaining
12 are normally used for all the other scopes.
Parameter PIDI: always refers to the first four bytes.
Parameter UDI: always refers to the user data, starting from the fifth byte.
| CGO: | CALLING address of the outgoing call |
| * | from 1 up to 15 decimal digits 0 - 9, *, # |
It sets the calling address of the outgoing call.
If "CGO:" contains only the character "*", the calling address of the incoming call is passed to the outgoing one without changes.
If "CGO:" contains only the character "#", the calling address of the incoming call is not passed to the outgoing one.
If "CGO:" contains some values, the calling address of the outgoing call will be set to them.
Unlike the parameter "CGI:", for the parameter "CGO:" the character "?" can't be used and the character "*" can be used only alone.
| CDO: | CALLED address of the outgoing call |
| * | from 1 up to 15 decimal digits 0 - 9, *, # |
It sets the called address of the outgoing call.
If "CDO:" contains only the character "*", the called address of the incoming call is passed to the outgoing one without changes.
If "CDO:" contains only the character "#", the called address of the incoming call is not passed to the outgoing one.
If "CDO:" contains some values, the calling address of the outgoing call will be set to them.
Unlike the parameter "CDI:", for the parameter "CDO:" the character "?" can't be used and the character "*" can be used only alone.
| UDO: | USER DATA of the outgoing call |
| * | from 1 up to 12 alphanumerical characters 0 - 9, a - z, A - Z, *, # |
It sets the user data field of the outgoing call.
If "UDO:" contains only the character "*", the user data field of the incoming call is passed without changes to the outgoing call.
If "UDO:" contains only the character "#", the user data field of the incoming call is not passed to the outgoing one.
If "UDO:" contains some values, the user data field of the outgoing call will be set to them.
Unlike the parameter "UDI:", for the parameter "UDO:" the character "?" can't be used and the character "*" can be used only alone.
The X.25 protocol defines the possibility of inserting in the call packet 16 bytes for user data (Facility FAST-SELECT
not subscribed), however the first four bytes are normally used in order to identify the DTE-DTE protocols and the remaining
12 are normally used for all the other scopes.
Parameter PIDO: always refers to the first four bytes.
Parameter UDO: always refers to the user data, starting from the fifth byte.
| PIDO: | PID of the outgoing call |
| * | 4 hexadecimal digits, *, # |
It sets the first four bytes of the user data field of the outgoing call.
If "PIDO:" contains only the character "*", the PID field of the incoming call is passed without changes to the outgoing call.
If "PIDO:" contains only the character "#", the PID field of the incoming call is not passed to the outgoing one.
If "PIDO:" contains some values, the first four bytes of the user data field of the outgoing call will be set to them.
The character "?" can't be used and the character "*" can be used only alone.
The X.25 protocol defines the possibility of inserting in the call packet 16 bytes for user data (Facility FAST-SELECT
not subscribed), however the first four bytes are normally used in order to identify the DTE-DTE protocols and the remaining
12 are normally used for all the other scopes.
Parameter PIDO: always refers to the first four bytes.
Parameter UDO: always refers to the user data, starting from the fifth byte.
| FFO: | FACILITY field of the outgoing call |
| * | from 1 up to 15 hexadecimal digits, *, # |
It sets the content of the Facility field of the outgoing call.
If "FFO:" contains only the character "*", the Facility field of the incoming call is passed without changes to the outgoing call.
If "FFO:" contains only the character "#", the Facility field of the incoming call is not passed to the outgoing one.
If "FFO:" contains some values, the user data field of the outgoing call will be set to them.
For the parameter "FFO:" the character "?" can't be used and the character "*" can be used only alone
Every hexadecimal digit is made of two character defined in the intervals [0 - 9] and [A - F].
IF an odd number of characters, or more than 30 characters, or a not valid character is inserted, the following message will be shown: "INVALID VALUE".
Here is an example of FFO in order to signal the demand for taxation to the called one: "S R PR:i FFO:0101", in the outgoing call the Facility field will contain the hexadecimals 01 and 01.
| COMP: | Compression protocol to use |
| NO | NO, QLLC, MBIT |
It sets the compression protocol to use on data exchanging, once the connections is established.
| Value | Meaning |
|---|---|
| NO | No compression protocol is associated to the routing, i.e. data go through the Abilis CPX in a transparent way. It has to be used for connecting users unprovided with Abilis CPX, or for connection, whose compression is not needed. |
| QLLC | The QLLC compression protocol is associated to the routing. |
| MBIT | The MBIT compression protocol is associated to the routing. |
It is indispensable that this parameter setting coincides with the one of the same parameter of the counterpart, obviously for the routing interested in the connection establishing. Protocol MBIT has a system of acknowledgment of the protocol used from the counterpart and if the protocols do not coincide the call is cleared from Abilis CPX with the F0,AA cause codes (Compression protocol of not compatible). Protocol QLLC does not have this system, therefore it is possible that the protocol error is not immediately detected, so that the connection could be closed either from the DTE user because of not valid data or from the Abilis CPX with the codes F0,C2 (Error of expansion) or F0,C3 (Data compressed format not valid)
| NEXT: | Enabling the alternative routing research |
| N (NO) | N (NO), Y (YES) |
It sets up the possibility to search of an alternative routing in the SVC routings table if the call, placed by this routing, fails.
The search of the alternative routing proceeds starting from the routing, whose priority is successive to that one previously used, and it is always based on the data present in the incoming call.
If a new routing is satisfied by the call, a new attempt of connection is carried out using the information configured in such routing.
If also this connection fails, the ulterior search of an alternative routing depends on the value of parameter "NEXT:" of the last routing used.
The procedure of alternative routing can proceed like indicated until (at maximum) 16 call tries with different routings are done.
Usually, every time that the incoming call matches one of the routing present in the table, in the Events Log the priority value of the satisfied routing is saved (e.g.: "Routing Match PR:i").
The recording is carried out whether the call is successful or not.
In the case of alternative routing search procedure the user will be able to detect in the Events Log all the tries made, before the call have been successful or before the definitive failure of the connection.
| IPSRC: | IP source address of the incoming call (Only if POI: is a XTP port type) |
| * | see table, *, 'ListName' |
It sets the source IP address of the incoming call received from the POO: port of XTP type.
The IP address of the incoming call is compared with the one stored in the "IPSRC:" routing parameter. Only those incoming call, whose IP source address matches the this parameter are accepted. The other calls are refused with codes F0,A0 (Customer not Configured. No routing matches the call).
The allowed values are summarized in the following table:
| HEX: | 00000000 | 01000000 - 7EFFFFFF | 80000000 - DFFFFFFF |
|---|---|---|---|
| DDN: | 0.0.0.0 | 1.0.0.0 - 126.255.255.255 | 128.0.0.0 - 223.255.255.255 |
IP address of class D and E are not currently supported.
The value 0.0.0.0 is shown with the character "*" and it means "any IP address". The calls, incoming from any IP source, are accepted.
The name of an element list is also accepted, for checking source IP address of the incoming call in a set of defined IP adresses. The accepted types of list are: IP list (IP), list of IP interval addresses (IR), Rule (RU) type or Rule Master (MR) type. The name of the element list must always be indicated between apexes and must correspond to list already existing when the routing has be configured.
The parameter is shown, it can only be configured if the output port (POO:) type is XTP.
For more detailed information about management of X.25 traffic over TCP/IP refer to the section The X.25 ports, session tunnelling protocol (XTP).
| IPDEST: | IP destination address (Only if POI: is a XTP port type) |
| # | see table, # |
It sets the IP destination address that will be placed in the call routed to the POO: port of XTP type.
The allowed values are summarized in the following table:
| HEX: | 00000000 | 01000000 - 7EFFFFFF | 80000000 - DFFFFFFF |
|---|---|---|---|
| DDN: | 0.0.0.0 | 1.0.0.0 - 126.255.255.255 | 128.0.0.0 - 223.255.255.255 |
IP address of class D and E are not currently supported.
The value 0.0.0.0 is shown with the character "#" and it means "no IP address". It can be used for disabling the routing. Every call is refused with the codes F0,A0 (Customer not Configured. No routing matches the call).
The parameter is shown, it can only be configured if the output port (POO:) type is XTP.
For more detailed information about management of X.25 traffic over TCP/IP refer to the section The X.25 ports, session tunnelling protocol (XTP).
The following examples will try to explain the differences between the above-mentioned functionalities.
To facilitate
the understanding of the examples we use the "extended" display of the routing table, the one obtainable with
D RE command.
PR:0 POI:* POO:0 COMP:NO
NEXT:N CGI:* CDI:00 UDI:CP PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
PR:0 represents the priority of routing verification.
For each incoming call the SVC routings table is checked starting from the routing with priority "0", the highest, until finding a routing that matches the incoming call. If all the table is checked, but no matches are found, the incoming call is rejected with codes of cause and diagnostic F0,A0 (Customer not Configured. No routing matches the call).
POI:, CGI:, CDI: and UDI: represent the values that must, at the same time, be present in the incoming call, so that the routing matches it, that is:
POO:, CGO:, CDO:, UDO: and FFO: represent the outgoing port and data contained in the outgoing call, that is:
COMP: contains information about the compression protocol to be used.
NEXT: this parameter enables the alternative routing searching in the eventuality that the call using the present routing fails.
In the example this functionality is disabled. (NEXT:N).
A call, whatever is its incoming port, is routed to the Control Port (POO:0), only if its user data field contains the sequence of ASCII characters "CP".
The example shows a really important routing: it is possible to access the Control Port from any remote equipment that can place SVC calls towards the Abilis CPX.
If in the SVC routings table there isn't at least one routing to the Control Port "0", it won't be possible to access the mentioned port through a SVC channel.
The same result is obtained if the incoming call matches a routing, whit higher priority and different port destination.
The next example will show that every incoming call matches the routing "0", so that the routing "1" will be never examined.
PR:0 POI:* POO:301 COMP:NO
NEXT:N CGI:* CDI:* UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
PR:1 POI:* POO:0 COMP:NO
NEXT:N CGI:* CDI:00 UDI:CP PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
To restore the access to the Control Port, it will be needed to add locally, by using the off-line configurator, the requested routing.
PR:1 POI:301 POO:302 COMP:MBIT
NEXT:N CGI:56565656 CDI:12345678 UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
In order to match this routing, a call:
Often, calls between two corresponding DTE happen in both directions, that is both can demand the opening of the logical channel.
In this case the appropriated presence of a routing is necessary also for the opposite direction.
The following example shows a routing that could correspond to the one already described.
PR:2 POI:302 POO:301 COMP:MBIT
NEXT:N CGI:12345678 CDI:56565656 UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
In order to match this routing, a call:
This example shows how the Abilis CPX manages the calling data, this is an alternative method to the previous one in order to establish which call must be compressed and the proper protocol.
 |
Routing in the calling Abilis CPX:
PR:3 POI:301 POO:302 COMP:MBIT
NEXT:N CGI:* CDI:87654321 UDI:* PIDI:*
CGO:* CDO:8765432199 UDO:* PIDO:*
FFO:*
Routings in the receiving Abilis CPX:
PR:2 POI:302 POO:301 COMP:MBIT
NEXT:N CGI:* CDI:8765432199 UDI:* PIDI:*
CGO:* CDO:87654321 UDO:* PIDO:*
FFO:*
PR:3 POI:302 POO:301 COMP:NO
NEXT:N CGI:* CDI:* UDI:* PIDI:*
CGO:* CDO:* UDO:* PIDO:*
FFO:*
In such way, the calls, received by the X.25 network, keep their original calling data (what they have before being processed by the Abilis CPX), while it is possible to recognize the "compressed call" through the sub-address "99" added to the called address.
Calls to the 87654321 address without the sub-address "99" are transparently sent by the routing "3" (COMP:NO).
This example shows what the Abilis CPX, in the fields CGI:, CDI:, UDI:, CGO:, CDO:, UDO:, means for:
PR:2 POI:302 POO:301 COMP:NO
NEXT:N CGI:*8 CDI:15* UDI:# PIDI:#
CGO:* CDO:* UDO:* PIDO:*
FFO:*
In order to match this routing, a call:
PR:3 POI:301 POO:302 COMP:NO
NEXT:N CGI:# CDI:???? UDI:* PIDI:*
CGO:* CDO:* UDO:# PIDO:#
FFO:#
In order to match this routing, a call:
[1] The parameter UDI: always refers to user data starting from the 5th byte. The parameter PIDI: always refers to the first four bytes.
[2] The parameter UDO: always refers to user data starting from the 5th byte. The parameter PIDO: always refers to the first four bytes.
Print this page