Subject: Re: M3UA Issues List

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 14:43:08 -0500

John,

John Schantz wrote:                                          (Fri, 24 Aug 2001 09:26:55)
> 
> 
> > > 1) Change Network Appearance semantics/format.      
> 
> > It seems to me that the majority of views have
> > suggested that we go back to the definition of
> > NA from version 6, where it is "network context"
> > rather than "network entity".  Any comments against 
> > this?
> 
> [John] Network context/NA is what I need.  The RC usage that Brian wants
> doesn't directly work for existing SS7 nodes that are migrating to SS7 over
> IP.  They could still use it, but they would have to changing their message
> handling function (perhaps borrowed from MTP3) to use RC instead of RL.  I
> don't plan on doing this.

Adding RC to SNMM and DATA makes no requirement on an implementation
to use it instead of RL.  The SG is welcome to use RL in the same
fashion as it does today.  Because RC can be set to the same value
as the current NA, you can use it directly as though it were NA in
your restricted configurations.  Why cannot the NA definition go back
to Lyndon's Network Context?  Perhaps we could even rename it as
Network Context to avoid confusion.

Per Lyndon's suggestion, we can continue this discussion on the other
thread "Network Appearance".

> > > 2) Add Routing Context in Data & SSNM messages.     
> > 
> > We've gone around a couple of times on this,
> > right now we seem to have agreed on adding RC
> > as an optional parameter, the remaining issue
> > being whether this is in addition to NA or
> > replacing NA.
> 
> [John] I thought I had a redefinition of NA/RC that was situation dependent.
> I could use it as a NA, some could use it as a RC, and some could use it as
> a combination; all dependent on the situation.  I think John L. and maybe
> Ken were agreeing with this.

You can set RC to your NA value or use the face that current NA is implicit
in RC.  There is no need for a separate NA parameter.

Per Lyndon's suggestion we can continue this discussion on the other
thread "RC in DATA and SNMM".

> > > 3) SSNM messages semantics at the SGP or SG level.  
> > 
> > Haven't seen too much on this.  Comments?
> 
> [John] It needs to be brought back to the SG level.  Having a partitioned
> end-node would mean that statements are needed to ensure that the SG
> informed each ASP (or ASP grouping - by AS?) since they seem to be
> functioning independently.  I think the issue of an SG being partitioned is
> a separate issue (no longer has a single management presence).  This is
> where separate management procedures and messages are needed.

I believe that SNMM messages might be brought back to the SG level
as long as the SGP is given better control to manage traffic on a
Routing Context level.  There is a proposal to use ASPIA Ack to
allow the SGP to tell the ASP that it can no longer provide service
within a Routing Context.  If this functionality is added, then the SGP
would not need to send DUNA or DRST to affect the same management.
SNMM messages can (and I agree should) only be used to indicate
SS7 network situations and could return to the SG level as John
points out.

John, take a look at the thread "[M3UA / SUA] Gracefull shutdown
of SGP".  I encourage you to lend your support for this ASPIA Ack
proposal.  It provides a more failure-related mechanism which might
replace the need for SNMM at the SGP level and would allow the SNMM
message to be brought back to the SG level.
> 
> > > 4) Format of Routing Label/SIO in DATA message.     
> > 
> > We don't seem to have reached any agreements
> > on this issue so far, although there has been
> > some discussion.
>  
> [John] I would rather not fool around with the existing SS7 RL/SIO at this
> point.  Changing it will mean that at least one system (maybe two) will have
> "waste" processing time to reformat it into the form that the MTP-users or
> SS7 network expects.

This statement is not supported.  The vast majority of MTP Users cited
in the WG pass RL parameters as agruments of the MTP-TRANSFER primitive.
On the contrary, leaving it as packed (which was never agreed to) pushes
variant specifics into the majority of M3UA ASP implementations where
none are required.

> It would also mean that systems that want to do
> routing on RC instead of RL will not be able to just pass the messages off
> to the users without processing the routing information.

The SG must format other M3UA parameters before sending the M3UA DATA
message to its peer, it is aware of the RL format at the time that it
is applying the RK to determine the RC.  It is a trivial matter for
the SG to place the RL contents into an unpacked format in the DATA
message at this time.  It removes the remaining variant specific
dependencies from the M3UA at the ASP.

Perhaps we should continue this discussion on the existing thread.

> > > 7) Change-over / Change-back support.            
> > > Status: Open
> > 
> > Have not seen any discussion on this.  Shall we
> > close the issue?

A BEAT procedure can be used for Changeback.  I understood that
Greg was interested in describing the procedure in the draft.
There is nothing which precludes one from using this procedure
in the current draft.

Changeover between ASPs during failover in either override
or loadsharing mode as a result of the ABORT of an SCTP
association has not been adequately addressed in the draft.
It has not been shown how, in terms of the capabilities made
available by SCTP, the SG and ASP are going to avoid either
message loss or duplication in either the single for multiple
SG cases.

A proposal for a Corelation Id and Ack procedure which would
accomplish smooth changeover was dismissed by Greg earlier as
"not necessary" for M3UA.  Either the Corelation Id and Ack
procedures is included in M3UA or the changeover issue remains.

I think that it is pretty much up to Greg to show why
Correlation Id/Ack is not required: its use for removing
abiguities in the SCTP retransmit buffer and holding copies
of cleared messages not processed by the ASP are clear.

Shall we start a new thread to discuss Issue 7?

> > > 10) User Part Unavailable support - STP-mode, SEP
> > > Mode
> > > Status: Open
> > 
> > Have seen (I think) some email against UPU support.
> > Any further comments?
> 
> [John] What is currently in the spec. is wrong.  It is the local M3UA's job
> to detect when an MTP-user is unavailable.  In this case, the local M3UA
> must generate the DUPU to be returned to the node that sent the message that
> encountered the condition.  It is the SG's job to convert the DUPU to a UPU
> if it is destined for the SS7 network or pass it on if the destination is
> another M3UA node.  The SG must also intercept UPUs from the SS7 network and
> convert them into DUPU messages.  In the case of partitioned end-nodes,
> these nodes should consider NOT generating the DUPU because it could shut
> off traffic for the entire node, not just the affected partition.  It should
> be made OPTIONAL for the generation of DUPU at SS7 over IP end-nodes.  It is
> the acceptance of UPU/DUPU that is required.

I think we are all agree that DUPU needs for some configurations to be
sent from ASP to SG.  All that is required is some explanatory text to
clarify this.  Francois has proposed some text lately which does not
impose any implementation restrictions.  If it is augmented by an
explanation that the SG may invoke user part flow control procedures
upon receiving DUPU I think we are done here.  With Francois' text as
a starting point, I'm sure we can leave it to Greg's capable hands to
smith the words and find a place in the overview to include them.

Can we move this to Agreed/Closed? (Text to be added).

> 
> > > 11) IPSP cases supported or not.                    
> > > Status: Open
> > 
> > Seems to be no strong interest in changing
> > the text.  Further comments?
>  
> [John] Strongly support the IPSP and non-backhaul scenarios being contained
> in M3UA.

I agree with John.  We still need to describe how IPSPs interact in some
situations where it is not apparent from SG/ASP operation.  Examples which
include IPSP operation would still be helpful (I think Maria-Cruz proposed
some).

John, can you propose some enhancements to the draft which would better
clarify IPSP operation?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 24 Aug 2001 15:29:16 -0500

....resend

John,

--brian

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

---