Subject: M3UA V8: SGP behavior upon AS/ASP failures

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 21 Aug 2001 19:20:40 +0200

Hello,

I did not find the description of a failure scenario in the draft.
When an SG can not transfer a message to some AS (ASP Inactive
message and no remaining ASP) or even to all the AS behind an ASP,
it is expected that a message be sent to the SS7 interface?
Assume for example that RK is (OPC=a, DPC =b), or RK = (OPC=a, 
DPC =b,SI=5), we could send TFP or UPU messages to the concerned
SS7 peers to reflect this situation. Did I miss something or is this
left implementation dependant?

Francois.

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

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 21 Aug 2001 13:11:18 -0500

Francois,

in the general case you can't do this in the examples you give. Any
addressing in m3ua finer than on DPC will severely restrict your network
configuration and/or compromise seamless network management.
Sending the TFP(b) to an STP would stop all traffic to DPC=b, not just that
from OPC=a, via that STP, which is problematic. Sending the UPU(SI=5) would
stop the traffic from OPC=a, even if there is a second SG which still can
reach the RK in question.

Klaus

> -----Original Message-----
> From: MOUILLAUD,FRANCOIS (Non-HP-France,ex2)
> [mailto:[email-masked]]
> Sent: August 21, 2001 1:21 PM
> To: sigtran
> Subject: M3UA V8: SGP behavior upon AS/ASP failures
> 
> 
> Hello,
> 
> 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: Tue, 21 Aug 2001 14:21:45 -0500

Francois,

I think you can see from Klaus' excellent summary of two of the issues
why text decribing when to send TFP or UPU was removed from the draft.
Much depends on the specific SG configuration (STP or not) and the
specifics of the SS7 variant being supported.  When to send what is
an implementation dependent choice, clearly not an easy one considering
transparent SS7 interworking, but a choice which should not be dictated
by the draft.

There were some general statements in earlier versions of M3UA regarding
the sending of TFP, but they were argued out on the basis that the
general statements did not meet the specific cases such as illustrated
by Klaus, and might even have been misleading.

Clearly the sending of TFPs or UPUs is the SG MTP responsibility and not
part of M3UA.  What events might invoke these procedures in the SG MTP
is a function of the NIF and out of scope of the M3UA document by
their very definition.

--brian

Gradischnig, Klaus wrote:                            (Tue, 21 Aug 2001 13:11:18)
> 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: Wed, 22 Aug 2001 09:52:16 +0200

Brian, Klaus

Thanks for your feedback on this. Sorry for catching up late on
this already discussed matter!
It is my understanding that a given SG has all the information
it needs (i.e. the RK and ASP configuration) to determine on its
own whether a failure of a given AS or ASP should impact the SS7
network. It clearly involves more than a dumb one to one mapping,
but it "SHOULD" be done by the NIF. The draft says "It (NIF) also
provides network status information to one or both sides of the
network."
I accept the fact that the NIF behavior is out of the scope of M3UA,
although, since the SG is discussed at length, general (and centralized)
guidelines about what the NIF SHOULD do would certainly not harm and 
could prevent interworking issues.

Francois.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 9:22 PM
> To: sigtran
> Subject: Re: M3UA V8: SGP behavior upon AS/ASP failures
> 
> 
> Francois,
> 
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 03:00:17 -0500

Francois,

I agree with your statements, but it is tough to come
up with general wording.  Did you have some text in mind?

--brian

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Wed, 22 Aug 2001 09:52:16)

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 11:04:14 +0200

Brian,

We could rearrange some of the text from 1.5.1 and put it in a new
section. The first three items are form 1.5.1, the last two are new.
Please feel free to comment on it.

Francois.

x.x.x NIF behavior at a SG

* For internal SGP modeling purposes, at the NIF level, SS7 signalling 
messages that are destined to the MGC are received as MTP-TRANSFER 
indication primitives from the MTP Level 3 upper layer interface, 
translated to MTP-TRANSFER request primitives, and sent to the local 
M3UA-resident message distribution function for ongoing routing to the 
final IP destination.  

* Messages received from the local M3UA network 
address translation and mapping function as MTP-TRANSFER indication 
primitives are sent to the MTP Level 3 upper layer interface as MTP-
TRANSFER request primitives for on-going MTP Level 3 routing to an SS7 
SEP.

* For the purposes of providing SS7 network status information the 
NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication 
primitives received from the MTP Level 3 upper layer interface to the 
local M3UA-resident management function. In addition, as an 
implementation and network option, restricted destinations are 
communicated from MTP network management to the local M3UA-resident 
management function.

* For the purposes of providing User Part status information the 
NIF also sends an UPU message to the MTP Level 3 upper layer interface
when it determines that it is unable to deliver MTP-TRANSFER indication 
primitives to that User Part e.g. because of AS unavailability or ASP
failures. Care must be taken that, based on Routing Key configurations,
the whole User Part must be unreachable for an UPU to be sent.

* When the SG acts as an STP (i.e. has its own point Code), the NIF
implements SS7 Signalling Network Management procedures on behalf of
the destinations in the SS7 network (per regular MTP procedures),
as well as of those in the IP network.
For the purposes of providing Destination status information for those
destinations located in the IP network, the NIF sends a TFP message to
the MTP Level 3 upper layer interface when it determines that it is
unable to deliver MTP-TRANSFER indication primitives to that destination
e.g. because of AS unavailability or ASP failures. Upon availability of
the AS or ASP, the NIF sends TFA to the SS7 destinations. The NIF also
reacts to routeset test messages (RSP) received from the SS7 network
per the SS7 standard. More generally, the NIF adopts the STP behavior
as if the destinations located in the IP network were regular SS7 
destinations. In case the SG is connected to several Network
Appearances, using different MTP standards or PC addressing schemes,
one PC/NI per network must be assigned to the SG and the NIF reflects
the events occuring to a destination in the IP network to the SS7
network under the same Network Appearance, and per this network's SS7
specifications.
Care must be taken that, based on Routing Key configurations, the whole
destination must be unreachable from the SG for a TFP to be sent. As in
MTP, a TFP does not imply that the destination is unreachable by the SS7
network, only that it is not reachable from the SG.

> Sent: Wednesday, August 22, 2001 10:00 AM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 22 Aug 2001 08:20:52 -0700

What you guys are describing here is an IMPLEMENTATION.  Any document that
wants to be a STANDARDs document should never specify an implementation.

I have a different view of how/where the NIF sits.

I think the management functions of the NIF sits BETWEEN M3UA and MTP3.
There is a lot of commonality between the management functions needed at a
SG/STP and I definitely think it is possible that management functions could
be shared between MTP3 and M3UA.  This is an implementation detail and the
MTP-user primitives are not needed.

I think the routing functions of NIF sits slightly above (and some between)
the M3UA and MTP3.  How messages are exchanged between M3UA and MTP3 is an
implementation detail and the TRANSFER primitives are not needed.

You can try to do it your way, but just be aware that there will be those of
us who already have SS7 experience that will "merge" M3UA and MTP3 functions
for efficiency.

John

> Sent: Wednesday, August 22, 2001 4:04 AM
> To: sigtran
> Subject: RE: M3UA V8: SGP behavior upon AS/ASP failures
> 
> 
> Brian,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 11:32:18 -0500

Francois,

Please see comments on the last two paragraphs...

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Wed, 22 Aug 2001 11:04:14)
> Please feel free to comment on it.
[snip]
> the whole User Part must be unreachable for an UPU to be sent.

I don't think the text should mention UPU with regard to the MTP Level
3 upper interface.  There is no defined method for sending "UPU", nor
MTP-STATUS for that matter, *to* the MTP Level 3 upper layer interface.
How MTP detects the accessibility or the provisioning of user parts
is implementation dependent and not much mention of a mechanism is given
in the MTP standards.  Most implementers will react to text which tells
them how to do something in the NIF.

A statement more like:

  "In response to a DUPU message from an ASP, the M3UA at the SG
   may indicate user part unavailability to MTP3 in an implementation
   dependent fashion."

Even that would probably get a reaction.  The simple course has been
to simply not mention these things.

> as well as of those in the IP network.

The above is probably already inherent in the definition of SPMC.

> network under the same Network Appearance, and per this network's SS7

The above is even more restrictive than the text which was struck from
the M3UA draft.  You shouldn't, for example, mention sending TFPs to MTP
Level 3 upper interfaces.  Not even MTP-PAUSE is sent in the downwards
direction.

> network, only that it is not reachable from the SG.

This above is really up to the implementation.

This is the "slippery slope" that Greg has referred to in trying to
say anything about how the NIF does what it does.  The "how" is part
of an implementation.  Even the "what" and the "when" are dictated by
the SS7 network and local specifications.  M3UA should not make statements
about "how," "what," or "when" things are done in the NIF.  What M3UA
can do is say what events, messages and parameters are available within
M3UA for use by the NIF in determining what and when to do something.
The "how" in the NIF, because it must interwork with SS7, is not only
implementation specific but SS7 variant specific.  Implementers (myself
included) react strongly to things in the draft which attempt to tell
them what to do with respect to the SS7 network.  WRT the SS7 network
there are volumes of standard to which an implementation must conformed:
M3UA makes that job easier by not mentioning them.

The existing definition of SPMC goes about as far as any of us let the
draft go on talking about SS7 point code management with respect to an
SPMC.  The SPMC definition itself is an abstraction which was necessary
to talk about SS7 network management (TFP,TFA,TFR, routing) in a general
fashion without getting into the "how" of the NIF.

In talking about UPU, perhaps a similar abstraction (such as UPMC - User
Part Management Cluster) could be defined an discussed; however, because
sending UPU to the SG is such a corner case, it would hardly be worth
all of the text.

I think that this one sentence is probably all that one could get away
with adding to the draft:

  "In response to a DUPU message from an ASP, the M3UA at the SG
   may indicate user part unavailability to MTP3 in an implementation
   dependent fashion."

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 18:39:58 +0200

John,

I am adopting an API perspective. No matter how you implement
it, you still have MTP3 and M3UA counterparts to which you
must send the messages and you still get primitives from the users.
Do you know a way to communicate to a User Part other than a
TRANSFER primitive?

I don't think the text prevents merging M3UA and MTP3 if you
can well distinguish the outside world interfaces. Also notice
that the added text (last two items) is in line with the wording
existing today (first three items). Are you saying you want to
remove the NIF wording from the draft?

The bottom line was to mention that a SG should send the appropriate
messages to the SS7 network when an event related to destination
or User Part located in the IP domain occurs. This is completely 
independent of the implementation in my view but I think it is a key
point to mention because it is the SG behavior.

Francois.

> From: Schantz, John [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 5:21 PM
> To: sigtran

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 19:02:42 +0200

Brian,

I see your point, although I notice that the existing description
of the NIF behavior in the draft is pretty much about "how," "what,"
or "when" things are done in the NIF with respect to mapping! Why
describe the mapping at length and not briefly mention other key
NIF features? You will also notice that the event mapping from SS7
to M3UA is pretty much described and TFP, etc.. are mentioned no
matter how variant specific they may be. It's just the other way
around that the description is missing.
Therefore I must say I am a bit confused as to what we expect to be
in the draft.

Your proposal below does not suit me because it does not cover the
less trivial case where the SCTP association is completely down, and
the SG should figure out the impact that this has on the SS7 network,
e.g. based on RK configuration.

Francois.

> Sent: Wednesday, August 22, 2001 6:32 PM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 22 Aug 2001 11:15:42 -0700

Francois,

The NIF is not a user part and as such does not have to be treated like one.

The TRANSFER primitives would go directly to the user parts but only if it
is known that that is where they go (destination is local).  I would have it
receive the TRANSFER primitives from the MTP users and determine if the
messages are destined for an IP connection (M3UA) or SS7 connection (MTP3).
Hence, I also have an API perspective.

The NIF (where I think management could live) would have the responsibility
of maintaining PC and route status.  It can do this by collecting DUNA/TFP,
DAVA/TFA, SCON/TFC information and using it to update its "tables".  In this
scenario, it would have the responsibility of sending PAUSE, RESUME, STATE,
& PCSTATE primitives to the MTP users.  Note, this view allows me to easily
define primary and alternate routes to destinations in either network (IP or
SS7).

John

> Sent: Wednesday, August 22, 2001 11:40 AM
> To: sigtran
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 13:17:21 -0500

Francois,

Greg was of the same mind: that some things should be mentioned in
the draft.  I fit more in John's camp: that those capable of
implementing M3UA know the SS7 network requirements applicable to
them and don't need suggestions, reminders or pointers in the M3UA
text.  The current text was toned down to the point that it was
acceptable by adding "might, for example," "could," and "may".
Avoid the words "must," "should," and others that could be construed
as placing a requirement on implementation.

You can use "UPU" in reference to a message the MTP might, for
example, send.  But, you cannot use it to refer to a primitive
sent to the MTP from the NIF.  I would suggest that you use words
like "user part unavailability" instead of "UPU" in these cases.

Please feel free to propose text.  

--brian

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Wed, 22 Aug 2001 19:02:42)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 22 Aug 2001 12:01:04 -0700

Francois,

I thought that you would like to see a picture:

			+-----------------+
			|   MTP User(s)   |
			+-----------------+
                  ^        |        ^ 
                 /         | MTP-    \
                /          | TRANSFER \
            +--/           v           \--+
           /          +----------+         \
          /           |   Msg    |          \
         /  +-------->| distrib. |<-------+  \
        /   |         +----------+        |   \ 
       /    V                             V    \
   +----------+                         +----------+
   |  MTP3    |       +---------+       |  M3UA    |
   |   Msg    |<----->|___Mgt___|<----->|   Msg    |
   | Handling |  TFP  |  Route  |  SNMM | Handling |
   +----------+  TFA  | - - - - |       +----------+
		     etc. | Traffic |
			    | - - - - |
			    |   Link  |
			    +---------+
                     |           |
                     +----NIF----+
  |                              |
  +-------------MTP3-------------+  
                     |                              |
                     +-------------M3UA-------------+

The only thing I am not showing is M3UA's Layer Mgt feeding Link Mgt about
association status and MTP2 Mgt feeding Link Mgt with Link status. 

The NIF is the middle part (Msg Distributer and Network Mgt).

John

> From: Schantz, John 
> Sent: Wednesday, August 22, 2001 1:16 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 14:15:40 -0500

Francois,

I agree with Gery's statement that the NIF is a black
box (implementation specific) and that the M3UA draft
need only describe what inputs (UA events) are made
available to that black box.  What the black box does
with those events are outside the scope of the drafts.

We only talk of the requirements placed on the black
box when determining the sufficiency of UA events made
available.  In the multiple SG case where SI routing
is performed, M3UA should make available a DUPU event
from ASP to SG.  The black box can then use this
information as it sees fit to affect (or not) user part
availability.

For standardized MTP primitives (MTP-PAUSE, TRANSFER,
etc.) and procedures (routset prohibited, routset
allowed, routset restricted) the draft can suggest that
an M3UA event might be used by the black box to trigger
a primitive or procedure, but should not require it.

User part availability is a nodal function which is
implementation dependent even within the MTP
specifications.  M3UA should make available the DUPU
event at the SG for those implementations which require
it, but should only suggest that the "user part
unavailability procedures" might be applied in response
at the implementation's discretion.

There is no call to define a new API (interface
specification) which the MTP standards have seen fit to
leave to implementation.

I believe that the existing text in M3UA follows this
approach.  Mention of TFP in the draft makes reference
to transfer-prohibited procedures which might be invoked
by the NIF in response to M3UA events (change in state
of the SPMC) as examples of the use of the M3UA event,
and not as a requirement for implementation.

--brian

John Schantz wrote:                                          (Wed, 22 Aug 2001 11:15:42)

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Fri, 24 Aug 2001 08:55:46 +0200

Please find below a new proposal for the last two items in the initial text:

* For the purposes of providing User Part status information to the SS7
network at a SG, the SG may apply the relevant user part availability
procedures when it is determined that the SG is unable
to deliver MTP-TRANSFER indication primitives to that User Part e.g. 
because of AS unavailability or ASP failures.

* When the SG acts as an STP (i.e. has its own point Code),
for the purposes of providing destination status information to the SS7
network for those destinations located in the IP network, the SG may apply
the relevant destination availability procedures when it determines that
it is unable to transfer SS7 messages to that destination
e.g. because of AS unavailability or ASP failures. 

Francois.

> Sent: Wednesday, August 22, 2001 8:17 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 02:19:18 -0500

Francois,

That sounds much better.  Because the text demands nothing of
the implementation, however, the best place for it would
probably be in an introductory section.

--brian

On Fri, 24 Aug 2001, MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:

> To unsubscribe send a blank email to [email-masked]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---