Subject: [Sigtran] NIF not available

From: "Nahar,virendra" <[email-masked]>
Date: Thu, 07 Mar 2002 14:38:07 +0530

Hi All
Assume the condition that SG side is up & running but due to some
implementation dependent options/conditions NIF becomes unavailable
(its equivalent that MTP3 is not available)
How this should be informed to ASP's
1 Is sending status indication user part unavailable is OK.
2 Send a DUNA which will indicate the entire region/network is down....
3 Have an error code for NIF unavailable

        Pls send in ur comments/implementation options

Thanks
Nahar

--
Virendra Nahar
HCL-Technologies Ltd
Networking Systems Lab
51, Jawaharlal Nehru Road
Guindy Industrial Estate,
Ekkatuthangal,
Chennai - 600 097.
Phone Off : +91 44 233 4174 or +91 44 233 4181(extn:261,218)
mailto:[email-masked]
############################################################
"He who has a why for life can put with any how."
                             Frederick Nietzsche
############################################################

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 7 Mar 2002 08:48:13 -0500

I think none of them. In my opinion it should send ASPIA-ACK for all of the
active ASs.

  Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Nahar,virendra
> Sent: Thursday, March 07, 2002 4:08 AM
> To: Sigtran
> Subject: [Sigtran] NIF not available
>
>
>
> Hi All

---

From: "Nitin Vairagare" <[email-masked]>
Date: Thu, 7 Mar 2002 09:41:45 -0500

Its equivalent to MTP3 Restart Procedure...

I would say restart of SGP is preferable.. you have any way lost most of 
route and state information. 

-----Original Message-----

Hi All

Thanks
Nahar

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 7 Mar 2002 10:24:14 -0500

Is it really equivalent to MTP3 Restart Procedure? In the described case,
nothing happens to MTP3 on SG. Just NIF is out of service. MTP3 is per SG
but NIF is per SGP. If you send DUNA because of NIF unavailability on a SGP,
this won't be correct. I think the scenario is a nice case, where ASPIA-ACK
can be used.

    Tolga

> Nitin Vairagare
> Sent: Thursday, March 07, 2002 9:42 AM
> To: Nahar,virendra; Sigtran
> Subject: RE: [Sigtran] NIF not available
>
>

---

From: "Nitin Vairagare" <[email-masked]>
Date: Thu, 7 Mar 2002 11:00:06 -0500

Tolga,

That is why I said restart of SGP not SG. Once you lost routing
information, can you send anything to IP side.. (that is implementation
dependent though).

Ideally what should happen here is, inform IP side inability to
route to any remote users (again are you going to have list of
remote SS7 destination with loss of NIF?), let SS7 side know
unavailability of IP nodes (TFP for public point codes and UPU.
Can you do that without NIF?).

Basically if you loose everything in MTP3, what you do? Similarly
it is difficult for SGP to restore state and route information
with out restart of SGP.

Regards,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tolga Asveren
Sent: Thursday, March 07, 2002 10:24 AM
To: Sigtran
Subject: RE: [Sigtran] NIF not available

    Tolga

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 7 Mar 2002 11:19:54 -0500

Nitin,

Your message was saying it is equivalent to MTP3 restart procedure. My point
is , that it isn't equivalent. So, in my opinion the situation should be
handled with ASPTM not with SSNM. ASPIA-ACK is introduced for situations
similar to what is described in the question. Alternatively, one can drop
the SCTP association, but ASPIA-ACK is IMHO more elegant.

Please see also further comments below.

   Tolga

> From: Nitin Vairagare [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 11:00 AM
> To: Tolga Asveren; Sigtran
> Can you do that without NIF?)
[TOLGA] So, you inform ASP with ASPIA-ACK.
> it is difficult for SGP to restore state and route information
[TOLGA] SGPs in a SG are a single entity from MTP3 point of view. So, that
one SGP goes down does not necessarly mean that your route information is
lost. In fact it shouldn't if other SGPs are still up, how one achieves
this, is implementation dependent.

---

From: Ken Morneault <[email-masked]>
Date: Thu, 07 Mar 2002 11:39:34 -0500

Nitin,

I also agree that ASP Inactive Ack would be the more elegant
solution.  The ASP would then periodically send ASP Active
to the SGP.

Ken

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Mar 2002 10:55:29 -0600

Ken,

While I agree that ASPIA Ack is useful, all three approaches
are possible, but in different cases:

o   If the entire SG (all the SGP) are isolated from the NIF,
    then all the users are isolated from the SS7 network and
    DUNA(*) is appropriate.

o   If only one SGP in the SG is isolated from the NIF, but
    is isolated enitirely from the NIF, then abortint the
    association is probably most appropriate.

o   If one or more SGP suffer partial failure (where aborting
    the association would cause active AS to fail), then the
    ASPIA Ack procedure is more appropriate.

--brian

Ken Morneault wrote:                                          (Thu, 07 Mar 2002 11:39:34)

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

---

From: Ken Morneault <[email-masked]>
Date: Thu, 07 Mar 2002 12:05:51 -0500

Pls see below.

Ken

>    then all the users are isolated from the SS7 network and

Yes, for the case of entire SG, sending DUNA would be
more appropriate.

>    association is probably most appropriate.

Aborting the association would potentially add to the
"confusion" from the point of view of the system operator.
Inactive Ack is a nice way to take the SGP "out of" the
SG while it gets its act together.

>    ASPIA Ack procedure is more appropriate.

I'm unclear about what you mean by this case.

---

From: "Nitin Vairagare" <[email-masked]>
Date: Thu, 7 Mar 2002 12:10:22 -0500

Ken,

I am not disagreeing to Tolga's solution. It is part of
solution. I agree that ASPIN ACK is the correct messgae to
send ASP's in event of loss of Routing data.

However, the problem is bigger You also need mechanism
to to start SS7 procedures for loss of routes to IP side.
Till now your NIF was interfacing with MTP3, now NIF is
lost. You risk loss of data, for which SS7 world is not
tolerable.

May be we need to define clear procedures for failuers like
this. I am saying restart procedure of SGP (not SCTP assoc)
as probable way, part of which can be sending ASPIN ACK.
Which also need a procedure defined for ASP when it receives
ASPIN ACK out of the Blue. And appropriate actions on SS7 side.

I think we are on same page, but the problem needs to be
seen in bigger view.

Regards,
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ken Morneault
Sent: Thursday, March 07, 2002 11:40 AM
To: Tolga Asveren; Sigtran
Subject: RE: [Sigtran] NIF not available

Nitin,

Ken

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Mar 2002 11:38:22 -0600

Ken,

Ken Morneault wrote:                                          (Thu, 07 Mar 2002 12:05:51)
> SG while it gets its act together.

If you prefer, you could send an unsolicited ASPDN Ack which
would be faster than sending individual unsolicited ASPIA Acks.
However, ASPDN Ack is not necessarily expedited around data in
queue, so ABORT would avoid message loss to a greater degree
under higher traffic loads.

> I'm unclear about what you mean by this case.

This is the case where an SGP can continue to service one or
more active AS, but due to a partial failure is unable to service
one or more of the active AS.  This is the case for which
unsolicited ASPIA Ack was intended.  Partial failure.  The
SGP sends unsolicited ASPIA Ack for only those AS which it is
unable to service and remains active for the rest.  When the
SGP receives a subsequent ASPAC Req for the AS that in can no
longer serve, it sends ERR("Refused Management Blocking") until
the failure clears.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Mar 2002 11:45:09 -0600

Nitin,

All MTP restart procedures are a function of the SS7
stack and do not involve the NIF.  The NIF need only be
responsible for getting MTP-User primitives to the UA
layer at the SG.

The functions of the NIF are outside the scope of the
protocol.

Also, see below.

--brian

Nitin Vairagare wrote:                                      (Thu, 07 Mar 2002 12:10:22)
> to to start SS7 procedures for loss of routes to IP side.

There are no "routes" to the IP side.

> lost. You risk loss of data, for which SS7 world is not

This is no different than having one or more MTP-Users
disappear.  No restart is taken with regard to the SS7
network.  The SG should simply returns UPU for these
user parts.  The SS7 MTP has not been isolated from the
SS7 network and no restart procedures are applicable.

> ASPIN ACK out of the Blue. And appropriate actions on SS7 side.

There is already a defined procedure for what the ASP does
when it receives ASPIA Ack.

> I think we are on same page, but the problem needs to be

I think you may be confusing MTP-Users with the MTP itself.
MTP-Users can come and go without causing MTP restart.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 7 Mar 2002 13:01:36 -0500

Nitin,

Please see comments below.

  Tolga

> Sent: Thursday, March 07, 2002 12:10 PM
> To: Ken Morneault; Tolga Asveren; Sigtran
[TOLGA] m3uav12 defines what an ASP should do, when an out of blue ASPIA-ACK
is received:
4.3.4.3.1
......
"If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive
message, the ASPshould now consider itself as in the ASP-INACTIVE state."
So, afterwards, what to do will depend on ASP (sending ASPAC periodically or
waiting for NTFY(AS Inactive) ).Also, once ASPAC/ASPAC-ACK exchange is
finished, it is again up to ASP what to do ( sending DAUD or not).
What else should be described from ASP point of view?
Actions on SS7 side are implementation dependent and not in the scope of
m3ua draft.

---

From: "Subhodeep Sarkar" <[email-masked]>
Date: Fri, 8 Mar 2002 16:39:02 +0530

PLEASE IGNORE THE DISCLAIMER TEXT FOR THE
MAILING LIST
	
*************************************************************
Hi ,

How will you come to know that the NIF is missing ? Since NIF just acts
as rely layer between
the UA layer and the TDM layer. There is no message or management
primitive that can be used
to indicate that NIF is missing .

Cheers,
Subhodeep

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tolga Asveren
Sent: Thursday, March 07, 2002 11:32 PM
To: Sigtran
Subject: RE: [Sigtran] NIF not available

Nitin,

  Tolga

> ASPIN ACK out of the Blue. And appropriate actions on SS7 side.
[TOLGA] m3uav12 defines what an ASP should do, when an out of blue
ASPIA-ACK
is received:
4.3.4.3.1
......
"If the ASP receives an ASP Inactive Ack without having sent an ASP
Inactive
message, the ASPshould now consider itself as in the ASP-INACTIVE
state."
So, afterwards, what to do will depend on ASP (sending ASPAC
periodically or
waiting for NTFY(AS Inactive) ).Also, once ASPAC/ASPAC-ACK exchange is
finished, it is again up to ASP what to do ( sending DAUD or not).
What else should be described from ASP point of view?
Actions on SS7 side are implementation dependent and not in the scope of
m3ua draft.
> >Your message was saying it is equivalent to MTP3 restart procedure.
My
> point
> >> > From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of
> >> > I would say restart of SGP is preferable.. you have any way lost
most
> of
> >> > From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of

---

From: "Nahar,virendra" <[email-masked]>
Date: Fri, 08 Mar 2002 23:46:29 +0530

Its always implementation dependent nothing related to draft

Thanks

Subhodeep Sarkar wrote:

> > Behalf Of
>   ------------------------------------------------------------------------
>                                Name: InterScan_Disclaimer.txt
>    InterScan_Disclaimer.txt    Type: Plain Text (text/plain)
>                            Encoding: 7bit