Subject: RE: [Sigtran] M3UA - ASP database equalization

From: "Zannin, Francois" <[email-masked]>
Date: Thu, 6 Feb 2003 09:27:21 +0100

Bidulock,,,

I think your example of 200,000 ASP "UP" as backup for an AS is really
realistic for a network!

The goal is to agree on procedure that can be used for the
implementation of M3UA. There were a lot of threads discussing on this
subject and not always concluded. The role of the IG is to clarify the
RFC in order to make it usable.

This procedure similar to the ss7 network (TFP inform all the SP of the
inaccessibility). If a SG is unable to reach all the ss7 SP (200000 PC,
means 200000 ungrouped SSNM) it can use the DOWN_ACK or INACTIVE_ACK
procedure for its own isolation.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, February 06, 2003 9:15 AM
To: Zannin, Francois
Cc: Samuel Dur D. Jeyaseelan; Nagar, Ashish; [email-masked]
Subject: Re: [Sigtran] M3UA - ASP database equalization

Zannin,,

That is contrary to the conensus of the RFC.

Consider 1 ASP active, 200,000 ASPs inactive.

The RFC cannot require an SG to send SSNM to an inactive ASP.

--brian

Zannin, Francois wrote:
(Thu, 06 Feb 2003 09:02:41)
> Samuel,
> 
> IMO, it's a good idea to inform inactive (BUT UP) ASP of the state of 
> the ss7 network especially in the override mode where an ASP can be 
> ready to recover an AS as soon as it receive an AS-Pending 
> notification from the SGp. In this condition, the ASP is ready to 
> operate quickly and minimize the risk of buffered message lost during 
> the pending timer.
> 
> If someone does not want to receive SSNM because it is not able to 
> recover an AS, it just stays in an ASP-Down state.
> 
> Because SSNM reflects ss7 Point Code state that is not "SI" dependant,

> it affects all AS for a network and then, unless SG that plays 
> multiple networks, the ASP UP is sufficient to filter the undesired 
> SSNM.
> 
> Francois.
> 
> -----Original Message-----
> From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> Sent: Thursday, February 06, 2003 8:35 AM
> To: Nagar, Ashish
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA - ASP database equalization
> 
> 
> 
> Ashish,
> 
> But when inactive ASP changes state to active, first of all it does 
> not know whether to send DAUD or not.
> 
> It will try to send traffic - but actually destination is unavailable.
> 
> The worst case is when SG triggers restart procedures this case all 
> the SS7 destinations are unavailable via restarted-SG.But this poor 
> ASP (newly come-up ASP) keeps sending traffic via restarted-SG to 
> reach the SS7 destination and for every message ASP receives DUNA.
> 
> Are we not doing double-work here?
> 
> --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 Wed, 5 Feb 2003, Nagar, Ashish wrote:
> 
> > Hi Samuel
> > 
> > My point is why to do any processing if ASP is in Inactive state.
> > Think about ASP is in Inactive state for longer period and receiving

> > lots of DUNA and DAVA, while what matter is the present only when
ASP 
> > state changes to ASP-ACTIVE.
> > 
> > Thanks & Regards
> > Ashish Nagar
> > 
> > 
> > -----Original Message-----
> > From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> > Sent: Thursday, February 06, 2003 12:30 PM
> > To: Nagar, Ashish
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] M3UA - ASP database equalization
> > 
> > 
> > Ashish,
> > 
> > My point is if SG is able to send DUNA to all inact and active ASPs,
> > we should not restrict it.
> > 
> > Sending DAUD is an alternative way ,If SG has direct way of sending
> > DUNA then Why do you need alternative way?
> > 
> > --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 Wed, 5 Feb 2003, Nagar, Ashish wrote:
> > 
> > > You can generate DAUD procedure at any time, so whenever ASP 
> > > changes
> 
> > > state from Inactive to Active Just generate DAUD.
> > > 
> > > Thanks & Regards
> > > Ashish Nagar
> > > 
> > > 
> > > -----Original Message-----
> > > From: Samuel Dur D. Jeyaseelan 
> > > [mailto:[email-masked]]
> > > Sent: Thursday, February 06, 2003 11:27 AM
> > > To: [email-masked]
> > > Subject: [Sigtran] M3UA - ASP database equalization
> > > 
> > > 
> > > Hi all,
> > > 
> > > Currently RFC 3332 says that SG sends SSNM messages to all
> > > 'concerned ASPs'(means only ACTIVE ASPs).
> > > 
> > > +----+           +---+           +-----+
> > > |SEP | ----------|SG |-----------| ASP1|
> > > +----+           +---+           +-----+
> > >                    |             
> > >                    |             +-----+
> > >                    +-------------| ASP2|
> > >                                  +-----+
> > > 
> > > (ASP1 is active and ASP2 is incative - override mode)
> > > 
> > > When SEP is getting restarted ,SG sends DUNA to ASP1.
> > > But SEP status is not changed in ASP2.There are two ways to solve
> > > this problem
> > > 
> > > 1. ASP1 can equalize its database with ASP2
> > > or
> > > 2.SG itself can send DUNA... to ASP2 (eventhough ASP2 is inactive)
> > > 
> > > IMO, SG can send SSNM messages to ASP (either ASP is in active or
> > > inact
> > > state)
> > > 
> > > Any comments?
> > > 
> > > -----
> > > 
> > > section 5.4.2.1
> > > 
> > > ...
> > >       - Pass the MTP-TRANSFER request primitive to the MTP3 of the
> > >         concerned Network Appearance.
> > > 
> > > It conveys the meaning that M3UA layer (at SGP) MTP-TRANSFER 
> > > request
> 
> > > is sent to MTP3.
> > > 
> > > But there is no primitive availabe between M3UA and MTP3.
> > > 
> > > I think it should be corrected.
> > > 
> > > ----
> > > Presently ASP is unaware of SG's MTP3 restart,
> > > ASP receives only DUNA for all SS7 point codes which can be 
> > > reachable via that SG.But in case of peer to peer protocol SG and 
> > > AS point codes are different, So why dont we send DUNA with SG's 
> > > point code to ASP? So that just by getting single DUNA(with SG's 
> > > PC) ASP will not route any message via that
> SG.
> > > This can avoid sending multiple DUNAs to ASP.
> > > 
> > > 
> > > Any comments?
> > > 
> > > -----
> > > section 1.4.1
> > > 
> > > ...
> > >    Where a particular AS can be reached via more than one SGP, the
> > >    corresponding Routing Keys in the SGPs should be identical.
> (Note:
> > >    It is possible for the SGP Routing Key configuration data to be
> > >    temporarily out-of-sync during configuration updates).
> > >  
> > >                               +--------+
> > >                               |        |
> > >                  +------------+  SG 1  +--------------+
> > >      +-------+   |  SS7 links | "STP"  |  IP network  |     ----
> > >      |  SEP  +---+            +--------+              +---/      \
> > >      |   or  |                    |*                      | ASPs
|
> > >      |  STP  +---+            +--------+              +---\      /
> > >      +-------+   |            |        |              |     ----
> > >                  +------------+  SG 2  +--------------+
> > >                               | "STP"  |
> > >                               +--------+
> > >  
> > >                     Figure 1  Example with mated SGs
> > > 
> > > Here SGP1 is in SG1 and SGP2 is in SG2. Basically mated SGs are
> > > located geographically in different places.The ideas is when SG1 
> > > goes down in CITY1(due to earthquake...) , all the traffice still 
> > > can be handled by SG2 which is in CITY2.
> > > 
> > > SGP2 is mate for SGP1, On failure of SGP1, all the messages will 
> > > be
> > > routed from SGP1 to SGP2.
> > > 
> > > Does all these things mean to say that SGP1's mate 'should be'
> > > present in SG2 and not in SG1 itself ?
> > >  
> > > 
> > > Comments are welcome.
> > > 
> > > --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.
> > *******
> > > 
> > > _______________________________________________
> > > 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

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 01:35:42 -0700

Zannin,,

Zannin, Francois wrote:                                                            (Thu, 06 Feb 2003 09:27:21)
> I think your example of 200,000 ASP "UP" as backup for an AS is really

200?  20?  It makes no difference.  The SG cannot be required to
send useless messages to bunch of ASPs that can do nothing with
the information.

> procedure for its own isolation.

DUNA corresponds to MTP-PAUSE not TFP.

Consider 100 APSs inactive, zero (0) ASPs active.

The SG cannot be required to send DUNA to inactive ASPs.  When the SG
NIF has no user to send MTP-PAUSE to, it is not possible for the SG
to send DUNA.

The SG cannot be required to send SSNM to inactive ASPs.

Besides, it is unnecessary.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 02:51:52 -0600 (CST)

Brian,

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

> send useless messages to bunch of ASPs that can do nothing with
Everything is useless at one point of time, we should see always
the 'usefullness of many times".

> Consider 100 APSs inactive, zero (0) ASPs active.

I can say 100 ASPs inactive and 100 ASPs active with
override mode.

> NIF has no user to send MTP-PAUSE to, it is not possible for the SG
You are saying user-part is unavailabe at inact ASP.
But logically it is available.

> The SG cannot be required to send SSNM to inactive ASPs.

It is required.Sending DUNA to inactive ASP is meaningfull.
 
> Besides, it is unnecessary.

I cant accept.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 01:56:44 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 02:51:52)
> the 'usefullness of many times".

In this case it is useless all the time to send SSNM to inactive ASPs.

> I can say 100 ASPs inactive and 100 ASPs active with

100 ASP cannot be active for the same AS in override mode: only 1 can.

> It is required.Sending DUNA to inactive ASP is meaningfull.

It is not required and cannot be required.

> > Besides, it is unnecessary.

Well, as we can't agree, we will have to stay with the RFC, which
says that SSNM is not sent to inactive ASPs.

It is not the WG's responsibiltiy to convince you that the RFC is
proper, it is your responsibility to convince the WG otherwise.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 6 Feb 2003 03:13:56 -0600 (CST)

Brian,

> 100 ASP cannot be active for the same AS in override mode: only 1 can.

Total misinterpretation.ASP1 is active ASP2 is inactive....
ASP100 is active and ASP100 is inactive - VIA RE-STARTED SG.

Now 100 ASPs are active and 100 ASPs are inactive from the point
of re-started SG.

> says that SSNM is not sent to inactive ASPs.

You know so far 'disagreement with RFC' only changes RFC.
(with good reason).
> proper, it is your responsibility to convince the WG otherwise.

no comments.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Feb 2003 02:24:37 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 06 Feb 2003 03:13:56)

--brian