Subject: M3UA: MTP Restart

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Sep 2001 17:58:34 -0500

Francois,

Consider the backhaul case alone for a moment:

  1) When the SG loses the last link for a represented signalling point,
     all MTP-Users associated with that signalling point which are
     AS-ACTIVE will have already received MTP-PAUSE (DUNA) for every
     signalling point except perhaps those signalling points which are
     on the SG itself.  Traffic has already stopped from MTP-Users to
     signalling points outside the SG.

  2) When the SG restores the first link at level 2 for a represented
     signalling point, it starts the MTP Restart procedures per Q.704.
     There is no need to send DUNA(*) to any ASPs.  Each ASP has already
     received the necessary DUNAs when the isolation occured.  As the SG
     receives TFP/TFR from any adjacent STPs, it collects the new
     routing information until MTP Restart ends.  When MTP Restart ends,
     the SG informs MTP-Users at ASPs with the updated routing
     information by sending DAVA and DRST.  As the MTP restart procedure
     has completed, the MTP-User can restart traffic as it receives
     MTP-RESUME primitives.

  3) When an AS goes AS-ACTIVE at an ASP, it either already has routing
     information, or it can perform a DAUD.  The SG need do nothing.  It
     doesn't matter whether the MTP-User assumes that desinations are
     available or unavailable.  If the MTP-User sends to an unavailable
     destination or attempts to send when becoming active in the middle
     of MTP restart, the SG will return DUNA (response) and the MTP-User
     will receive an MTP-PAUSE.

Therefore, for the backhaul case, no special MTP restart procedure is
required.

In the IPSP case, the MTP-User at the ISPS should be treated no
differently than the MTP-User at the ASP.  The only question is whether
the IPSP might have to perform MTP Restart procedures between itself and
other IPSP peers.  Whether this is the case or not depends highly on
whether IPSPs are perceived as exchanging MTP Peer PDUs or whether they
are seen as transporting MTP-User primitives.  The only case than an
IPSP perceived as exchanging MTP Peer PDUs might require a restart
procedure is if it is adjacent to an IPSP which somehow has the transfer
function.  An IPSP with the transfer function is so poorly defined at
this point for M3UA, it is hard to even say how this should work.

One thing is certain, if the IPSP is establishing its first association
(and more importantly first route) to the peer IPSP, then it should
perform MTP restart procedures and the peer should perform adjacent
restart procedures.  In this case it is not necessary for the peer IPSP
to signal MTP Restart to the restarting IPSP (the restarting IPSP is
fully aware that it is restarting).  Therefore the ASPAC Ack delay does
not make sense.  What is required is a method for the peer IPSP to
signal Traffic-Restart-Allowed at the end of the procedure.  M3UA has
seen fit to not provide any M3UA message for an IPSP to signal this and
it is an issue concerning IPSP operation anyway.

Because it is not necessary for MTP-Users and so poorly defined for
any IPSP case to which it is questionable whether it even applies, I
propose that the entire MTP Restart section be struck and that the
SGP, ASP and IPSP never be allowed to send SNMM to inactive ASPs.

In many cases when the ASP is ASP-INACTIVE, it is impossible to tell
which ASs (MTP-Users) the ASP is inactive for.

--brian

On Tue, 04 Sep 2001, Brian F. G. Bidulock wrote:

> Francois,
> 
> On Tue, 04 Sep 2001, MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:
> 
> > Brian,
> > I think we are close to a common view. Please see comments below.
> > Francois.
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Tuesday, September 04, 2001 1:50 AM
> > > To: sigtran
> > > Subject: Re: M3UA Issues List
> > > Importance: High
> > > 
> > > 
> > > Francois,
> > > 
> > > Q.701 clause 8.5 states:
> > > 
> > >   "When the MTP restart procedure is terminated, the MTP indicates the
> > >    end of MTP restart to all local MTP Users showing each signalling
> > >    point's accessibility of inaccessibility.  The means of doing this
> > >    is implementation depedent (see 9/Q.704)."
> > > 
> > > It is clear that the proscribed approach in Q.701 is not for the
> > > MTP-User to assume that all destinations are available, but, rather
> > > upon MTP RESTART, all destinations are indeed deemed unavailable
> > > (because they are unavailable).  When MTP RESTART completes, each
> > > user is told the availability or unavailability of all destinations
> > > in kind of a single clump.
> > > 
> > 
> > [FM] Clearly all destinations are unavailable when isolation begins
> > (last link unavailable at level 2).
> > At the beginning of the Restart procedure (first link unavailable at level
> > 2),
> > MTP should consider that all destinations are available (quote from Q.704):
> > 
> > "9.6.1	When the MTP of a signalling point restarts, it considers 
> > at the beginning of the MTP restart procedure all signalling
> > routes to be allowed."
> > 
> > At the end of the restart procedure, any destinations for which TFP
> > was not received are deemed available. That's all I meant to say but
> > I agree my wording was imprecise. 
> > For the M3UA section, the SGP should compile the status of all destinations 
> > and send it to MTP Users as you described. That's a good point.
> > 
> > > Consistent with this, when an MTP User first joins a service interface
> > > to an MTP Provider (as paralleled by ASPAC), the MTP user should
> > > obtain the status of all signalling point to which it is concerned
> > > before staring traffic in the interface.
> > > 
> > 
> > [FM] IMO, there is no point doing this in the absence of restart context.
> > All routes are innocent untill proven guilty.
> > But, the SG should signal destination unavailability or restriction before
> > returning an ASPAC ACK. In the absence of such indication, the ASP
> > should deem the destinations are available. This is consistent with MTP.
> > Why do you want to make the regular AS activation match the restart
> > procedure?
> 
> In the case of ASPAC, the ASP is fully aware that it is becoming newly
> available and is also fully welcome to do a DAUD if it wants to audit
> the current state of destinations.  Why make the SG blindly send this
> state before ASPAC Ack when it is only the ASP which knows whether it is
> necessary or not?  Why not just let the ASP send DAUD as provided for in
> DAUD procedure?  This would allow the ASP to forgo the auditing of
> destination states where it was not necessary.  If the SG is forced to
> send this state, it will be sent whether necessary to the ASP or not.
> 
> > 
> > > Attempting to make both approaches consistent in M3UA backhaul would
> > > require that ASPs should always perform DAUD(*) after ASPAC and
> > > before starting traffic.  An ASP can certainly assume than a 
> > > destination
> > > from which an AS receives traffic in this interval is available.
> > > After the DAUD(*) procedure completes, the ASP can deliver 
> > > the information
> > > to the AS in the matter described in Q.701.
> > 
> > [FM] Another way to make both approaches consistent would be to mention that
> > the SG MUST deliver destination status to the ASP:
> > 1. for all destinations (after restart) or for all unavailable or restricted
> > destinations (normal activation)
> > 2. and, before the SG sends a message allowing the AS to start traffic (i.e.
> > DAVA(*) for restart case and ASPACK Ack for normal case)
> 
> Again, the reason that the draft should not force the SG to send this
> state after ASPAC is that it is not always needed by the ASP.  The ASP
> has a procedure (DAUD) already proscribed in the draft for obtaining
> this state when necessary after ASPAC.
> 
> Also, there is a conflict between proper treatment for MTP Users and
> proper treatment for MTP Peers under restart at the restarting node.
> MTP Users need to treat all destinations as unavailable and be informed
> of availability.  MTP Peers need to treat all destinations (offered by
> the adjacent SP against which they are restarting) as available.
> Because even in the IPSP case, M3UA is not a MTP peer-to-peer protocol,
> (it is an MTP-User to MTP-User transport), the ASP could always treat
> all destinations as prohibitied (as clearly indicated by DUNA(*) anyway)
> and the MTP specifications require that upon network separation each
> MTP-Users will have received MTP-PAUSE for every offered destination (as
> all routesets become unavailable during separation).  This already
> ensures that no traffic is flowing from the ASP (all destinations are
> prohibited).  The ASP only needs to be informed of destinations which
> are available/restricted/congested coincident with the end of the
> restart procedure.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Adams, Richard Anthony (Richard)" <[email-masked]>
Date: Wed, 5 Sep 2001 09:38:36 +0100

All,
a comment on the "implementation dependent" parts of MTP restart. This term
was used because MTP restart was defined well after MTP implementations were
in the field. Hence, each implementation already had its own initialisation,
we couldn't tear that up and start again. The understanding in SS No.7 is
that the information content only of a primitive is specified, how this
information is actually conveyed is up to the implementation. Even so, in
the MTP restart case, we didn't even agree the primitives.
But M3UA, is still being defined. I would recommend that any primitives
required should be specified as precisely as possible. 
And Francois is correct, given the choice of assuming all destinations
available unless told otherwise or all unavailable and to be tested, we
chose the first as being a more likely case, and causing fewer problems if
the assumption was wrong. Q.701 is really an overview of the MTP, the
procedures are defined in Q.704.  

> With kind regards,
> Richard A. Adams,
> [email-masked], tel : +44 1666 83 2503
> fax: + 44 1666 83 2712
> Lucent Tech.,
> Swindon Road,
> Malmesbury,
> Wiltshire SN16 9NA.
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 04:35:05 -0500

Richard,

During MTP restart procedure it is only MTP routing that assumes
all remote destinations as available until TFP is received.  This
follows the assumption that most nodes in an SS7 network at any
given point in time will be available, and that this would limit
the number of SNTM messages which needed to be sent during restart.

An MTP-User on the other hand has been told that each remote
destination was unavailable (with MTP-PAUSE) at the time that the
isolation occurs.  It is clear from the notes in Q.701 that the
accessibility of each remote signalling point is signalled to the
MTP-User only after MTP restart ends.  This is clear, because
point codes may still be available even though the MTP restart
procedure is being performed with regard to some part of the
network.

As M3UA transports the MTP-User interface, there is no need for
a restart begins (DUNA(*)) and restart ends consists merely of
the updating of remote signalling point accessibility as indicated
in Q.701.  In M3UA this update can be performed with a string of
DAVAs and DRSTs which are sent after the MTP restart procedure
has completed for some part of the network.

Is there a description in Q.704 of how or whether MTP restart
begins should ever be indicated to MTP-Users?  Does Q.704 describe
how MTP-Users are to treat an MTP restart beings indication even
if they received one?  For MTP restart ends?
	
Where in Q.704 does it say that MTP-Users are to treat a MTP
restart begins indication as though it were an MTP-RESUME for
all destinations?  Where does it say that MTP-Users can expect
only to receive MTP-PAUSE after MTP restart begins and before
MTP-restart ends?

The only description I have seen is the note in Q.701, which
makes perfect sense and is quite consistent with the procedures
and the MTP-User interface.  It is clear from this passage that
the MTP-User is given an update to destinations which have changed
since the isolation and the end of the MTP restart procedure.

There is no need for the MTP-User to test destinations for which
it has received MTP-PAUSE.  It simply waits for an MTP-RESUME
before restarting traffic to that destination.  So, I don't know
what you mean by "all unavailable and to be tested".  Could you
clarify?

--brian

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

---

---

From: "Adams, Richard Anthony (Richard)" <[email-masked]>
Date: Wed, 5 Sep 2001 13:01:21 +0100

Brian,
please see my comments between [RAA] and [raa].

> the number of SNTM messages which needed to be sent during restart.
	[RAA] In fact, until the end of restart, the restarting MTP treats
all other nodes as unavailable for traffic messages, but it will (if it is
an STP), send TFPs, TFRs, TFAs then a TFR to adjacent nodes it considers
available in phase 2 of its restart. The assumption of availability should
indeed limit the number of messages sent during restart. [raa]
> procedure is being performed with regard to some part of the
	[RAA] A node will only undergo MTP restart if all its links to the
network become unavailable, and later some go into service at level 2. So,
before the end of restart, all the other signalling points in that network
are inaccessible to MTP users at the restarting point. The "end of restart"
signalled by the restarted MTP is equivalent to an MTP resume for each
available remote signalling point - that is, now available to the restarted
MTP. If an "exchange" or "switch" spans several MTP networks, then it is
possible that its MTP in one network could restart, while its MTP in another
doesn't need to. (I'm trying to avoid the philosophical discussion about one
MTP for all MTP networks, the network being distinguished by NI value! ). Of
course, if the implementation uses a centralised processor, there might be
just one "MTP", and so if MTP restart is needed in one network (caused by
the processor going down and then recovering), it will be needed in all.
[raa]
> has completed for some part of the network.
	[RAA] I agree. But it seems that the network is now taken to mean a
set of networks! One thing I never liked in the ITU MTP was that the TFP,
TFA, TFR messages only ever referred to just one signalling point. We had
problems in MTP restart because of this, and also had to worry about TFP
loading elsewhere. We even changed the SLS value from 0 to allow load
sharing of TFPs (albeit with a warning that TFAs and TFPs should be
carefully sequenced!). The US cluster messages are an advance. For MTP to
MTP user primitives, using just one RESUME for each available signalling
point seems wasteful, better use one primitive with a set of signalling
points as parameter. It's a pity that M3UA, in modelling the primitives, has
done a one for one copy ! [raa]
> if they received one?  For MTP restart ends?
	[RAA] MTP users don't "need to know" when restart begins, only when
it ends. They might like to know after being told MTP PAUSE how long it will
be before the RESUME, but I guess the MTP itself wouldn't know. The restart
is probably after a fairly severe failure (although it could be after just a
second of processor outage on all links), so its duration of less than ~ 1
minute could be insignificant. As far as the "restart ends", fitting restart
into a node that already had its own initialisation meant using, as far as
possible, existing implementation interfaces (about which ITU-T could only
guess), so we said so. A single RESUME for just one available signalling
point didn't cause much argument, but the equivalent for a whole set of
points would have opened a can of worms. [raa]   	
> only to receive MTP-PAUSE after MTP restart begins and before
	[RAA] It's MTP restart ends that is equivalent to MTP RESUME for all
available destinations in this MTP network. And MTP PAUSE for each
destination would occur if the MTP lost all its links but could still tell
its users. They should then prepare for the MTP restart ends indication.
[raa]
> since the isolation and the end of the MTP restart procedure.
	[RAA] The Q.701 stuff is consistent with Q.704, but in principle the
indication from the MTP at the end of restart contains information about all
signalling points in the MTP network with which this signalling point has a
signalling relation. The implementation could just signal from MTP to MTP
user about changed states since isolation. [raa]
> what you mean by "all unavailable and to be tested".  Could you
	[RAA] If the MTP receives a TFP, it starts a periodic route set
test, so the user doesn't need to do any test if it gets an MTP PAUSE. If a
direct linkset fails, the MTP will attempt to restart it. 
	When we wrote MTP restart, we took the decision to send routing
information from adjacent nodes to the restarting MTP about unavailable
signalling points. The other possibilities were to inform about available
signalling points, or for the restarting MTP to test all its routes (as in
the Red Book section 12.4.2 b) national option, which, when a direct linkset
became available, allowed a signalling point to do a route set test for each
signalling point which should be accessible via that linkset ). The
assumption that a signalling point is considered available by the restarting
MTP unless told otherwise means that, if a TFP is not received during
restart (perhaps it is delayed), message traffic could be restarted towards
the SP, only to receive a TFP. In network failure conditions this could mean
that the restart took longer. 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 14:10:06 -0500

Richard,

Please see comments below...

On Wed, 05 Sep 2001, Adams, Richard Anthony (Richard) wrote:

> MTP.

The above is precisely my point and my proposal for M3UA.  I'm glad you agree.

> If an "exchange" or "switch" spans several MTP networks, then it is

Adjacent nodes will still perform the procedures of Q.704 Clause 9.3,
"Actions in a signalling point X, adjacent to a signalling point Y whose
MTP restarts" even if the restarting signalling point has not lost all
of its links to the network.   In claus 9.3 it is clearly stated that
MTP-RESUME to the MTP-Users is delayed until T21 is either cancelled or
has expired, and then MTP-RESUME is the primitive provided to users.

This procedure does not depend on all links down.  An adjacent signalling
point is considered to be restarting when inaccessible and either a route
becomes available or the first link in a direct linkset to the adjacent
signalling point becomes available.

> done a one for one copy ! [raa]

ITU provides for cluster routing in the national network.  It is unnecessary
in the international network (too few nodes to cluster route).  M3UA provides
for clustered DUNA/DAVA/DRST even SCON.

> points would have opened a can of worms. [raa]   	

There are existing implementations of MTP to which M3UA is being retrofitted.
What makes you think that M3UA can succeed where the MTP specifications have
failed in this implementation specific area?

> user about changed states since isolation. [raa]

I think that the precise contents of the indication (whether a list
of all signalling points or just deltas) is implementation dependent.
Sending DAVA/DRST from the SG (and not DUNA) does represent the deltas
from the last information sent to the ASP when the isolation occured.
Resetting routes to available and sending only DUNA/DRST would require
the M3UA ASP to maintain both routing information (signalling relations)
as well as the state of routesets from the SG.  That is not practical.
The M3UA ASP implementation should not be forced to maintain this
information when it is not necessary to do so.

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Thu, 6 Sep 2001 10:07:57 +0200

Brian,
  Yes, we can play it as you describe.
  Signalling the MTP Restart situation would have some benefits:
     be a little more friendly to the ASs to distinguish the
     simple unavailability of one destination form the isolation case,
     thus would help prevent unnecessary audits during the restart
     phase and provide alarms closer to the real situation.
  But I agree that it is not necessary to achieve the interworking
  and we can do away with this.
  Still, as you point out, the current restart description in the
  draft should be struck and rewritten, which was the starting point
  of this discussion. I take it that you will endorse this action.
Francois.

> Sent: Wednesday, September 05, 2001 12:59 AM
> To: sigtran
> Subject: M3UA: MTP Restart
> Importance: High
> 
> 
> Francois,
> 
> > To unsubscribe send a blank email to 
> [email-masked]
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 04:17:39 -0500

Francois,

>   and we can do away with this.

Even the current draft has no way of indicating MTP restart begins.
DUNA(*) indicates isolation.

>   of this discussion. I take it that you will endorse this action.

Did you want to propose text, or shall I?

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Thu, 6 Sep 2001 14:07:07 +0200

Brian,
How about this (replacing current 4.4 section):

4.4 MTP3 Restart

In the case where the MTP3 in the SG undergoes an MTP restart, event
communication SHOULD be handled as follows:

When the SG discovers SS7 network isolation, the SGPs send an indication to
all concerned available ASPs (i.e., ASPs in the ASP-
ACTIVE, ASP-STANDBY or ASP-INACTIVE state) using DUNA message(s) for the
concerned destinations.

When the SG has completed the MTP Restart procedure, the SGP M3UA layers at
the SGPs inform all concerned ASPs in the ASP-ACTIVE, or ASP-STANDBY states
of any available/restricted SS7 destinations using the DAVA/DRST message. No
message is necessary for those destinations still unavailable after the
Restart procedure.

When the M3UA layer at an ASP receives a DUNA message indicating SS7
destination unavailability at an SG, MTP Users will receive MTP_PAUSE
indication and will stop any affected traffic to this destination.
When the M3UA receives a DAVA/DRST message, MTP Users will receive
MTP_RESUME indication and can resume traffic to the newly available
SS7 destination via this SGP, provided the ASP is in the ASP-ACTIVE state
towards this SGP.

The ASP MAY choose to audit the availability of unavailable destinations by
sending DAUD messages. This would be for example the case when an AS becomes
active at an ASP and does not have up to date destination statuses.
If MTP restart is then in progress at the SG, the SGP returns a DUNA message
for that destination, even if it received an indication that the destination
became available or restricted. 

In the IPSP case, MTP restart could be considered if the IPSP also has
connection to an SS7 network. In that case, the same behavior as described
above for the SGP would apply to the restarting IPSP. This would also be the
case if the IPSPs were perceived as exchanging MTP Peer PDUs, instead of MTP
primitives between MTP User and MTP Provider. In other words, M3UA does not
provide the equivalent to Traffic Restart Allowed messages indicating the
end of the restart procedure between peer IPSPs that would also be connected
to an SS7 network.

Francois.

> Sent: Thursday, September 06, 2001 11:18 AM
> To: sigtran
> Subject: Re: M3UA: MTP Restart
> Importance: High
> 
> 
> Francois,
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 07:21:46 -0500

Francois,

Excellent!  However, the IPSP case might need to be revisited after
M3UA Issue #11 is resolved.

In the meantime, I certainly support replacing the current section
4.4 with your proposed text.

In doing so, there would be no more reason for ASP, SGP or IPSP to
accept SNMM for an INACTIVE ASP.  So, for example, section 4.2.3.4
ASP-Active Procedures should be updated from:

   The ASP SHOULD NOT send Data messages for the related Routing
   Context(s) before receiving an ASP Active Ack message, or it
   will risk message loss.

 to:

   The ASP SHOULD NOT send DATA or SNMM messages for the related
   Routing Context(s) before receiving an ASP Active Ack message,
   or it will risk message loss.

There may be more occurrences of permitting SNMM to inactive ASPs
which would need cleaning up.

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Thu, 6 Sep 2001 14:18:42 +0200

Correction: second paragraph should read:

When the SG discovers SS7 network isolation, the SGPs send an indication to
all concerned available ASPs (i.e., ASPs in the ASP-
ACTIVE, or ASP-STANDBY state) using DUNA message(s) for the concerned
destinations.

Sorry about this,
Francois.

> From: MOUILLAUD,FRANCOIS (Non-HP-France,ex2)
> [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 2:07 PM
> To: sigtran
> Subject: RE: M3UA: MTP Restart
> 
> 
> Brian,
> [email-masked]

---

---

From: "Adams, Richard Anthony (Richard)" <[email-masked]>
Date: Thu, 6 Sep 2001 13:35:26 +0100

Brian and Francois,
	OK by me !

---