Re: Multiple SUA SGs, sending for SSP from SGs

Ilie,

I think Tolga's remarks are more applicable to M3UA than SUA.  MTP does
not provide messaging for user management.  This is partly the
responsibiliy of the MTP User itself.  So, for example, when ISUP
receives MTP-STATUS indicating user part unavailabilty (corresponding to
UPU), ISUP can send UPT to test for return to service of the user part,
but UPT is an ISUP message, not an MTP message.

With RK granularity of a Network Appearance, the ASP needs to send DUNA,
DAVA, DRST, SCON (corresponding to TFP, TFA, TFR, TFC) and the SG needs
to work those messages and AS availability into a management view of the
network appearance, point code and user part.

With RK granularity of a point code, multiple SGs as STP can treat the
AS as though it were any (A-link) attached SEP.  That is, when the AS is
inactive at the SG, it can send TFP for the AS point code, but this does
not stop traffic from being routed via the alternate SG (associated STP
in the STP pair).

When RK granularity is that of an SI value, it is still possible for an
SG as STP supporting the ANSI "Alias" point code concept (see ATIS
T1.111/2000) to suppress issuing UPU and, instead, route traffic to the
associated STP in the STP pair.

SUA, OTOH, supports management of SCCP Users.  In the case of SUA, for
RK at Network Appearance granularity, the ASP needs to send DUNA, DAVA,
DRST, SCON (corresponding to TFP, TFA, TFR, TFC, and SSP, SSA, SOR/SOG,
SSC) and the SG needs to work those messages and AS availability into a
management view of the network appearance, point code and subsystem.

When RK granulariy is that of a point code, the ASP needs to send DUNA,
DAVA, DRST, SCON (corresponding to SSP, SSA, SOR/SOG, SSC) for affected
subsystems and the SG needs to work those messages and AS availability
into a management view of the point code and subsystems.

When RK granularity is that of a subsystem, the ASP uses AS activation
only for subsystem management and the SG needs to work AS availability
into a management view of the subsystem.

For RK granulariy beneath a subsystem (e.g, global title or global title
range), the ASP uses AS activation only for management and the SG needs
to use AS avialability to coordinate a management view of the state of
the subsystem.

As regards when an SG as STP sends SSP or SSA, this is peformed in
accordance with SS7 standards (for both local and remote broadcast and
responsive methods), given the management view of the subsystem at the
STP as formulated above.  Contrary to Tolga's statements, for SUA, and
in general, an SG (as STP and SCCP relay), will not send SSP when the
subsystem is available via the associated STP.  Furthermore, if the
subsystem is replicated, unavailability of one entity in an entity set
does not cause the subsystem to be prohibited if the another entity in
the entity set is available.

But, for both M3UA and SUA, this is largely a matter of MTP transfer and
SCCP relay management and provisioning at the STPs and is outside of the
scope of M3UA and SUA.

When formulating the specifications, we took some care to ensure that
sufficient messaging existed within the M3UA and SUA protocols to
support the multiple SG as STP scenarios.

For M3UA, the message is largely complete (there are cases where it
would be good to send DUPU from the ASP, and load sharing is quite
broken, requiring an approach similar to that described in
draft-bidulock-sigtran-loadsel to fix it).

For SUA, OTOH, the multiple SG as STP scenario is largely broken for
connection-oriented protocol classes (the STP is unnaturally and
untransparently forced to couple connection sections) and DRN/TID
labelling is inadequate for the scenario.  I proposed some years ago
a registration mechanism that would fully support the multiple SG as
STP scenario and it was included in the SUA drafts, but later removed
in favor of the broken DRN/TID labeling mechanism.  You will find many
references to this defect on the mail archives.

--brian


Ilie Glib wrote:                                                      (Tue, 10 Jan 2006 19:29:32)
> Hello Folks,
> 
> Let's consider two SUA SGs which provide connectivity to an SSN in IP network.
> SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the
> AS serving the SSN goes inactive in the SG and I also assume in case
> the SG loses connectivity to the AS.
> 
> 5.1.2.3.  Unsuccessful ASP Fail-over scenario
> 
>      ASP-a1            ASP-a2                SG                  SEP
>    (Primary)           (Backup)
>        +-------------ASP Inactive------------->
>        <-----------ASP Inactive ACK-----------+
>        <--------------------NTFY (AS Pending)-+
>                          <--NTFY (AS Pending)-+
>              After some time elapses (i.e., timeout).
>                                               +--------SSP-------->
>                                               <--------SST--------+
>        <-------------------NTFY (AS Inactive)-+
>                          <-NTFY (AS Inactive)-+
> 
> 
> 
> What shall be done in multiple SGs scenario when the SSN is allowed
> via another SG?
> 
> Is this a realistic example?
> 
> Thank you in advance
> 
> --
> Ilie
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/