Subject: RE: M3UA Issues List

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 3 Sep 2001 10:05:46 +0200

Brian, 
Please see comments below.
Francois.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 8:52 PM
> To: sigtran
> Subject: Re: M3UA Issues List
> Importance: High
> 
> 
> MOUILLAUD,FRANCOIS,
> 
> On Fri, 31 Aug 2001, MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:
> 
> > Brian,
> > 
> > I have not seen any reply to your issue, and I must say
> > I am also puzzled by this Restart procedure, especially
> > the use of ASPACK Ack to signal the end of the restart.
> 
> > I understand that not sending an ASPAC ACK immediately 
> > makes sense, but using that message to signal the end
> > of the procedure seems very strange.
> 
> I'm not sure that not either delaying ASPAC Ack or sending SNMM
> to ASPs for INACTIVE AS makes any sense either.

[FM] I tend to agree. SNMM and ASPTM should be decoupled.

> 
> It is clearly the obligation of the ASP for performing audits as
> necessary using the DAUD procedure.  Whenever an ASP becomes
> ACTIVE is has the ability to audit, if required, the state of
> any and all destinations.

[FM] The draft currently says that an ASP MAY send DAUD messages upon
becoming ASP_ACTIVE or ASP_INACTIVE.
What is maybe missing here is a clear understanding on both sides 
as to what is the default status of destinations when an ASP newly
becomes active. My proposal is that destinations are considered by
default available (following general principles in SS7). Therefore,
after a restart procedure, an SGP MUST broadcast messages regarding
unavailability of destinations. Of course, this does not prevent the
ASP from sending DAUD messages if it chooses to do so.

> 
> An ASP going active for an AS in the middle of restart is no
> different.  The ASP either has the pertinent information from
> SNMM received for other AS for which it is active, or it is
> advisable that the ASP audit the connection anyways.

[FM] How does the ASP know if those states are still valid?
Are you suggesting that when restart begins, the destination
states should be flagged "unknown"?

> 
> > I believe that the beginning of the restart is signaled
> > by a DUNA sent to the ASPs with affected PC=SG PC.
> > Then why is the end of the restart not signaled with the
> > corresponding DAVA?
> 
> My question as well.  I think end of restart should be signalled
> with DAVA(*).

[FM] I agree on this. Question: Does DAVA(*) means you set CPC=*?
> 
> > What could be done would be, at the end of the restart
> > procedure, broadcast all TFP/TFR received to each ASP
> > ACTIVE (DUNA/DRST), and finish with a DAVA for the SG PC.
> 
> I agree.
> 
> > Also, upon returning an ASP ACTIVE ACK, the SGP should always
> > send the DAVA/DRST for those destinations that it knows
> > are not fully available since, presumably, the AS does not
> > have this information.
> 
> I don't think that is necessary.  The ASP which has gone newly
> active is already permitted to (and should) perform a DAUD
> procedure if it does not have current information.

[FM] You have a point here. So, the SGP sends the destination status
once for all and the ASP records these states.

> 
> I would say that when SS7 network isolation is encountered at
> the SG, the SG may send a DUNA(*) to all ASPs (which are active
> for an AS to which the isolation applies) to signal MTP restart.
> 
> The SG then sends DUNA/DRST throughout the MTP restart procedure
> to the same set of AS to which DUNA(*) was sent.  The SG sends
> DAVA(*) to the same set of AS to signal MTP restart ends.
> 
> If the SG receives an ASPAC for an AS for which the SG is in MTP
> restart, is returns ASPAC Ack as per normal procedures.  It is
> the responsibility of the ASP newly active for the AS to either
> obtain current routing information received for other active AS
> in the ASP or to perform a DAUD procedure before starting
> traffic as per normal ASPAC procedures.

[FM] Yes. Here, you make the usage of DAUD optional. Is that your
proposal?

> 
> When an SG is restarting an it receives a DAUD for an AS for
> which the ASP is newly active, it may delay completely
> responding to the DAUD until the MTP restart of the SG is
> complete.
> 
> In this way DAUD handles ASP restart, whereas DUNA(*) and
> DAVA(*) handle SG restart.

[FM] DAUD would only handle ASP restart when the states have been
lost which is not assumed to be the ususal case.

> 
> This procedure decouples restart from ASPTM and reassures that
> no M3UA messages (DATA and SNMM) are sent to an ASP in the
> INACTIVE state for an AS.
> 
> What do you think?

[FM] Not sure why ASP restart should behave like this. The remaining
of your proposal relies on the assumption that once the SGP has sent
network status to the ASP, then no further exchange of messages should
occur since the ASP has all it needs. Then why would ASPs send DAUD 
if they already have this information?
Of course ASPs are still welcome to send DAUD e.g. if they encounter
corruption or have lost the destination states, etc.. But I don't think
it is necessary to make it mandatory.

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

---
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: Mon, 3 Sep 2001 18:50:23 -0500

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.

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.

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.

An existing ASP in the ACTIVE state will receive the DUNA(*) at MTP
restart, and should assume that all destinations are "unavailable"
(because they are).  It is possible for an ASP receiving DUNA(*) to
follow it up with a DAUD(*) to obtain the necessary information.

--brian

On Mon, 03 Sep 2001, MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:

> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 4 Sep 2001 14:05:12 +0200

Brian,
I think we are close to a common view. Please see comments below.
Francois.

> Sent: Tuesday, September 04, 2001 1:50 AM
> To: sigtran

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

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

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Sep 2001 15:26:00 -0500

Francois,

> Why do you want to make the regular AS activation match the restart

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.

> the SG MUST deliver destination status to the ASP:

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/

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 5 Sep 2001 09:16:56 +0200

Brian,

Can I summarize your proposal as follows:
1. When isolation begins, the SG sens a DUNA(*) to all ASPs
2. When restart ends, the SG sends DUNA/DRST/SCON concerning destinations
for which TFP/TFR/TFC were received during the restart procedure, then
it sends a DAVA (self PC). DAVA(*) can not be sent if DUNA/DRST were
sent before. Alternatively the SG could send a DAVA(*) followed by
the relevant DUNA/DRST/SCON (a bit misleading for the ASP, though).
3. Upon receiving ASPAC Ack, the ASP may send DAUD (e.g. for those
destinations for which it requires status when this status is unknown
to the ASP). This is particularly relevant when the ASP is put in service
for the first time.
4. ASPAC Ack are not delayed anymore by the SG when an ASPAC is received
while MTP is restarting. Because it received a DUNA(*), the ASP is however
aware that the SS7 network is unreachable at that time.

Francois.

> Sent: Tuesday, September 04, 2001 10:26 PM
> To: sigtran
> Cc: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 03:07:23 -0500

Francois,

Not quite what I had in mind.  See comments below...

> 1. When isolation begins, the SG sens a DUNA(*) to all ASPs

There is no need to send DUNA(*). The SG has already sent separate
DUNAs for each remote destination per normal procedures.

> the relevant DUNA/DRST/SCON (a bit misleading for the ASP, though).

When restart ends, the SG sends DAVA concerning destinations for which
TFP was *not* received during the restart procedure and sends DRST
concerning destinations for which TFR was received during the restart
procedure.

There is no need to send anything regarding SG-owned PCs.  A DUNA
was never sent in the first place and SG-owned PCs remain available
through the entire procedure.  SG-owned PCs can send messages to each
other during isolation if desired.

> to the ASP). This is particularly relevant when the ASP is put in service

Correct.

> aware that the SS7 network is unreachable at that time.

Correct: ASPAC Ack is not delayed.  However, the ASP is only aware that
it has received DUNA for destinations which are inaccessible.  DUNA(*)
is no longer required.

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 5 Sep 2001 11:31:20 +0200

Brian,

So what you're saying now is that no special message is sent
to the ASP to signal the beginning of the restart, only the
regular DUNA for all the unreachable destinations.
The issue with this is that the ASP will not be able to
distinguish the regular unavailability case from the
restart situation. For example, per Q.704:

Any test message received during the restart procedure is ignored
by the restarting point (Q.704 9.6.3).
All messages to another destination received at a signalling point 
whose MTP is restarting are discarded (Q.704 9.6.6).

What you're saying if I'm not mistaken is:
During the restart procedure, any TFP/TFR/TFC received are
"held" by the MTP (not transmitted to the ASP). At the end of
the restart procedure, the SGP sends DAVA for the destinations
available and DRST for the restricted ones. The ones that would
remain unavailable have their status unchanged and no message is
necessary.

Does this summarize your proposal? And in that case how do you meet
the MTP requirements listed above? Or are you saying they are not valid?
In that case that will cause a lot of unnecessary message flows during
the restart procedure (DAUD that will be ignored or negated because the
ASP still does some destination-related manageemnt). 
Doesn't this call for a specific M3UA message to inform the ASP when
MTP restart begins and ends? That does not prevent from using the DUNAs
to let MTP Users know whta happens, but the issue is more for the "peer"
treatement performed by the ASPs with the DAUDs.

Francois.

> Sent: Wednesday, September 05, 2001 10:07 AM
> To: sigtran

---

---

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

Francois,

> by the restarting point (Q.704 9.6.3).

I would expect the SG to ignore any test messages received from
the SS7 network per Q.704 9.6.3.

> whose MTP is restarting are discarded (Q.704 9.6.6).

I would expect the SG to discard any messages which would be sent
on routes affected by a restart.  The AS will have already received
MTP-PAUSE for those destinations and should not be sending messages.

> available and DRST for the restricted ones.The ones that would

Yes.

> 
> Does this summarize your proposal?

That is what is described in Q.701.

> And in that case how do you meet the MTP requirements listed above?

The above are restrictions placed on the SG only.  The SG knows that
it is in restart and which routesets are affected by the restart.
It is fully able to meet the requirements you cite from Q.704.  The
ASP (or IPSP for that matter) has no such requirements, because they
are not the restarting nodes (the ASP is the MTP-User, the IPSP is
the node ajacent to a restarting node).

> Or are you saying they are not valid?

They are valid but only impinge on the SG.

> ASP still does some destination-related manageemnt). 

It can't be helped, otherwise, the SG will not be able to represent more
than one point code to the SS7 network or the ASP will have to know the
current routing tables and route status for all the point codes represented
by the SG.  (Because one can restart without the other and they can all
talk amongst themselves even if the SG is completely isolated.)

DAUD is not required during restart.  It is only required in some
circumstances when an ASP becomes active for an AS.

> MTP restart begins and ends?

There is no primitive described for restart begins because it is
unnecessary.  If the MTP-PAUSE and MTP-RESUME primitives are used to
update point code availability after MTP restart ends, there is no need
for an MTP restart ends indication either.

> That does not prevent from using the DUNAs to let MTP Users know whta
> happens, but the issue is more for the "peer" treatement performed by the
> ASPs with the DAUDs.

Sending DUNA(*) is completely unnecessary.  What will the MTP-User do
with this information?  It cannot (and need not) stop sending traffic
to destinations which are still marked as available (its own point
code and other point codes represented by the SG).

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 5 Sep 2001 13:51:32 +0200

Brian,

Per M3UA the ASP may audit periodically unavailable 
destinations (note that it is destinations, not user parts).
DAUS is unnecessary during restart but the ASPs are not aware of restart
and so may check those destinations for which DUNA was received.
(M3UA: "The DAUD message MAY be sent from the ASP to the SGP to audit the 
availability/congestion state of SS7 routes to one or more affected 
destinations.").
Short question:
How do you expect the SG to react to a DAUD? During the restart procedure,
destination status is assumed to be somewhat transient untill the
procedure has been completed, and moreover, when MTP restart begins,
all destinations are assumed to be available (previous Q.704 quote)
untill a TFP is received. Only at the end is the status assumed to be
stable.
Do you expect the DAUD to be ignored (per Q.704) or replied per the current
"transient" SG state?

Francois.

> Sent: Wednesday, September 05, 2001 12:03 PM
> To: sigtran
> > > > > > > before starting traffic.  An ASP can certainly 
> assume than a 
> > > > > > > destination
> > > > > > > After the DAUD(*) procedure completes, the ASP 
> can deliver 
> > > > > > > the information

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 12:59:13 -0500

Francois,

> untill a TFP is received. Only at the end is the status assumed to be

In response to DAUD during MTP restart, I would expect the SG to
respond with DUNA for every destination auditted which is affected
by the restart, and reply with DAVA/DUNA/DRST for the point
codes represented by the SG.

> Do you expect the DAUD to be ignored (per Q.704) or replied per the current

Q.704 doesn't say anything about ignoring implementation specific audits
from the MTP-User.  The MTP ignores test messages from the MTP peer.  That
is an SG MTP requirement only and does not affect M3UA.  Why do you think
that it applies to DAUD?

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 11 Sep 2001 14:45:14 -0700 (PDT)

Folks,

FYI, due to the size of the job, Javier Pastor will be
helping Greg with editing of M3UA.  Thanks to Javier 
for agreeing to help out.

Cheers,

L. Ong

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 17 Sep 2001 14:56:47 -0700 (PDT)

Folks,

I continue to get queries about when we will be
completing the M3UA spec, so we need to continue
to make progress on this.

Looking at the 4 main issues, we now have the
following:

1) NA definition
-- candidate definition proposed by Javier et al.

2) RC in the DATA and SNMM messages
-- agreed to include RC as an optional parameter
-- no agreement to remove NA as an optional parameter
-- proposed procedures to include both whenever
   applicable (i.e., RC when there are multiple AS's
   configured or registered at the ASP, NA when there
   are multiple network appearances at the SG)

3) SG/SGP Management
-- general agreement to go back to SG wording instead
   of SGP in the SNMM section (may need further 
   detail)
-- agreement to incorporate ASPIA Ack for graceful
   shutdown

4) Payload formats
-- still mixed views, will take poll.

There are also a number of smaller issues that
still need resolution.

Let's go with this (with the exception of payload
formats, still to be resolved) as the basis for
the next version of M3UA, which we can then consider
for either another WG Last Call or IESG review.

Cheers,

L. Ong

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 17 Sep 2001 17:03:15 -0500

Lyndon,

What other issues on the M3UA issues list are still outstanding?
Which will be addressed by M3UAv9 and which will not?

--brian

Lyndon Ong wrote:                           (Mon, 17 Sep 2001 14:56:47)

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 18 Sep 2001 12:54:39 -0400

Hi Brian,

   I'm right now updating the M3UA issues list, based on discussions with
Javier and Lyndon, and sending it out later this afternoon - I hope this
will help.

Cheers,

   Greg
----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, September 17, 2001 6:03 PM
Subject: Re: M3UA Issues List

> You are currently subscribed to sigtran as: [email-masked]

---