Subject: poll - m3ua RC vs NA issue

From: Lyndon Ong <[email-masked]>
Date: Thu, 6 Sep 2001 09:35:10 -0700 (PDT)

Folks,

We've been going around and around on this for a
while,
can I take a poll to see who supports

(a) RC only in DATA and SNMM
(b) RC and NA both in DATA and SNMM

and see if we can resolve this?

Thanks,

L. Ong

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

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

---

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 18:44:44 +0200

Lyndon,

I support only RC in DATA and SNMM messages.

As long as we have agreed that a RK can not extend across 
more than one NA:
> [snip from Brian's]... Perhaps the definition should be reworded as:
> 
>   "Signalling Point Management Cluster (SPMC) - The complete set of
>   Application Servers represented to the SS7 network under a single
>   MTP entity (Signalling Point) in one specific Network Appearance.
>   ..."
> 
> to make this clear.

/MCruz

> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 6:35 PM
> To: sigtran
> Subject: poll - m3ua RC vs NA issue
> 
> 
> Folks,
> 
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: Ken Morneault <[email-masked]>
Date: Thu, 06 Sep 2001 12:58:57 -0400

Lyndon,

I support RC and NA in DATA and SNMM messages.

Ken

At 06:44 PM 9/6/01 +0200, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 6 Sep 2001 11:05:33 -0700

I agree with Ken.

The flexibility should be there for the network owner to decide based on the
equipment they have bought, how they want to solve situations, and
administer their network and network connections.

John

> From: Ken Morneault [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 11:59 AM
> To: sigtran
> Subject: RE: poll - m3ua RC vs NA issue
> 
> 
> 
> 
> Lyndon,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Thu, 6 Sep 2001 13:21:37 -0500

b) as both in both

> Sent: September 06, 2001 12:35 PM
> To: sigtran
> [email-masked]

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Sep 2001 13:50:52 -0500

I prefer a)

Tolga

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 12:35 PM
To: sigtran
Subject: poll - m3ua RC vs NA issue

Folks,

Thanks,

L. Ong

---
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, 6 Sep 2001 14:13:43 -0700

Actually I'm curious about the definition of RC.  We have spent to much time
on NA.  The definition for RC still says: "A value that uniquely identifies
a Routing Key."  And the last that I knew, you still needed a PC as an
element of the RK to "uniquely define the range of signalling traffic to be
handled by a particular Application Server".  Hence, the argument that RC
can degenerate down to an NA doesn't fly.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 1:50 PM
> To: sigtran
> Subject: Re: poll - m3ua RC vs NA issue
> Importance: High
> 
> 
> Lyndon,
> 
> I'm curious: what definition of NA are you talking about here?
> 
> --brian
> 
> On Thu, 06 Sep 2001, Lyndon Ong wrote:
> 
> > Folks,
> > 
> > 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: Thu, 6 Sep 2001 16:52:29 -0500

John,

John Schantz wrote:  (Thu, 06 Sep 2001 14:13:43)
> Actually I'm curious about the definition of RC.

Use the definition from SUAv7.

> We have spent to much time on NA.

And there are still many definitions one can point to.  What is yours?

> The definition for RC still says: "A value that uniquely identifies
> a Routing Key."

This is true.

> And the last that I knew, you still needed a PC as an element of the
> RK to "uniquely define the range of signalling traffic to be handled by a
> particular Application Server".

PC is a mandatory parameter for REG REQ but that does not affect
the form of the RK.  The form of the RK is not defined in M3UA.
For example, RK's can have SSNs as elements, where the REG REQ
does not support SSN values.

The RK merely has the restriction that it cannot span SPMC or NA
(as defined in M3UAv8).  (Note that for the RC == NA case, REG
REQ is not even required, because if the ASP has the NA value
to put in the REG REQ it also has the RC value returned in the
REG RSP).

> Hence, the argument that RC can degenerate down to an NA doesn't fly.

Actually, the RC/RK definition explicitly permits RC to be NA for
coarse RKs.  The only thing that it does not permit is for the RK
to span SPMC (but NA can't span multiple SPMC either) and that RK
cannot span NA.

Setting RC == NA where NA identifies the SPMC for management view
purposes (i.e., M3UAv8 NA definition) is not only completely allowed
but MUST be allowed to permit nodes to have multiple alias point
codes, yet have a single RC value.  This guarantees that where NA
is sufficient, RC can always be assigned to the same value as NA.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 7 Sep 2001 09:31:43 +0200

My vote: (a)

BR // Javier.

> [email-masked]

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Fri, 7 Sep 2001 09:31:47 +0200

Brian,
Please see a question below.
Francois

> Sent: Thursday, September 06, 2001 11:52 PM
> To: sigtran

What do you mean by that? If REG REQ needs RK parameters and SSN
is allowed in RK, how can REG REQ not support SSN?
Also, I though from previous threads that the use of SSN in RK
would be discontinued in future drafts. Is that still valid?

> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 03:20:27 -0500

Francois,

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote: (Fri, 07 Sep 2001 09:31:47)
> would be discontinued in future drafts. Is that still valid?

REG REQ does not determine the form of the RK.  RK is a completely
OPTIONAL procedure.  I think that we agreed to remove SSN from
REG REQ, but that it would not be explicitly excluded and that
anyone wishing to define it in a statically defined RK could do
so.  A statically defined RK can be anything that one likes.  The
only current restrictions on a RK are that it not span an SPMC
and that it not span NA.

The NA advocates want to use NA as a coarse MTP-SAP (SPMC) and
thus they can define RK == NA.  REG REQ is not required in this
case cause RC == RK == NA and the RC value returned would simply
by the NA value anyway.

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

---

---

From: [email-masked]
Date: Fri, 7 Sep 2001 11:56:59 -0400

Lyndon,

I support (b).

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

Lyndon Ong <[email-masked]>
09/06/01 12:35 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        poll - m3ua RC vs NA issue

Folks,

Thanks,

L. Ong

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

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

---

---

From: Amish Chana <[email-masked]>
Date: Sat, 08 Sep 2001 11:43:16 +0100

(a) RC only

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

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: Andrew Barrington <[email-masked]>
Date: Mon, 10 Sep 2001 16:20:16 +0100

All,
     My ten-penneth is below - I tried sending it yesterday but I have had some
problems getting email out.

thanks,

Andrew
---------------------- Forwarded by Andrew Barrington/MAIN/MC1 on 10/09/2001
16:19 ---------------------------

(Embedded image moved to file: pic11449.pcx)
From: Andrew Barrington On: 09/09/2001 11:49:51

To:   [email-masked]
cc:

Subject:  Re: poll - m3ua RC vs NA issue  (Document link: Andrew Barrington)

My vote is for option (b) below.

Because (if I have understood the arguments correctly - and I'm willing to be
corrected !) -

- RC (and/or NA !) is useful for those implementations of ASP that are not
provisioned with SS7 RL information (or those ASPs that wish to minimise the
amount of rerouting done at the ASP) and wish to route to and from users only on
RC (and/or NA).

- NA is useful for those implementations of ASP that may route again on the SS7
RL but require additional information on the SGWs OPC, NI   and SS7 protocol
version (i.e. network appearance) to aid in routing to the user on an ASP.  I
would expect (in the cases that I am interested in) that the numbers of NA will
be relatively small in relation to the number of RCs (although they do reduce to
RC <= NA in some cases) and so the per message processing on the ASP may likely
be reduced by the use of NA in preference to RC. For this reason I would also
oppose the removal of NA in favour of RC only in any particular DATA or SNMM
message.

- Therefore it seems sensible to me to supply both the RC and NA in the DATA and
SNMM messages to allow the different - implementations to be realised and to
co-exist.

This does however seem to put an onus on all M3UA implementations to support
both the RC and NA (and routing label) as mandatory parameters to achieve total
interoperability with all vendors implementations.

Andrew
z-------------------------------------------------------------------------------

>L. Ong

============================================================
Any views expressed in this email are my own and not those of Marconi

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Sep 2001 13:09:05 -0500

Andrew,

Please see commment below...

Andrew Barrington wrote:                                   (Mon, 10 Sep 2001 16:20:16)
> ---------------------- Forwarded by Andrew Barrington/MAIN/MC1 on 10/09/2001

Because NA can always be derived from RC independent of the
peer node, why require both?  RC is sufficient.

--brian

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

---

---

From: Andrew Barrington <[email-masked]>
Date: Tue, 11 Sep 2001 19:14:04 +0100

Brian,
     I agree that RC is sufficient, my point below is that is is not as
efficient as using NA in some scenarios. (i.e. when the number of NAs is less
than the number of RCs - the most normal case I presume).
For example in the implementation I am looking at the number of RC may be approx
1000 (or more)  whereas the number of NAs may be as little as four. I certainly
see an advantage in using NA in my particular scenario.

However my vote for option (b) is because I can also see the case for RC when
number of RC approach the number of NAs.

Andrew

---------------------- Forwarded by Andrew Barrington/MAIN/MC1 on 11/09/2001
19:08 ---------------------------

"Brian F. G. Bidulock" <[email-masked]> on 10/09/2001 19:09:05

Please respond to [email-masked]

                                                              
 cc:       (bcc: Andrew Barrington/MAIN/MC1)                  

Andrew,

Andrew Barrington wrote:                                   (Mon, 10 Sep 2001
16:20:16)

--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: Tue, 11 Sep 2001 13:38:01 -0500

Andrew,

I hash on RC with no loss of efficiency regardless of
the ratio of RC to NA.  An RC hash is required for ASPTM
anyway.  I strongly disagree with putting NA unnecessarily
into SNMM messages just because some implementation does
not wish to implement a hash table.

--brian

Andrew Barrington wrote:                                   (Tue, 11 Sep 2001 19:14:04)

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

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 13 Sep 2001 10:38:49 +0100

Andrew

See comments below.

Amish

>efficient as using NA in some scenarios. (i.e. when the number of NAs >is 
>less than the number of RCs - the most normal case I presume).
>For example in the implementation I am looking at the number of RC >may be 
>approx 1000 (or more)  whereas the number of NAs may be as  >little as 
>four. I certainly see an advantage in using NA in my >particular scenario.

If we use your reasoning for the inclusion of NA then tomorrow we could have 
someone requiring the inclusion of the SI because the number of SIs will be 
very small, possibly 2 or less compared to the number of RCs. What about the 
number of SSNs, OPCs, CIC ranges, etc. relative to the number on RCs in 
other implementations?

If all the RK parameters are eventually included in the DATA and SNMM 
messages, why not make the RC obsolete?

>
>However my vote for option (b) is because I can also see the case for >RC 
>when

---

---

From: Verwimp Gery <[email-masked]>
Date: Mon, 17 Sep 2001 13:23:35 +0200

Lyndon,

maybe a bit too late in the polling process, but I say :

(a)

____________________________

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: donderdag 6 september 2001 18:35
To: sigtran
Subject: poll - m3ua RC vs NA issue

Folks,

Thanks,

L. Ong

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

---