Subject: Re: [Sigtran] m3ua- IG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 10 Jan 2003 16:11:37 +0200

Brian,

[...snip...]
> [TOLGA] This is responsibility of SCCP. M3UA-ASP will just delºver the
> messages to the corresponding entity, taking care of traffic for the AS,
> corresponding to RC in the message.

But the only reason for using SSN RK is because SCCP is partitioned
over multiple ASPs.  How can ASP get SCCP management messagess to
the correct SCCP user without knowing where they appear?
[TOLGA] It is not M3UA-ASPs responsibility to toute messaegs to SCCP-Users.
M3UA-ASP will deliver the message to the correct SCCP entity based on RC.
The rest belongs to SCCP itself.

[..snip...]
> [TOLGA] I consider it ot as the same DATA replicated to multiple
> destinations but as a SCCP management message replicated by the
management
> functionality on SG. But still I proposed in my former message a new
> sentence to clarify this. I think it should be enough to address your
this
> concern.

No it is not.  You must say which messages are to be duplicated,
how, and to which ASPs in which AS.
[TOLGA]Maybe just one more sentence:
"The filtering/generation of managament messages happens on the protocol
layer, the RK type is construct of. This filtering/generation must be based
on the information in the relevant protocol specification to build a global
view of the corresponding protocol entity."

[...snip..]
> [TOLGA] ASP does not need to know/care what is going on with SCCP. It
just
> cares about RC in the message and delivers it to the corresponding user
> based on that.

If that were the case, there would be no need for RK on SSN in the first
place.  It is only by nature of the fact that SCCP users could be split
over ASPs that the RK would be necessary at all.  So, the ASP needs to
know/care what is going on with SCCP.
[TOLGA]M3UA-ASP will route just based on RC. Why should it do more?

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Jan 2003 08:13:46 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 10 Jan 2003 16:11:37)
> The rest belongs to SCCP itself.

But which SCCP management messages are arriving on which RC?

> view of the corresponding protocol entity."

Which messages are to be generated by SG and which by AS?  Which messages
will be intercepted and handled by SG and which are to be passed transparently
to AS?

> 
> 
> 
> [...snip..]
> > [TOLGA] ASP does not need to know/care what is going on with SCCP. It just

Which RC are the messages arriving?  It seems to be different for your
solution (which is broken) and Valerie's and Joe's.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 05:24:42 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> TOLGA ASVEREN wrote:                                
>                                 (Fri, 10 Jan 2003
> 16:11:37)
[TOLGA] Each AS will receive the necessary management
messages. Now you might ask, which ones are
"necessary"? As I said, for this one has to look to
the relevant specification. There is no
interoprability problem, let me explain why for the
SSN case just as an example. The goal is to
interoperate with a M3UA compliant ASP which has a
SCCP stack compliant with relevant specification.So we
have a regular M3UA and SCCP on ASP and we don't want
to touch them and to assume any special behavior from
them. Now, for each AS(which is based on DPC+SSN), SG
will send management messages sent for this SSN and
also management messages sent for the whole
SCCP(requires duplication of SCCP message in this
case). This IMO is not something to be described in
M3UA RFC. Did we put any extra requirement to M3UA on
ASP, or on any M3UA procedure or on SCCP on ASP side?
And the decision how to implement the managemnt
functionality was based just on SCCP specification
itself. 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 07:10:30 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 05:24:42)
> functionality was based just on SCCP specification

Say there are 8 ASPs in the AS.  Take one SCCP management
message: SST.  You send SST once to each ASP.  Each ASP
with a compliant SCCP will return one response (say SSP).
The distant end will receives 8 SSPs for each SST sent.
This is a violation of SCCP specifications.  Your
implementation is broken.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 08:54:46 -0800 (PST)

Brian,
wrote:
> Tolga Asveren wrote:                                
>                                 (Sat, 11 Jan 2003
> 05:24:42)
> > >                                 (Fri, 10 Jan
> 2003
> > > > > [TOLGA] This is responsibility of SCCP.
> M3UA-ASP
> > > will just delºver the
> > > > But the only reason for using SSN RK is
> because
> > > SCCP is partitioned
> > > > the correct SCCP user without knowing where
> they
> > > appear?
> > > > M3UA-ASP will deliver the message to the
> correct
> > > SCCP entity based on RC.
> > > But which SCCP management messages are arriving
> on
> > > which RC?
[TOLGA]This is the reason why you have the management
functionality on SG. You get the responses and create
the global view of the corresponding subsystem. Not
all of the SSP is sent to SS7 network, only one.

---

From: [email-masked]
Date: Sat, 11 Jan 2003 12:05:22 -0500 (EST)

Brian/Tolga,
 Reading your discussion I have few thoughts/comments -
Are we not trying to violate principles of layered protocol here by trying 
to change M3UA to make distributed SCCP work. The point is we should 
not try to change M3UA behaviour to satisfy needs of M3UA user.
We should not assume how M3UA users will be distributed for example based 
on SSN or not. It is responsibility of distributed SCCP to handle 
possibilities of receiving SCMG messages for a given SSN on one or more 
ASP's. This can be easily acheived in implementation specific way. 
For example if we distribute single SSN across two ASP's then there is 
possibility of receiving TCAP response on wrong ASP. But M3UA should not 
be responsible for resolving this. This can be resolved in implementation 
specific way.
-Narender

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 09:22:29 -0800 (PST)

Narender,
> Are we not trying to violate principles of layered
[TOLGA]I also would think this is against the spirit
of a layered approach. But with any non-MTP3 RK type
it is obvious that one has to dig in to the payload of
a message to reach the corresponding protocol part.
Not nice, but as long as there is no functional
problem, still I would think as doable.
> not try to change M3UA behaviour to satisfy needs of
[TOLGA] For that I disagree. I said several times, it
is mandatory not to bring interoperability problems
while implementing necessary management functionality
to be able to handle non-MTP3 RKs. Such a managemnt
functionality would not change any M3UA behaviour at
all. 
> possibilities of receiving SCMG messages for a given
[TOLGA] What you say is a possible way of doing things
and for most of the cases probably the better one. But
IMO there is no reason to put a restriction. 
> resolved in implementation 
[TOLGA] This won't create a problem. If you distribute
single SSN across two ASPs, this means tere is a
single SCCP entity on those ASPs. So, it doesn't
matter where the TCAP response is sent.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 10:38:47 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 08:54:46)
> all of the SSP is sent to SS7 network, only one. 

Not all the responses necessarily go through the same SG.

Still broken.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 10:40:04 -0700

Tolga,

> all of the SSP is sent to SS7 network, only one. 

In fact, the responses don't necessarily go through
the SG at all.  SCCP can use another network appearance
which is directly connected to the SS7 network to send
the message back.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 10:41:26 -0700

ngoel,

[email-masked] wrote:                                            (Sat, 11 Jan 2003 12:05:22)
> be responsible for resolving this. This can be resolved in implementation 

Or in a standard way using SUA.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 10:42:28 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 09:22:29)
[snip]
> matter where the TCAP response is sent.

Huh?  Is your M3UA SG handling transactions state now too?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 10:45:41 -0700

Tolga,

> > 
> > Say there are 8 ASPs in the AS.  Take one SCCP management message: SST.
> > You send SST once to each ASP.  Each ASP with a compliant SCCP will return
> > one response (say SSP).  The distant end will receives 8 SSPs for each SST
> > sent.  This is a violation of SCCP specifications.  Your implementation is
> > broken.

M3UA supports multiple SGs.  How is one SG to know that
the other has sent SSP?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 10:49:15 -0700

Tolga,

> all of the SSP is sent to SS7 network, only one. 

Now tell me how SOR/SOG is going to work.  Particularly when it
is for a subsystem with mated point codes both served by multiple
SG acting as STP.  They are signalling each other.  There are 8 ASPs
per AS on both point codes.  The algorithm can have no races and must
handle ASP failure and AS deactivation in the middle of the procedure
(or it will violate SCCP specifications).

--brian

---

From: [email-masked]
Date: Sat, 11 Jan 2003 13:08:47 -0500 (EST)

On Sat, 11 Jan 2003, Tolga Asveren wrote:
Tolga,
 My response is inline.
> problem, still I would think as doable.
[Naren] There is a basic problem of taking a piece meal approach.
 We do not know what a M3UA user can do and we cannot limit the M3UA-user 
to a given set of behaviours. It might be possible to satisfy needs of 
SCMG but what about Connection Oriented SCCP. SCOC is not state less as is 
SCLC and there and many more issues involved with it, like sharing 
connection cotext across ASPs and handle connection inactivity,
handling error messages. But all these can be resolved in implementation
specific ways and better left to the implementation. 
> matter where the TCAP response is sent.
[Naren] Unfortunately TCAP is not stateless protocol. It is
important to share TCAP context to take advantage of 
distrbuted design of M3UA/sigtran stack. Even though M3UA
 spec is not expected to provide solution to this problem.
-Narender

---

From: [email-masked]
Date: Sat, 11 Jan 2003 13:28:32 -0500 (EST)

On Sat, 11 Jan 2003, Brian F. G. Bidulock wrote:
Brian,
 SUA spec is does bot describe clearly how to handle SCOC and may not be 
better solution overall.
I believe it may be better if we general set of guidelines for M3UA users 
without assuming specific M3UA user like SCCP/ISUP/TUP etc. The main 
issues with distributed sigtran user are -
1. Sharing to user state/context across distributed ASPs.
2. Handling of broadcast messages.
Any any other generic behaviour that everyone agrees and try to present a 
common solution to the user and not link the solution to a specific 
protocol.
-Narender

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 12:04:05 -0700

ngoel,

SUA clearly describes handling of connection oriented messages.  SCOC is
a SCCP protocol state machine that resides below SUA in a standard SCCP.
The SCOC for SUA is precisely the SCOC of Q.714, ANSI T1.112.4, etc.
It does not need any description in the SUA standard because it is adequately
described in the SCCP standards.  SUA is designed to export the SCCP/SCCP-User
interface, not to replace SCCP state machines.

--brian

[email-masked] wrote:                                            (Sat, 11 Jan 2003 13:28:32)

---

From: [email-masked]
Date: Sat, 11 Jan 2003 14:29:21 -0500 (EST)

On Sat, 11 Jan 2003, Brian F. G. Bidulock wrote:
Brian,
 Some of the problems with SCOC and SUA are -
1. Routing context is mandatory in SUA messages. SUA has DPC/SSN routing 
keys. SCOC DT1 message does not contain SCCP addressing information. It is 
not trivial to find the RC for a incoming DT1 at the SG. Do we mantain 
connection context at SG and no connection context at ASP level? Can a SUA 
user allocate or delete connection context? Or these functions be RPC 
calls which are implemnentation dependent? Does any SCCP Connection 
Oriented functionality is required on ASP  side in addition to what is 
defined in SUA draft. 
2. Problem similar to shring connection state. If one ASP sends a Connect 
Request what is the gurantee the same will receive Connection Confirm. 
This is much easier to handle with SCCP/M3UA. I think there are much more 
implementation dependent issues with SUA.
-Narender

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 12:46:35 -0700

ngoel,

[email-masked] wrote:                                            (Sat, 11 Jan 2003 14:29:21)
> 1. Routing context is mandatory in SUA messages.

That is not a problem.

> SUA has DPC/SSN routing keys.

SUA has AMF (Address Mapping Function).  SUA has can route on GT and
can even route on SLR/DLR.

> SCOC DT1 message does not contain SCCP addressing information.

DT1 has SLR/DLR.

> It is not trivial to find the RC for a incoming DT1 at the SG.

It is trivial: lookup on DLR.

> Do we mantain connection context at SG and no connection context at ASP
> level?

Connection context is referenced both at SG and ASP by DPC/DLR.

> Can a SUA user allocate or delete connection context?

Allocated with CORE/COAK, deallocated with RELRE/RELCO.

> Or these functions be RPC calls which are implemnentation dependent?

Not implementation dependent.  Completely within the context of SCCP.

> Does any SCCP Connection Oriented functionality is required on ASP  side in
> addition to what is defined in SUA draft. 

No.

> Request what is the gurantee the same will receive Connection Confirm. 

Base on the local reference in the CR.  SG sends CC to correct ASP.

> This is much easier to handle with SCCP/M3UA.

Very wrong.

> I think there are much more implementation dependent issues with SUA.

I think you just don't have a good understanding the SUA standard yet.

There are no issues other than DRN Label with multiple SGs under failure.
draft-bidulock-sigtran-regext-01.txt submitted to the I-D editor several days
ago which provides better solution for multiple SG case than DRN Labels.  You
can pick up a copy at

	http://www.openss7.org/sigtran01.html

until it appears on the I-D server.

But I think you should take some time to read carefully through the SUA spec,
ask some questions, and understand it well before making such sweeping
statements.

--brian

---

From: [email-masked]
Date: Sat, 11 Jan 2003 14:46:58 -0500 (EST)

> a SCCP protocol state machine that resides below SUA in a standard SCCP.

[Naren] Are you suggesting both SUA and SCCP should be present on ASP 
side?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 12:57:38 -0700

ngoel,

[email-masked] wrote:                                            (Sat, 11 Jan 2003 14:46:58)
> [Naren] Are you suggesting both SUA and SCCP should be present on ASP 

SCCP only needs to be present on SG side.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 12:03:50 -0800 (PST)

Brian,
[...snip....]
> Not all the responses necessarily go through the
[TOLGA] We were already here I think. The solution is
simple, do not use multiple SG configuration, which
anyhow is a strange mode of operation (multiple MTP3
logic for the same PC, working independently)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 13:17:39 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 12:03:50)
> logic for the same PC, working independently)

M3UA can support MTP3 routing keys on multiple SG.

Besides, its still broken.  How do you handle subsystem
congestion?

Also, you have race condition with your correlation of
SSP messages.  One ASP can issue SSA before the SSP
has arrived from other ASP.  Like so:

ASP1   SSA ----- SSP                            SGP1
ASP2                        SSA ----- SSP       SGP2
ASP3              SSA ----- SSP                 SGP3
ASP4         SSA ----- SSP                      SGP4
ASP5                             SSA ----- SSP  SGP5
ASP6                  SSA ----- SSP             SGP6
ASP7            SSA ----- SSP                   SGP7
ASP8                         SSA ----- SSP      SGP8

The SCCP thinks it has sent SSP followed by SSA.  The
SG receives:

  SSP, SSP, SSP, SSA, SSP, SSA, SSA, SSP, SSP, SSP,
  SSA, SSA, SSP, SSA, SSA, SSA

Some are responsive to SST, some are broadcast.  What
will the SG send?  Also note that SCCP management
messages are not send on the same SLS, so some of these
can get reversed in between ASP and SGP.

Your algorithm falls flat on its face because it
cannot tell the different between respones to SST and
broadcast messages (it is not contained in the message).

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 12:18:48 -0800 (PST)

Brian,
wrote:
> 09:22:29)
[TOLGA] Why do you think this? If ASPs are working in
loadshare mode for an AS, their corresponding user
parts are synchronized.
And let's say SG keeps also some TCAP info. Why would
M3UA care about this? The point I am trying to make
from the very beginning of this discussion is, please
don't try to put restrictions on SG itself, leave it
free as long as it is compliant with M3UA. But you
just focus on the specific SSN RK case and try to
finish a design for a implementation dependent
management functionality which can be used to be able
to support SSN based RKs on SG.

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 12:24:55 -0800 (PST)

Narender,
--- [email-masked] wrote:
> > > Are we not trying to violate principles of
> layered
> > > protocol here by trying
[TOLGA] The main topic of this thread is non-MTP3 RK
types, so SSN based RKs are just an example. And for
that, I think at the very beginning I mentioned that
the management functionality we discuss is only about
class0/class1 SCCP (then Brian also added no GTT
routing)
My goal is not to modify M3UA to use SSN based RKs,
but the leave the way open -as long as it does not
bring interoperability problems- for non=MTP3 RK
types.
> 
> > > to change M3UA to make distributed SCCP work.
> The
> > > point is we should 
> > > not try to change M3UA behaviour to satisfy
> needs of
> > > M3UA user.
> > > on SSN or not. It is responsibility of
> distributed
> > > SCCP to handle 
> > > possibilities of receiving SCMG messages for a
> given
> > > SSN on one or more 
> > > ASP's. This can be easily acheived in
> implementation
> > > specific way. 
> > > For example if we distribute single SSN across
> two
> > > ASP's then there is 
> > > possibility of receiving TCAP response on wrong
> ASP.
> > > But M3UA should not 
[TOLGA] If one uses ASPs in loadsharing mode for soem
AS, then the corresponding user parts should work as a
single entity. So, TCAP context will be shared, but
this is responsibility of TCAP itself.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 13:25:26 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 12:18:48)
> loadshare mode for an AS, their corresponding user

Synchronization is costly and you cannot normally
strew pieces of transactions across processors.

> free as long as it is compliant with M3UA.

I would also like to see it compliant with MTP Level 3
as well and allow MTP User to be compliant with their
specifications.  All that you have proposed is to break
the MTP-User (and the SS7 network) for the cause of
keeping flexibility.  Flexibility at the cost of
interoperablity is not the IETF way.  Rigidity for the
sake of interoperability is.

> But you just focus on the specific SSN RK case and try to

Because there is no evidence that any such implementation
dependent management function can be made interoperable.
And, because of that, it needs to be restricted from the
specification to follow IETF principles.

You keep claiming that such an implementation exists: but
you have not presented one.  Lacking a single example of 
an interoperable implementation, exclusion is the only
course.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 13:38:07 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 12:24:55)
> class0/class1 SCCP (then Brian also added no GTT

You can also add no multiple SG.

Also, no routing on SSN=0 (which will break Valerie's
approach), or do we allow that and break Tolga's approach?
You see they are not interoperable.

It think you will have to add no mated subsystems, because
Tolga doesn't have a SOR/SOG solution.

Also, I think you will have to share transaction state
in real-time (effectively makine it one big ASP) because
Tolga's approach cannot get transactions back to the correct
place.

Oh, and no congestion controls, because Tolga's approach
cannot handle SCCP congestion.

Oh, and one should mention that one shouldn't use load-sharing
or broadcast because race conditions at the SG will break SCCP
conformance.  And the ASP should send messagses to only one SGP
to avoid races between SGP.

And you could have load-shared over SSN instead of routing
on SSN in the first place a nothing would break.  But Tolga
wants to encourage non-interoperable solutions where
interoperable ones exist (loadsharing on SSN).

> bring interoperability problems- for non=MTP3 RK

It brings interoperablity problems.  Just use loadsharing
on SSN instead of routing.  Routing on SSN should be
prohibited by the specification.

--brian

---

From: [email-masked]
Date: Sat, 11 Jan 2003 16:01:19 -0500 (EST)

> It is trivial: lookup on DLR.
State machine is duplicated on SG and ASP.
> > addition to what is defined in SUA draft. 
How about context management? What if SUA is acting as a internudiate on 
ASP with IPSP. Are you saying this cannot happen. I think you need to 
SCCP spec. Don't you think these cases can be much better handled by 
SCCP/M3UA.
> > This is much easier to handle with SCCP/M3UA.
Why? How can you say SUA is better solution than M3UA/SCCP.
> until it appears on the I-D server.
I am talking about SUA draft not indvidual submissions.
> ask some questions, and understand it well before making such sweeping
Sometime  back in our earlier discussion you yourself agreed that SUA was 
weak in supporting CO and also you mentioned that AMF was not clearly 
described. I don't know if things have changed much in SUA draft since 
then. You can check the mailing list on that.
I am not making any aweeping statements nut only saying that 
IMO SCCP/M3UA better capturees SCCP Connection Oriented functionality in 
sigtran world.
-Narender

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 13:11:17 -0800 (PST)

Brian,
wrote:
> 12:03:50)
> > > > the global view of the corresponding
> subsystem.
> > > Not
[TOLGA] I think supporting multiple SG case is
optional. And I wouldn't consider not supporting it as
a modification to M3UA protocol but just as not
supporting one type of configuration.
> Besides, its still broken.  How do you handle
[TOLGA] What is specail about it? How different it is
from congestion of signalling point case for ANSI
networks when multiple SGs are used? Again management
logic decides, when to declare the subsystem as
congested.
> can get reversed in between ASP and SGP.
[TOLGA] For the ones which are not sent on the same
SLS, isn't there also the possibility that they get
missequenced in the TDM based SS7 network?
Although all of those are questions about the
implementation dependent part and are not related with
M3UA, still I would think:
For your scenario, SG would respond with SSA if it has
received one SSA from one ASP -and if it didn't
received SSP from it afterwards-, before the timer it
started after receiving SST, expires.

> broadcast messages (it is not contained in the
[TOLGA] Again my answer for the non-M3UA part:
Management logic on SG keeps global SSP states. When
this state is changed based on a message received from
an ASP, it can be considered as an event to be broadcasted.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 14:23:18 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 13:11:17)
> supporting one type of configuration.

MTP3 RKs are supported on multiple SG.  You will need
a statement saying the your SSN RKs are not supported
on mutliple SG (amoung other things).

> logic decides, when to declare the subsystem as

Subsystem congestion is implementation dependent and
resides on the ASP.  The SGP cannot know the algorithm
and cannot correlate multiple congestion messages from
multiple ASPs.

> missequenced in the TDM based SS7 network?

Only during failures or congestion (which almost never occur).
With your solution, because of the way SCTP treats streams,
it will occur as in normal operation with no failures.  This
will fail conformance tests.

> started after receiving SST, expires.

But SSA and SSP can get reversed by SCTP, them being on
different streams and even different associations to
different SGP.  Therefore, your algorithm is often wrong
in the normal course of affairs and cannot be shown to
meet SCCP conformance.  Your are breaking the MTP User by
mucking with its messages.

> an ASP, it can be considered as an event to be broadcasted.

You cannot tell at the SG, only at the ASP.  Which was the
response to SST?  The SSA's above or the SSP's?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 14:28:36 -0700

ngoel,

[email-masked] wrote:                                            (Sat, 11 Jan 2003 16:01:19)
> State machine is duplicated on SG and ASP.

No state machine duplication.  State machine resides on SG.  ASP merely
passed messages based on DRN to the correct connection.  ASP does not
need connection state machine.  SG exports SCCP-User connection interface
to AS.

> SCCP spec. Don't you think these cases can be much better handled by 

It am speaking of SG/ASP, not relay.  Relay is prohibited in M3UA by the RFC.
It cannot handle it at all.  SUA has relay built in.

> Why? How can you say SUA is better solution than M3UA/SCCP.

How can you say M3UA/SCCP is better solution than SUA?

> then. You can check the mailing list on that.

Weak on DRN Labels for multiple SG as STP case.  Tolga can't even get class 0
working on multiple SG for M3UA, so SUA is still far superior.

> IMO SCCP/M3UA better capturees SCCP Connection Oriented functionality in 

M3UA does not capture it at all.  M3UA cannot support class 2 or 3 routing
keys.  SUA can.

--brian

---

From: [email-masked]
Date: Sat, 11 Jan 2003 17:05:58 -0500 (EST)

> need connection state machine.  SG exports SCCP-User connection interface
How SG exports user connection interface. Is it specified in draft? If not 
this is a weakness/grey area.
> It cannot handle it at all.  SUA has relay built in.
I don't know why m3ua will need to perform relay here. In this case relay 
will be done by SCCP which is very well defined in SCCP spec.
> working on multiple SG for M3UA, so SUA is still far superior.
I need to catch up with what tolga is doing in this case. But I don't 
understand how M3UA is preventing SCCP functions. M3UA definition should 
not depend on its user. But IMHO we should not try to define things which can 
be done in implementation dependent way and do not hurt interoperability. 
 
> M3UA does not capture it at all.  M3UA cannot support class 2 or 3 routing
I don't understand why m3ua needs to support SCCP specific routing 
key. We had class 2 working with M3UA with no 
problems. How can M3UA impose limitations on SCCP functionality. If this 
is the case then may be SCCP needs to be fixed. But I don't think that is 
the case.

-Narender

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 11 Jan 2003 14:33:10 -0800 (PST)

Brian,

Again some answers/questions below although I really
believe this is misuse of the SIGTRAN WG list, because
IMO those things are not related with M3UA, we are
discussing some hypothetical implementation dependent
functionality. For example, if a SG claims to support
RKs based on called party number just for
query/response scenarios, do you think this is the
place to discuss it? 
So, as a final word I want to say that I think RKs
should be kept flexible, as they are now. I don't see
a problem by removing SSN from examples, as they migth
bring some confusion.

[...snip...]
> on mutliple SG (amoung other things).
[TOLGA] Yes this should be stated, but IMO not in M3UA
RFC but in the product specification of the SG itself.
For example there one can say that one just supports
single SG configurations, or just query/response
scenarios, only class0/class1 SCCP in case of SSN RKs
etc.... Personally I don't consider those things as
violation of the protocol, but just as limitations of
a specific SG.

[...snip...]
> and cannot correlate multiple congestion messages
[TOLGA] IMO this is really very similar to the
signalling point congestion case for ANSI networks in
multiple SG case. The nodes decides by themselves,
when they are congested. And SG decides in an
implementation dependent way, what to do.

[..snip...]
> will fail conformance tests.
[TOLGA]Why only during failures? Maybe for those
different SLS, they are follwoing different STPs on
their way to the peer SCCP. 

[...snip...]
> response to SST?  The SSA's above or the SSP's?
[TOLGA]Important is, that SG knows that there is a
pending SST to be replied and when the corresponding
timer expires, it replies based on the global view of
the subsystem. And any SCCP management message
received from ASP, which changes global subsystem
state is sent to its destination.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 16:27:47 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Sat, 11 Jan 2003 14:33:10)
> query/response scenarios, do you think this is the

I think that M3UA routing keys should be restricted
to MTP L3 information and then there would be no need
to discuss interoperability of these solutions.

An IETF WG is a proper place to discuss interoperability.

> violation of the protocol, but just as limitations of

No SG can support these things in an interoperable
fashion.  This is not just restricted to a specific
SG or a specific implementation.  No implementation
can support them and interoperate.

> implementation dependent way, what to do.

That is different: nodal TFC is optional even in ANSI.

Congestion is not optional in SCCP management.

> their way to the peer SCCP. 

In the absence of failures and congestion they will
not be reversed.

> state is sent to its destination.

SST responses and broadcasts can occur close enough
together that your timer (which violates SCCP conformance
in itself) cannot tell the difference between them.

I will say again: there is a correct way to do this
in M3UA with load-sharing on SSN.  Routing keys using
SSN are not interoperable, but load-sharing on SSN is.

Routing keys should be restricted to MTP L3 information
only.  Load-sharing can be performed on any criteria
because the rule is that every ASP in a load-share AS
must be prepared to processs any message.  Therefore,
the SG can send management messages, messages not 
containing SSN, to whichever ASP in the load-share AS
is likes and the ASP must be prepared to process it.

So: loadsharing on SSN, CIC, color, smell of the message,
is interoperable.  Routing keys are not.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Jan 2003 16:39:08 -0700

ngoel,

[email-masked] wrote:                                            (Sat, 11 Jan 2003 17:05:58)
> this is a weakness/grey area.

Please read the spec:

    1.4 Services Provided by the SUA Layer 
    
    1.4.1 Support for the transport of SCCP-User Messages 
    
       The SUA supports the transfer of SCCP-user messages. The SUA layer 
       at the SG and at the ASP support the seamless transport the user 
       messages between the SG and the ASP. 
    
...

    1.6 Definition of SUA Boundaries 
 
    1.6.1 Definition of the upper boundary 
    
       The following primitives are supported between the SUA and an SCCP-
       user (a reference to ITU and ANSI sections where these primitives 
       and corresponding parameters are described, is also given): 
    
       Generic     |Specific  |  
       Name        |Name      |ANSI/ITU Reference                           
       ------------+----------+-------------------------------------------  
       N-Connect   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)     
		   |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)  
		   |Response  |  
		   |Confirm   |  
       ------------+----------+------------------------------------------- 
       N-Data      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)     
		   |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)  
       ------------+----------+------------------------------------------- 
       N-Expedited |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)     
       Data        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)  
       ------------+----------+------------------------------------------- 
       N-Reset     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)     
		   |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)  
		   |Response  |  
		   |Confirm   |  
       ------------+----------+------------------------------------------- 
       N-Disconnect|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)     
		   |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1) 
       ------------+----------+------------------------------------------- 
       N-Inform    |Request   |ITU-Q.711   Chap 6.1.1.3.1 (Tab 7/Q.711)     
		   |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1) 
       ------------+----------+------------------------------------------- 
       N-Unit Data |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 10/Q.711)    
		   |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1) 
       ------------+----------+------------------------------------------- 
       N-Notice    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 11/Q.711)    
		   |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1) 
    
> will be done by SCCP which is very well defined in SCCP spec.

SCCP cannot relay for an SCCP-User without also performing MTP transfer.
MTP transfer requires STP functionality.  M3UA forbids STP functionality
at the M3UA IPSP.  M3UA IPSPs are point-to-point only.  M3UA cannot
support SCCP relay.

> be done in implementation dependent way and do not hurt interoperability. 

What things are those?

> is the case then may be SCCP needs to be fixed. But I don't think that is 

All classes work with SUA with no problem.

M3UA imposes limitations on SCCP functionality by being unable to
support MTP transfer at the IPSP, making it impossible to support
SCCP relay on an M3UA IPSP or ASP.  SUA supports SCCP relay on both
IPSP and ASP.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Mon, 13 Jan 2003 04:29:54 -0600 (CST)

Hi,

So the concensus was M3UA can not be used effectively between
STP(SG) to SCP(AS) -- unawareness of SSN

can not be used effectively with MGC- unawareness of cic

now i have a doubt , Where M3UA can be used effectively?

any node which routes messae on DPC- here it is used , thats all?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Jan 2003 03:51:50 -0700

Samuel,

DPC, DPC/SI, even OPC/DPC, OPC/DPC/SI.

But don't forget that the SG can easily Load-Share on CIC, SSN,
DLR/SLR, TID, etc.  We have just been talking the use of Routing
Keys (which are 1:1 with the definition of the AS).

So we are saying that it doesn't make too much sense to split
Application Servers into sub-SI Application Servers.  SGs are
worried about point code status and user part status and don't
care about things like subsystem status.  Having Application
Servers (remember, defined by Routing Keys) that are either
point codes or user parts therefore makes a lot of sense.

But *within* an Application Server there can be multiple ASPs
serving the AS.  Load-sharing permits some messages to be sent
to some ASPs and other messages to be sent to others.  With an
extension such as draft-bidulock-sigtran-loadsel-01.txt or
draft-bidulock-sigtran-loadgrp-01.txt the ASP can even be under
control of which range of traffic it receives.  With a Broadcast
AS, the ASPs are in control over which messages it chooses to
process and which it does not choose to process.

So, to summarize, using Load-Share or Broadcast Application
Servers, everyting that one thought could be accomplished with
sub-SI granularity Routing Keys, is possible with Load-Sharing.
It, however, does not mess up the SG's view of PC and SI state
and is therefore interoperable.

Sub-SI RKs are just the wrong solution for the wrong problem.
Load distribution with Load-sharing or Broadcast is the
proscribed way of distributing traffic over multiple ASPs.

So, we should remove SSN and CIC from Routing Key (even restrict
RK to not have non-MTP3 RKs) and yet, keep the sections where
they are mentioned for load-sharing.  This gives maximum
interoperability without sacrificing any functionality.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Mon, 13 Jan 2003 04:29:54)

---

From: "Narendar Goel" <[email-masked]>
Date: Mon, 13 Jan 2003 10:34:43 -0500

Brian,
 I agree adding sub SIO routing keys is not a good ides at m3ua level. But
loading sharing traffic based on SSN, CIC or TID is only one possible
solution
to the problem of destributing application traffic. One of the other
possible
solution is using distributed shared memory (DSM) for sharing context among
ASPs. This DSM approach is simpler in certain implementation conditions. DSM
solution provides truly distributed and fault tolerant application server.

-Narender

~
~

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Monday, January 13, 2003 5:52 AM
To: Samuel Dur D. Jeyaseelan
Cc: [email-masked]
Subject: Re: [Sigtran] m3ua- IG

Samuel,

--brian

Samuel Dur D. Jeyaseelan wrote:
(Mon, 13 Jan 2003 04:29:54)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Jan 2003 15:25:10 -0700

Narendar,

Yes, loadsharing on CIC, SSN should not be mandatory.  ASP can use
other communications mechanisms (e.g. a ASP-ASP protocol) to transfer
messages to the correct place.  Also, there is broadcast mode where
each ASP gets each message and the ASP itself can decide which messages
to process and which to leave for other ASPs.

--brian

Narendar Goel wrote:                                                              (Mon, 13 Jan 2003 10:34:43)

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Tue, 14 Jan 2003 00:54:55 -0600 (CST)

Brian,

section A.2.2

   .............................................The distribution of
   the MTP3-user messages over the SGPs should be done in such a way to
   minimize message missequencing, as required by the SS7 User Parts.

How ASP sends message to SGP?

 The point codes ASP has registered , only to those point codes
 ASP can generate messages?

 or 

ASP can send message to any point codes (which even he has not
regsitered)?

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Jan 2003 00:49:17 -0700

Samuel,

The Routing Context identifies a traffic flow (in both directions).  In
general an ASP should not send traffic for a Routing Context to point codes
from which it cannot receive traffic for the same Routing Context.

This is only an issue for non-MTP-SAP routing keys.  MTP-SAP routing keys
are those which identify either a complete signalling point (DPC) or which
identify an MTP-User at a signalling point (DPC/SI).

For security and screening purposes, an SG cannot be expected to transfer
messages which do not belong to the Application Server.

--brian

Samuel Dur D. Jeyaseelan wrote:                  (Tue, 14 Jan 2003 00:54:55)

---

From: ksrinivas <[email-masked]>
Date: Tue, 14 Jan 2003 14:34:25 +0530

Brian,

   Does the OPC list in the REG Req indicates to the SGP that the AS can send or
receive traffic from these point codes (of OPC list) only?.

If true then, Does the OPC list skipped in the REG Req indicates to the SGP that
the AS can send or receive traffic from any point code?.

--Srini

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Tue, 14 Jan 2003 03:06:04 -0600 (CST)

Brian,

> from which it cannot receive traffic for the same Routing Context.
                                (PC 333)
                                STP/SG-------------------AS
                               |  
                               |  
    NODE-A(PC 111)-------------+
    |
    |  
    +------NODE-B(PC 222)

AS registers PC 111 with SG.

Say NODE-A sends query to PC 333( performs GTT and reaches AS) AS returns
a LRN number to NODE-A.

NODE-A finds that LRN is actually a subcriber of NODE-B
But at NODE-B MTP-restart procedure is going on.

So NODE-A sends TFP(PC 222) to STP.
In this scenario Will SG send DUNA(affected PC 222) to AS?
(note AS is unware of PC 222)

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Jan 2003 03:31:05 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Tue, 14 Jan 2003 14:34:25)
> 
>    Brian,
> 
>        Does  the OPC list in the REG Req indicates to the SGP that the AS
>    can  send  or  receive  traffic  from  these point codes (of OPC list)
>    only?.
> 
>    If  true  then,  Does the OPC list skipped in the REG Req indicates to
>    the SGP that the AS can send or receive traffic from any point code?.
> 
>    --Srini

Yes and yes: that's my understanding.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Jan 2003 03:35:07 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Tue, 14 Jan 2003 03:06:04)
> (note AS is unware of PC 222)

If the AS is unaware of PC 222, it doesn't matter whether the SG
sends it DUNA(222) or not.

--brian