Subject: Re: M3UA07: RC in DATA and SSNM messages

From: Lyndon Ong <[email-masked]>
Date: Tue, 14 Aug 2001 12:06:47 -0700

Brian,

I have no stake in this.  However, as you are the one
proposing to include RC into the messages, it is your
responsibility to convince enough people in the group
to form a rough consensus in favor of your proposal.

This has not been the case, and there is no point
continuing with this thread (BTW again we are overlapping
on the NA thread) unless there is some change.  Given
the length of this discussion to date, there is no reason
to believe that there will be any such change.

You're welcome to lodge a protest, it would not be
the first time :o)

Cheers,

L. Ong
--

On Tue, 14 Aug 2001 13:52:32   Brian F. G. Bidulock wrote:
>Lyndon,
>
>I will not move on.
>
>I object to the lack of RC in DATA messages on the technical
>grounds that it violates the SIGTRAN architecutre and
>introduces interoperability issues into M3UA at both the
>syntactic (RK) and semantic (differences between ITU and
>ANSI MTP/MTP-User semanitcs) levels.
>
>At the M3UA bake*ff in Madrid, most of the chatter the first
>days was whether an implementation supported a ANSI RL or an
>ITU RL.  MTP-Providers and MTP-Users were not even being
>tested.  The syntactic violation was obvious.  Why should an
>M3UA implementation need to be RL specific?  Why should it
>be MTP/MTP-User semantic specific? (Which was also raised
>at the bake*off by Heinz Pratner's question as to whether
>we supported ITU-T semantics at the MTP/MTP-User boundary or
>ANSI semanitcs.)
>
>As it stands M3UA cannot be implemented without MTP protocol
>variant specifics (both syntax and semantic) being embedded
>in the implementation.  This neither promotes interoperability
>nor adheres to the SIGTRAN architecture.
>
>While a proper approach is clear (SUA), M3UA does not address
>these interoperability issues and you might leave no recourse
>but to lodge formal complaint on technical grounds if the WG
>moves the existing draft to IESG.
>
>--brian
>
>Lyndon Ong wrote:                                          (Tue, 14 Aug 2001 11:32:20)
>> Brian,
>> 
>> The issue is resolved, based on rough consensus of the
>> group, against the inclusion of RC.  As I noted, this
>> can be added in future if it really appears to be needed.
>> 
>> SUA is a separate discussion and should be handled
>> as such.
>> 
>> Let's move on, please.
>> 
>> Thanks,
>> 
>> L. Ong 
>> --
>> 
>> On Tue, 14 Aug 2001 13:18:10   Brian F. G. Bidulock wrote:
>> >Lyndon,
>> >
>> >I do not agree.  This issue must be resolved as
>> >implementation depends on it.
>> >
>> >It is also an issue for SUA Last Call whether
>> >SUA needs align itself with M3UA or M3UA needs
>> >align itself with SUA.
>> >
>> >--brian
>> >
>> >Lyndon Ong wrote:                                          (Tue, 14 Aug 2001 11:06:54)
>> >> I'm simply saying that the consensus in
>> >> the group at this time appears to be against the
>> >> RC, and we should move on. 
>> >> 
>> >> Cheers,
>> >> 
>> >> L. Ong
>> >> --
>> >> 
>> >> On Tue, 14 Aug 2001 12:58:24   Brian F. G. Bidulock wrote:
>> >> >Lyndon,
>> >> >
>> >> >John L. indicated that there should be consistency between
>> >> >M3UA and SUA on this matter, and that this was of some
>> >> >importance.  As it stands M3UA sticks out amoungst the UAs
>> >> >and is not consistent with the others in this respect.
>> >> >
>> >> >I would expect that one WG UA could strive for consistency
>> >> >with the others.  M3UA has not.
>> >> >
>> >> >Are you saying that this consistency is of some lesser
>> >> >importance that was originally laid out by John?
>> >> >
>> >> >--brian
>> >> >
>> >> >Lyndon Ong wrote:                (Tue, 14 Aug 2001 10:37:24)
>> >> >>
>> >> >> Folks,
>> >> >> 
>> >> >> We are getting carried away in this discussion.
>> >> >> I see no point in making new proposals every day
>> >> >> for changing this or that parameter in this or 
>> >> >> that UA.  We cannot make progress in this manner.
>> >> >> 
>> >> >> People are welcome to submit their own versions
>> >> >> of UAs to the IETF, and if they wish, they can
>> >> >> submit new versions with new ideas whenever the
>> >> >> urge comes to them.
>> >> >> 
>> >> >> We should be trying to narrow down exactly what
>> >> >> changes we have consensus on to make in the drafts
>> >> >> so that they can get finished.  Please try to 
>> >> >> focus your messages on this goal.
>> >> >> 
>> >> >> Thanks,
>> >> >> 
>> >> >> L. Ong
>> >> >>  
>> >> >
>> >> >-- 
>> >> >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]
>> >> >
>> >> 
>> >> 
>> >> Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
>> >> 
>> >> 
>> >> ---
>> >> You are currently subscribed to sigtran as: [email-masked]
>> >> To unsubscribe send a blank email to [email-masked]
>> >
>> >-- 
>> >Brian F. G. Bidulock
>> >[email-masked]
>> >http://www.openss7.org/
>> >
>> >
>> >---
>> >You are currently subscribed to sigtran as: [email-masked]
>> >To unsubscribe send a blank email to [email-masked]
>> >
>> 
>> 
>> Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
>> 
>> 
>> ---
>> You are currently subscribed to sigtran as: [email-masked]
>> To unsubscribe send a blank email to [email-masked]
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to [email-masked]
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

---
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, 14 Aug 2001 14:22:40 -0500

Lyndon,

And I will continue the dicussion with those who are willing,
resting on the guarantees of the IETF process for an unmoderated
discussion.  If the WG moves M3UA to IESG last call, I may
very well lodge a formal complaint, which I expect will be
dealt with properly under the IETF process.

I do not agree that there is rough concensus to exclude either.

There are three people other than myself who wanted to see RC
in DATA messages and expressed that view on the list.  There
are several (albeit far more vocal) people who object.  There
are a number of people on this thread who have discussed the
technical points, yet who have not expressed an opinion about
excluding it as an optional parameter.

You will have to put it to a Hmmm if you really want to judge
concensus.

--brian

Lyndon Ong wrote:                                          (Tue, 14 Aug 2001 12:06:47)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 16 Aug 2001 18:02:21 +0200

Lyndon,

There is support, from the SUA group (well, me at least). Hopefully I've
made some clear arguments and have avoided to make any assumption on
specific architectures or implementations.

Another reason why I favor the RC instead of NA is that REG procedures could
be used (in the future) for all IP case as well, where network appearance
doesn't come into play. I don't know where M3UA is going to stand in this
case.

In SUA there is the capability to route on any address information (PC, GT,
hostname, IP address) and the possibility of a relay function (scalability
of the SCTP association network, some mobile operators/vendors already
thanked us for this one ;)). With use of RC instead of NA, we can extend the
use of SSNM messages from strictly SS7 interworking to real SUA management
messages, where the affected peer can be an SS7 or IP node.

Best regards,

P.S. I appreciate your efforts for trying to defuse the
last-call-shouting-match. I don't like it, and I'm afraid we'd kill off a
number of good ideas if things get personal ...

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: dinsdag 14 augustus 2001 21:07
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Brian,

Cheers,

L. Ong
--

On Tue, 14 Aug 2001 13:52:32   Brian F. G. Bidulock wrote:
>> >> >To unsubscribe send a blank email to
[email-masked]
>> >> To unsubscribe send a blank email to
[email-masked]
>> >To unsubscribe send a blank email to
[email-masked]
>> To unsubscribe send a blank email to
[email-masked]
>To unsubscribe send a blank email to
[email-masked]

Join 18 million Eudora users by signing up for a free Eudora Web-Mail
account at http://www.eudoramail.com

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 16 Aug 2001 09:22:09 -0700

Gery,

	Your approach might be OK for new servers in a backhaul scenario but
it is just extra stuff in the case were existing SS7 nodes are migrating to
using IP for transport.  In this scenario, we may want to keep our model of
PC routing between the nodes.  Hence, the RK is PC.  Also this is probably
statically assigned.  

I am expecting that if my node wants to support more than one PC for a given
network, the SG only needs to be told how to assign it to a route to my
node.  I do not expect the traffic to be separated for me.  In the case of
multiple networks, my node will either do the connections or if the SG does
it, all I need is a NA for me to separate the traffic.

So please try to look at it from an existing SS7 node/network point of view.

John

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Thursday, August 16, 2001 11:02 AM
> To: sigtran
> Subject: RE: M3UA07: RC in DATA and SSNM messages
> 
> 
> Lyndon,
> 
> >Lyndon Ong wrote:                                          
> (Tue, 14 Aug
> 2001 11:32:20)
> >> >Lyndon Ong wrote:                                         
>  (Tue, 14 Aug
> 2001 11:06:54)
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 17 Aug 2001 10:28:06 +0200

Hi John,

If you don't need separation of traffic, you can do without NA or RC. If you
need separation (multiple networks, whatever), the RC will do better than
NA, although NA might be all you want. RC is not extra stuff, it's the more
general approach and replaces NA where needed in the protocol messages.

Also, from an existing SS7 network point of view, a simple NA might not do.
The message origin might also be important. I don't suppose you want to
extend the definition of NA and attach an NA to each SS7 linkset. You might
as well throw away the OPC parameter ranges out of the RK parameters then.

NA simply means : MTP(for M3UA) or SCCP(for SUA) variant/version
(ANSI/ITU/China/Japan, version x) and a single address space for PCs. RC may
imply just this, but also more (network subdomains by range of OPCs,
MTP-user by SI and it's variant/version).

All I'm saying is the approach is not just ok for some specific
architectures.

-Gery

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: donderdag 16 augustus 2001 18:22
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Gery,

John

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 17 Aug 2001 07:24:55 -0700

Gery,
	No thank-you, I've already been here.  All I need is NA.  I don't an
additional routing entity, RC (and for that matter RK), to configure and
administer at my node.  I'm not sure if a network operator will want to do
this on a network basis either.

	If your opinions are limited to the backhaul case because you are
NOT talking about full systems and hence need to limit their traffic, fine.
BUT DO NOT impose this requirement on the regular systems that don't need
it.

John

> Sent: Friday, August 17, 2001 3:28 AM
> To: sigtran

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 17 Aug 2001 17:20:34 +0200

John,

If you don't need RK/RC, you refuse to accept the basic definition of AS
agreed in the WG. AS only exists by the grace of defining a RK/RC. Fine if
your RK only contains a NA parameter, but don't impose your short-cut
solution on the draft. The definition of a "regular" system will be
different depending on who you ask.

My opinions are certainly not limited to a backhaul case or whatever. All
you have to administer is a RK (NA in your case) in your ASP, send a REG
REQ, and the SG returns a RC to you in the REG ACK. Or better still, if you
don't want to use the registration procedures either, there's nothing
preventing you of assigning NA as the value of the RC. In this case it all
depends on mutual understanding between SG and ASP anyway.

In my opinion there's every room to collapse RK/RC into NA whenever you see
fit.

Gery

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: vrijdag 17 augustus 2001 16:25
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Gery,

John

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 17 Aug 2001 08:52:02 -0700

Gery,
	I think you have forgotten that AS is logical entity and it only
exists in M3UA.  This is consistent with the definition in the spec.
Therefore it is really just a routing concept, it defines a set of traffic
that my M3UA will process.

	Since I have a fully functional existing SS7 node, and I plan to
keep my RK what it is in the existing SS7 network -- PC!!!  I expect that my
customers will want to keep their configuration model, hence, the RK will be
statically configured.  I think you will find that when I first expressed
this view about a month ago, there were several vendors and network operator
that shared this view.

	I'm surprised that you don't like "short-cuts", they are usually
simple and they work.

John

> Sent: Friday, August 17, 2001 10:21 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 17 Aug 2001 15:54:06 -0500

John,

How about we replace NA with RC but allow you to assign RC == Network Id?
That appears to meet all your requirements.

--brian

John Schantz wrote:                                          (Fri, 17 Aug 2001 08:52:02)

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

---

---

From: [email-masked]
Date: Mon, 20 Aug 2001 13:16:17 +0300

Hi Brian,

> How about we replace NA with RC but allow you to assign RC == 
> Network Id? That appears to meet all your requirements.

That would be an idea!  I think that this would be a clean way
forward.

best regards,
John

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 20 Aug 2001 08:24:47 -0500

Hi John,

If like this, how can you send ASPAC for different traffic ranges, unless you have one huge AS containing all of the traffic of the whole network ?

    Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 20, 2001 6:16 AM
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Hi Brian,

best regards,
John

---
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, 20 Aug 2001 08:43:22 -0500

Tolga,

John does not need (and clearly wishes not to) distinguish traffic
on any other basis than Network Id.  Neither does John and Barry
seem to need to demultiplex traffic based on AS, so I belive one big
AS would be sufficient.  However, if anyone wishes to distinguish
traffic on the basis of Network Id/Network Attachment, then they can
set RC == Network Id/Network Attachment (i.e, RC == v7/v8 NA).  If
anyone wishes to distinguish traffic on a more granular basis, they
can assign RC values on a normal basis.

--brian

Asveren, Tolga wrote:                                    (Mon, 20 Aug 2001 08:24:47)
> Hi John,
> 
> If like this, how can you send ASPAC for different traffic ranges, unless
> you have one huge AS containing all of the traffic of the whole network ?
> 
>     Tolga
> 

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 20 Aug 2001 07:38:47 -0700

I'm not sure which John is which.  But this proposal seems different than
the one you made Fri. (just reading this stuff now).  I would prefer the one
you are pushing now.

	NA == v5/v6 NA (an ID)
	RC == v7/v8 NA (an ID plus CPC/network attachment)

I can use NA in my large system, non-backhaul case when multiple network are
involved.  You can use your RC in the backhaul & small system case where
traffic is more granular.

John S.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 8:43 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 10:27:51 -0500

John,

Are we in agreement then?  

  NA in REG REQ:
 	NA == v5/v6 NA (an ID)

  RC in SNMM and DATA allowing:
 	RC == v7/v8 NA (an ID plus CPC/network attachment)

Does anyone else object to this arrangement?

--brian

John Schantz wrote:                                          (Mon, 20 Aug 2001 07:38:47)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 20 Aug 2001 08:29:58 -0700

There is something I just don't understand.  If multiple networks/accesses
are NOT involved (the regular case).  Then RL is all that is needed for DATA
and nothing extra is needed for SNMM.  Then why isn't NA (== an ID) all that
is needed in the multiple network/access cases.  It provides a means for the
nodes to separate the traffic (and nodes) into overlays (logical regular
cases).  Each overlay is equal to the case where multiple networks/accesses
are not involved.  Therefore, nothing extra is needed.  

So if nothing extra is needed in the regular case and you can use NA to
create multiple logical regular cases, why do you need extra stuff?

> From: Schantz, John 
> Sent: Monday, August 20, 2001 9:39 AM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 20 Aug 2001 08:39:16 -0700

Ahhh, NO.  We are only agreeing on NA and RC definitions.  We are missing
each other in their use.

If multiple networks/accesses are involved, I will need NA in all DATA and
SNMM messages.  I don't see the need for RC and hence have no plans on using
or needing RC in messages.

But in your backhaul scenarios where you believe you need finer detail, I
would be willing to allow RC as an optional parameter in the DATA and SNMM
messages.

John

> Sent: Monday, August 20, 2001 10:28 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 10:55:41 -0500

John,

As you so aptly put, finer granularity is needed in small system
and backhaul cases where, for example, routing is performed on a
CIC-range basis, or other user-part granularity (SSN, TID).
In these cases the ASP can use the more granular RC to determine
which to slice of a user part the DATA messages are destined without
the ASP being required to examine the RL and part of the MSU payload.
This also permits the ASP DATA handling functions to be protocol
variant neutral where multiple protocol variants are supported on
the same system.

--brian

John Schantz wrote:                                          (Mon, 20 Aug 2001 08:29:58)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 11:04:28 -0500

John,

John Schantz wrote:                                          (Mon, 20 Aug 2001 08:39:16)
> SNMM messages.

With RC in the SNMM message set to ID plus CPC/network attachment the
ID will be in the SNMM message.  That is all that you need.

> I don't see the need for RC and hence have no plans on using

Don't set it to other than ID plus CPC/network attachment.

> would be willing to allow RC as an optional parameter in the DATA and SNMM

Thank you.

I see no need for NA in DATA and SNMM when RC is set to ID plus
CPC, but it is possible to leave NA == Network Id as optional
in DATA and SNMM, if others prefer that form of the Network Id.

Does any one else prefer NA in the message when ID plus CPC RC
assignment is sufficient?

Are there any other objections to RC as optional in DATA and SNMM
messages?

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 20 Aug 2001 09:18:37 -0700

I would like to make sure that everyone understands what
is being proposed and if they agree.  We should not keep going
back and forth over this.

Please restate the proposal and let's take a poll over the 
next few days.

Cheers,

L. Ong 
--

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 11:47:41 -0500

Lyndon,

Once the kinks are ironed out with John, I might
take you up on your offer to take a poll.

--brian

Lyndon Ong wrote:                         (Mon, 20 Aug 2001 09:18:37)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 11:59:57 -0500

John,

Do you see my point?  If you have Network Id in the RC whenever
you assign RC == ID plus CPC/network attachment, why do you ever
need NA in DATA or SNMM messages?

In the more granular case, NI is implicit in RC as well.

Why would you ever need NA in DATA and SNMM where RC is included?

--brian

Brian F. G. Bidulock wrote:                               (Mon, 20 Aug 2001 11:04:28)

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 20 Aug 2001 13:11:04 -0700

I'm glad you approve ;o)  It might be difficult otherwise
to demonstrate a consensus in favor of adding the RC.

L. Ong
 
--

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 20 Aug 2001 13:28:40 -0700

No I don't see your point.  My node is already perfectly happy with using
the RL to do its discrimination of the messages.  Hence, introducing an
alternative parameter for discrimination (and distribution through the user
parts) affects my current system.  Therefore, I do not and will not
introduce another parameter such as RC for processing when the information I
need is in the RL.  I still think that a node should use the RL for
discrimination and distribution to its users.  The MTP3 users have their own
discrimination and distribution functions, and M3UA should not violate this.

I am not sure of why RC needs to be present in the messages to begin with,
even in the backhaul cases.  I can see where RK/RC is useful if you want to
support a partitioned system and you want the SG to do the
discrimination/distribution (note, this seems to fit well with backhaul).
But this should only be needed at set up.  I don't see why the SG should
reconfirm this discrimination/distribution with every message by including
an RC.    The ultimate verification that the SG is doing it correctly is to
have the receiving partitioned element examine the RL, the RC can not be
used to do this.

Now suppose that you want this partitioned element to handle 2 or more sets
of traffic (i.e., RKs).  [Actually why would you do this.  You just blew up
your node into elements and now you want to put it back together in a
strange way]  Once you have it set up with the SG, that should be it.  The
SG is doing the pre-discrimination / distribution function for the
partitioned elements.  The partitioned element should still look at the RL
to do the final distribution (and discrimination).  This impels to me that
you want to include RC in the DATA so that your elements don't have to know
anything about MTP/ISUP/SCCP parameters.  

Why do you need RC in SNMM messages?  Are you going to send SNMM that are RC
specific?  This implies to me that you just want to pass the info on and not
have M3UA maintain any status of its own.  How will you be able to do this
if your partitioned element connects onto more than one SG, or are you going
to restrict it a single SG.

I do not think that these strange backhaul limitations have any
applicability to network level issues and non-backhaul scenarios.  I think
this may be the main reason that there were so many objections to including
RC in the messages because may be this "dumbing-up" of the M3UA is beyond
what most people/engineers can stand.

Conclusion:  I do not need RC and will not be using it in my non-backhaul
environment.  And I question whether it should be used even in the backhaul
cases.  Therefore may be I should stay with my NA = (an ID) and NO RC
stance.

> Sent: Monday, August 20, 2001 12:00 PM
> To: sigtran

---

---

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

Lyndon,

...just as there has been no concesus shown for changing the definition
of NA, or doing a global search and replace of SGP for SG in the M3UA
document.  Both of which have received numerous objections and the WG
was not consulted with a poll or vote for NA (only two people commented)
and was not consulted at all for the s/SG/SGP/g.

So, it does not appear that it takes concensus to make a change to the
M3UA draft (Greg adds the things in he sees fit), nor does it appear to
take concensus to move the draft forward.

This is what I believe that WG Last Call is for, am I wrong?  To obtain
concensus on the document as a whole rather than voting on each and
every edit which goes into the document?  Striving to determine
concensus on every spelling correction or logical error would be rather
time consuming approach.

With regard to the currrent issue, the lack of any concerted objection
should certainly be enough to change the text in the document.  M3UA has
so many outstanding issues, voting and polling them all could delay the
next draft.  Voting and polling the v7 and v8 changes which were not
discussed (or later objected to strenusously) in the WG might be
pointless.  There are enough changes an issues that a review of the next
draft will likely be required before it can be moved forward to IESG.

Greg has already made changes to the v8 draft based on a seat-of-the
pants judgment of working group approval.  No votes or polls were
necessary for those changes.  (Not to mention that a vote or poll would
lengthen the process: how long do you wait for responses?  How do you
include everyone who read and agreed to the SUA approach in the poll?)

I think that it would be wise to let us settle this out, Lyndon, come to
some agreement or compromise with each other in the WG and then move
forward.  Being just on the verge of comming to agreement with John,
with no outstanding objections from others, why would you suggest a vote
or poll at this time?

You say you have no stake in this: I wonder...  You seem quick to try to
keep us from discussing the issues in the WG for several days, yet want
to prolong the result of those dicussions with a vote or poll which will
span over a week.

Allowing RC == Network Id or ID+CPC/attachment or however one wants to
assign it, even placing text which says that RC SHOULD be assigned in
certain fashions under some circumstances appears to be able to dissolve
the dispute, and as John L. says: establishes a clear path forward.

Why would you want to place ostacles in the path?

Clearly placing RC in DATA and SNMM has been requested by a number of
people in this dicussion.  The need for RC at the ASP in these messages
has been expounded by a number of people.  I see only two bases for the
objections to RC being allowed in DATA and SNMM:

    1) someone doesn't see the need (but the need has been
       explained).

    2) someone is intentionally trying to block those
       who wish to use RC in this fashion from being
       able to do so.

My question to the WG would be: Does anyone know of a reason not to
allow RC in DATA and SNMM?

As there has been no reason presented not to allow it, I would suggest
that it should be pretty much a done deal that RC be allowed in DATA and
SNMM for the next draft.  Precise wording is details that probably
doesn't need much discussion before text is available for review.

The objections to Gery's proposal to use NA == ID in REG REQ and replace
NA with RC in DATA and SNMM messages has been objected to on the
following grounds:

    1) someone doesn't see the need for RC (but see
       above).

With RC allowed in DATA and SNMM messages and the ability or even
recommendation to set RC == ID + CPC/attachment, there is no need for NA
in DATA and SNMM because the required Id is present and explicit in the
RC in those circumstances requiring explicit Network ID (it is always
implicit).

So my next question to the SG would be:  Is there any need to have NA in
DATA and SNMM if RC is allowed and is assiged to ID + CPC/attachment in
circumstances requiring NA?

Of course there is no need for NA in this case: Network ID is explicit
in RC and so RC will do.  The tables have turned.  Because NA is coarser
than RC, NA cannot replace RC, but the reverse is true: RC can replace
NA.

Not suprisingly, this is consistent with the CONCENSUS approach taken
for SUA.  Even though SUA is at WG last call, there is no issue with
using routing context instead of NA in SUA.  Where are those who object
to RC replacing NA in M3AU when it comes to SUA last call?

So, the combined question becomes: Is there any reason not to replace NA
with RC in all M3UA messages except REG REQ and make M3UA consistent
with SUA in this critical regard?

Aside from some possibly wanting some assurances in the text for the
more restricted settings of RC (ID + CPC/ attachment), it appears clear
that the answer is no: there is no good reason not to.

Can anyone think of a good reason not to?  Does anyone intend to object
to replacing NA with RC given these details?

Please make yourself and your good reason know so that I may discuss it
with you and come to some agreement or compromise.

Lyndon, can *you* think of a good reason not to replace NA with RC in
DATA and SNMM?  Please contribute to the discussion rather than trying
to place walls around it...

--brian

Lyndon Ong wrote:                                          (Mon, 20 Aug 2001 13:11:04)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 16:59:57 -0500

John,

John Schantz wrote:                                          (Mon, 20 Aug 2001 13:28:40)
> discrimination and distribution functions, and M3UA should not violate this.

MTP-Users neither disciminate nor distribute.  But, nevertheless, please
don't use RC in any other fashion that you are using NA today.  Just pull
the Network Id out of the RC and use it as you are using NA today.

> have the receiving partitioned element examine the RL, the RC can not be

I don't think that we need to explain the need for RC to you, John.  There
are five individuals who have requested it for DATA and its use is well
documented in SUA (we can include common text in M3UA of you'd like).
Its ability to replace NA is clear: you set RC == Network Id + CPC/attachment.
We even place text in M3UA which says when this SHOULD be done.  You
pick Network Id out of RC and you don't need NA.

> anything about MTP/ISUP/SCCP parameters.  

MTP-Users don't do discrimination/distribution.  I have an ISUP-User which
only expects to receive messages for OPC/DPC/CIC-ranges.  Each ISUP-User
has an RK/RC/AS for the OPC/DPC/CIC-range as defined by the registration
model (one RC returned for each OPC/DPC/CIC-range).  I do not need to examine
any RL or dig into CICs in the DATA message, because RC tells me at the ASP
to which AS (RK/RC/AS/ISUP-User) the message is destined.  I have one hash and
go on RC, versus applying a possibly large vector of RK mask and range
matches.  I do not hash on OPC/DPC/CIC-range because, for one it is a range,
for another the form of the OPC/DPC depends on the NI-bits and variant.
I would have to use NA/OPC/DPC/SI/CIC as a hash key where with RC, I can
simply use the 32-bit RC as a hash key.  The RC approach is much simpler
and is variant neutral.

Even in your case, where whole point code routing is performed, I will hash
the 32-bit RC (ID + CPC/attach) rather than using (NA/DPC)-list, and because
that is efficient, variant neutral and sufficient, RC can easily replace NA.

> to restrict it a single SG.

When you set RC = ID + CPC/attacment, sending RC in SNMM messages is the same
as including CPC which you agreed to already as preferred to the expanded
definition of NA (allowing NA to be just Network ID).  Since RC = ID + CPC/
attachment in these cases, NA = Network Id is redundant because RC already
explicitly contains it.

When routing is performed on and OPC/DPC/CIC basis, I will use RC to identify
which ISUP-User interface (AS/RC) to which to deliver MTP-PAUSE/RESUME/STATUS
primitives.

In your case of whole point code routing, I will use (ID + CPC/attach) to
identify the SPMC (whole point code) to which the MTP-PAUSE/RESUME/STATUS
applies and deliver the primitives.

Again, the RC is a simple 32-bit hash and go.  (NA/DPC/attach)-lists are a
worse key.  RC (ID + CPC/attach) is all that needs to be used to hashed on to
identify the SPMC in your case.

> cases.  Therefore may be I should stay with my NA = (an ID) and NO RC

NA is not required in the non-backhaul case (it is implicit in the association
as granularity of routing context does get larger than an SPMC) and per the
draft will be ignored if included in DATA or SNMM for the non-backhaul case.
On the other hand, RC *is* needed even for the non-backhaul case where
multiple user parts (less than a full SPMC) are provided over the same
association for the same reasons as in the backhaul case: efficient
demultiplexing of traffic at the ASP, variant neutrality and consistency with
SUA.

Please don't waffle here: it bothers Lyndon ;)

Regardless of how I'm going to use RC outside the restricted set of cases
and configuration which you intend to use NA, do you not agree that a
parameter with the value ID + CIC/attachment in DATA and SNMM will be
sufficient to meet your needs?

All that I purpose is for that parameter to be RC, so that others can use
it for others purposes in situations _already_provided_for_ in the M3UA
draft which are other than yours (e.g. CIC routing) and without restricting
other implementations to your set of implementation decisions.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 20 Aug 2001 17:03:44 -0700

Brian,

I'll let the personal insinuations slide, except to point
out that you would have much more success arguing your case 
if you adopted a less confrontational tone.

You're right, some of the previous changes to M3UA were
done without much more than a comment or two.  As I've
explained before, I am trying to rein in the comment
process so that changes now require a clear consensus
in the group - I don't see why you object to this.

Based on the email, there appeared to be more than a 
handful of people objecting to having the RC in the DATA 
message in M3UA, based on the argument that all of the
necessary information was already in the DATA message.

You are trying to create a compromise proposal with
the RC taking the place of the NA, all I am asking is
that you state clearly what the proposal is, and we
find out what people on the list think of it.

Thanks,

L. Ong

--

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 19:27:09 -0500

Lyndon,

I though we were discussing the details of an
agreement/compromise.

What did you think we were discussing?

Lyndon Ong wrote:                                          (Mon, 20 Aug 2001 17:03:44)
> necessary information was already in the DATA message.

Count the number of people saying don't put it in there (~2).
Count the number of poeple asking about the need (~3 or 4).
Count the number of people wanting RC in DATA (~5).
Count the number of poeple pointing out why NA is not required
where RC is included (~2).

> find out what people on the list think of it.

I'm trying to acheive a compromise.  Compromises are not
achieved by taking a hard line.  Further, the current definition
of NA is unsatsifactory to those wishing to use it as Network Id.
So we are searching for the compromise which meets the needs of
all concerned.  There is no question that the current v8 needs
changes.  Of that we are all agreed (the leave things as is option
was not even obvious).  We are discussing which changes to make.

Do you have a technical opinion?  Can you propose a compromise
at this point?

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 20 Aug 2001 18:06:26 -0700

Brian,

Comments below.

>What did you think we were discussing?

I was happy to let you work towards a compromise,
you addressed a message to me suggesting I had
some sort of hidden motive.  This whole thread has
been totally unnecessary IMHO.

>where RC is included (~2).

As I said, there were more than a handful of people with
objections to incorporating RC in the DATA message.
This is not consensus.

>was not even obvious).  We are discussing which changes to make.

I was not asking for a hard line, just to keep the discussion
from going on indefinitely if we are not reaching a conclusion.

>Do you have a technical opinion?  Can you propose a compromise

What I was proposing was that you state your compromise
(feel free to keep working at it until you're ready - but
not indefinitely) and we see the level of support.  Any
problem with that?

Cheers,

L. Ong

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 20:53:11 -0500

Lyndon,

Please see questions below...

Lyndon Ong wrote:                                          (Mon, 20 Aug 2001 18:06:26)
> been totally unnecessary IMHO.

Why do you feel that is has been unnecessary?

> objections to incorporating RC in the DATA message.

The same handful has objections to the current M3UAv8
definition of NA.  That is not concensus either.  If M3UA
is not going anywhere without concensus then it looks
like it's not going anywhere until a compromise can be
reached.

> from going on indefinitely if we are not reaching a conclusion.

I think the discussion would benefit without a moderator
to scope, frame or limit the discussion.

> not indefinitely) and we see the level of support.  Any

Do you not have a technical opinion?  Please contribute to the
current technical discussion.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Mon, 20 Aug 2001 22:27:47 -0700

>to scope, frame or limit the discussion.

Sorry, Brian, but you're stuck with me.  You can, of course,
propose your own group and mailing list if this would be more
satisfactory to you.  I actually intervened because in my view
the discussion was going around in circles.

>current technical discussion.

All right, please note I am taking off my WG chair cap...

It seems to me that RC is not required in the DATA message
because all of the necessary information is already there.  The
argument is whether RC simplifies processing at the ASP or
not, and that seems to be implementation-dependent.

Can we define two cases, one where
there is no demuxing at the ASP and the ASP relies on the SG
to send it the right set of traffic, and then an extension case
that defines where there is demuxing
at the ASP based on an RC?   Then the two cases
are separated and carriers could decide their preference.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 02:34:48 -0500

Lyndon,

Lyndon Ong wrote:                                          (Mon, 20 Aug 2001 22:27:47)
> It seems to me that RC is not required in the DATA message because
> all of the necessary information is already there.  The argument
> is whether RC simplifies processing at the ASP or not, and that
> seems to be implementation-dependent.

It seems to be more configuration dependent that implementation
dependent.  Some implementations are not considering the full range
of possible configurations (e.g, CIC-range or even SI routing)
provided for in the draft.

> 
> Can we define two cases, one where there is no demuxing at the ASP
> and the ASP relies on the SG to send it the right set of traffic,

What do you mean by "relies on the SG to send it the right set of
traffic"?  In the RC case, the ASP is relying totally on the SG to
send it the right set of traffic (and label it with the correct RC).

If anything, the case where the ASP goes digging in the RL to, as
John puts it, distribute traffic at the ASP, the ASP is not relying
on the SG, it is actually re-examining the RL and information in the
message.

> and then an extension case that defines where there is demuxing at
> the ASP based on an RC?

John, Tolga and others (except Barry) acknowledge that distribution
or demultiplexing is required at the ASP even in the non-RC case.

> Then the two cases are separated and carriers could decide their
> preference.

Let me contrast the two cases a little differently:

NA case for DATA:

  In the current case, the NA (as Network Id/Attachment) is looked
  up against a statically provisioned table to determine the variant
  (form) of the Routing Label (assuming no Protocol Data 3). Then
  the ASP applies a set of Routing Keys (NA/OPC/DPC/SI/CIC-range)
  for the association against the Routing Label and possibly data in
  the payload (e.g, CIC).  After matching one of the Routing Keys
  for the association, the ASP determines the Application Server
  (MTP-User) to which the data is intended.

  In the current case, the ASP must maintain a statically
  provisioned list of NA values, must associate a variant (form) of
  the RL with each NA value, must maintain as statically provisioned
  list of Routing Keys (regardless of whether static allocation of
  Routing Contexts is used) and must keep those Routing Keys in
  per-variant form, and must associate Application Servers
  (MTP-Users) with the Routing Keys (and, of course Routing Contexts
  so that ASPAC can be sent).
  
  Each MTP-User must provide or have provided the appropriate NA
  value (which is not just Network Id, but also contains Attachment
  which contains SG SS7 network configuration dependent information).
  Routing keys must also include this SG SS7 network attachment
  dependent NA value.

  In the current case, the entire RK list for the association must
  be run against the variant-formatted RL in each DATA message.

RC case for DATA:

  In the RC case, the ASP indexes an AS table by RC and provides the
  data to the indexed AS.

  In the RC case, the ASP need only maintain a list of AS indexed
  (hashed) by RC.  Nothing more than the RC need be examined to
  provide the DATA message to the correct AS.  The RC list can be
  generated statically or by dynamic registration per the draft.

  Each MTP-User provides Network ID as provided in SS7.  Routing
  Keys do not need to be maintained at the ASP.  Any Routing Keys
  which might be maintained for dynamic registration contain Network
  Id only (not attachment) and are completely independent of the SG
  SS7 network configuration.

  This is how SUA works today.

The difference between some applications of M3UA and others is the
number of Routing Keys (Application Servers) which are multiplexed
over the same association.  If there is only one AS per association,
there is no difference.  If there are some 1000-odd disjoint
CIC-ranges in multiple networks, the difference is drastic.

If RC is placed in data and RC <= NA in those simpler cases where
the difference is moot and dynamic registration is not desired, the
advocates of the NA case can perform the process described above
using RC as they would NA.

However, when supporting many CIC-ranges over a single association
and dynamic registration are desired, RC can be assigned on a more
granular level and the simple one-hash process described above used
for efficiency.

Do you see any error in how I have described the DATA situation?

Now for SNMM, the cases are similar:

NA case for SNMM:

  In the current case, the NA (as Network Id/Attachment) is looked
  up against a statically provisioned table which is reverse indexed
  to list the Application Servers associated with the NA.  For each
  AS in this list, the ASP must send an equivalent primitive to the
  AS (MTP-User).

  This requires a statically provisioned list of NA values and a
  reversed index of AS by NA.  Each MTP-User must provide or have
  provided the appropriate NA value (which is not just Network Id,
  but also contains Attachment which contains SG SS7 network
  configuration dependent information).

RC case for SNMM:

  In the RC case, the ASP need only maintain the same list of AS
  indexed (hashed) by RC as is used for DATA.  Each AS (MTP-User)
  for each RC in the SNMM is sent the equivalent primitive.

  MTP-users provide or have provided Network ID as per current
  SS7 interfaces.
  
  This is how SUA works today.

Do you see any error in how I have described the SNMM situation?

So, what is the problem with putting RC in DATA and SNMM for
multiple AS per association cases?

RC can be assigned in the same manner as NA for those that wish to
use it that way.  Unfortunately, NA cannot be assigned the same way
as RC (because dynamic registration takes NA and returns RC).

Does that make things a little clearer for you Lyndon?

It is not simply the case that different implementations experience
different efficiencies: it is the case that some implementers are
doing only a small portion of the draft, and particularly are not
implementing CIC-ranges and granular RKs, dynamic registration,
dynamic port allocation, nor backhaul cases.

For all of the cases in which they are not interested, but which are
still provided for in the draft, RC in DATA and SNMM is needed for
efficient implementation.  Ironically, RC in DATA and SNMM assigned
as NA would suit these more restricted needs as well.

What can be the possible purpose of blocking efficient implementation
in these other cases which hold no interest to those who object,
even when the proposed change does not impact their approach?  It
appears to me as the epitome of selfishness.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 03:02:20 -0500

Hi Lyndon,

I should have noted that when the specific needs of ISUP Application
Servers are considered, the difficulties presented by the current
situation of providing NA in SNMM becomes even more problematic.

ISUP as an MTP User is not concerned about the status of all of the
routesets to all of the destinations available to the signalling
point.  This is particularly true where both ISUP and SCCP users are
present at the signalling point.  While the SCCP MTP-User is
typically has a large number of routesets for which it is concerned,
the ISUP MTP-User is only concerned about routesets for signalling
points to which it has trunks.  Contrasting the cases for SNMM for
ISUP MTP-Users, the following occurs:

NA case for SNMM:

  In the current case, the NA (as Network Id/Attachment) is looked
  up against a statically provisioned table of NA values to determine
  the form of the affected point code and to reverse index a list
  the Application Servers associated with the NA.  For each AS in
  the list, the ASP must compare the variant specific form of the
  affected destination against the variant specific Routing Key
  associated with each ISUP AS to determine whether the affected
  destination matches the OPC of the ISUP AS NA/OPC/DPC/SI/CIC-range.
  (Note that because a CIC-range is only applicable to an OPC/DPC
  pair, RKs and ASs cannot be assigned on a multiple OPC basis where
  they include CIC-range.)  If the affected destination in the SNMM
  matches the OPC of the RK, then the equivalent primitive is issued
  to the AS (ISUP MTP-User).

  Again, this requires a statically provisioned list of NA values
  which include SG SS7 configuration specifics (attachment) reverse
  indexed to Application Server.  The ISUP MTP-User must provide or
  have provided the SG SS7 configuration specific NA value.

RC case for SNMM:

  In the RC case, the SG can perform the screening of SNMM messages
  which are applicable for the AS (by NA/OPC/DPC/SI/CIC-range RK
  at the SG as is already performed on DATA).  The ASP need only
  maintain the same list of AS indexed (hashed) by RC as is used for
  DATA.  Each AS (MTP-User) for each RC in the SNMM is sent the
  primitive.

Neither TALI nor SUA seem to have any problems with these
situations, just M3UA.  An ISUP solution for M3UA is needed.

--brian

Brian F. G. Bidulock wrote:                               (Tue, 21 Aug 2001 02:34:48)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 21 Aug 2001 10:30:42 +0200

John,

Actually I proposed a short-cut in my mail below, which includes RC = NA,
and which would fulfill everyone's requirements. See also Brian's comments.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: vrijdag 17 augustus 2001 17:52
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Gery,

John

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 21 Aug 2001 10:35:18 +0200

Hi Tolga,

Yes, the AS is an entire Point Code and gets all the traffic of the network
destined to this PC.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: maandag 20 augustus 2001 15:25
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Hi John,

    Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 20, 2001 6:16 AM
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Hi Brian,

best regards,
John

---

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 21 Aug 2001 11:59:50 +0200

Hello Lyndon,

The proposal is to only use NA in the REG REQ/ACK. Brian and I already sent
a number of mails explaining why RC replaces NA (other way around is not
possible) in all other messages. It can even be done economically, when you
assign the RC value wisely, in those cases where NA is sufficient.

Of course the NA (together with RL) might be sufficient is some
architectures, but this is not the general approach and requires additional
RC ("extra stuff") in other contexts. Our proposal has the goal of :

1) Reaching a common solution for all UA's.
2) Not to make any assumptions on the architecture, the possibility of
collapsing RK/RC into NA/CPC-attachment has been described also. Use of RC
can cover all cases, NA doesn't. RC is not extra stuff, if you use it
instead of NA.
3) Resolving the problems we have now with NA definition.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 21 augustus 2001 3:53
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Lyndon,

Lyndon Ong wrote:                                          (Mon, 20 Aug 2001
18:06:26)

--brian

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

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 21 Aug 2001 10:16:54 -0700 (PDT)

Gery,

Thanks for restating the proposal.  Perhaps as part
of this that the definition for NA could revert back
to the one in version 6 (if we can kill two birds 
with one stone, even better).

Can I have more general views from the list on
the proposal?

RC would be come an optional parameter in DATA
and SNMM messages, replacing NA.  However, in
some configurations RC would provide the equivalent
information to NA.

Cheers,

L. Ong

--- Verwimp Gery <[email-masked]> wrote:
>       (Mon, 20 Aug 2001
>          (Mon, 20 Aug
> 2001 17:03:44)
> You are currently subscribed to sigtran as:
> [email-masked]

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 21 Aug 2001 13:27:35 -0400

Why not just put RC and NA into DATA and SNMM
messages so that "some" configurations/implementations
don't need to worry about how they provision RC.  Instead,
they use NA and ignore RC in the DATA and SNMM
messages.

At 10:16 AM 8/21/01 -0700, you wrote:
> > [email-masked]
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 21 Aug 2001 10:46:07 -0700 (PDT)

Brian,

All I originally asked for was what Gery
sent out, a restatement of the proposal
so that we could poll the group for views
pro and con.

Does this make things clearer for you?  Do
you have an objection to listening to see
what others on the list think?  Hopefully not.

Regarding the discussion below, I would think
that how much more efficient the RC allows
your implementation to be depends on (a) whether
you need to demux at the ASP or use some other
mechanism (separate associations?) and (b) 
if you do demuxing at the ASP, then what 
information you use for demuxing, e.g.,
if it's based on the SI only, then adding an RC
is really not necessary.  As I said, I have no
stake in this, but others on the list do.

In any case, let's see what the other views are
on the list.

Cheers,

L. Ong

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> Lyndon,
> 
> Lyndon Ong wrote:                                   
>       (Mon, 20 Aug 2001 22:27:47)
> > >
=== message truncated ===

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 13:57:37 -0500

Lyndon,

Lyndon Ong wrote:                                          (Tue, 21 Aug 2001 10:46:07)
> Brian,
> 
> All I originally asked for was what Gery sent out, a restatement
> of the proposal so that we could poll the group for views pro and
> con.

I'm sorry, I didn't quite understand the question I suppose,
because that proposal has been stated about 5 or 6 times
recently and discussed to great length.  Thanks, Gery, for
restating it once again.

> 
> Does this make things clearer for you?  Do you have an objection
> to listening to see what others on the list think?  Hopefully not.

No objections whatsoever.

> 
> Regarding the discussion below, I would think that how much more
> efficient the RC allows your implementation to be depends on (a)
> whether you need to demux at the ASP or use some other mechanism
> (separate associations?) and (b) if you do demuxing at the ASP,
> then what information you use for demuxing, e.g., if it's based on
> the SI only, then adding an RC is really not necessary.  As I
> said, I have no stake in this, but others on the list do.

In (a) demuxing is required to the capabilities provided for in
the draft: i.e, the ability to multiplex multiple AS over a
single association.  All the UAs accomplish this:  Why would one
want to restrict M3UA?  If M3UA is restricted to one AS per
association, some serious text changes will be necessary to both
spell that out and require it.

In (b) demultiplexing on NA/OPC/DPC/SI/CIC-ranges is provided
for in the draft.  Again: ISUP support is needed in M3UA because
there is no ISUA to support ISUP.  (Perhaps you were not aware
of it, but this was the conclusion of a long discussion regarding
routing keys in M3UA and the value of and explicit support for
SSN/TID/CIC in routing keys.)

Therefore, RC allows much more efficient implementation (and
administration) of the complete draft.

Again, you seem to have missed several points:  NA defined as
Network Id/Attachment (current v7 v8 definition) is horribly
unworkable from an adminstration and provisioning viewpoint.
Because it requires different values depending on the network
attachment at the SG (which is changeable), coordinating assignment
between M3UA at the SG and AS is quite problematic.  It is not a
part of the normal MTP-SAP (i.e, it is not just NI) and therefore,
the existing MTP-User interface cannot be used as is (which the
draft wrongly claims to support).

Proposals to make NA == ID + CPC/Attachment to relieve this
administrative burden and permit passive monitoring have been
strongly objected to by John S.

RC as a clear identifier of the MTP-SAP and removes this
administrative burden and MTP-User incompatibility by allowing
routing keys (rather than attachments) to be used to identify
traffic flows and administrative domains.  The Routing Key is
made up of the arguments of primitives available to the MTP-User,
and the MTP-User does not need to change its current interface
to MTP.

Also, regardless of whether demultiplexing is performed at the
SI level (or whole point code level), the use of RC relieves
the ASP M3UA from being required to maintain variant specific
routing keysh, and from (without Protocol Data 3) needing to
examine variant specific packed RLs.

So, even in the case where RC == NA and even in the case of
whole point code routing, RC permits the ASP M3UA to be liberated
from RK variant and SG-RK sepecifics as well as liberated from
RL-variants and RL packing.  Some implementations may be so
restricted enough (operating in a single network with a single point
code for a single SPMC over a single association with single
SG) to not take advantage of these clear efficiencies, nevertheless
the majority of the configurations provided for in the draft may
take full advantage of these benefits in all configurations.

Even where RC (or NA) are not provided for in the message, the
M3UA ASP must maintain a concept of an RK and RC and an AS.
What is clearly not required where not provided in the messages
is a concept of NA.

> 
> In any case, let's see what the other views are on the list.

I look forward to it.  However, as it appears that you do not
see that there are benefits from replacing NA with RC even for
the restricted cases where NA might appear to suffice, I will
continue to illustrate the benefits of Gery's proposal.

I don't believe that your summary of the benefits or pitfalls
of either approach is yet complete because it does not address
the other negative impacts that the current defintition of NA
poses in all situations where it is used.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 14:13:24 -0500

Ken,

Even where NA would appear to suffice, replacement with RC has the
following advantages:

  -  RK neutrality (NA requires variant-specific RKs)
  -  No need for RK's at the ASP (NA requires RKs for demux at the
     ASP)
  -  RL neutrality (NA requires examination of RL in DATA for demux
     at the ASP)
  -  Permits existing MTP-User interface (NA requires assigment of
     non-MTP-SAP value)

The reason that these advantages appear for RC = NA and not for NA,
is because when RC = NA, and on the basis of the definition of RC,
the ASP knows that the RC value (whatever it may be) uniquely
identifies the traffic flow.  The NA definition makes no such
guarantee to the ASP, so to support the current definition for NA,
the following would still be required:

  - statically configured SG-configuration specific NA value
  - variant-specific RKs for demultiplexing traffic
  - variant-specific examination and application of variant-specific
    RKs to variant-specific packing of RLs in each DATA message
  - some non-MTP-User mechanism for assigning configuration-specific
    NA values to MTP-Users

It is to avoid the ASP being forced to implement these things that
RC needs to *replace* NA, not just augment it.  Of course, if one
wants to place all this variant and SG configuration specific
information in their ASP implementation, be my guest!  There is no
reason to force implementations to do so, however.

I suppose one could place RC in DATA and SNMM and place a
*different* NA (some other definition) as well, but the value of
that approach would depend highly on what this *different*
definition of NA would be.  To avoid the above variant-specific
difficulties, RC would still be required whenever NA is required in
the message (for the unique traffic flow guarantee), making NA in
the message redundant.

If something is added to RC, I think it should be an optional CPC
parameter to SNMM included whenever the SG/AS wish to permit passive
monitoring.

--brian

Ken Morneault wrote:                        (Tue, 21 Aug 2001 13:27:35)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Aug 2001 14:35:56 -0500

Brian,

For sure I don't agree with "No need for RK's at the ASP'. For the general
case, it is needed there. Some M3UA implementations can live without it, by
pushing the responsibility to user applications, but anyway one will need
RKs on ASP side somewhere to be able to choose a SG for the general case.

    Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 3:13 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Ken,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 15:06:02 -0500

Tolga,

Please feel free to place RKs in an ASP.  Feel free to place
variant-specific and even pseudo-arbirtrary RKs that some SG
designer might imagine in the future in an ASP as well.  RC
does not stop one from doing that.

On the other hand, the current NA approach requires all ASP
implementation to include them, when static RC configuration
is all that is otherwise required and provided for in the M3UA
draft.  Implementations should no be required to provision RKs,
when they can simply be configured based on static RC
provisioning as provided for in the draft.

The NA approach to demultiplexing requires RKs where none are
necessary.

RC removes that requirement and permits ASP configuration based
on static RC provisioning without RKs once again.

So, you see, the ASP which is statically provisioned by RC
does not need RKs.  As registration is an optional behavior,
a fully compliant M3UA ASP implementation should not need RKs.
Not dealing with RKs is IMO one of the major advantages of
static RC configurations: it is intended to permit unimagined
RKs to be used at the SG yet permit ASP interoperability based
on static RC assignment.

You may decide that you need them in your application, however,
the draft provides for configurations where they should not
be necessary (where it not for the current NA approach).

--brian

Asveren, Tolga wrote:                                    (Tue, 21 Aug 2001 14:35:56)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 15:28:50 -0500

Gery,

You have aptly framed the use of RC in DATA and SNMM as supporting
the SIGTRAN AS model.  It is in implementation of M3UA and discovery
that it does not support the AS model provided by the other UAs
that this issue first arose for me.  I would like my implementation
of the SGP/ASP to be able to work to the same AS model which is
provided for in all other UAs.  This requires that RC as an AS
identifier be communicated on UA specific messages between ASP and
SGP as IID is communicated for IUA and M2UA and RC is indeed
communicated for SUA.  The existing NA approach in M3UA does not
permit an implementation to take advantage of the benefits offered
and the value inherent in the AS model for M3UA.  M3UA V8 in NA uses
some other model based on the restricted requirements of a small
subset of implementations and configurations in spite of the
architectural claims in the draft.

(I'm sure I'm preaching to the choir here... ;)

--brian

Verwimp Gery wrote:                                       (Fri, 17 Aug 2001 17:20:34)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Aug 2001 15:40:31 -0500

Brian,

The case I am speaking of is for OUTGOING traffic, from ASP to SG. In that direction, one should know to which RC a message is belonging to be able to select the correct SG (one can use different SGs for different traffic ranges) So, one needs to analyze the message coming from user application to be able to decide to whihc RK it is corresponding. Well, this responsibility can be given to user application but I prefer not to make M3UA constructs visible to user applications as much as possible.
For INCOMING traffic, for most of the implementations RL is enough to demux the message, because SS7 user parts are not aware of different route keys, they only know point codes. But I agree that depending on implementation, a real RK analysis can be needed and in such a case to have RC in DATA will save the demux effort, but it seems most of the people haven't choosen that approach. 
As you have pointed out in some of your former messages, it is important to make general mechanisms in SUA and M3UA as similar as possible. I agree that AMF can be database size on SG side for SUA, but I don't know whether the same complexity is needed in AMF on ASP side or not.

      Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 4:06 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 16:34:41 -0500

Tolga,

Please see comments below...

Asveren, Tolga wrote:                                    (Tue, 21 Aug 2001 15:40:31)
> Brian,
> 
> The case I am speaking of is for OUTGOING traffic, from ASP to SG. In that
> direction, one should know to which RC a message is belonging to be able to
> select the correct SG (one can use different SGs for different traffic
> ranges) So, one needs to analyze the message coming from user application to
> be able to decide to whihc RK it is corresponding. Well, this responsibility
> can be given to user application but I prefer not to make M3UA constructs
> visible to user applications as much as possible.

Per the AS model, the RK is not used to select from different SGs.
In M3UA V8 one of multiple SGs is selected on the basis of SG state
(open SGP association for which the ASP is ASP-ACTIVE) and routeset
availability, restriction (and possibly congestion) on a per active
SGP basis (SHOULD) or per SG basis (MUST).  RK need never be involved.

It is true only that the ASP need examine the DPC in the outgoing
message to determine the routeset availability.  This is not an
application of a RK (which is outgoing message OPC based).  It is
true that some MTP functionality (traffic routing) must be performed
in the ASP for the multiple SG case, but this is an oddity only of
the multiple SG case.  For single SGs the ASP need neither examine
the message nor maintain any state concerning outgoing routesets.

Neither case (single or multiple SGs) need apply RK (nor needs RK)
where RC is available.

>
> For INCOMING traffic, for most of the implementations RL is enough to demux
> the message, because SS7 user parts are not aware of different route keys,
> they only know point codes. But I agree that depending on implementation, a
> real RK analysis can be needed and in such a case to have RC in DATA will
> save the demux effort, but it seems most of the people haven't choosen that
> approach. 

I would agree for "some configurations" but not for "most implementations."
I also agree for "some vocal people" but not for "most of the people."

I might point out that these people and these configurations or
implementations of which you speak of must not be using RK's based
on ISUP CIC-range, or SCCP SSN (per Greg's approach).  Suggestions
to remove ISUP CIC-range and even SCCP SSN from the M3UA draft
received strong opposition, so we can asssume that there are people
who intend to use these capabilities.  (I am using CIC.)  The NA
approach does not meet the needs of ISUP CIC-range nor SCCP SSN
based routing keys.

There is no reason here to break the SIGTRAN AS model for M3UA,
particularly when RC will serve "all of the configurations and
implementations" and suit the approach of "all of the people",
including CIC and SSN RKs.

There is little reason for those wishing to implement only a subset
of M3UA capabilities to force a more restricted model than the AS
model on M3UA and preclude others from using M3UA's full range of
capabilities in the manner which was intended when the WG formed the
AS model, particularly where the concensus AS model will do the job
for these restricted cases plus the more general cases perfectly
well.

> As you have pointed out in some of your former messages, it is important to
> make general mechanisms in SUA and M3UA as similar as possible. I agree that
> AMF can be database size on SG side for SUA, but I don't know whether the
> same complexity is needed in AMF on ASP side or not.

AMF need not even be present in ASP because SUA follows the SIGTRAN
AS model and uses RC in all SUA messages.  The current SUAv7 spec
does not include a registration procedure (although one has been
proposed) and the only way to configure RCs in SUAv7 is by static RC
configuration.  Because the RK:RC:AS relation is a 1:1:1 relation,
RC is sufficient to identify AS both at ASP and SGP and there is no
need to maintain RK at the ASP and no AMF (which only maps RK to RC
anyways) need be present.

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 21 Aug 2001 14:45:22 -0700

Please read all of this before you comment.

I think our main differences come from what we want M3UA to be.  I want M3UA
to be a protocol that is a true peer to MTP3 (similar to MTP3b which is an
extension of MTP3)(non-backhaul).  I think you want M3UA to be an
interworking function to span the gap between MTP3 and the MTP-users located
remotely (backhaul).  Actually, I think M3UA can be both.  We also differ in
the functionality that we plan to support in our nodes.

The real issue boils down to traffic separation.  Both usages of M3UA have
their traffic separation needs and I think there could be a middle ground,
so see me through to the end.  I know its long but I like to get all the
facts laid out.

Scenario 1:  Simple case - non-partitioned node - single network. For
example, an existing SS7 node migrating to use IP transport.  The mode of
operation for node is to remain the same, hence, routing to node remains PC
oriented.  Hence, a single RK is defined for the node (RK == PC).  No RC or
NA is needed since no traffic separation is needed.

But suppose that the node's M3UA does not want to deal with SS7 parameters,
an RC (RC == RK) could be used but it seems pointless in this case.

Scenario 2:  Multiple network case for scenario 1.  In this scenario, an RK
is required for each network involved (node has PCs assigned from each
network).  Since multiple networks (and protocols) are involved, a parameter
is needed in all M3UA messages to separate the traffic (to much analysis is
needed to figure it out from the messages' content).  Also, separate
protocol stacks may be require at the MTP user level and it may also require
multiple M3UA stacks for the processing of the messages.  This is an
implementation issue.  Since the node implements M3UA as a protocol, an NA
(NA == ID) is all that is needed to steer the message to appropriate stack.

An alternate solution of RC (RC == ID + RK) is possible if the node does not
already support the MTP3-like procedures.

But either solution should be an implementation's choice other than it does
require the SG(s) agreement of using either NA or RC.

Scenario 3:  Simple case - partitioned node - single network.  In this
scenario, each node element wants its own set of traffic.  Some elements
might share traffic sets, but lets assume that they don't.  In this case,
each element has its own unique RK.  No RC or NA is needed since no traffic
separation is needed (traffic was already separated by the SG(s)) BUT if the
implementation does not want to deal with SS7 parameters, an RC (RC == RK)
could be used.  To use an RC, the SG(s) would need to agree to supply the RC
in the DATA message.  RC is not needed in SNMMs since an M3UA implementation
must analyze these messages - assumption is that the elements are connected
to more than one SG.  This scenario does require the SG(s) to send SNMMs to
each node element since the node is not really functioning (in a management
sense) as a single node (each element has its own remote status).

Scenario 4:  Multiple network case for scenario 3.  In this scenario, an RK
is required for each network involved (node has PCs assigned from each
network and each node element services its own sub-set of the traffic from
each network).  As in scenario 2, there are 2 solutions.  If separate stacks
are used, an NA (NA == ID) in all messages is all that is needed to separate
the traffic.  It is also possible to use RC (RC == ID + RK) to separate the
traffic.

Scenario 5:  Partitioned node - multiple RKs per element - single network.
In this scenario, an RK is required for each traffic set defined.  If the
node implements MTP-like routing functions, it only needs to examine the
appropriate SS7 parameters to separate the traffic (i.e., no RC is needed).
If the node does not want to examine the SS7 parameters, an RC (RC == RK) in
the DATA message could be used to maintain the traffic separation from the
SG(s) through the element.  Only in the case where the element maintains
separate remote status per RK supported would an RC be needed in the SNMMs.
This seems to be extreme but it could be possible.

More scenarios are possible, but I think the point is that depending on the
functionality of the implementation, different valid solutions are possible.
M3UA should not force a specific implementation.  Hence, I can see where it
would be valid to have both the NA (== ID) and RC (== [ID +] RK) as optional
parameters for the messages.  Of course, RK could just be another ID
associated with the RK, hence RC could be just == ID.  If you only want a
single optional parameter, pick a generic name and make the definition
flexible enough so that it can be tailored to the situation.

John
"Don't Fence Me In"

> Sent: Tuesday, August 21, 2001 2:13 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 20:10:34 -0500

John,

(Please read my entire comments before answering.)

John Schantz wrote:                               (Tue, 21 Aug 2001 14:45:22)
> extension of MTP3)(non-backhaul).

Being close to MTP3b is not an objective on M3UA.  It is, however, the
approach taken by M2PA.  What you appear to want to do was discussed at
great length a good while ago.  I had identified a need for an M3PA at
that time which would provide what you are looking for.  It was Greg's
opinion (and a few others) that M3UA could somehow be adapted to handle
the peer case as well.  I argued long an hard that if the ASP was not
made aware of routeset restriction that M3UA could not operate with
multiple SGs.  It took forever to get C-links between the multiple SG
as STPs in the diagram.  Now it is clear that DUPU must be provided by
the ASP in the multiple SG case where RK is based on SI.

It was Greg's opinion at the time that with some additional functionality
that M3UA could be made to handle this multiple SG case as well and that
an M3PA protocol (peer to peer) was not required in addition to M3UA
(backhaul) and that M3UA could be made to handle both cases (it was
originally just backhaul).  There are still issues popping up with this
configuration.  The IPSP case in M3UA is clearly underspecified and it
is not clear from discussions on other threads and has been raised as
an issue for M3UA on a good number of occasions that it does not properly
address the non-backhaul cases, particularly where multiple SGs are
involved.  This is also an issue for SUA (the IPSP case) where it is
also under-described and still has many salient issues as well.  M2UA
does not suffer this problem, it has M2PA to handle the peer to peer
case.  IUA doesn't really make sense peer-to-peer.

Because both M3UA and SUA poorly address the IPSP case and it is not
clear how the ASPSM and ASPTM procedures even apply (or whether they are
even needed), the recent discussion arose concerning the possibility of
specifying a protocol for the IPSP cases (say, M3PA and SPA).  This has
met with some interest.  (See thread "Network Evolution").

As such, backhaul is the predominant case for M3UA and any peer
functionality that you might find there you can thank me for by not
ruling out the backhaul case which M3UA was intended to address from
inception.  The backhaul case has more significance within the SIGTRAN
architecture because there are existing protocols which address the IPSP
case in a satisfactory manner (TALI, ISTP) and are already fielded.

IMO, the backhaul case for M3UA takes precedence over the non-backhaul
case, it only because of the significance of the backhaul case within
the SIGTRAN architecture and the shoe-horned nature of peer functionality
in the spec.

> I think you want M3UA to be an
> remotely (backhaul).

I have no wants in the matter: M3UA *provides* for this case in the draft.
M3UA should be usable in the fashions which it are proscribed in the draft,
which includes the backhaul case where the MTP-User interface is exported
to an ASP and usable by MTP-User without modifications.  This is clearly
stated in the draft as a supported architecture and an objective of the
protocol.

Even in the non-backhaul case, M3UA's architecture declares that the MTP-User
interface can be used unchanged and that M3UA in the non-backhaul case
acts as a transport from MTP-User interface to MTP-User interface.  You
seem to want to dig below the MTP-User interface (users are bound by SI and
are attached to only one signalling point, regardless of how many signalling
point codes that SP has).

> Actually, I think M3UA can be both.  We also differ in

It remains to be seen whether the M3UA can properly support anything more
than a restricted range of functionality for the multiple SG case and
still meet its other objectives.

I believe that we differ in the funcationality that we plan to support
as follows:

	- I plan to support the full range of M3UA functionality
	- It appears you only plan to support a subset.

> so see me through to the end.  I know its long but I like to get all the

I agree that the issue is on of traffic separation: traffic separation
is address in the UA AS model using RK/RC/AS.  (Note the lack of NA).
Please hear me out.

> NA is needed since no traffic separation is needed.

Scenario 1 is not at issue.  Where there is only a single AS per association,
the AS (and thus RC) is implicit in the identification of the association.

> an RC (RC == RK) could be used but it seems pointless in this case.

I don't understand your point: (RC == RK)?  The draft and the concensus
AS model guarantees a 1:1 relationship between RK and RC and AS?

Do you mean that an RC could be placed in the messages in Scenario 1?
That is at the sender's option.  The ASP need not rely upon it because
any required RC value can be directly associated with the STCP association
id.

> network).

This means that there are two RC values: one which uniquely identifies
each Routing Key.

> Since multiple networks (and protocols) are involved, a parameter
> needed to figure it out from the messages' content).

We already have two RK's, two RC's and two AS's by definition of the
AS model.  The RC is sufficient to distinguish between the two AS's:
by definition.

> Also, separate

NA == ID is not needed.  There are already two RC values, one for each
AS, by definition in the concensus AS model.  Why do we need an NA?

> already support the MTP3-like procedures.

This is not an alternate: we already have two RC's which identify the
traffic flows by nature of the 1:1:1 relation between RK:RC:AS.  To
separately activate and deactivate traffic to these two AS using ASPAC
and ASPIA messages, the RC's alread exist.  They are not RC == ID + RK:
they are RC <=> RK.  It is the RK that has the Network ID in it.  The
Netowrk ID is already implicit in the RC, why the need for NA?  If you
really want the RC *value* to be the Network ID *value* anyone is already
permitted by the AS model to assign RC as such.

> require the SG(s) agreement of using either NA or RC.

There is no need for the NA: the SG and ASP already are required to agree
over the value of RC: there are two RC's in this scenario, each which
uniquely identifies the traffic flow.  The RC value is required for ASPAC
and ASPIA for multiple AS over the same association anyway.  Just put the
same RC in the messages that you put in ASPAC and ASPIA.  If you require
an NA in the messages, it will have to be generated in *addition* to the
RC values which are already required in this scenario for ASPAC ASPIA.

Therefore, for Scenario 2, NA is not required and the existing values
(already assigned) for RC will suffice.

> sense) as a single node (each element has its own remote status).

This is equivalent to Scenario 1.  It is already at the SG and ASPs option
to place RC in ASPAC or ASPIA even though it is implicit in the SCTP
association.  The receive would be foolish to rely on it in this case,
but can use it if it is there.  Because there are multiple RKs, the SG
might very well have one RC value per RK anyway, by definition.

Scenarios 1 and 3 are not at issue.

> the traffic.  It is also possible to use RC (RC == ID + RK) to separate the

Again, because there are multiple RKs (RCs, ASs) per association, there are
already unique RC values for each routing key.  There is no need to generate
and maintain NA in the message, RC already identifies the traffic flows.
RC never needs to be set to ID + RK, because ID is part of RK.  RC is a
unique identifier of both an RK and an AS.

> appropriate SS7 parameters to separate the traffic (i.e., no RC is needed).

Ummm, RC is still there.  There are multiple RKs and multiple ASs: there is
one unique RC value for each RK and AS for use in ASPAC and ASPIA.  Therefore
there is no need to implement MTP-like routing functions because these
existing RC values can be placed in the messages.  M3UA does not require
MTP-link routing functions: it does require RC values consistent with the
concensus AS model.  RC needs to be there anyway, MTP-like routing need
not be.

> This seems to be extreme but it could be possible.

RC can be placed in SNMM because it is already there at the SG.  It would be
foolish for the SG not to provide this information which is immediately at
it's disposal (it has a 1:1 association with the Routing Key which is used to
identify the AS to find the ASP to find the SCTP association over which the
message needs to be transmitted).  That's how the AS model works, John.

> functionality of the implementation, different valid solutions are possible.

The existin NA approach violates the concensus AS model.  The guarantee that
the SG gives the ASP by placing a value in the RC in a message is that this
RC value has a 1:1 association with an RK and an AS.  NA makes no such
assurances.  Your scenarios are contrived in that the NA uniquely identifies
an RK by happenstance.

> M3UA should not force a specific implementation.

There is no problem with M3UA providing the concensus AS model over this
unworkable NA approach.  It is consistent with the goals of the SIGTRAN
architecture, the WG, the charter, the other UAs.  It will even works
like a charm in all the scenarios you presented here.  Nothing will be
forced.  The RC values are a necessary part of even the M3UAv8 because
they are used to identify the RK/AS in ASPIA and ASPAC.

> Hence, I can see where it
> parameters for the messages.

I don't see where it is valid or even necessary to have NA in DATA and
SNMM at all.  RC will do just fine.  Please present (if you can) a scenario
where RC will not suffice in place of NA.

> Of course, RK could just be another ID associated with the RK,

I think you misunderstand the AS model: there is a 1:1:1 relationship
between RK:RC:AS.  Therefore, the RC *is* both an RK Id and an AS Id.

> hence RC could be just == ID.

You are welcome to assign RC <= ID in the existing AS model as long as
this value of RC uniquely identifies a traffic flow (that is, the only
RK's that need distinguishing are different only in ID).

> If you only want a single optional parameter, pick a generic name and make
> the definition flexible enough so that it can be tailored to the situation.

Let's do that:  Lets take a parameter and call it Foo Bar.  For scenario
5, Foo Bar will need to uniquely identify an AS so that demultiplexing
can be performed at the ASP.  It is sufficient for scenarios 2 and 4 that
Foo Bar uniquely identify an AS so that traffic can be distinguished
between networks (each AS belongs to a different network by definition).
In scenarios 1 and 3, Foo Bar need not be placed in SNMM and DATA.

So we will include the Foo Bar parameter as optional in SNMM and DATA
and get rid of NA.  The definition of Foo Bar is:

	Foo Bar: a 32-bit integer value agreed between SG and ASP which
	         uniquely identifies an AS.

We will place the definition just before Routing Context:

        Routing Context: a 32-bit integer value agreed between SG and ASP
	         which uniquely identifies an AS.

I'm pretty sure then it won't be long before RC is used instead of Foo Bar,
because their definitions are identical.

Which leads to the situation as already proposed by Gery:

	replace NA with RC in all M3UA messages except REG REQ.

It is clear from your scenarios that RC in DATA and SNMM means that
there is no need for NA in those messages.  If you really wanted the
NA *values* for some purpose, you have already been invited to set
the RC *value* to the same value in the same circumstances.  Text could
even be included to assure this.  I cannot see that it would take much
effort even to convert an existing implementation of some draft version
of M3UA to the concensus AS approach.  Simply tag the NA parameter in
each DATA or SNMM message with the RC tag instead of the NA tag.

I have not seen any scenarios where RC cannot completely replace NA.
I have presented scenarios where NA cannot take the place of RC.

RC/IID is already present and well defined within the AS model in all
UAs.  NA has a contentious and unclear definition with some problematic
administrative concerns.  We are not adding RC to M3UA.  We are merely
using it where NA was before because NA is unnecessary and poorly suited
to the task of traffic separation.  RC identifies traffic flows by
definition (it has a 1:1 relationship with RK which is the only thing
used to separate traffic between AS).

Take the offer to assign particular values to RC in restricted scenarios
(such as your 1, 2, 3, and 4).  This could meet even restricted
implementation dependent needs if the implementation is largely incapable
of supporting the concensus AS model).

My major reason for not wanting NA hanging around in DATA and SNMM
messages is that my ASP needs the gurantee provided by RC in the AS
model which states that the RC value has a one to one relationship
with a Routing Key (so I don't have to apply a RK to identify the
traffic flow for the message) and a one to one relationship with an
AS (so I don't have to examine anything other than RC to demux traffic).
These are the assurances which are provided by IID and RC in all other
UAs and is a principle part of the AS model that the RK be used to
separate traffic flows and RC be used to identify each flow.

Even if you assure me that in all configurations the setting of NA
will uniquely identify the AS, NA is unnecessary because then its
definition becomes that of RC, an already existing parameter.

So, John, please comment on proposal to *replace* NA with RC in all
M3UA mesages except REG REQ.

Can you think of a scenario which you require where (assigned to
whatever *value* you wish as long as that value uniquely distinguishes
AS) RC alone will not suffice?

I have not seen one presented yet.  RC replaces NA nicely in the 5
scenarios you present here, and I'm pretty sure that if you knew of
a scenario where RC would not do the job you would have mentioned it.
But, its worth a shot:  Do you know of a useful M3UA scenario where
RC alone will not suffice?

--brian

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

---

---

From: [email-masked]
Date: Wed, 22 Aug 2001 09:19:23 +0300

Hi John S.,

Thanks for the scenarios, I think they illustrate the points
well.

> More scenarios are possible, but I think the point is that 
> depending on the functionality of the implementation, different 
> valid solutions are possible. M3UA should not force a specific 
> implementation.  

Agreed.  I think that we should just make sure we cover all of the
bases & have a flexible enough solution.

> Hence, I can see where it would be valid to have both the NA (== ID) 
> and RC (== [ID +] RK) as optional parameters for the messages.  Of 
> course, RK could just be another ID associated with the RK, hence RC 
> could be just == ID.  If you only want a single optional parameter, 
> pick a generic name and make the definition flexible enough so that 
> it can be tailored to the situation.

I think that we are all converging on a solution here.  My proposal, 
Would be:

	RC = [ID] + [RK]

In otherwords, a Routing Context MAY contains one of the following options:
	ID
	RK
	ID + RK (in this case the ID applies for all of the RK contained in
the RC)

I still like the term routing context because it implies that this
parameter provides the context on how to distribute the traffic
for which the RC is valid over.

I think that the authors of M2UA, M3UA, SUA and interested parties (Brian,
Gery, John S. ...) should try to normalize the language sufficiently
over the terms NA (ID), RC, RK so as to have agreement.  

I think the solution will be much more architectural clean & much
easier to administer if these concepts were harminized among the
UAs .

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 01:50:07 -0500

John L.,

Speaking of normalizing language....  I don't follow your
"parameter math" here.  What is 

> 	RC = [ID] + [RK]

supposed to mean?

> 	ID + RK (in this case the ID applies for all of the RK contained in the RC)

Sorry, but this description doesn't help me: how does an
RC "contain" an RK and how does one "apply an ID" to such
a "contained" RK?

It completely escapes me as to what you are proposing here.

Let's start with this: RC is a 32-bit value.  What value is
[ID] + [RK] and how does that preserve the 1:1 relationship
between RK, RC and AS?

--brian

John Loughney wrote:                                         (Wed, 22 Aug 2001 09:19:23)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 11:54:45 +0200

Hi Ken,

This would introduce ambiguity in the implementations, or yet another thing
to configure (use NA or use RC). The main purpose of the proposal was to
have, over all UA's, the same parameter in the protocol messages for
describing the SS7 traffic context.

You'd have to worry about provisioning the NA anyway; there's no additional
worry if NA is sufficient as RK and you can use it as RC. There is
additional worry if you allow to use both.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: dinsdag 21 augustus 2001 19:28
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2001 09:27:16 -0500

Brian,

Please see comments below:

......
>>>SGP basis (SHOULD) or per SG basis (MUST).  RK need never be involved.
......

You also say that SGP is selected based on finding an association for which
the ASP is ASP-ACTIVE. But how can you guarantee that ASP is active for all
of the ASs it is serving in the same SGs? It is possible that it is active
for AS1 in SG1 but for AS2 in SG2. So, that the state is ASP-ACTIVE does not
mean that it is active for all of the ASs (as we were discussing in another
thread, ASP state machine is per AS). So, ASP-ACTIVE is a per AS state. You
should know to which AS a traffic is belonging to to be able to select the
correct SG, unless there is a limitation which says that an ASP should be
active for all of the ASs it is serving in one SG or inactive for all of
them.

      Tolga 

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 22 Aug 2001 07:28:43 -0700

Well at least the 2 Johns can "read" and "see" what was written.  I was
about to reply back to BB to say that I had wasted my time - clearly not a
person that has ever dealt with people in standards and needed to understand
other peoples' views and opinions to reach a compromise.

Lets move forward and I'll forget the last BB message.

John

> Sent: Wednesday, August 22, 2001 1:19 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 10:36:52 -0500

Tolga,

Asveren, Tolga wrote:                                    (Wed, 22 Aug 2001 09:27:16)
> active for all of the ASs it is serving in one SG or inactive for all of

Yes, ASP-ACTIVE state is on a per-AS basis.  That is: the ASP knows when it is
active for a particular AS and when it is not.

The AS is where the traffic is coming from.  The AS does not need to be
selected for outgoing traffic: it is the MTP-User.  The RC can be implicit to
the MTP/MTP-User interface at the AS and, therefore, ASP does not need to
maintain RK.  It is not always possible to apply an SG RK to an outgoing
message at an ASP anyway.  RKs are stated in terms of traffic in the SG to ASP
direction and, as Greg pointed out, don't always have an obvious ASP to SG
equivalent.

--brian

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

---

---

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

John,

The proposal on the table is to replace NA with RC in all
M3UA messages except REG REQ.  Your proposal is different
(both NA and RC somehow).

You have not shown a scenario where RC will not suffice
as a replacement for NA.

Can you present such a scenario?

Please comment on the replace NA with RC proposal.

--brian

--

John Schantz wrote:                                          (Wed, 22 Aug 2001 07:28:43)

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

---

---

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

I already did but you couldn't "see" it.

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 22 Aug 2001 18:05:57 +0200

Hi John,

Please do me a favor and point to the scenario you have in mind, it is easy
to miss the point in long descriptions, whether they come from Brian, you or
anyone else.

But as far as I could notice, you seem to use NA where RC is at least
equally appropriate. If this is not the case (I could easily have missed
something), there's a flaw in the AS/RK/RC definitions which should be
addressed as quickly as possible. 

Thanks,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: woensdag 22 augustus 2001 17:50
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Wed, 22 Aug 2001 09:19:18 -0700 (PDT)

Hey Folks,

Let's keep this discussion under control.

From the discussion, I think there are still
two models of how SGs and ASPs work 
in M3UA, a "simple" model and a "distributed
ASP" model.  We should be able to come up
with a protocol compromise that supports both.

Maybe the respective parties can work out an
informational document that explains the models
and how they apply the tools in M3UA (at least
Brian's emails put together would probably
form a rather large book (The Gospel of
Sigtran AS?  The Epistles of Brian?), but
this can be done later.

Right now it seems like we're actually close
to a compromise, where either RC is optionally
included and in some cases is used identically
to "per network" NA, or where both RC and NA
are optionally included and used separately.

The first seems a bit simpler if we can work
out acceptable text (NA reverts to the older
definition, any notes needed to the use of RC?)
Why don't we see if we can reach a compromise
on that basis?

Cheers,

L. Ong

--- "Schantz, John" <[email-masked]> wrote:
> > John Schantz wrote:                               
> > (Wed, 22 Aug 2001 07:28:43)
> > > Well at least the 2 Johns can "read" and "see"
> what was 
> > written.  I was
> > > about to reply back to BB to say that I had
> wasted my time 
> > - clearly not a
> > > person that has ever dealt with people in
> standards and 
> > needed to understand
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 12:49:06 -0500

Lyndon,

I have no problems with the first approach.  I have problems
(Epistels of them) with the second.

--brian

Lyndon Ong wrote:                       (Wed, 22 Aug 2001 09:19:18)

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2001 13:40:38 -0500

....resending for the second time

Brian,

My point is that you assume registeration of MTP3 users id done per AS. So, a user application (e.g. a call control) should select the correct MTP3 user to send its traffic, then on M3UA one does not need to worry about the AS value because there is 1:1 relationship between MTP3 User and AS. What I am saying is that, this is not the only possible implementation way, although -probably to your suprise- I also follow this approach. It is also possible to have implementations where there isn't a 1:1 relationship between MTP3 User and AS. And also, it should be noted, even in the former case (1:1 relationship case), still a decision should be done -this time on user application level- to send the traffic to the correct MTP3 user base on RKs. So, at some place on ASP side an analysis is required.

      Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:37 AM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

--brian

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

---

---

---

From: Ken Morneault <[email-masked]>
Date: Wed, 22 Aug 2001 14:10:27 -0400

Gery,

Pls see below.

Ken

>describing the SS7 traffic context.

Quite the opposite.  If an ASP is happy using NA + Routing Label to
route messages, then it does not need to have RC provisioned.  For
this type of ASP, the operator that provisions the SG must be aware
that RC must be provisioned to be NA (if NA is left out of DATA and SSNM
messages).  I believe this adds ambiguity.  Given that you think there
will be some ASPs that do not need RC (as noted from your previous
email) what is the harm in having NA and RC in DATA and SSNM
messages? 

---

---

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

Ken,

The current defintion of NA presents problems for provisioning
and adminstration of values which is unacceptable to even those
supporting NA.  No case has been presented where the previously
NA providing SG cannot get away with simply retagging the NA
with the RC tag.

Replacing NA with RC removes the requirement for static
provisioning of NA values at the ASP and removes the ASPs RK and
RL dependencies, yet doesn't affect SG implementations based on
NA aside from retagging.

Replacement has clear advantages for the ASP over running both.

--brian

Ken Morneault wrote:                                          (Wed, 22 Aug 2001 14:10:27)
> >Fax: +32 14 25 3212

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

---

---

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

Lets get back to "nuts & bolts".

RK is defined as a set of SS7 parameters and parameter values.

RC is defined as just an "index/ID assigned to the RK entity.

Hasn't anyone else noticed that protocol variant and network "appearance"
are not SS7 parameters or values and therefore is not part of RK (hence, not
implied by RC).  This part of the NA definition is the only thing that is
consistent between the v5/v6/v7/v8 definitions of NA.

Therefore, RC does not contain this critical piece of information since it
is defined as only SS7 parameters.

This is also the reason why the Johns were trying to re-define RC as:

	- ID (NA, v5/v6 definition),
	- RC (old definition of RC),
	- ID (NA, v5/v6 definition) + RC (old definition of RC)

depending on the situation (RK had been used to show that it was SS7
parameter information and because somebody wanted a PC in there).  This
whole thing started because somebody wanted a PC in there.

John

> Sent: Wednesday, August 22, 2001 2:27 PM
> To: sigtran

---

---

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

Tolga,

Asveren, Tolga wrote:                                    (Wed, 22 Aug 2001 13:40:38)
> My point is that you assume registeration of MTP3 users id done per AS. So,
> a user application (e.g. a call control) should select the correct MTP3 user
> to send its traffic, then on M3UA one does not need to worry about the AS
> value because there is 1:1 relationship between MTP3 User and AS. What I am
> saying is that, this is not the only possible implementation way, although
> -probably to your suprise- I also follow this approach.  It is also possible
> to have implementations where there isn't a 1:1 relationship between MTP3
> User and AS. And also, it should be noted, even in the former case (1:1
> relationship case), still a decision should be done -this time on user
> application level- to send the traffic to the correct MTP3 user base on RKs.

I think you are confusing RK:  Take an illustration of your example
where there is not a 1:1 relationship between MTP-Users and AS.  We have
an AS which has a routing key which includes both SI=ISUP and SI=SCCP.
When the message is sent from SG to ASP, it is labelled with the RC
value which has a 1:1 relationship with this RK(SI=ISUP+SCCP).  At the
ASP, the message is delivered to the AS by RC value.  Note that the RK
does not distinguish between ISUP and SCCP, so reapplying it at the ASP
serves no purpose.  Once the message is delivered to the AS, and out of
the M3UA at the ASP, the AS itself decides what to do with SI=ISUP or
SI=SCCP.  If the AS wishes to receive SI=ISUP separated from SI=SCCP,
for example, there should be two routing keys: SI=ISUP and SI=SCCP.
If the MTP-User is willing to have messages for more than one SI
delivered to it aggregated, RKs with multiple SI(ISUP+SCCP) are provided.

I do not believe that it is expected behavior in the AS model for the SG
to use one RK (e.g., SI=ISUP+SCCP) yet require the ASP to use another
(two RK's: SI=ISUP and SI=SCCP).

> So, at some place on ASP side an analysis is required.

For multiple SI values, it should be the AS's responsibility to split
traffic which it has requested be delivered to it aggregated, not the ASP
or the SG of which the aggregation was requested.

Now, details at the ASP/AS boundary is completely implementation
dependent and you can move the boundary back and forth as you like.
You can even accomplish in your implementation this splitting of SI
values before delivery to separate MTP-Users at the ASP.

RC still provides such an implementation value in not having to apply
the SG's version of the RK, nor examine the RL to determine the form
(variant) of the routing label.  Such an ASP need only index on RC and
then split on SI.  Without RC, such an ASP will need to determine the
form (variant) of the Routing Label (implicit or statically provisioned
NA) and filter each message through a list of variant specific SG RKs.
The RK values (if maintained in the same form as that of the SG for
dynamic registration purposes) will still only yeild an RC corresponding
to the SG RK(SI=ISUP+SCCP) and SI splitting will still have to occur.
RC in the message removes the need to maintain a copy of the SG's RKs
in the ASP, and removes the need to reapply a potentially long list of
SG RKs to each message.  From an ASP designer's viewpoint, it is rather
annoying not to have RC in the message whenever it is not implicit.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2001 15:24:09 -0500

....sending for the second time

Brian,

I agree with the things you are saying but I am speaking for outgoing
traffic in ASP to SG direction. Your comments are related with SG to ASP
direction and as I have indicated above I agree with them.
 
     Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 4:05 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

Asveren, Tolga wrote:                                    (Wed, 22 Aug 2001
13:40:38)

--brian

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

---

---

---

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

John,

John Schantz wrote:                                          (Wed, 22 Aug 2001 12:53:44)
> consistent between the v5/v6/v7/v8 definitions of NA.

Network Appearance is a parameter of the Routing Key in REG REQ.
> is defined as only SS7 parameters.

This information is already implicit in RC.

> whole thing started because somebody wanted a PC in there.

The above does not follow because NA is implicit in RC.

--brian

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

---

---

From: Ken Morneault <[email-masked]>
Date: Wed, 22 Aug 2001 16:43:39 -0400

Brian,

Pls see below.

Ken

>NA providing SG cannot get away with simply retagging the NA

I agree that retagging NA with the RC tag will work.  The issue I have 
is with the "get away with" part of your statement.  I'm saying it is
cleaner to keep NA in these messages while adding RC so that
we do not have a need to "get away with" retagging NA with RC tag.
Then, there would be no need to have the operator or SG understand
that it needs to retag NA with RC tag in some cases.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 16:07:37 -0500

Ken,

Ken Morneault wrote:                                          (Wed, 22 Aug 2001 16:43:39)
> that it needs to retag NA with RC tag in some cases.

The operator need not be concerned at all.  The SG which is
incapable of anything else merely configures its RC values
that way from the start.  NA need not even be provisioned.
RC is provisioned instead.  If a particular SG implementation
places limitations on the range of assignable RC values,
and that is perceived in the field as a limitation of the
implementation, I would suggest that the implementation be
redesigned so as to relieve the restriction.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 Aug 2001 16:24:01 -0500

Tolga,

Asveren, Tolga wrote:                                    (Wed, 22 Aug 2001 15:24:09)
> direction and as I have indicated above I agree with them.

In the ASP to SG direction there is no way for the SG to determine which
DATA and SNMM messages are coming from which AS unless the RC is placed
in DATA and SNMM messages.  The SG will be incapable of ASPTM procedures
as applied to DATA and SNMM messages on a per-AS basis where multiple ASs
exist on the same association.

M3UAv8 says:

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

and

  "If the SGP or IPSP receive any Data mesages before an ASP Active Ack
  message, the SGP or IPSP MAY discard them."

But without RC in DATA and SNMM in the ASP to SG direction where RC is not
implicit to the association, the SG cannot distinguish the "related Routing
Context(s)" and has little choice but to process the message.

Actually, the SG cannot tell in this case whether the messages belong to
an AS which is not even configured.

The same is true in the reverse direction.  The ASP may apply the entire
routing key list to the message just to discover that the message does
not match any routing key and needs to be discarded.  What does the ASP
send the SGP in this case?  With RC in the message, the ASP sends
ERR ("Invalid Routing Context").

ASPTM procedures for M3UA cannot work the same way as the other ASs because
RC is not carried in all messages other than ASPUP/Ack ASPDN/Ack and REG REQ.
All other UAs carry IID/RC in all messages other than ASPUP/Ack ASPDN/Ack and
REG REQ.

This makes the discussion of whether RC should be included in DATA and
SNMM rather moot.  RC is required in the messages where not implied for
proper ASPTM handling at both the SG and the ASP.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2001 17:17:04 -0500

Brian,

Thanks for thebrief explanation about "SGP management thread", which I couldn't follow.
Just a small question, if we assume that some RKs don't have an obvious ASP to SG equivalent, then how can we find the RC of a message from ASP to SG direction on ASP side? (When I say ASP side, it includes user application, MTP3 Users, NIF, M3UA)

      Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 5:24 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

M3UAv8 says:

and

--brian

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

---

---

---

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

Tolga,

Asveren, Tolga wrote:                                    (Wed, 22 Aug 2001 17:17:04)
> Brian,
> 
> Thanks for the brief explanation about "SGP management thread", which I
> couldn't follow.

The short problem is that SGPs can't manage the load that they are
offerred in M3UA.

Also, M3UA SGs can't do ASPTM procedures where RC is not implicit
because the SG does not know to which AS any received DATA or SNMM
messages belong.

> Just a small question, if we assume that some RKs don't have an
> obvious ASP to SG equivalent, then how can we find the RC of a
> message from ASP to SG direction on ASP side?

Use the 1:1 AS to RC relationship: if we know the AS we know the RC.
The RC is either statically assigned to the AS or associated with
the AS at registration.  Where it is not implicit, the ASP must
already have the RC value associated with the AS because it needs
it for the ASPAC.

> (When I say ASP side, it includes user application, MTP3 Users,
>  NIF, M3UA)

Even where there is multiple users per AS, each user selects only
one AS for outgoing messages.  The RC is an attribute of the AS.

The 1:1:1 relationship between SG RK, RC and ASP AS allows RC to
identify the traffic flow both at the SG and at the ASP and is the
only value which is used for ASPTM procedures and the only value
necessary to identify traffic flow.  NA is cruft.

--brian

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

---

---

From: "Antonio Roque-Alvarez (ECE)" <[email-masked]>
Date: Thu, 23 Aug 2001 16:11:52 +0200

Hi all,

Coming back from holidays I found this huge amount of mail traffic. It's amazing...

First thing I will do is trying to understand what is the object of this discussion:

- RC should be included in DATA and SSNM messages.
 I agree.

 In SGP side, Incoming:
 In DATA messages, it will help the SGP to know what AS the message is coming from and thus will be able to check if the sending AS is already ACTIVE in that ASP or not in order to process or discard the message. 
 As long as the RC implies an NA the message will be delivered to the right SS7 Network (if there is more than one ). There is no need to make a check of the RL ( that is flavour/variant dependent ).
 In SSNM messages ( SCON and DAUD ) the use of RC is just substitutive of the NA. Am I right ?

 In SGP side, Outgoing:
 We can include RC in DATA messages without problems. It has been obtained in the routing. There we make a check of the RL of the message.
 The same applies to SSNM messages. If a MTP-PAUSE for an specific DPC implies more than one AS, a DUNA message will be sent to each one of these ASs. Corresponding RC can be then included in every DUNA sent.

 In ASP side, Incoming:
 In DATA messages, it will help M3UA to discriminate what AS the message is directed to. The ASP must have been previously statically configured with the relation between L3 Users and ASs. This can be as flexible as implementation allows. ( N users per AS, etc.. ). There is no need to make a check of the RL ( that is flavour/variant dependent ).
 Equally, In SSNM messages, RC will be used to know what L3 User(s) to send the primitive.
 In both cases if RC implies an NA ( and SI if the user cannot discriminate between Services ), the correct L3 user will be chosen.

 In ASP side, Outgoing:
 In DATA messages, a routing must be performed against the message RL in order to select the correct SG and its serving SGP. We find here with a new RK which implies a new RC. I will call them ORK and ORC ( from Outgoing ).
 The RC to be included in DATA and SSNM messages must be extracted from the previous statically configured L3 User - AS Relation Table.

- NA can be replaced by RC.
I agree as long as NA is implicit in RC.

Am I right or missing something ?

Also I have a question:

Let's suppose that one ASP has established two associations to two different SGPs (SGP1 and SGP2), both serving the same SG.
ASP sends ASPAC to SGP1 and receives ASPAC ACK. DATA and SSNM messages are interchanged.
In any time, ASP receives a DATA or SSNM message from SGP2. Is that correct since the AS state information is shared between all the SGPs serving the same SG ?

Cheers,
Antonio

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 12:39 AM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

--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: Thu, 23 Aug 2001 18:00:59 -0500

......resend

Antonio,

Welcome back!  The draft is fairly clear that if an ASP
sends data messages on an association for an AS for
which it has not sent an ASPAC and received ASPAC Ack
it is risking message loss and that the SGP MAY discard
such messages.

If, however, the SGP is capable of processing the messages
then I suppose it MAY the way things are worded, but
should give careful consideration to doing so because of
the possibility of message duplication.

Also NA *is* implicit in RC.  A routing key has the
characteristic that it cannot span multiple SPMC and
thus has at least one unique value for every value of
NA.  NA as it is defined is an attribute of the routing
key (Network Id + PC).

Implementations which need NA could easily map RC to NA.
But, because NA is less granular, there NA cannot be
mapped to RC.

--brian

Antonio Roque-Alvarez (ECE) wrote:             (Thu, 23 Aug 2001 16:11:52)
>  In DATA messages, it will help the SGP to know what AS the
>  message is coming from and thus will be able to check if the
>  sending AS is already ACTIVE in that ASP or not in order to
>  process or discard the message. 
>
>  As long as the RC implies an NA the message will be delivered
>  to the right SS7 Network (if there is more than one ). There
>  is no need to make a check of the RL ( that is
>  flavour/variant dependent ).
>
>  We can include RC in DATA messages without problems. It has
>  been obtained in the routing. There we make a check of the RL
>  of the message.
>
>  The same applies to SSNM messages. If a MTP-PAUSE for an
>  specific DPC implies more than one AS, a DUNA message will be
>  sent to each one of these ASs. Corresponding RC can be then
>  included in every DUNA sent.
>
> 
>  In ASP side, Incoming:
>
>  In DATA messages, it will help M3UA to discriminate what AS
>  the message is directed to. The ASP must have been previously
>  statically configured with the relation between L3 Users and
>  ASs. This can be as flexible as implementation allows. ( N
>  users per AS, etc.. ). There is no need to make a check of
>  the RL ( that is flavour/variant dependent ).
>
>  In both cases if RC implies an NA ( and SI if the user cannot
>  discriminate between Services ), the correct L3 user will be
>  chosen.
> 
>  In ASP side, Outgoing:
>
>  In DATA messages, a routing must be performed against the
>  message RL in order to select the correct SG and its serving
>  SGP. We find here with a new RK which implies a new RC. I
>  will call them ORK and ORC ( from Outgoing ).
>
>  The RC to be included in DATA and SSNM messages must be
>  extracted from the previous statically configured L3 User -
>  AS Relation Table.
>
> 
> Let's suppose that one ASP has established two associations to
> two different SGPs (SGP1 and SGP2), both serving the same SG.
>
> In any time, ASP receives a DATA or SSNM message from SGP2. Is
> that correct since the AS state information is shared between
> all the SGPs serving the same SG ?
> 
> Cheers,
> Antonio
> 
> 

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2001 13:56:31 -0500

...sending again

Brian,

I have two more questions-comments:

1) To select SG for traffic from ASP to SG direction
If ASP knows the RC, then it can select only among the SGs, which it has sent ASPAC for this RC. What it is wrong with this approach?

2) It is obvious there is a 1:1 relationship between AS:RK:RC. But in the case where one user application serves more than one RK (is part of more than one AS), then it should decide, a message it is sending is belonging to which AS. So, there will be a need of RK analysis on user application level in such a case. Unless it is said that a user application can't be part of more than one AS, I think this case should be also considered.

     Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 6:39 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

--brian

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

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2001 15:10:44 -0500

Brian,

I agree with the things you are saying but I am speaking for outgoing traffic in ASP to SG direction. Your comments are related with SG to ASP direction and as I have indicated below I agree with them.
 
     Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 4:05 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Tolga,

--brian

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

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 24 Aug 2001 07:07:13 -0500

Brian,

1) With the current approach any malicious or insane ASP already can send anything to SG. But if ASPs route to SGs also by considering RC, then normal working ASPs will have a chance, not to send traffic belongging to a RC, if they can't recieve traffic for that RC. I agree, that here the ultimate goal should be a screening on SG (or maybe a double screening?), which can be achieved if RC is in DATA message. According to me, this is a strong argument to include RC in DATA messages.

2)If you keep your RK simple (OPC/DPC) then of course analysing it will be also simple. But what if you also include CIC ranges? then the selection of the interface will be based also on CIC. If we call this analysis also trivial, then why is the same analysis not trivial on ASP itself?

3) In one of my former messages I have said that AMF in ASP possibly shouldn't be as complicated (data-base size) as the one in SG for SUA. I know, that in SUA there is no AMF on ASP, because Rc is used in DATA. My point is, it is not a very strong argument to include RC in DATA for SUA, becase one thinks AMF in SG is complicated and without RC one would need AMF also on ASP side.

     Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 7:00 PM
To: [email-masked]
Subject: Re: M3UA07: RC in DATA and SSNM messages

.....resend

Tolga,

Asveren, Tolga wrote:                                    (Thu, 23 Aug 2001 07:54:29)
> If ASP knows the RC, then it can select only among the SGs, which it has
> sent ASPAC for this RC. What it is wrong with this approach?

The only thing wrong is that RC is not in DATA and SNMM so that the SG
can know which AS the messages are for and can determine whether it
has the AS in the AS-ACTIVE state.  Otherwise, any malicious or insane
ASP can send whatever it may and the SG cannot determine whether the
traffic is valid.

If the ASP labels DATA and SNMM with the RC of the AS, the SG can perform
ASPTM and other functions on the traffic flow as identified by the RC.

> 
> 2) It is obvious there is a 1:1 relationship between AS:RK:RC. But in the
> case where one user application serves more than one RK (is part of more
> than one AS), then it should decide, a message it is sending is belonging to
> which AS. So, there will be a need of RK analysis on user application level
> in such a case. Unless it is said that a user application can't be part of
> more than one AS, I think this case should be also considered.

I think this is really a trivial matter:  an application has one interface to
M3UA bound to OPC=5/DPC=6/SI=ISUP another bound to OPC=5/DPC=7/SI=ISUP.  IAMs
received on interface #1 are responded to on interface #1, the same for #2.
There is no RK "analysis" here, the selection of RK is implicit in the
selection of the interface.  The selection of the interface is trivial and
obvious to the application.

--brian

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

---

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 24 Aug 2001 05:41:00 -0700 (PDT)

...resending (great mail server !!!)

Brian,

1) With the current approach any malicious or insane
ASP already can send anything to SG. But if ASPs route
to SGs also by considering RC, then normal working
ASPs will have a chance, not to send traffic
belongging to a RC, if they can't recieve traffic for
that RC. I agree, that here the ultimate goal should
be a screening on SG (or maybe a double screening?),
which can be achieved if RC is in DATA message.
According to me, this is a strong argument to include
RC in DATA messages.

2)If you keep your RK simple (OPC/DPC) then of course
analysing it will be also simple. But what if you also
include CIC ranges? then the selection of the
interface will be based also on CIC. If we call this
analysis also trivial, then why is the same analysis
not trivial on ASP itself?

3) In one of my former messages I have said that AMF
in ASP possibly shouldn't be as complicated (data-base
size) as the one in SG for SUA. I know, that in SUA
there is no AMF on ASP, because Rc is used in DATA. My
point is, it is not a very strong argument to include
RC in DATA for SUA, becase one thinks AMF in SG is
complicated and without RC one would need AMF also on
ASP side.

     Tolga

-----Original Message-----
From: Brian F. G. Bidulock
[mailto:[email-masked]]
Sent: Thursday, August 23, 2001 7:00 PM
To: [email-masked]
Subject: Re: M3UA07: RC in DATA and SSNM messages

.....resend

Tolga,

Asveren, Tolga wrote:                                 
  (Thu, 23 Aug 2001 07:54:29)
> sent ASPAC for this RC. What it is wrong with this
approach?

The only thing wrong is that RC is not in DATA and
SNMM so that the SG
can know which AS the messages are for and can
determine whether it
has the AS in the AS-ACTIVE state.  Otherwise, any
malicious or insane
ASP can send whatever it may and the SG cannot
determine whether the
traffic is valid.

If the ASP labels DATA and SNMM with the RC of the AS,
the SG can perform
ASPTM and other functions on the traffic flow as
identified by the RC.

> more than one AS, I think this case should be also
considered.

I think this is really a trivial matter:  an
application has one interface to
M3UA bound to OPC=5/DPC=6/SI=ISUP another bound to
OPC=5/DPC=7/SI=ISUP.  IAMs
received on interface #1 are responded to on interface
#1, the same for #2.
There is no RK "analysis" here, the selection of RK is
implicit in the
selection of the interface.  The selection of the
interface is trivial and
obvious to the application.

--brian

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

---
[email-masked]

---

---

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

....resend

Tolga,

Perhaps the strongest argument for RC in DATA and SNMM
is so that both the SGP and the ASP can perform the
ASPTM functions.  In this case it is optional but
required where not implicit.  What other use the SGP
or ASP makes of the RC thus included is pretty much
its own business.  Any implementation is able to acheive
what efficiencies it can in the use of RC for purposes
other than ASPTM.

--brian

Tolga Asveren wrote:                                        (Fri, 24 Aug 2001 05:41:00)

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

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 09:51:08 -0400

Brian,

I have never supported the idea of "one big AS". This is an absurd 
restriction and eliminates the need for the concept of an AS.  Please stop 
putting words in my mouth.

What I have supported is that we follow the draft (see section 5.4.2.2 - Support for MTP-TRANSFER Indication Primitive at the SGP), and select the destination AS at the SGP. 

There is no need "demultiplex at the ASP". 

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

"Brian F. G. Bidulock" <[email-masked]>
08/20/01 09:43 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: M3UA07: RC in DATA and SSNM messages

Tolga,

--brian

Asveren, Tolga wrote:                                    (Mon, 20 Aug 2001 
08:24:47)

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 10:28:30 -0400

Brian,

I would prefer to see your proposed text.

Barry Nagelberg

08/20/01 11:27 AM

John,

  NA in REG REQ:
                 NA == v5/v6 NA (an ID)

--brian

John Schantz wrote:                                          (Mon, 20 Aug 
2001 07:38:47)

-- 
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: "Asveren, Tolga" <[email-masked]>
Date: Tue, 28 Aug 2001 09:33:43 -0500

Barry,

If you want to avoid demultiplexing on ASP with the current approach, I see
only two choices:
1) Every ASP serves only one AS.
2) For every AS there is a different association between ASP and SG.

Basically both of them have the same meaning, to have one association per
AS.
But I don't think this will fit well with the general case. I am for
supporting multiple ASs with one assocaition.

     Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 9:51 AM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Brian,

What I have supported is that we follow the draft (see section 5.4.2.2 -
Support for MTP-TRANSFER Indication Primitive at the SGP), and select the
destination AS at the SGP. 

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Tolga,

--brian

---

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 11:02:56 -0400

Brian,

In regard to your question: Does anyone know of a reason not to allow RC 
in DATA and SNMM?

Yes, I do. It destroys interoperability based upon the M3UA draft. Your 
suggestion to make RC "optional" is really very deceiving. In reality, an 
ASP that needs the RC to do "demultiplexing", as your implementation 
evidently does, would not be able to interoperate with an SGP that does 
not support the addition of RC to the DATA message. Thus the RC would be 
"optional" only to the extent that interoperability is "optional".

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/20/01 05:24 PM

Lyndon,

--brian

Lyndon Ong wrote:                                          (Mon, 20 Aug 
2001 13:11:04)

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 28 Aug 2001 17:37:24 +0200

Barry,

I don't see anything deceiving about it, nor any interoperability issue :

- if the ASP only serves 1 AS, the RK/RC is fixed implicitly (also the NA,
as possible parameter of the RK) and RC needn't be present in any message.

- if the ASP serves more than 1 AS, over the same SCTP association, RK/RC
are configured between SG and ASP (either statically or dynamically). The
use of RC is required when the routing label does not contain enough
information to determine which is which. (Remark : routing label doesn't
contain NA either). Otherwise, your ASP is restricted to scenario 1 only (1
context per association). The same is true for an SGP.

Interoperability comes down to agreeing what scenario's are supported
between SGP and ASP. In case of scenario 2, you'll always need an extra
parameter : we propose RC instead of NA for reasons already stated (generic
UA approach, better granularity, a.s.o.)

If the SGP doesn't use RC (or whatever) it simply refuses an ASP to register
for more than 1 AS; the M3UA procedures allow this !

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 28 augustus 2001 17:03
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Brian,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Lyndon,

--brian

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

---

---

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 28 Aug 2001 12:28:01 -0400

Gery,

Pls see below.

Ken

>context per association). The same is true for an SGP.

Yes, but routing label plus NA is sufficient.;

>for more than 1 AS; the M3UA procedures allow this !

First, who would build such a SGP?  Second, such an SGP could support
more than one AS per association if the routing label alone was sufficient to
determine AS - which is the case for some configurations.

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 11:55:08 -0400

Brian,

Your assertion that "The existing NA approach in M3UA does not permit an implementation to take 
advantage of the benefits offered and the value inherent in the AS model 
for M3UA" is simply untrue. It is true only for your restricted implementation, 
which itself does not follow the M3UA model.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/21/01 04:28 PM

Gery,

--brian

Verwimp Gery wrote:                                       (Fri, 17 Aug 
2001 17:20:34)

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

---

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 12:40:55 -0400

Brian,

Your ability to twist things around is amazing. The RC is NOT required in the messages where not implied for
proper ASPTM handling at both the SG and the ASP. You correctly note that

M3UAv8 says:

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

and

Then you say that it won't work because "the SG cannot distinguish the 
related Routing Context(s). Please note that based upon what you quoted, 
it's the ASP that has to do this, not the SGP. And the ASP has the routing 
context. It's in the MTP-Transfer primitive.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/22/01 05:24 PM

Tolga,

15:24:09)

M3UAv8 says:

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

and

But without RC in DATA and SNMM in the ASP to SG direction where RC is not
implicit to the association, the SG cannot distinguish the "related 
Routing
Context(s)" and has little choice but to process the message.

ASPTM procedures for M3UA cannot work the same way as the other ASs 
because
RC is not carried in all messages other than ASPUP/Ack ASPDN/Ack and REG 
REQ.
All other UAs carry IID/RC in all messages other than ASPUP/Ack ASPDN/Ack 
and
REG REQ.

--brian

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

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 13:11:11 -0400

Tolga,

The reason that demultiplexing (at the ASP from one SCTP association to 
several ASs) is not needed is that the ASP _is_ the process instantiation 
of the AS. The AS is only a logical concept.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

"Asveren, Tolga" <[email-masked]>
08/28/01 10:33 AM
Please respond to sigtran

Barry,

If you want to avoid demultiplexing on ASP with the current approach, I 
see
only two choices:
1) Every ASP serves only one AS.
2) For every AS there is a different association between ASP and SG.

     Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 9:51 AM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Brian,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Tolga,

--brian

08:24:47)

---

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 28 Aug 2001 12:31:13 -0500

Barry,

You are right but an ASP can be instance of more than one AS. In such a
case, for incoming traffic, one should sometimes know, in which AS context
the message should be processed. But I agree that for this demux routing
label + NA (old definition) will be enough with some approaches. In fact,
here that what saves us from finer demultiplexing is that all of the
messages, which are destined to the same point code and to the same user
part, are processed in the same way, even if they belong to different route
keys (for example DPC=1-1-1 CIC=100 OPC=2-2-2 and DPC=1-1-1 CIC=200 OPC
=2-2-2)
If one wants to process those messages differently, then a finer
demultiplexing (which requires actual knowledge of route key) will be
necessary. I think this is the source of disagreement in the discussion
about necessity of RC in DATA messages.
As a final word related with this, what I call "demultiplexing" in my
original message was to analyze RL+NA.

     Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 1:11 PM
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Tolga,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Barry,

     Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 9:51 AM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Brian,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Tolga,

--brian

08:24:47)

---

---

---

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 13:33:24 -0400

Brian,

You are correct that the addition of the RC in the data message will make 
the ASPTM procedures easier at the SGP (it's still possible now, but 
admittedly slower and more cumbersome).

Therefore I agree with you that the RC should be in the DATA message. 
However it must be mandatory, not optional, to ensure interoperability 
with ASP implementations such as yours, which depend upon the existance of 
the RC to do "demultiplexing". 

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/23/01 07:00 PM

Tolga,

Asveren, Tolga wrote:                                    (Thu, 23 Aug 2001 
07:54:29)

> more than one AS, I think this case should be also considered.

I think this is really a trivial matter:  an application has one interface 
to
M3UA bound to OPC=5/DPC=6/SI=ISUP another bound to OPC=5/DPC=7/SI=ISUP. 
IAMs
received on interface #1 are responded to on interface #1, the same for 
#2.
There is no RK "analysis" here, the selection of RK is implicit in the
selection of the interface.  The selection of the interface is trivial and
obvious to the application.

--brian

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

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 28 Aug 2001 12:53:17 -0500

Barry,

What do you mean exactly when you say "It is still possible now, but admittedly slower and more cumbersome"? Probably you mean, that DATA which arrived from ASP to SGP can be analyzed on SGP to find, from which AS it is send. 
But if like this, one should be carefull because in one of the messages in this thread it is said that not all of the RKs have an ASP to SG equivalent (I couldn't follow the discussion about this, can somebody give an example for such a RK?). In such a case it is impossible to guarantee a successfull analysis on SGP side for messages arriving from ASP.
Also, we are at a very interesting point. If RC is put to DATA messages, I think your implementation can have some problems. Let me explain:
For messages from ASP to SG side, you have to populate RC. But again from ASP to SG side you cannot do RK analysis (as stated above it is not always meaningfull). So the only choice is then you follow an approach like Brian's, registering for every AS separetly so when a message comes from SS7 user part, you know automatically for which AS it has arrived. 
In fact even with that approach there can be some problems with messages from ASP to SGP, which are originated on ASP side (whihc are not responses to received messages from SGP side)

   Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 1:33 PM
To: sigtran
Subject: Re: M3UA07: RC in DATA and SSNM messages

Brian,

Barry Nagelberg
Software Engineer
RadiSys, Corp.

Tolga,

--brian

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

---

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 13:44:10 -0500

Ken,

Routing label plus NA is not sufficient for ASPTM procedures, which
require RC in SNMM and DATA when not implicit.

--brian

Ken Morneault wrote:                                          (Tue, 28 Aug 2001 12:28:01)
> >parameter: we propose RC instead of NA for reasons already stated (generic
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 13:45:29 -0500

Barry,

[email-masked] wrote:                (Tue, 28 Aug 2001 12:40:55)
> context. It's in the MTP-Transfer primitive.

The text you quote says "SGP or IPSP" not ASP.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 13:48:25 -0500

Barry,

I'm glad you agree.  RC is "optional" in DATA and SNMM but REQUIRED where
not implicit to the association.

Becaues NA is no longer required with RC present, it should be removed.

--brian

[email-masked] wrote:                (Tue, 28 Aug 2001 13:33:24)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 28 Aug 2001 11:49:43 -0700

Tolga, comments below.

> Sent: Tuesday, August 28, 2001 12:53 PM
> To: sigtran
> What do you mean exactly when you say "It is still possible 
> now, but admittedly slower and more cumbersome"? Probably you 
> mean, that DATA which arrived from ASP to SGP can be analyzed 
> on SGP to find, from which AS it is send. 

Why do you think the SG should route message differently based on what
AS/ASP the message was received from.  Forward routing for the SG should be
based on the DPC in the RL, PERIOD!!!  Nothing else is needed.  You are
creating a nightmare if you try and tie backward information to it.

> But if like this, one should be carefull because in one of 
> the messages in this thread it is said that not all of the 
> RKs have an ASP to SG equivalent (I couldn't follow the 
> discussion about this, can somebody give an example for such 
> a RK?). In such a case it is impossible to guarantee a 
> successfull analysis on SGP side for messages arriving from ASP.

I think you are forgetting that AS is a logical concept and that one of its
many definitions is a set if ASPs handling the traffic associated with the
AS (RK).  To me this means that when the AS wants to send a message to an
SG, it can use any ASP from this set.  The ASPs have already established
connects to a set of SGPs to receive this traffic.  RK is an end-node
concept where the SG can sub-divide traffic into RK groupings (ASs).  There
is no need to sub-divide the traffic returning from the ASs to the SGs.

> Also, we are at a very interesting point. If RC is put to 
> DATA messages, I think your implementation can have some 
> problems. Let me explain:
> For messages from ASP to SG side, you have to populate RC. 
> But again from ASP to SG side you cannot do RK analysis (as 
> stated above it is not always meaningfull). So the only 
> choice is then you follow an approach like Brian's, 
> registering for every AS separetly so when a message comes 
> from SS7 user part, you know automatically for which AS it 
> has arrived.

No, only an implementation with limited routing functionality would need
this approach.  An implementation that has full routing functionality does
not need this.

> In fact even with that approach there can be some problems 
> with messages from ASP to SGP, which are originated on ASP 
> side (whihc are not responses to received messages from SGP side)
> 
> 
> 
>    Tolga
> 
> 
> > 2) It is obvious there is a 1:1 relationship between 
> AS:RK:RC. But in 
> the
> > which AS. So, there will be a need of RK analysis on user 
> application 
> level
> > in such a case. Unless it is said that a user application 
> can't be part 
> of
> OPC=5/DPC=7/SI=ISUP. 

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 28 Aug 2001 11:55:52 -0700

Conclusion is wrong if premise is wrong.  SNMM should never require RC since
they are conveying remote PC state information.  This should have no effect
on a RK or RC!  Using SNMM to manage a partitioned SG has already been
discussed as being unacceptable.

> Sent: Tuesday, August 28, 2001 1:44 PM
> To: sigtran
> 2001 09:18:37)
> [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 28 Aug 2001 14:09:21 -0500

John,

[snip]
>creating a nightmare if you try and tie backward information to it.

[TOLGA] What I say is choosing SG based on RC information, when ASP is
sending data to SG.
And I think there the better choice is to choose among the SGs, to which an
ASPAC is sent for the RC of DATA message.

>is no need to sub-divide the traffic returning from the ASs to the SGs.

[TOLGA] The intention is not to subdivide the traffic but to be able to
understand from which AS the message is sent. This can be nice, so that SG
can filter the messages which are sent for not active ASs.

>this approach.  An implementation that has full routing functionality does

[TOLGA] As indicated in my message, not every RK has an equivalent in ASP to
SG direction.So, "full routing functionality" is impossible (unless every RK
has an equivalent in ASP to SG direction)

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 11:43:39 -0400

Brian,

Demultiplexing at the ASP is definitely NOT required by the M3UA draft. 

The only reason you need it is because you have implemented the ASP in the 
Linux kernel and the ASP in the Linux user space, and you are now 
evidently having problems communicating between them.

I think this whole effort of yours is a very cynical effort to twist the 
draft to match your very particular implementation. 

Barry Nagelberg
Software Engineer
RadiSys, Corp.

08/21/01 02:57 PM

Lyndon,

Lyndon Ong wrote:                                          (Tue, 21 Aug 
2001 10:46:07)

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 15:32:25 -0500

Barry,

Please adopt a more professional tone...

--brian

[email-masked] wrote:                (Tue, 28 Aug 2001 11:43:39)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 15:38:24 -0500

John,

John Schantz wrote: (Tue, 28 Aug 2001 11:55:52)
> discussed as being unacceptable.

This is very reason why RC is placed in SNMM, so that the ASPTM procedures
can accept, discard, or reroute them internally.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 23:23:38 -0500

Barry,

I can provide proposed text, but I agree with Lyndon that
we should come to some basis of agreement before proposing
text.

--brian

[email-masked] wrote: (Tue, 28 Aug 2001 10:28:30)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 23:25:09 -0500

Tolga,

The case cited when RK has no equivalent in the reverse direction was when RK
is based on SCCP SSN or TCAP TID.  Greg's (and some others') defended keeping
it possible for M3UA RK's to include SSNs and anthing else imaginable.  Some
of these imaginable RK's do not have direct equivalents in the opposite
direction.  Some of them are not even passive keys in the filtering sense, but
are active routing algorithms which may include state.

Removing the possibility for M3UA to support SSN, TID and these imaginable
keys might make it possible to perform a reverse RK assignment, but my last
attempt to have SSN and TID precluded was resisted.  SSN and TID routing
keys are still permitted in M3UA.

I think that it may be possible that Barry does not intend to support these
other routing keys, but there are clearly those who do.

--brian

Asveren, Tolga wrote:                             (Tue, 28 Aug 2001 12:53:17)
>
> Barry,
> 
> What do you mean exactly when you say "It is still possible now, but
> admittedly slower and more cumbersome"? Probably you mean, that DATA which
> arrived from ASP to SGP can be analyzed on SGP to find, from which AS it is
> send.  But if like this, one should be carefull because in one of the
> messages in this thread it is said that not all of the RKs have an ASP to SG
> equivalent (I couldn't follow the discussion about this, can somebody give
> an example for such a RK?). In such a case it is impossible to guarantee a
> successfull analysis on SGP side for messages arriving from ASP.  Also, we
> are at a very interesting point. If RC is put to DATA messages, I think your
> implementation can have some problems. Let me explain: For messages from ASP
> to SG side, you have to populate RC. But again from ASP to SG side you
> cannot do RK analysis (as stated above it is not always meaningfull). So the
> only choice is then you follow an approach like Brian's, registering for
> every AS separetly so when a message comes from SS7 user part, you know
> automatically for which AS it has arrived.  In fact even with that approach
> there can be some problems with messages from ASP to SGP, which are
> originated on ASP side (whihc are not responses to received messages from
> SGP side)
> 
> 
> 
>    Tolga
> 

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 23:24:35 -0500

Tolga,

It is true that NA only provides for coarse routing control and
cannot handle finer control such as the SI or CIC-range granularity
which is provided for in M3UA.

(I don't think that there is any question that M3UA needs to
 support SI granularities and ISUP users.)

On the other hand, RC in the existing AS model provides both
coarse and fine routing control and suits all granularities.

--brian

Asveren, Tolga wrote:                             (Tue, 28 Aug 2001 12:31:13)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 23:24:18 -0500

Barry,

The reason that RC is required in DATA and SNMM is because
RC *is* the basis for providing ASPTM. ASPTM is not a logical
concept, it is a described and proscribed set of procedures
which apply to all messages exchanged between M3UA peers.

--brian

[email-masked] wrote:         (Tue, 28 Aug 2001 13:11:11)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 23:23:29 -0500

Barry,

I do not propose that RC be optional in DATA and SNMM in the manner
which you describe.  I propose that RC be required in DATA and SNMM
in all messages in which RC is not implicit.  There is no
interoperability issues in this case: every implementation can then
rely on being able to discern RC from every message for ASPTM
procedures as well as any other use the implementation might have
for it.

The situation you point out is a very good reason why RC should be
required where not implicit in all DATA and SNMM messages and is the
reason for requiring it where not implicit.

Given that RC would be required only where not implicit in DATA and
SNMM, can you see a reason why it could not be included?

--brian

[email-masked] wrote:         (Tue, 28 Aug 2001 11:02:56)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 23:24:03 -0500

Barry,

[email-masked] wrote:         (Tue, 28 Aug 2001 11:55:08)
>
> Brian,
> 
> Your assertion that "The existing NA approach in M3UA does not permit an
> implementation to take advantage of the benefits offered and the value
> inherent in the AS model for M3UA" is simply untrue. It is true only for
> your restricted implementation, which itself does not follow the M3UA model.
> 

It is true for efficiency in some implementations and very true for any
implementation which wishes to perform the ASPTM procedures as provided
in the draft.  I don't know how any implementation is going to escape
performing ASPTM procedures.  Common ASPTM procedures is one of the
benefits of the AS model which is common to all UAs.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 29 Aug 2001 09:31:19 +0200

Ken,

See below !

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: dinsdag 28 augustus 2001 18:28
To: sigtran
Subject: RE: M3UA07: RC in DATA and SSNM messages

Gery,

Pls see below.

Ken

[GV] : So is RC (use NA value if you're in a lazy mood) ;)

First, who would build such a SGP?  Second, such an SGP could support
more than one AS per association if the routing label alone was sufficient
to
determine AS - which is the case for some configurations.

[GV] : I don't know, certainly not us ! Second, RC is an optional parameter.
Yes, it's possible (in M3UA at least), but the issue is the usage of RC vs.
NA in cases where ambiguity is possible (multiple networks etc.)
Here we propose RC because it's simply more general ! NA is obvious from RC
through (static/dynamic/one-to-one map) configuration. Whatever scenario or
message you come up with, the answer is always the same, regardless of the
clouds everybody is trying to make ("you're system is more limited than
mine") ;o

---

---