RE: DUNA applies to SG as a whole

Daniel,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Daniel Cohn
> Sent: Friday, January 06, 2006 12:36 PM
> To: [email protected]
> Subject: RE: [Sigtran] DUNA applies to SG as a whole
>
>
> Does this apply to M3UA as well?
[TOLGA]Yes.
>
> The RFC (3332bis) seems to contain contradictory statements in this
> regard.  Consider the following excerpt from 1.3.2.5:
>
>    As shown in Figure 1 an ASP may be connected to multiple SGPs. In
>    such a case a particular SS7 destination may be reachable via more
>    than one SGP and/or SG, i.e., via more than one route. As MTP3 users
>    only maintain status on a destination and not on a route basis, the
>    M3UA layer must maintain the status (availability, restriction,
>    and/or congestion of route to destination) of the individual routes,
>    derive the overall availability or congestion status of the
>    destination from the status of the individual routes, and inform the
>    MTP3 users of this derived status whenever it changes.
>
> and this excerpt from A.2.2:
>
>    From the perspective of the M3UA layer at an ASP, a particular SG is
>    capable of transferring traffic to a provisioned SS7 destination X if
>    an SCTP association with at least one SGP of the SG is established,
>    the SGP has returned an acknowledgement to the ASP to indicate that
>    the ASP is actively handling traffic for that destination X, the SGP
>    has not indicated that the destination X is inaccessible and the SGP
>    has not indicated MTP Restart.  When an ASP is configured to use
>    multiple SGPs for transferring traffic to the SS7 network, the ASP
>    must maintain knowledge of the current capability of the SGPs to
>    handle traffic to destinations of interest.
>
> Also, the statement in 1.4.1 regarding coordination of states across
> SGPs is worded as "SHOULD", which implies that other implementations are
> possible.
>
> To me this suggests that the ASP is responsible for maintaining the
> status of each destination on a per-SGP basis.  Is it not possible for
> an SGP to be partially isolated from the SS7 network, such that some SS7
> destinations are reachable and others are not?  Since the SGP generally
> operates in server mode, it cannot simply terminate its SCTP association
> with the ASPs.  The ASPs will try to re-establish.  So, the only way it
> can inform the ASPs that a particular destination is unreachable is via
> the DUNA message.
[TOLGA]SG is a single entity form MTP3 point of view. Actually this is
pretty much the practical meaning of SG, a group of SGPs with a unique MTP3
view.


>
> The example redundancy model contained in A.1 suggests that SGPs are
> processes within the same host.  However, this is a restrictive
> definition, and I do not believe it is intended to be taken as normative
> text.  In fact, SGPs are individually addressable, which suggests to me
> that they can indeed exist on separate physical hosts.  In this case,
> the isolation of one SGP from the SS7 network should not be taken to
> mean that the whole SG is isolated.  Since there is no "SGP Inactive"
> message, I see no other way to communicate this type of situation to the
> ASP.
[TOLGA]I agree that it makes more sense to have SGPs in different hosts to
provide host redundancy -BTW, I believe this is the case in Figure A-1 as
well, please note that SGP1.1. and SGP1.2 are part of SG1, and they reside
on different hosts-.

What I don't understand is why this causes a problem from current M3UA
procedures point of view. One has a distributed MTP3 implementation spanning
multiple hosts, which acts as a single entity. Each of those hosts are
different SGPs part of the same SG.

For the problem of "SGP being isolated from SS7 network":
a)A multi-SGP SG probably will have an internal messaging mechanism to
provide a unique MTP3-view. So, messages can be forwarded to another SGP of
the same SG, which have active links to SS7 network.
b)Like Ilie has suggested, ASPIA-ACK could be used.
>
> Comments?
>
> Thanks,
> Dan
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Brian F. G. Bidulock
> Sent: Friday, January 06, 2006 10:37 AM
> To: Ilie Glib
> Cc: SIGTRAN
> Subject: Re: [Sigtran] DUNA applies to SG as a whole
>
> Ilie,
>
> Ilie Glib wrote:
> (Fri, 06 Jan 2006 10:39:00)
> > Hello Folks
> >
> > Let's consider an SG with multiple SGPs.
> >
> > RFC 3868 says (1.2.2.  Terminology)
> >
> >    Where an SG contains more than one SGP, the
> >    SG is a logical entity and the contained SGPs are assumed to be
> >    coordinated into a single management view to the SS7 network and to
> >    the supported Application Servers.
> >
> > I interpret this statement so that SGPs of the same SG have identical
> > connectivity to SS7 NW, in particular DUNA, DAVA messages sent from
> > one SGP apply to all SGPs of this SG. Thus if an SGP sends a DUNA to
> > an ASP, the ASP assumes that Affected SPC is unavailable through the
> > SG, and this applies to all SGPs in the SG.
> >
> > section 3.4.1.  of SUA RFC says
> >
> > 3.4.1.  Destination Unavailable (DUNA)
> >
> >    The DUNA message
> >    is sent from the SG or relay node to all concerned ASPs (servicing
> >    SCCP-users considered local to the SG or relay node, see chapter
> >    1.3.1.1), when a destination or SCCP-user has become unreachable.
> The
> >    SUA-User at the ASP is expected to stop traffic to the affected
> >    destination or SCCP-user through the SG or relay node initiating
> the
> >    DUNA.
> >
> > Here SG is mentioned. Thus in case of multiple SGPs DUNA applies to SG
> > as a whole. The same is valid for DUPU, and DAVA.
> >
> > Is this reading of the RFC statements correct?
>
> Yes.
>
> --brian
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>