RE: Multiple SUA SGs, sending for SSP from SGs

Brian,

I tried to look to the issue only from SIGTRAN point of view abot what can
be done with mechanisms described in SUA/M3UA. The SCCP mechanisms you
describe could be helpful but I am not sure how -just brain exercising
here-:

*) The situation of an SG is different than an STP, SG hosts the SCCP layer,
which becomes unavailable, OTOH, STP doesn't. So, I am not sure whether it
would be correct to compare their behavior and expect from SG not to send
SSP, despite corresponding AS is no more ACTIVE.

*) Do we expect SCCP not to send SSP, if there is a replicated subsystem?


    Tolga

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, January 10, 2006 3:22 PM
> To: Ilie Glib
> Cc: SIGTRAN
> Subject: Re: [Sigtran] 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/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>