TO: MIDWEST SCP REQUIREMENTS SUBCOMMITTEE
SUBJECT: COMMENTS ON GTT LOOPING (ANNEX A) FROM NYNEX
FROM: WAYNE HEINMILLER 847-248-5415 wayne.heinmiller@ameritech.com
I received the following comments on our Annex A on GTT looping from
Arthur Doskow of Nynex. It represents "new business" which we can
take up on our call on Tuesday, 7/29. While some of Art's comments
may have been addressed in our discussions, it may not have been
fully captured in our written material.
Art's new schemes should be considered by carriers implementing LNP.
They represent "configurational" approaches to addressing the GTT
looping issue. Ameritech has already implemented similar schemes in
its deployment of LNP.
Content-Type: message/rfc822
Date: Sun, 27 Jul 1997 20:08:42 -0500
From: "WAYNE HEINMILLER " <>
Subject: Nynex GTT Looping Letter
Message-Id: <"11400272707991/2159 IN-DECTSAP"@MHS>
[Editors note: This letter has been reformated from a Word document
to a simple text document by the editor. In order to maintain the
organizational structure which could not be supported in a simple
text document, the editor has added headings and other formating in
converting the document to simple text. No content has been
changed, however.]
July 18, 1997
Mr. Heinmiller,
While NYNEX did not participate in the drafting of the SCP Generic
Requirements for Number Portability, we have had the chance to
review Annex A, which deals with strategies for dealing with the
looping and misrouting of Signaling Messages. We would like to
provide the attached comments in the spirit of enhancing the
document. We are not aware whether the document is subject to
further revision, but the comments that follow can be taken as a
contribution to any such continuing efforts on our part. We have
also reviewed these comments with Bell Atlantic, in light of our
pending merger, and they have expressed their agreement with the
points made. What follows are a set of comments on the proposed
methods, followed by suggestions for two additional methods for
looping prevention.
Comments on Option 1 (10 Digit GTT Node Performs Final GTT)
===========================================================
The second paragraph of the description of method 1, The 10 Digit
GTT Node Always Performs FGTT reads as follows:
"Previously, for other applications, there has been opposition to
non-destination networks performing FGTT because it would limit
architecture flexibility in a destination network (e.g., keeping
number moves from one database to another data base within a network
transparent to other networks). This is not a valid argument for
applications in an LNP environment."
We fail to understand how the implementation of LNP alters the
reasonable position that FGTT should always be performed in the
destination network. When FGTT is used to addresses a single node
(e.g., CLASS services), the location where FGTT is performed is less
of an issue. When replicated or partitioned databases are addressed,
however, it should be clear that FGTT should be performed in the
network which administers the destination database. Several
scenarios follow:
Scenario 1
----------
The example referred to in the text remains valid. Consider a
company which deploys two pairs of SCPs in support of a service and
partitions the data so that one set of records is kept in the first
pair of SCPs while the remainder of the records are kept in the
second pair of SCPs. If data is partitioned in order to equalize
query volumes among the two pairs of SCPs, actual traffic experience
may force the provider to move records from one pair of SCPs to the
other in order to balance the load among the SCP pairs. If FGTT were
being performed outside the destination network, this would require
modification of the Global Title entries by all of the nodes which
perform FGTT. This is a process over which the destination network
would have no control, and would not be in a position to manage.
Scenario 2
----------
A second example is a network which requires either primary / backup
or load sharing as its algorithm for performing FGTTs. In setting
Fraud Monitoring thresholds in an SCP, one must make an assumption
as to whether will be routed to the SCP on a load shared basis, or
on a primary / backup basis. (Thresholds must be set twice as high
for SCPs which receive traffic as a primary SCP as for SCPs which
receive traffic on a load shared basis.) Leaving aside the issue of
whether all Message Relay Points would be capable of performing both
primary / backup and load sharing routing as required, the
destination network would again have to rely on nodes over which it
had no control to consistently implement its preferred method of
load sharing. Further, if primary / backup were used in such a way
that one SCP was primary for certain Global Titles and backup for
others, the destination network would have to rely on external nodes
to use the same set of Global Titles and results as it used
internally.
Scenario 3
----------
A third example is the sharing of load among more than two SCPs.
Requirements now call for STPs to be capable of sharing load across
as many as 4 SCPs, and STP vendors are developing capabilities to
share load across as many as 16 destinations, with a variety of
algorithms covering priority and failure modes. A network which
performed FGTT internally could easily deploy its SCPs to maximize
their effectiveness subject to the capabilities of their deployed
STPs. If FGTT were to be performed in external networks, however,
the multiple databases could not be used effectively unless all
Message Relay Points were capable of emulating the same algorithm as
the destination network's STPs.
For these reasons, we believe the above quoted paragraph is
incorrect and should be removed from the document. Further, under
'Cons', we believe a bullet should be added indicating that this
approach complicates and restricts database management options
available to destination networks.
Comments on Option 4: (Gateway Screening)
=========================================
With respect to option 4 (Gateway Screening), it should be pointed
out that some networks, notably incumbent networks may be required
to perform 10 digit GTT on behalf of interconnected networks. Such
services may well result in a query being returned to the network
where it originated. As such, any scheme which compares the Network
ID of an incoming query to the network ID of the outgoing query
cannot be used by a network which performs 10 digit GTT on behalf of
other networks. Option 2 (TT Mapping) offers a partial solution to
this problem in that it restricts mapping on a linkset basis.
However, if the same linkset is used for incoming queries from
carriers with their own 10 digit GTT capability and carriers who
have contracted the destination network for these services (as might
be the case from a hub provider), TT mapping will not be effective.
These facts should be added to the list of 'Cons' for Options 2 and
4.
* It should be further noted that Options 2 and 4 rely on
traditional STP functions residing at the node which performs 10
digit GTT. These options therefore require that either 1) 10 digit
GTT be performed at an STP, or 2) the functions be extended in some
way so that they can be performed at an LNP SCP. It is uncertain if
there is any analog of TT Mapping which could be performed at an
SCP.
* Several of the proposed schemes (e.g., #12, TT Mapping at the 10
digit GTT Node) attempt to make use of 6 digit Translation Tables.
It is important to point out traditional 6 digit tables are not
sufficient to handle 'ported in' numbers or numbers which were
ported out and then ported back in, but to a different switch. In
such cases, the NPA-NXX in the Global Title give no clue to the
identity of the appropriate switch. One remedy for this is Global
Title Replacement, in which the Global Title in the message is
replaced by the LRN of the appropriate destination at the time when
10 digit GTT is performed. The 6 digit table would then have to be
populated with LRNs rather than NPA-NXXs (to the extent that they
are different). We know of no other means by which queries can be
delivered to the proper destination using 6 digit GT Tables and
believe this is the rationale underlying option 13 (TT Mapping with
GTAI Replacement at the 10 Digit GTT Node). To the extent that any
scheme uses existing 6 digit tables, the description should either
add GT Replacement, or (if GT Replacement is not performed), or it
should include the inability to support either ported in numbers or
numbers porting back to a different switch on its the list of
'cons'.
Comments on Option 5 (Transaction Comparison)
=============================================
Option 5 suggests creating and maintaining a list of Transaction IDs
of incoming queries so that a query which has been previously routed
will be dropped if it returns to the same Translation Point. While
this solution will discard looping queries, it should be recognized
that they may complete several loops before being discarded. This
can occur when networks use replicated nodes to perform 10 digit
GTT. In such an environment, the looping query will not be discarded
until it visits the same physical replicate for the second time.
Comments on Option 6 (MTP Loop Detection and Removal)
=====================================================
Option 6, MTP Loop Detection and Removal Procedures seem unsuited
for dealing with the temporary looping conditions which result from
non-simultaneous updating of LNP databases. First, they test for MTP
circular routes whereas the looping in question arises from Global
Title Translation, an SCCP function. An STP generating the loop test
message specified by this procedure (a Route Congestion Test Message
with priority 3) will never have the message routed back to itself,
because the loop occurs only when Global Title Translation is
performed. In addition, the actions which are taken on detection of
a loop are not appropriate to the problem at hand. Individual loops
will arise and be resolved in a relatively short period of time. The
remedies of the MTP Loop Detection and Removal procedures are to
notify maintenance and possibly to remove routes from service. What
is required is an algorithm to remove looping messages from the
signaling stream.
Comments on Option 10 (Internetwork OMAP)
=========================================
For some of the same reasons, Option 10, Internetwork OMAP does not
provide relief. MRVT messages are MTP routed and so will not
encounter loops; SRVT messages are intended to detect long term
loops, due to misprovisioning of Global Titles. By the time SRVT
procedures detect a loop, it is likely to have resolved itself.
Further, SRVT procedures, by themselves, do nothing to prevent
individual messages from looping or the associated consequences.
Comments on Option 12 (TT Mapping) and Option 13 (TT Mapping and
GTAI Replacement)
============================================================
Options 12 and 13 (TT Mapping with and without GTAI Replacement)
appear to be options which reliably prevent looping. As previously
discussed, Option 12, as presented, will not work for 'ported in'
numbers or numbers ported back to a different switch because it
relies on 6 digit GTT tables without Global Title Address
Information Replacement (hence Option 13). Both options have the
disadvantages that they consume additional Translation Type
resources as well as GT entry capacity (the number of GT entries
that an STP can accommodate). They also require a coordination with
interconnected networks which will both be required to perform TT
mapping (and GTAI Replacement) as well as deploy Translation Type
tables for the mapped Translation Types.
New Options Proposed
====================
We would like to propose two additional methods for consideration as
means of preventing SCCP looping. Each functions to drop queries
which are being routed based on 10 digit Global Titles which have
not been consistently provisioned in interconnected networks.
Proposed New Option 14 (Multiple Capability Codes)
==================================================
The first method contemplates the use of an STP pair for 10 digit
GTT. It can be adapted to an SCP, but requires the implementation of
Capability Point Codes for the 10 digit GTT function as well as a
limited implementation of Gateway Screening capability. It will be
described here in its STP implementation. This method was developed
jointly by NYNEX and Tekelec and can be implemented using the
Tekelec Eagle platform in conjunction with its LNP application.
To implement this solution, two Capability Point Codes are defined
for the LNP functions at an STP pair. One can be referred to as the
"Pre Query" Capability Point Code and is intended to provide 10
digit Global Title Translation for queries which have not yet
undergone 10 digit GTT. The other can be referred to as the "Post
Query" Capability Point Code and is intended to provide final
routing for queries which have already undergone 10 digit GTT and
have been routed to the destination network on that basis. Queries
from the implementing network requiring 10 digit Global Title
Translation, as well as queries from other networks which purchase
this capability from the implementing network, are addressed to the
Pre Query Capability Point Code. Queries from networks which
implement their own 10 digit Global Title Translation function, or
which purchase it from a third party provider, are addressed to the
Post Query Capability Point Code. For other networks performing 10
digit GTT, the Post Query Capability Point Code should be
provisioned in two places. First, the Post Query Capability Code
should be provisioned as the "default" destination point code for
queries concerning non-ported numbers in NPA-NXXs within the
implementer's network. Second, in records for numbers porting into
the implementing network, the Post Query Capability Point Code
should be provisioned (via the appropriate NPAC) as the destination
point code to which queries for the four LNP-impacted services
should be routed.
Looping is prevented by means of Gateway Screening which is
implemented at the STP. This screening is defined to discard any
incoming queries addressed to the Post Query Capability Point Code
which, after 10 digit GTT, are to be routed to any external network.
The rationale for this discard is that queries addressed to the Post
Query Capability Point Code have already been subject to 10 digit
GTT which has determined that they should be delivered to the
implementing network. If the implementing network thinks they belong
elsewhere, it is indicative of a loop. That queries addressed to the
Pre Query Capability Point Code are not screened enables the
implementing network to offer 10 digit Global Title Translation
capability to external networks without compromising its looping
prevention algorithm.
This method has the advantages that it can be implemented
unilaterally by a network to prevent looping. (Interconnected
networks must adhere to the point code assignments of the
implementing network, but this does not differ from the present
method of operations.) In addition, it requires no changes to the
SS7 protocol.
One item should be noted concerning the use of "LNP Capability Point
Codes". These point codes are designated for LNP use only and are
implemented in such a way that if the LNP capability at the node
goes out of service, network management messages will be issued
which will direct incoming queries to the mate application.
Proposed New Option 15 (Separate Pre & Post 10 Digit STPs)
==========================================================
The second proposed option makes use two pairs of STPs, one to
handle queries which have not undergone 10 digit GTT, and the other
to handle queries which have. (These are analogous to the Per Query
Capability Point Code and the Post Query Capability Point Code of
the previous option, except that here, they are implemented using
separate pairs of STPs.) The first pair would determine the
destination network for the query (for the implementer's nodes and
networks purchasing 10 digit GTT capability) The second pair would
route only to nodes in the implementer's network.
The second (Post Query) STP pair could operate in several ways. As
in the previous option, it could perform 10 digit GTT and discard
(via Gateway Screening) any query which, after 10 digit GTT, was
destined for an external network. Alternatively, it could use a 6
digit table of LRNs and require all accessing networks to replace
the Global Title with the LRN of the recipient switch.
Depending on the routing methodology used by the Post Query STP
pair, this option may be implemented either unilaterally by a
network (by deploying 10 digit GTT and Gateway Screening), or with
the cooperation of interconnected networks (using 6 digit LRN Global
Title Tables and requiring Global Title replacement by all querying
nodes).
Conclusion
==========
We are pleased to offer these comments and proposals for industry
consideration and would welcome any feedback on the material herein.
Nothing herein should be construed as a commitment on the part of
NYNEX to deploy, or refuse deployment of any capability described.
Thank you.
Arthur Doskow
Member of Technical Staff, Signaling System Engineering
NYNEX Science and Technology
140 West Street, Room 600
New York, New York 10007
(212) 577-5418