Subject: Re: [Sigtran] IG-03 Section 3.4 issue

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 7 Mar 2003 08:05:06 +0200

Samuel,

Tolga,

section 1.5.1

says NIF is part of SGP which is an interface between MTP3 and M3UA.
Though it is an example in the RFC, i think still it holds good.
[TOLGA]In fact, I would think even the concept of isolation of SGP from NIF
for most implementations won't make sense, assuming that it will be just a
functionality inside SGP entity. But again, this might be considered
implementation dependent.

If your implementation has single NIF for all M3UA,then your point is
good to send DUNA(*) to all ASPs.
[TOLGA]Even in that case still not DUNA(*), just DUNA for destinations in
traditional SS7 domain -assuming the implementation can route between ASPs
during NIF isolation, whatever NIF isolation means-. I believe it is better
to exclude 3.4 from IG.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Fri, 7 Mar 2003, TOLGA ASVEREN wrote:

>
> Hi All,
>
> One small remark, 3.4 is about NIF isolation of the whole SG -all SGPs- ,
> so if because of my implementation NIF isolation occurs always for all
> SGPs, I wouldn't send ASPIA-ACK but DUNA for the destinations in SS7
domain
> -destinations which are not reachable because of NIF isolation-, because
> again depending on my implementation I can route between two ASPs even
> during NIF ısolation. That all said, I still think all those are
> implementation dependent.
>
>     Tolga
>
>
> Hi all,
>
> I agree with Brian.
> If one or more SGP suffer a partial failure , then the SGP has to send
> ASP Inactive Acks for all the concerned ASPs.So that the concerned
> ASPs will not route any messages to the SS7 destinations via the
partially
> failed SGP(s).
>
> --Samuel
>
>   Alcatel USA, Inc.                  Internet: <userid>
@ssd.usa.alcatel.com
>   1000 Coit Road, Plano, Texas 75075
>   ******* The opinions expressed are not those of Alcatel USA, Inc.
*******
>
> On Thu, 6 Mar 2003, Ken Morneault wrote:
>
> >
> >
> > All:
> >
> > Brian has posted proposed changes to Section 3.4 of the IG
> > in December.  It would be useful to finish discussing his
> > proposed changes so that the IG can be updated and corrected
> > (if needed).
> >
> > Here are the original comments:
> >
> > Section 3.4
> >
> >   This section is against the concensus in the RFC.  The concensus was
> >   that if an SGP suffers a partial failure, it should send ASP Inactive
> >   Ack for the affected AS, and that if it should suffer a complete
> >   failure, it should send ASP Down Ack.
> >
> >   DUNA(*) is completely incorrect, particularly because the ASP is
> >   permitted to interpret DUNA(*) from one SGP to mean DUNA(*) from
> >   all SGPs in an SG.  SNMM are not per-SGP messages and were kept
> >   as indicating routing at SG scope.  Section 3.4 is in conflict with
> >   this.
> >
> >   Pertinent passages in 4.3.4.2 permitting the unsolicited ASP Down
> >   Ack procedure are:
> >
> >     "If the ASP receives an ASP Down Ack without having sent an ASP
Down
> >      message, the ASP should now consider itself as in the ASP-DOWN
> state.
> >      If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state,
> >      the ASP should then initiate procedures to return itself to its
> >      previous state."
> >
> >   Pertinent passages in 4.3.4.4 permitting the unsolicited ASP Inactive
> >   Ack procedure are:
> >
> >     "...                If the ASP receives an ASP Inactive Ack without
> >      having sent an ASP Inactive message, the ASP should now consider
> >      itself as in the ASP-INACTIVE state.  If the ASP was previously in
> >      the ASP-ACTIVE state, the ASP should then initiate procedures to
> >      return itself to its previous state."
> >
> >   Sending DUNA(*) for a partial failure at one SGP will result in
> >   MTP-PAUSE being issued to all MTP Users per section 4.5.2.1:
> >
> >     "At an ASP, upon receiving an SS7 Signalling Network Management
> (SSNM)
> >      message from the remote M3UA Peer, the M3UA layer invokes the
> >      appropriate primitive indications to the resident M3UA-Users.
Local
> >      management is informed."
> >
> >   making the IG Section 3.4. sending of DUNA(*) in an incorrect action.
> >   Partial failure of one SGP will wipe out traffic to all SGPs.
> >
> >   Sending DUNA(*) is also in conflict with section 4.5.2.1 which says:
> >
> >     "In the case where a local event has caused the unavailability or
> >      congestion status of SS7 destinations, the M3UA layer at the ASP
> >      SHOULD pass up appropriate indications in the primitives to the
M3UA
> >      User, as though equivalent SSNM messages were received.  For
> example,
> >      the loss of an SCTP association to an SGP may cause the
> >      unavailability of a set of SS7 destinations.  MTP-PAUSE indication
> >      primitives to the M3UA User are appropriate."
> >
> >   Reword to use ASP Down Ack and ASP Inactive Ack for full or partial
> >   failures of an SGP, as this was always the intended use of
unsolicited
> >   ASP Down Ack and ASP Inactive Ack.  Remove the MUST from both DUNA(*)
> >   and DUNA so as to not conflict with the unsolicited procedures and
the
> >   requirements of Sections 4.5.2.
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 7 Mar 2003 00:34:39 -0600 (CST)

Tolga,

I can mention 2 cases.

case 1) All NIFs are partially failed,this is very very rare case
        But still sending ASP Inact Ack seems not to be an inefficient
	method.Moreover basic aim is ASP should not be sending messages
	to SS7 nodes via partially failed SGPs, this is achieved by
	sending ASP Inact Ack.
 
case 2) Only a particular NIF is partially failed within a SGP.
	Sending ASP Inact ack is an appropriate solution to handle this
	case.

	So why do you say to remove 3.4 IG?

--Samuel

On Fri, 7 Mar 2003, TOLGA ASVEREN wrote:

> > during NIF ýsolation. That all said, I still think all those are