Re: DUNA applies to SG as a whole

Dan,

Draft draft-ietf-sigtran-rfc3332bis-05.txt has the following statement

3.4.1 Destination Unavailable (DUNA)

   The DUNA message is sent from an SGP in an SG to all concerned ASPs
   to indicate that the SG has determined that one or more SS7
   destinations are unreachable.  It is also sent by an SGP in response
   to a message from the ASP to an unreachable SS7 destination. As an
   implementation option the SG may suppress the sending of subsequent
   "response" DUNA messages regarding a certain unreachable SS7
   destination for a certain period to give the remote side time to
   react. If there is no alternate route via another SG, the MTP3-User
   at the ASP is expected to stop traffic to the affected destination
   via the SG as per the defined MTP3-User procedures.

Thus I believe that in M3UA every SGP upon receiving a message towards
an unreachable destination sooner or later will answer with a DUNA to
the ASP. But of couse some traffic can be lost, which can be saved if
there is another SG with connectivity to the affected SPC.

Apropo, SUA RFC does not have a statement like "DUNA is also sent by
an SGP in response to a message from the ASP to an unreachable SS7
destination"
So I could imagine an implementation that sends DUNAs from one SGP only.


Regards

Ilie

On 1/6/06, Tolga Asveren <[email protected]> wrote:
> 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
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>


--
Ilie