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

From: "Richard Adams" <[email-masked]>
Date: Thu, 6 Feb 2003 12:35:02 +0100

Brian,
The discussion is similar to the arguments we had when defining MTP
restart. 
There, a restarting SP (SEP or STP) is sent, by all its adjacent running
STPs, TFPs referring to all 
SPs that each such adjacent STP can't currently reach. 
All other SPs in the restarting SP's routing tables are assumed by the
restarting SP to be accessible. 
This keeps the number of messages as low as possible. Then a TRA message
interchange signifies the
end of restart. 
TFPs and TFAs are sent only to those adjacent SPs that are available.

The M3UA messages defined for ASPs becoming active (ASPTM messages)
imply that the ASP part of the network does not act in the same way as a
collection of SS7 SEPs.
We don't have the M3UA equivalent of a TRA message (and the primitive
for the MTP notifying
its local users when restart has completed, was purposely left in Q.704
as implementation dependent).

Now, we have a question of ASP doing a restart, but also of a restarting
SG(P). 
For the SS7 network, a restarting SG presumably will do MTP 
restart as an SEP or an STP. Should it also then send out SSNMs to all
ASPs (that it presumably
thinks are inactive ?) The ASP part of the network could have been
treated as SEPs, but it wasn't.
In our case, the becoming active ASP itself could prompt for information
in DAUD(s), 
and receive DUNA(s) or DAVA(s) as appropriate. This is ~similar to the
Q.704 Red Book 
(section 12.4.2(b) I think) national option of an SP doing a route set
test to 
an adjacent STP when a linkset becomes available. 
And that worked, although it could lead to large numbers of messages in
the network.
Being able to aggregate PCs in DAUD and response messages helps avoid
this problem.

With the ASP active procedures, an alternative would have been for the
ASP Active message 
from ASP to SG to prompt the SG to send DUNA(s) about inaccessible SS7
nodes, followed
by the ASPAC Ack, but I don't read that in the M3UA RFC.     

So, IMO, whether or not a newly active ASP sends DAUD or not is up to it
(although in a managed IP
network maybe the network owner could state if it wanted this to be
done). The ASP could, entirely
dependent on its implementation, decide not to send DAUD and rely on
DUNAs, from the
SG  in response to DATA, if the destination is inaccessible. Or the ASP
could assume
some destinations to be available and others need testing (much as SCCP
does for
subsystems with which it is concerned on its own restart). 

So, I do NOT think that an SG should be required to send SSNM messages
to inactive ASPs. 

Kind regards,
Dick Adams,
[email-masked]

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

Richard,

Let's say it is an override AS...  In that case only one can be
active at a time.

I'm glad you agree with the concensus in the RFC.  We have discussed
this many times over the last several years and have always arrived
at the same conclusion: SG cannot be required to send SSNM to inactive
ASPs.

It is even worse on an SG when dynamic registration is not performed.
In this case, every ASP is considered to be ASP-INACTIVE for every
AS when it comes up.  Sending SSNM to inactive ASPs would send every
SSNM to every ASP, regardless of the more restricted set of AS that
the ASP is actually configured to ever be active for.

--brian

Richard Adams wrote:
(Thu, 06 Feb 2003 09:41:41)
> Brian,
> I agree with you. I think when the ASP becomes active, it should do an
> audit to update its knowledge of the SS7 network. The ASP needs to
take
> the initiative to find out about the SS7 nodes etc. in which it is
> interested. Any other method of working would lead to impossible
loading
> on the SG. 
> Of course, I hope 199,999 of your inactive ASPs do not decide to
become
> active at the same time.....! 
> Kind regards,
> Dick Adams,
> [email-masked]
> 
>  
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 06 February 2003 09:15
> 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

-- 
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 04:49:05 -0700

Richard,

Yes, this is what we arrived at in the "MTP Restart" thread of
September 2001.

I agree with your analysis as I did then.

The simplest approach for the newly active ASP is to just send
traffic and rely on responsive DUNAs (there being very few
inaccessible destinations at any point in time with the exception
of MTP Restart).

The intelligent SG designer could, as you say, send preventative
DUNAs (or DUNA(*) during MTP Restart) immediately following
ASPAC Ack without violating any requirement of the RFC.  I would
consider that "sending SSNM to concerned ASPs."

I also agree with your conclusion: SG should not be required
to send SSNM to inactive ASPs.

--brian

Richard Adams wrote:                                                               (Thu, 06 Feb 2003 12:35:02)