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

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 7 Mar 2003 10:58:28 +0200

Samuel,

                    "Samuel Dur D.                                                                              
                    Jeyaseelan"                To:     [email-masked]                                         
                    <[email-masked]       cc:                                                              
                    catel.com>                 Subject:     Re: [Sigtran] IG-03 Section 3.4 issue               
                    Sent by:                                                                                    
                    [email-masked]                                                                        
                    rg                                                                                          

                    07.03.2003 08:34                                                                            

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.
[TOLGA]SGP can still route between ASPs. With ASPIA-ACK you are preventing
this, if NIF failure is global.

case 2) Only a particular NIF is partially failed within a SGP.
           Sending ASP Inact ack is an appropriate solution to handle this
           case.
[TOLGA]Is it a MUST? If I drop the association to ASP will this be "wrong"?

           So why do you say to remove 3.4 IG?
[TOLGA]Mainly because IMO what to do in such a case is implementation
dependent. BTW, I disagree with the statement "SGP isolation from NIF". SGP
is the whole entity, maybe we better think of SGP-M3UA isolation from NIF.
I don't believe it is business of RFC to describe how and where one
implements NIF and what to do during implementation dependent failure
scenarios.

--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:

>
> 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
>

_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 02:23:57 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 07 Mar 2003 10:58:28)
>                     catel.com>                 Subject:     Re: [Sigtran] IG-03 Section 3.4 issue               

What makes you think that messages can be routed betwen ASPs (I think you
mean between AS) when the NIF fails?  The NIF is access to MTP3 at the
SGP: MTP3 is responsible for routing between MTP-Users regardless of which
domain they are in.  Failure of the NIF implies failure to route between
AS as well.  Therefore, APSIA Ack is appropriate and DUNA is not.

> [TOLGA]Is it a MUST? If I drop the association to ASP will this be "wrong"?

If the partial failure only affects some AS, yes, that would be wrong.
You would be failing AS that might otherwise have no connection to the SS7
network.  What is meant in the RFC by partial failure is an abrogation of the
guarantee that the SGP has the same connectivity to the SS7 network as other
SGPs, but that the SGP is still able to meet that guarantee for some traffic
(AS).  Otherwise, it is surely complete failure.

> implements NIF and what to do during implementation dependent failure

I agree that references to NIF could be removed, however, what an SGP does
in event of partial failure and complete failure, where failure is the
failure to be able to transfer traffic for one or more AS is important to
interoperability.  DUNA is clearly inappropriate.  ASPIA Ack and ASPDN Ack
are appropriate.  IMO dropping an SCTP association for events that can be
handled within the M3UA protocol is the wrong thing to do and should be
recommended against.

--brian

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

---

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

Tolga,

> this, if NIF failure is global.
What does it mean 'SGP can still route between ASPs' ?

> [TOLGA]Is it a MUST? If I drop the association to ASP will this be "wrong"?
We can drop the association but when NIF becomes available, once again
ESTABLISH_SCTP,ASP_UP,REG,ASP_ACTIVE... these messages will be transmitted
between SGP and ASP. So i would suggest to send ASP Inact.
> > > during NIF ýsolation. That all said, I still think all those are