Subject: [M3UA Issue #2]: Add RC and/or NA in DATA msg

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Tue, 4 Sep 2001 11:16:52 +0200

Hi,

I'm trying to catch up with your discussions on different
issues and I found pretty difficult to follow them, I think it
would be better to treat each pointed issue in a different
thread, this is why I opened this new thread to deal with issue 2,
coming from "M3UA: Proposed Solutions to issues 1, 2, 4, 16" thread,
I hope this is alright for all of you.

Although the discussion is getting the more and more complex, 
I think Brian's point is based on his sentence:

[snip]
RK's can neither span NA's nor span SPMCs.  In the current draft
they cannot even span DPCs.  Therefore, RC implies both the NA and
DPC of the routing key.  Where RC is provided, neither NA (nor DPC
in the current draft) is required.
[snip]

In the current draft the RK definition says:
".... the Routing Key cannot extend across more than a single SPMC",
what means (as you stated) that a RK can not extend across more than
one DPC.

However, in the draft nothing is said about do not extend more than
one NA, I know we talked about that previously and as far as I know an
agreement wasn't reached. If you remember the RK parameter format
was depending on that (see M3UAv8: Routing Key parameter). However,
I missed a good bunch of mails (trying to catch up ;-), so let me know
whether I'm wrong or not.

Then, I think that firstable WE ALL NEED TO AGREE ABOUT WHETHER A RK 
CAN OR NOT SPAN ACROSS MORE THAN ONE NA.

If it is agreed that a RK does NOT span across more than one NA, then I agree
with Brian: only the RC is enough because it implies a NA (an only one NA).
Then, only the RC should be added as an optional parameter within DATA messages.

However, if it is agreed that a RK DOES span across more than one NA, the
RC does not imply an NA, so the NA is needed as well. Then, both RC and
NA should be added as optional parameters within DATA messages.

Comments?
/MCruz

---
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, 4 Sep 2001 10:56:55 -0500

Maria-Cruz,

If an RK in the current draft cannot extend across more than one
DPC, how can it span more than one NA?

--brian

On Tue, 04 Sep 2001, Maria-Cruz Bartolome-Rodrigo (ECE) wrote:

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

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

---

---

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Tue, 4 Sep 2001 19:02:36 +0200

Brian,

Do you think that do not extend across more than one DPC implies
do not span more than one NA? Why? I can't see any reason.

The same SPMC could be providing service to more than one network
(identified by an NA), e.g. different flavours or variants (as 
considered in the NA definition).

Taken from the definition:
"Signalling Point Management Cluster: The complete set of ASs represented
to the SS7 network under a single MTP entity (Signalling Point)..."

In my opinion the same PC could be used to represent the same set
of ASs towards more than one SS7 network (identified by NA). 

What is your point?

/MCruz

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 5:57 PM
> To: sigtran
> Subject: Re: [M3UA Issue #2]: Add RC and/or NA in DATA msg
> Importance: High
> 
> 
> Maria-Cruz,
> 
> > 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]
> 

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 4 Sep 2001 12:19:10 -0500

Hi,

I agree with Brian. Maybe this should be stated more clear in the draft. The other interpretation sounds strange to me, in one RK one can have traffic for two signaling points in different networks but they should have the same point code. Why do they need to have the same point code? As far as I know, such a restriction does not exist in SS7 network for a node, which acts as signaling points in two different networks. 
So, this makes me think, that what meant in the draft is "just one signaling point" and not "possibly multiple signaling points with the same point code but in different networks".

     Tolga

-----Original Message-----
From: Maria-Cruz Bartolome-Rodrigo (ECE)
[mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 1:03 PM
To: sigtran
Subject: RE: [M3UA Issue #2]: Add RC and/or NA in DATA msg

Brian,

What is your point?

/MCruz

> [email-masked]

---
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, 4 Sep 2001 13:05:08 -0500

Maria-Cruz,

The M3UAv5, v6 and v7 had the following definition for SPMC:

  "Signalling Point Management Cluster (SPMC) - The complete set of
   Application Servers represented to the SS7 network under one
   specific SS7 Point Code of one specific Network Appearance. ..."

The reason that v8 was changed to:

  "Signalling Point Management Cluster (SPMC) - The complete set of
   Application Servers represented to the SS7 network under a single
   MTP entity (Signalling Point). ..."

was to permit for "alias" point codes for the SPMC.  (I believe that
I was the one that asked for the change.)  It was never intended to
permit an SPMC to span NA.  It is similar to the change you supported
for allowing RK to span multiple DPC (but not multiple SPMC.  The
old definition of "point code" would not allow this.

It is not possible for an SPMC to "aggregate the availability,
congestion and user part status of an MTP entity (Signalling Point)"
in more than one NA.  Perhaps the definition should be reworded as:

  "Signalling Point Management Cluster (SPMC) - The complete st of
  Application Servers represented to the SS7 network under a single
  MTP entity (Signalling Point) in one specific Network Appearance.
  ..."

to make this clear.

Please see comments below...

--brian

> do not span more than one NA? Why? I can't see any reason.

A DPC (as an MTP-SAP and identifying an MTP entity) only exists in
one NA, regardless of the NA definition.

> of ASs towards more than one SS7 network (identified by NA). 

But, the SPMC is not permitted to span NA and as such RC does
not span NA.

> What is your point?

That RC is not permitted to span NA in the current draft.

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

---

---

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Wed, 5 Sep 2001 09:35:34 +0200

Brian, Tolga

See comments below...

> Sent: Tuesday, September 04, 2001 8:05 PM
> To: sigtran

This rewording sounds great for me, and makes things more understandable.

Then, I agree with you about the point under discussion: 
- a RK can not extend across more than one NA, and then
- only adding the RC in the DATA message will be enough 
  (NA can be omitted because it is implied).

Does someone disagree now?

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 5 Sep 2001 07:51:18 -0700

Maria,
	I think you missed the point.  RC is specific to a node and its PC
etc. (all the info is rolled into one parameter).  Sure it can imply the NA
BUT what about the traditional SS7 nodes.  Traditional SS7 nodes use the RL
by level 3 (MTP or M3UA) and other parameters by MTP-users to handle the
traffic.  RC is NOT one of them.  

In the case where the true application can handle traffic from multiple
networks, all that is needed by these traditional nodes is a parameter that
identifies the network, hence, the NA.

I think the only compromise is to allow both NA & RC as optional parameters.
Traditional nodes will not need the NA until multiple networks or
appearances occur and they may never use RC.  I have the feeling that RC
might be used without the existence of multiple networks because it
eliminates/replaces the level 3 routing function (a poor man's
implementation of SS7).

John

> Sent: Tuesday, September 04, 2001 4:17 AM
> To: sigtran
> Subject: [M3UA Issue #2]: Add RC and/or NA in DATA msg
> 
> 
> 
> Hi,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Wed, 5 Sep 2001 17:39:48 +0200

John,

See comments inline.

/MCruz

> From: Schantz, John [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 4:51 PM
> To: sigtran

I agree, both RC and NA have been defined within the IP domain.

> identifies the network, hence, the NA.
 
Traditional nodes (I presume SS7 nodes) do not need NA, NA has
only significance in the IP domain.

> eliminates/replaces the level 3 routing function (a poor man's

I think we are trying to agree about whether or not the RC and/or NA
should be sent within the M3UA DATA messages, i.e. messages in the
IP domain, traditional nodes will never use/need neither RC or NA.
I do not understand your point here.

/MCruz

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 5 Sep 2001 11:43:21 -0700

MCruz,
	You are sadly mistaken.  NA is needed in the SS7 world not just the
IP world.  Currently the "NA" is restricted to a node, allowing it to
connect onto multiple networks.  This is the basis for MTP-SAP and SCCP-SAP.

BUT now this concept is being extended beyond just a single node (now we
have the IP world).  The multiple network connections have moved from the
node (in the SS7 only case) to the SG/STPs sitting in front of the node (the
node itself could also support multiple network connections without
involving any other network nodes, but this is not the case we are
discussing).  Now both the node and the SG/STP have multiple shared
networks/environments that need to be kept separate (an environment is the
network connection/appearance, network specific traffic, the PCs and
statuses of the PCs in this network, the protocol variant, and network
specific parameter options (e.g., NI)).  Its like supporting multiple
instantances of a single network scenario, and it is.  All you need is
common set of NAs from the node's and SG/STP's point-of-view to keep
everything separate, logically speaking.

John

> Sent: Wednesday, September 05, 2001 10:40 AM
> To: sigtran
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 14:41:54 -0500

John,

> connect onto multiple networks.  This is the basis for MTP-SAP and SCCP-SAP.

RC is also a basis for MTP-SAP and SCCP-SAP and (by your analogy)
RC is just as firmly implanted in SS7 as you consider NA to be.

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 5 Sep 2001 13:00:46 -0700

RC is not / was not a basis for SAP.  There is / was no "do all" parameter
that kept growing in definition because it is supposed to do everything for
you.

> Sent: Wednesday, September 05, 2001 2:42 PM
> To: sigtran

---

---

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

John,

NA is not / was not a basis for SAP either.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Wed, 5 Sep 2001 14:47:28 -0700 (PDT)

John brings up one distinction between RC and NA
that I had not noticed before: a Routing Key is 
defined to include a Point Code as a mandatory 
element, ergo RK and RC as well is specific to a node
as John points out below.

Network Appearance under the definition now being
discussed is not specific to a node/Point Code, but
would apply possibly to a group of Point Codes.

If that is the case, the argument (which I thought
was fairly strong) that you can configure RC to have
the same meaning as NA is not correct.  You could not
set RK/RC to mean NA only, you would need to specify
a Point Code as well.

Comments?

Cheers,

Lyndon
> > If it is agreed that a RK does NOT span across
> more than one 
> > NA, then I agree
> > with Brian: only the RC is enough because it
> implies a NA (an 
> > only one NA).
> > Then, only the RC should be added as an optional
> parameter 
> > within DATA messages.
> > 
> > However, if it is agreed that a RK DOES span
> across more than 
> > one NA, the
> > RC does not imply an NA, so the NA is needed as
> well. Then, 
> > both RC and
> [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 17:16:29 -0500

Lyndon,

> set RK/RC to mean NA only, you would need to specify

It doesn't matter that a point code need be supplied
in REG REQ, the SG can return whatever value for RC
works.  That is, the SG can return the NA value for
RC, regardless of whether a point code is supplied in
REG REQ or not.

Maria-Cruz' proposal to permit the point code in
REG REQ to identify an SPMC (group of point codes
beloning to the same SPMC identified by one of the
point codes) permits this as well (but requires no
syntax change).

There is no requirement placed on the RC to return a
unique value of RC for every combination of DPCs in
routing keys.  There is only the requirement that RC
must not span SPMC (or NA).

John S. wishes to treat management within an NA from
a single management view.  As such, all point codes
in the NA must be capable of being treated as belonging
to the same SPMC.  John S. didn't want to use REG REQ
anyways, however, the simple approach to setting RC
to his view of NA is to simply return the NA value
which would be used as the RC value in REG RSP.

So, it is always possible to set RC == NA whenever
NA would suffice.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 14:58:10 +0200

Hi John, 

There exists a kind of NA in SS7 nodes. It's called MTP-SAP.

At an SG you can differenciate traffic coming from different SS7 nodes with the same SPC with help of MTP-SAP. In the IP world we can translate MTP-SAP as NA. If NA is a parameter of the RK, RC will be sufficient to get NA. So that sending RC in Data is enough to have all the info needed in SGP and ASP (i.e. NA). How to assign NA values, it's an implementation specific issue.

BR // Javier.

> Sent: Wednesday, September 05, 2001 8:43 PM
> To: sigtran
> [email-masked]

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 15:05:26 +0200

Hi, 

That NA value is returned as RC, is an implementation dependant issue. It does not affect to interoperability since

> Sent: Thursday, September 06, 2001 12:16 AM
> To: sigtran

That NA value is returned as RC, is an implementation dependant issue. It does not affect to interoperability.

> must not span SPMC (or NA).
Moreover, RC is considered to be a value that uniquely identifies a RK.

> So, it is always possible to set RC == NA whenever

Implementation specific. This does not contradicts that sending RC in Data messages is enough. :-)

---

---

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

John,

See comments inline.
/MCruz

> connect onto multiple networks.  This is the basis for 

SAPs are terms relevant for the SS7 world, in the same way NA (and RC)
have been defined for the IP world. Of course, they need to be
linked somehow, there should be a mapping between them. I would never
disagree about what you said: NA is mapped to SAPs (or the other way
around). Fine, I got a different impresion out of your lastest e-mail.

> everything separate, logically speaking.

Yes, the network 'appearances' defined in the SS7 world should be kept separate
in the IP world. Then, SAPs are mapped onto NAs and these NAs are used 
as routing parameters within a routing key, then the RC implies an NA
(as long as a RK can not extend across more than one NA, as I think we
have already agreed). Therefore, sending the RC within the DATA would 
be enough, the remote M3UA would use the RC to transfer the message to
the right MTP3-User (in case of different users per NA).

Do you disagree? Am I misunderstanding your point?

/MCruz

---

---

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

Lyndon,
See comments below
/MCruz

> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 11:47 PM
> To: sigtran

A RC can imply an NA, it doesn't mean, in my opinion, that
you can configure a RC to have the same meaning as an NA.

---

---

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

Brian, John,

Comments inline
/MCruz

> Sent: Wednesday, September 05, 2001 9:42 PM
> To: sigtran

RC could be a basis for MTP-SAP and SCCP-SAP, but take into account
that a RC implies an NA but an NA does NOT imply a RC (different
RC could be defined for the same NA). Then, I agree with John: SAPs
are mapped onto NA values.

/MCruz

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 6 Sep 2001 08:31:19 -0700

Javier,
	If you will read the previous messages, I am the one stating that NA
and MTP-SAP serve the same purpose.

Now lets talk about RC and NA.  I don't like using a node specific parameter
(RC) to derive network specific information (NA).  RC is supposed to imply a
node's PC and possibly some other node specific SS7 "routing" information.
Each node is supposed to have its own RC.

I see NA as a network specific parameter, it describes the network
environment that these nodes participate in.  I see NA as an extension of
the SAP concept because the multiple network connections has moved from the
node (SAP) to the SG/STP (NA) AND because the associations between the nodes
will carry all of the traffic for all of the networks.  If there were
separate associations defined for each network involved, then we could
revert back to just SAP.  BUT there is a problem separate associations,
associations are defined at the IP level (single IP address (network
interface) to another single IP address (network interface)).  This is
independent of the multiple PCs the node will be known by from the different
networks.  Hence, separate associations are not possible unless you use
separate interface hardware.

The ideal NA model would have the SGs that are providing the network
connections and the end-nodes supported by the SGs, share a common NA value
for each specific network.  This is not possible in the RC model.  Each
end-node would have to have its own RC AND would have to have one for each
network.  An SCP would have to have extra tables just to track what the PC
and RC of its mate is for each network.  At least in the NA model, the mate
SCP in a network would have the same NA.  Hence, its current management and
configuration model could remain the same.

I think the SGs life is more difficult in the RC model, it must now do an N
(# of end-nodes) to 1 (one network of many) mapping for traffic received
from its end-nodes to determine if it destined to a specific network.  In
the NA model, this is a 1-to-1 mapping.

So please stop trying to tell me that a node specific parameter is a better
solution to a network specific problem.

Therefore, NA == RC is rejected.  I understand where I need NA and I
understand where you need RC.  I am willing to let them co-exist.  If you
must have a single parameter, then I only support NA!

John

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 7:58 AM
> To: sigtran
> At an SG you can differenciate traffic coming from different 
> SS7 nodes with the same SPC with help of MTP-SAP. In the IP 
> world we can translate MTP-SAP as NA. If NA is a parameter of 
> the RK, RC will be sufficient to get NA. So that sending RC 
> in Data is enough to have all the info needed in SGP and ASP 
> (i.e. NA). How to assign NA values, it's an implementation 
> specific issue.
> 
> BR // Javier.
> 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 18:00:59 +0200

Hi John, 

I fully support your view of NA utility. But there is one point I disagree with you:

You can also have one NA for each of your network in the RC model. You'll have a different RC per RK, but you can have the same NA for all the nodes included in the RK that belong to the same network. No problem with that. At ASP you can find your network's NA using the RC you send in DATA msg. Therefore you have what you need.

With this model you can assign NA the same value for a whole network. But with this model, other people can assign NA the same value as RC. This is implementation especific. The model works for both options.

BR // Javier.

> Sent: Thursday, September 06, 2001 5:31 PM
> To: sigtran

I have already read it.

> > > > > > If it is agreed that a RK does NOT span across more 
> than one 
> > > > > > NA, then I agree
> > > > > > However, if it is agreed that a RK DOES span across 
> more than 
> > > > > > one NA, the

---

---

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

Hi Maria,

My point was that it had been suggested that
folks who preferred the NA approach could 
simply configure RC to have the same value
as they would have with NA, and that's not
quite true.

From your message, I gather that you don't
see this as a limitation, though.

Cheers,

Lyndon

--- "Maria-Cruz Bartolome-Rodrigo (ECE)"
<[email-masked]> wrote:
> > > 	I think you missed the point.  RC is specific
> to a
> > > node and its PC
> > > etc. (all the info is rolled into one
> parameter). 
> > > Sure it can imply the NA
> > > In the case where the true application can
> handle
> > > traffic from multiple
> > > networks, all that is needed by these
> traditional
> > > nodes is a parameter that
> > > I think the only compromise is to allow both NA
> & RC
> > > as optional parameters.
> > > appearances occur and they may never use RC.  I
> have
> > > the feeling that RC
> > > eliminates/replaces the level 3 routing function
> (a
> > > poor man's
> > > implementation of SS7).
> > > 
> > > John
> > > 
> > > 
> > > > Subject: [M3UA Issue #2]: Add RC and/or NA in
> DATA
> > > msg
> > > > 
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > I'm trying to catch up with your discussions
> on
> > > different
> > > > would be better to treat each pointed issue in
> a
> > > different
> > > > thread, this is why I opened this new thread
> to
> > > deal with issue 2,
> > > > coming from "M3UA: Proposed Solutions to
> issues 1,
> > > 2, 4, 16" thread,
> > > > Although the discussion is getting the more
> and
> > > more complex, 
> > > > RK's can neither span NA's nor span SPMCs.  In
> the
> > > current draft
> > > > they cannot even span DPCs.  Therefore, RC
> implies
> > > both the NA and
> > > > ".... the Routing Key cannot extend across
> more
> > > than a single SPMC",
> > > > However, in the draft nothing is said about do
> not
> > > extend more than
> > > > one NA, I know we talked about that previously
> and
> > > as far as I know an
> > > > agreement wasn't reached. If you remember the
> RK
> > > parameter format
> > > > I missed a good bunch of mails (trying to
> catch up
> > > ;-), so let me know
> > > > Then, I think that firstable WE ALL NEED TO
> AGREE
> > > ABOUT WHETHER A RK 
> > > > NA should be added as optional parameters
> within
> > > DATA messages.
> > > > 
> > > > 
> > > > Comments?
> > > > /MCruz
> > > > 
> > > > 
> > > > ---
=== message truncated ===

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 6 Sep 2001 18:12:30 +0200

Hi Lyndon, 

If you give the same value to NA and RC, that could imply to have different NA for each node. But the problem disappear if you use NA as a part of the routing key (previously agreed), and get the networks NA from there with the help of RC.

BR // javier.

> Sent: Thursday, September 06, 2001 6:01 PM
> To: sigtran

---

---

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

Lyndon,

See comments
/MCruz
> as they would have with NA, and that's not

I agree, this is not the solution, although a single RC
could be configure to identify the whole network (NA),
this wouldn't solve anything.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 13:18:33 -0500

Maria-Cruz,

> are mapped onto NA values.

I agree that RC does not *always* imply NA, but it is possible to
identity map RC to NA, in which case RC *is* NA.  It just so happerns
that these are also the cases that John has steadfastly presented.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 13:37:51 -0500

Lyndon,

> as they would have with NA, and that's not

It is true.  Why do you think it is not true?

(Remember that registration does not restrict
the form of the RK, RK can contain parameters
not present in REG REQ like SSN).

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 16:23:34 -0500

John,

John Schantz wrote:                                          (Thu, 06 Sep 2001 08:31:19)
> and MTP-SAP serve the same purpose.

The MTP-SAP defined in Q.701 includes SI.  As no NA definition includes
SI, it is clear that NA is not sufficient to identify MTP-SAP.  RC via
the RK does include SI.  RC alone is sufficient to identify MTP-SAP.

> (RC) to derive network specific information (NA).

It is clear that the *value* of NA is not network specific, but is node
specific: it is a value that must be agreed between SG and ASP.

> RC is supposed to imply a node's PC and possibly some other node specific
> SS7 "routing" information.

That is an understatement.  The definition of RC includes the statement:

  "The Routing Context also uniquely identifies an SS7 entity (point
   code) into an SS7 network, as represented by the SG."

> Each node is supposed to have its own RC.

There is no restriction on RC requiring each node to have its own RC.
This statement is incorrect.

> environment that these nodes participate in.

That would depend on the definition of NA.  Which definition are you
referring to?

> I see NA as an extension of the SAP concept because the multiple network
> connections has moved from the node (SAP) to the SG/STP (NA) AND because the
> associations between the nodes will carry all of the traffic for all of the
> networks.

This is not the case for the MTP-SAP as defined in Q.701, and in particular
clause 4.2.

> If there were separate associations defined for each network involved, then
> we could revert back to just SAP.

RC identifies SAP per Q.701 4.2, NA does not.

> BUT there is a problem separate associations, associations are defined at
> the IP level (single IP address (network interface) to another single IP
> address (network interface)).  This is independent of the multiple PCs the
> node will be known by from the different networks.  Hence, separate
> associations are not possible unless you use separate interface hardware.
> 
> for each specific network.

It is not possible for SGs to share NA values the way that NA is defined.
Current NA definitions require different values depending on the network
configuration of the SG.

> This is not possible in the RC model.

It is possible in the RC model.  There is no restriction placed on RC which
precludes coordination of RC values across multiple SG.

> Each end-node would have to have its own RC AND would have to have one for
> each network.

There is no restriction placed on RC which precludes coordination across
multiple ASP.  In fact the AS concept provides a framework for precisely
that.  RC values can be assigned to AS independently of which ASP is
supporting the AS.

> An SCP would have to have extra tables just to track what the PC
> and RC of its mate is for each network.

This is implementation specific.  Extra tables are not required if RC
values are assigned wisely.

> At least in the NA model, the mate SCP in a network would have the same NA.

There is nothing precluding the mate SCP from having the same RC.  In fact,
there is nothing requiring the NA to be the same for mate SCP as defined
either.  NA is agreed between SG and ASP, just as RC is.

> Hence, its current management and configuration model could remain the same.

It can remain the same.  Both NA and RC are agreed between SG and ASP.
There is nothing precluding assigning RC values in identically the same
fashion as NA values are assigned.

> from its end-nodes to determine if it destined to a specific network.

The RC model is required for ASP management.  Where NA will suffice, the
value of RC can be assigned to the value that you would otherwise assign
to NA.

> In the NA model, this is a 1-to-1 mapping.

There is noting in the NA definition which requires such a 1-to-1 mapping.
That is an adminstrative matter between SG and ASP.  For RC, you can make
this a 1-to-1 mapping just as easily as NA.

> solution to a network specific problem.

NA is node specific an does not identify MTP-SAP per Q.701/4.2.

> must have a single parameter, then I only support NA!

Given that RC is required in DATA and SNMM when not implicit to the
association, when do you propose that the draft require NA to also
be included?  Which definition for NA?  How is NA provisioned between
SG and ASP?

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 6 Sep 2001 15:03:27 -0700

I think you enjoy making this stuff up.

I think you should do a search again on all of Q.70X for SAP.  You will not
find it.  You will have to look at SCCP.  

But it might take you a while to understand it.  I was at the ITU meeting in
Geneva when Mr. Talle of France Telecom introduced the concept.  Its use and
application is not obvious from the standard but MTP-SAP was created for
separating traffic because of different network environment(s).  The
examples only give separating MTP3 from MTP3b traffic, but the original
intent was so that multiple MTP network interfaces could be supported and
kept logically separate.

> Sent: Thursday, September 06, 2001 4:24 PM
> To: sigtran
> Cc: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 17:54:37 -0500

John,

John Schantz wrote: (Thu, 06 Sep 2001 15:03:27)
> I think you enjoy making this stuff up.

I did not make up Q.704/4.2

> find it.  You will have to look at SCCP.  

MTP-SAP does not occur in the specs.  Q.704/4.2 is the closest
it gets.  What did you mean by MTP-SAP?  I presumed that you
meant the OSI/ISO definition of SAP (which also occurs in SCCP).
That would be the Service Access Point at which a provider
gives service to its users.  That is precisely what is described
in Q.704/4.2.

Regardless of whether NA is an MTP-SAP or not, there is no
restriction on RK which precludes one from defining one's
RK's to route on NA only.

Because you can set RK == NA, and RC == RK, you can set
RC == NA by definition.

Because the definition of RC does not permit it to span NA,
it is always the case that RC => NA.

There is no need for NA in any message where RC is provided.

Any implementation can decide to route on NA only (RK == NA)
and can use NA for whatever purposes it wants (RC => NA)
without NA even being in a message where RC occurs.

Because this is true and RC is required where not implicit
in DATA and SNMM, it will not be possible to force an
implementation to ever include NA where RC is included.

Thus, even if NA is optional in DATA and SNMM, the spec
will be unable to force an implementation to ever include
it.  The only thing that can occur is the statement that
an implementation MAY include NA in DATA and SNMM if it
wants.  An implementation cannot be required to either
include it or use it.  That would be against the principles
laid out in RFC 2119.

--brian

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

---

---

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Fri, 7 Sep 2001 10:06:19 +0200

All,

It seems that people do still have different opinions... fine,
however, let me attempt to reach an agreement...

We know some people think that with the RC it should be enough
but... personnally I wouldn't have 
any problem voting for both (NA and RC) parameters if folks 
think they need them. 

Brian, in your opinion, is it 'unacceptable' to have both of them?
is that your point or you just preffer RC alone?

Hoping it helps.
/MCruz

> Sent: Friday, September 07, 2001 12:55 AM
> To: sigtran

---

---

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

Maria-Cruz,

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:       (Fri, 07 Sep 2001 10:06:19)
> is that your point or you just preffer RC alone?

What definition of NA and when would it be required in DATA and SNMM?

--brian

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

---

---

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

Hi all, 

In order to get more clarification, I would like to get technical reasons to know why the RC model is not valid for everybody. I try to summarize first:

We have a premise already accepted: NA is one more parameter included in the RK. So that possible examples of RK are <DPC=2-200, SSN=4> or <NA=5, OPC=2-300, DPC=2-400>. NA only takes part of the RK when needed  (this is implementation dependant). Cases where NA has to be taken into account have already been discussed and it's not needed to be repeated here again. If you send RC within your DATA msg, you can always find NA inside the RK at both ends (SGP and ASP). Why do you need to send NA as well?

If NA is not sent you don't have to support both models and your implementation would be simpler...

Any technical reasons against this? 

BR // Javier.

---

---

From: Dan Brendes <[email-masked]>
Date: Fri, 7 Sep 2001 09:29:36 -0400

> From Lyndon...
> 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

Since my personal view of this is different than what anyone else has offered, I
may as well throw this in the mix...

My preference is:
- RC only in DATA
- NA only in SNMM.

- For DATA msgs, I think RC only is probably the best choice (although I think
any variation of RC-only, NA-only, or RC+NA would be fine for my
implementation).
- condider NA only:
From the standpoint of providing the minimum set of info that is needed to
figure out which network this DATA msg applies to, I think an indication of
which network this data msg relates to is all that is needed.  Personally, I
think allowing an ASSOC to go asp-active for only a subset of the AS's that the
assoc has registered for is not a required capability and not something every
implementation will support.  Therefore I don't really think including RC just
to figure out if the traffic is arriving for an AS that has gone active is
necessary in all cases (it's not needed if the asp is active for all of its
routing keys or active for none of them).
- For traffic from SG->ASP:
However, I can also understand why the ASP would like to receive RC to minimize
work it may have to do wrt de-multiplexing traffic streams, and since the info
is readily available at the SG by the time I'm formatting a data msg, I really
don't mind putting it in there.  It also helps solve the problem of only
accepting service traffic related to AS's that the ASP has gone active for,
which is needed for those implementations that plan on supporting 'assoc only
active for a subset of its routing keys'.  I would agree that RC implies which
NA it is, so it is merely redundant to include the extra NA parameter in this
direction.
- For traffic from ASP->SG:
It is not absolutely clear to me that the RC makes sense in this direction
(since the routing keys are defined at the SG, not the ASP), but I can buy the
concept that the traffic is originating from some ApplicationServer on the ASP
side and the ASP is really just indicating which AS this is coming from to the
SG.  The arguments for RC in this case are pretty much the same as the SGS->ASP
direction.  SG implementations don't allow an ASP to be active for a subset of
there AS's would probably prefer to just receive NA instead of RC in this
direction, but I can get over it (it's just an extra lookup at the SG side).
- I think RC-only works for the widest range of implementations.

- For SNMM msgs, I think NA is all that is needed and is all that makes sense
for every implementation.
- Consider the SG sending a DUNA regarding a PC-1 in NA-1 to the ASP over an
assoc which has been configured/registered for 6 routing keys (3 in NA-1, 1 in
NA-2, 1 in NA-3, 1 in NA-4).
- How does the SG know which AS's on the ASP side are going to be concerned with
this DUNA?  The SG can probably assume that the 3 RC with NA=NA-1 need to be
informed, but how can the SG know which other AS (for NA-2, NA-3, and NA-4) need
to know about DUNA(NA-1)?  Should the SG include the RC for NA-2 in the DUNA
indication?  The SG has no way of knowing of if a particular AS with NA!=NA-1 is
going to care about the DUNA(NA-1) or not.  What is the SG supposed to do,
simply echo all of the RC that are configured/registered for that ASP back to
the ASP on the DUNA?  How useful is that?  Sounds like a big waste of SG CPU
cycles to me.
- The ASP side is the only side that knows which AS's need to know about
DUNA(NA-1).  If that intelligence resides up at the AS level on the ASP (as
opposed to the association level), then I think it should be the ASPs job to do
the replication.
- Of course for an implementation where a single routing key is being serviced
by a single assoc, the RC would work just fine.  But that's not the most general
model.
- I think NA-only works for the widest range of implementations.

"Javier Pastor-Balbas (ECE)" <[email-masked]> on
09/07/2001 05:46:43 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Dan Brendes/Raleigh/TEKELEC)
Subject:  RE: [M3UA Issue #2]: Add RC and/or NA in DATA msg

Hi all,

In order to get more clarification, I would like to get technical reasons to
know why the RC model is not valid for everybody. I try to summarize first:

We have a premise already accepted: NA is one more parameter included in the RK.
So that possible examples of RK are <DPC=2-200, SSN=4> or <NA=5, OPC=2-300,
DPC=2-400>. NA only takes part of the RK when needed  (this is implementation
dependant). Cases where NA has to be taken into account have already been
discussed and it's not needed to be repeated here again. If you send RC within
your DATA msg, you can always find NA inside the RK at both ends (SGP and ASP).
Why do you need to send NA as well?

If NA is not sent you don't have to support both models and your implementation
would be simpler...

BR // Javier.

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 07:06:03 -0700

I think its very neat that you deleted your first reference of Q.701
section 4.2.  Now you say its Q.704 section 4.2.  Here is a copy of
Q.704 section 4.2, please point out the MTP-SAP for me:

4.2	Normal routing situation
4.2.1	Signalling traffic to be sent to a particular signalling point
in the network is normally routed to one or, in the case of load sharing
between link sets in the international network, two link sets. A load
sharing collection of two or more link sets is called a combined link
set. Within a link set, a further routing may be performed in order to
load share the traffic over the available signalling links (see clause
2).
To cater for the situations when signalling links or routes become
unavailable, alternative routing data are defined.
For each destination which may be reached from a signalling point, one
or more alternative link sets (combined link sets) are allocated. An
alternative combined link set may consist of two or more (or all) of the
remaining available link sets, which may carry signalling traffic
towards the concerned destination. The possible link set (combined link
sets) appear in a certain priority order. The link set (combined link
set) having the highest priority is used whenever it is available. It is
defined that the normal link set (combined link set) for traffic to the
concerned destination. The link set (combined link set) which is in use
at a given time is called the current link set (combined link set). The
current link set (combined link set) consists either of the normal link
set (combined link set) or of an alternative link set (combined link
set).
For each signalling link, the remaining signalling links in the link set
are alternative links. The signalling links of a link set are arranged
in a certain priority order. Under normal conditions the signalling link
(or links) having the highest priority is used to carry the signalling
traffic.
These signalling links are defined as normal signalling links, and each
portion of load shared traffic has its own normal signalling link.
Signalling links other than normal may be active signalling links (but
not carrying any signalling traffic at the time) or inactive signalling
links (see clause 12).
4.2.2	Message routing (normal as well as alternative) is in principle
independently defined at each signalling point. Thus, signalling traffic
between two signalling points may be routed over different signalling
links or paths in the two directions.

> Sent: Thursday, September 06, 2001 5:55 PM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 07:27:14 -0700

The definition of NA that we have been working on via these e-mails this
past month (definitely not v8) and it would be required in all DATA &
SNMM messages when multiple networks are involved or when every traffic
must be separated (maybe to separate out (long (MTP3b style) vs. short
(MTP3 style) messages as discussed in ITU SCCP).  We could add a
disclaimer to say that if an SG & end-node are already using RC in DATA
& SNMM messages, then these nodes would have the option of including the
NA in the RC and hence, only RC would be used in this situation.
Otherwise, NA must be used.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 3:33 AM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 07:31:51 -0700

Because many of the SS7 nodes migrating to SS7 over IP will not need to
define RKs and they will not use RC to replace RL for routing.  In this
situation, RC is not present at all.  You can't get more technical than
that.

> Sent: Friday, September 07, 2001 4:47 AM
> To: sigtran
> In order to get more clarification, I would like to get 
> technical reasons to know why the RC model is not valid for 
> everybody. I try to summarize first:
> 
> We have a premise already accepted: NA is one more parameter 
> included in the RK. So that possible examples of RK are 
> <DPC=2-200, SSN=4> or <NA=5, OPC=2-300, DPC=2-400>. NA only 
> takes part of the RK when needed  (this is implementation 
> dependant). Cases where NA has to be taken into account have 
> already been discussed and it's not needed to be repeated 
> here again. If you send RC within your DATA msg, you can 
> always find NA inside the RK at both ends (SGP and ASP). Why 
> do you need to send NA as well?
> 

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 07 Sep 2001 11:00:24 -0400

Pls see below.

Ken

>We have a premise already accepted: NA is one more parameter included in the RK. So that possible examples of RK are <DPC=2-200, SSN=4> or <NA=5, OPC=2-300, DPC=2-400>. NA only takes part of the RK…

There has always been a desire to support three different provisioning
options:

(1)  RK only defined on SG
(2)  RK defined on SG and ASP
(3)  RK only defined on ASP (must use REG/DEREG in this case)

You can review the email threads regarding the Registration/Deregistration
and consider the support for not placing RCs in ASP Active/Inactive
as evidence.   

For option (1) to work, NA is needed and RC is not needed.  

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

---

---

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

Hi John, 

I'm not sure that I understand your point. But anyway, you always need to have a RK to discover what destination corresponds in the IP world. RC is not used to replace RL. RKs have some of the parameters that belong to the RL to analyse the ASP where to go. And RC is a reference to it (also seen as an index to RKs). In that way RKs and RCs are always present.

BR // Javier.

> Sent: Friday, September 07, 2001 4:32 PM
> To: sigtran

---

---

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

Hi Ken, 

Se answer below.

> From: Ken Morneault [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 5:00 PM
> To: sigtran

As RK has the NA inside and you have a relation 1:1 between RK and RC, at the ASP you can decide upon RC what application is involved. Therefore RC is enough.

---

---

From: Joe Keller <[email-masked]>
Date: Fri, 7 Sep 2001 11:12:12 -0400

Javiar,

    If the routing key is statically provisioned at the SG, the ASP doesn't know
the
RK or RC.  Please refer to option 1 of Ken's email.

Joe

09/07/2001 11:07:54 AM

To:   "sigtran" <[email-masked]>
cc:    (bcc: Joe Keller/Raleigh/TEKELEC)
Subject:  RE: [M3UA Issue #2]: Add RC and/or NA in DATA msg

Hi John,

I'm not sure that I understand your point. But anyway, you always need to have a
RK to discover what destination corresponds in the IP world. RC is not used to
replace RL. RKs have some of the parameters that belong to the RL to analyse the
ASP where to go. And RC is a reference to it (also seen as an index to RKs). In
that way RKs and RCs are always present.

BR // Javier.

> [email-masked]

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Sep 2001 10:24:47 -0500

If the RK is not provisioned on ASP side, how can RC be filled to DATA in
ASP to SG direction?

    Tolga

> From: Joe Keller [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 11:12 AM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 08:41:54 -0700

It wasn't needed in the first place.  You still have the RL with its DPC
to tell you where you need to send it next.

John

> From: Asveren, Tolga [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 10:25 AM
> To: sigtran
> > "Javier Pastor-Balbas (ECE)" 
> <[email-masked]> on
> > 09/07/2001 11:07:54 AM
> > 

---

---

From: [email-masked]
Date: Fri, 7 Sep 2001 11:43:55 -0400

Brian and Lyndon,

Brian is wrong when he states that "There is no requirement placed on the [SG] to return a unique value of RC 
for every combination of DPCs in routing keys."

Section 1.2 states "A Routing Key describes a set of SS7 parameters and parameter values that 
UNIQUELY define the range of signalling traffic to be handled by a particular Application Server."

Futhermore, I object to the change that was made to Section 1.4.2.2 (Routing Key Limitations), between versions 6 & 7, where MUST was 
changed to SHOULD: "Routing Keys SHOULD be unique in the sense that each 
received SS7 
signalling message SHOULD have a full or partial match to a single routing result to an Application Server."

This contradicts the definition of Application Server in Section 1.2: "A logical entity serving a specific Routing Key."

Why have the logical concept of Application Server if a given message can 
be linked to more than one RK, and can be routed, at the SG, to more than 
one AS?

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

"Brian F. G. Bidulock" <[email-masked]>
09/05/01 06:16 PM
Please respond to sigtran

        cc: 

Lyndon,

--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: [email-masked]
Date: Fri, 7 Sep 2001 11:54:31 -0400

Javier,

You cannot have a differenct RC per RK. Section 1.4.2.1 states "... the Routing Context parameter is a 4-byte 
value (integer) that is associated to that Routing Key in a 1:1 relationship."

Barry Nagelberg
Software Engineer
RadiSys, Corp.

"Javier Pastor-Balbas (ECE)" <[email-masked]>
09/06/01 12:00 PM
Please respond to sigtran

Hi John, 

I fully support your view of NA utility. But there is one point I disagree 
with you:

You can also have one NA for each of your network in the RC model. You'll 
have a different RC per RK, but you can have the same NA for all the nodes 
included in the RK that belong to the same network. No problem with that. 
At ASP you can find your network's NA using the RC you send in DATA msg. 
Therefore you have what you need.

With this model you can assign NA the same value for a whole network. But 
with this model, other people can assign NA the same value as RC. This is 
implementation especific. The model works for both options.

BR // Javier.

I have already read it.

> > > > >                I think you missed the point.  RC is specific to 
a node 
> > > > > and its PC

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Sep 2001 12:04:13 -0500

John,

What I was asking was, if it is decided that RC will be there in DATA, then how can one fill it on ASP side for messages to be sent to SG side, if RK is not provisioned on ASP side? If the users are registered per RC, then you can use the incoming stream to decide for RC but then the users will need to provision it.
I think what you meant with your message was -correct me if I am wrong- SG selection should be done just based on DPC. I don't think this is a good approach, because this will allow that between two signaling points, messages can be sent in one direction but not in the other direction.

    Tolga

> Sent: Friday, September 07, 2001 11:42 AM
> To: sigtran

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Sep 2001 12:17:55 -0500

resending......
John,

    Tolga

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:04:30 -0500

John,

Pardon.  Typo.  Q.701/4.2.

--brian

John Schantz wrote:                                          (Fri, 07 Sep 2001 07:06:03)
> 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: Fri, 7 Sep 2001 13:09:16 -0500

John,

So you are saying that these implementations don't want to implement
the ASP/AS model at all?  Why should M3UA worry about them?

--brian

John Schantz wrote: (Fri, 07 Sep 2001 07:31:51)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:12:48 -0500

Ken,

Ken Morneault wrote:                                          (Fri, 07 Sep 2001 11:00:24)
> For option (1) to work, NA is needed and RC is not needed.  

It is for option (1) that it has been argued that RC is needed
most.  With NA, RK is needed on ASP to demux traffic.  For options
(1), (2) and (3) to work, RC is need and NA is not.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:07:30 -0500

John,

Are you saying that when RC is in the message, NA need not
be used?  RC will carry the requirement that it be in DATA
and SNMM when not implicit to the association.  That means
that NA will never need to be used?

--brian

John Schantz wrote:  (Fri, 07 Sep 2001 07:27:14)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:17:19 -0500

Joe,

If you given an example of Ken's (1), we will work through it for you.

--brian

Joe Keller wrote:   (Fri, 07 Sep 2001 11:12:12)
> the RK or RC.  Please refer to option 1 of Ken's email.
> 
> Joe
> 

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 11:22:03 -0700

Typo or not, its still not in Q.701/4.2.  Here is a copy of the section
and you still will not find it.  Oh, by the way, this section has been
around a for a LONG time and it has not been modified since the BLUE
BOOK days (pre-1988).

> Sent: Friday, September 07, 2001 1:05 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:23:14 -0500

John,

RL is not sufficient to tell where to send the message from 
the ASP, the ASP also needs to know the context of the RL.
This context is provided by RC in the same fashion as NA.
RC == NA provides an NA context to frame the RL.  RC => NA
povides a more granular context (such as SI as provided in
Q.701/4.2).  Both are provided at the ASP in the same way.

--brian

John Schantz wrote:                                          (Fri, 07 Sep 2001 08:41:54)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 11:31:18 -0700

Actually, my nodes will never use RC, hence like you, I can claim the
"RC will never need to be used".  My nodes will only use NA when they
handle traffic from multiple networks.

I was trying to compromise to say that for nodes that already must use
RC to function, since they lack the appropriate protocol routing
functionality, they could extend the RC to include NA since they are
SOOOO DEPENDENT on RC.  The rest of us that DO NOT have this DEPENDENCY
will use NA.

> Sent: Friday, September 07, 2001 1:08 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:19:46 -0500

Tolga,

Becase RC is associated with the interface to the MTP-User.  The
MTP-User by selecting the interface for an outgoing message also
selects a value of RC.  So, where RC == NA, by selecting the
interface, the MTP-User implicitly selects the NA value.  This
is no different for NA or RC.  They are both the same concept.
It is just that RC can become more granular than NA.

--brian

Asveren, Tolga wrote: (Fri, 07 Sep 2001 10:24:47)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 11:35:51 -0700

Joe,
	Are you trying to say that the ASP doesn't know who he is?  He
should know that that he is a specific PC and he should also know if he
is handling a subset of the PC's traffic such as CIC range or SSN.

John

> Sent: Friday, September 07, 2001 10:12 AM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 11:40:56 -0700

If RL has not been sufficient, then I would hate to have to tell the
hundreds of SS7 networks that have been in existence for almost 20 years
that they don't have sufficient information for routing their messages.

> Sent: Friday, September 07, 2001 1:23 PM
> To: sigtran
> [email-masked]
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:48:21 -0500

Barry,

[email-masked] wrote:                (Fri, 07 Sep 2001 11:43:55)
> Brian and Lyndon,
> 
> Brian is wrong when he states that "There is no requirement placed
> on the [SG] to return a unique value of RC for every combination
> of DPCs in routing keys."
> 
> Section 1.2 states "A Routing Key describes a set of SS7
> parameters and parameter values that UNIQUELY define the range of
> signalling traffic to be handled by a particular Application
> Server."

This deos not require a unique RC for every combination of DPCs.
It only requires no overlap.

> 
> Futhermore, I object to the change that was made to Section
> 1.4.2.2 (Routing Key Limitations), between versions 6 & 7, where
> MUST was changed to SHOULD: "Routing Keys SHOULD be unique in the
> sense that each received SS7 signalling message SHOULD have a full
> or partial match to a single routing result to an Application
> Server."

It was changed because of the default ASP.  In the case of the
default ASP a RK may result in multiple ASPs.  The SHOULD should
be removed as well, because how the SG performs this analysis,
whether determinant or not, is the SG implementation's business.

> This contradicts the definition of Application Server in Section
> 1.2: "A logical entity serving a specific Routing Key."

There is no contradiction.

> Why have the logical concept of Application Server if a given
> message can be linked to more than one RK, and can be routed, at
> the SG, to more than one AS?

It can resolve to more than on ASP, not more than on AS.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Sep 2001 13:46:36 -0500

Brian,

I know your approach to this question, I just want to clarify that other implementations can get here into problems by filling RC. If the interface is per NA, then filling RC based on it will be impossible, unless an analysis is done on the message -because as you have said RC is more granular than NA-. And this analysis would require RK info.

    Tolga

> Sent: Friday, September 07, 2001 2:20 PM
> To: sigtran

---

---

From: Joe Keller <[email-masked]>
Date: Fri, 7 Sep 2001 14:51:26 -0400

John,

    That is not what I am saying.  Actually it is the opposite.  Consider the
scenario
where ASP-1 services just DPC=PC-1, SI=5 and CIC range 1-100.  The SG can be
provisioned with a routing key which matches that criteria for ASP-1.  When an
MSU
from the PSTN reaches the SG, it matches the routing key and sends it to ASP-1.
The ASP isn't going to receive traffic from the SG that doesn't match the
routing key.
What would the ASP do with a routing context if it is only to handle traffic for
that routing
key?  Granted this is a simple scenario but it is out there today and working.
What am
I missing?

Joe

"Schantz, John" <[email-masked]> on 09/07/2001 02:35:51 PM

Joe,

John

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 13:52:43 -0500

Javier,

I agree with Barry here.  The 1:1 relationship between RK
and RC is necessary.

--brian

[email-masked] wrote:                (Fri, 07 Sep 2001 11:54:31)
> Javier,
> 
> You cannot have a differenct RC per RK. Section 1.4.2.1 states "... the
> Routing Context parameter is a 4-byte value (integer) that is associated to
> that Routing Key in a 1:1 relationship."
> 
> Barry Nagelberg
> Software Engineer
> RadiSys, Corp.

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Sep 2001 14:04:50 -0500

Hi,
 But the general case is that an ASP can serve more than one AS.Your example
(1 AS in 1 ASP) is a special case.

   Tolga

> Sent: Friday, September 07, 2001 2:51 PM
> To: sigtran
> key?
>  Granted this is a simple scenario but it is out there 
> today and working.
> What am
> I missing?
> 
> Joe
> 
> 
> 
> 
> 

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 07 Sep 2001 15:03:03 -0400

Brian,

Pls see below.

Ken

>(1), (2) and (3) to work, RC is need and NA is not.

For option (1), RC would not be defined on the ASP since RK
is not defined (RC 1:1 mapping to RK).  For option (1) with
NA, only RL/NA is needed to demux traffic.

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 07 Sep 2001 15:05:16 -0400

John,

No, Joe was just staying that if the ASP does not have
provisioned RKs, it will not have provisioned RCs either.
Of course, this ASP would have Routeset(s) information.

Ken

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 7 Sep 2001 12:27:32 -0700

Joe,
	No, I don't think you missed anything, it just sounded like you
didn't know how the traffic would be filtered by the SG via an RK.  This
has been my point from the beginning.  I am expecting for my nodes to
have their RK == PC to be statically configured at the SGs.  Since I
have a fully functional node, I will actually verify that I only get
messages for my PC.  No need for RK, no need for RC.

In the reverse, I will statically assign routes for all remote PCs via
the SGs.  Sounds like regular SS7 configuration stuff doesn't it.

John

> Sent: Friday, September 07, 2001 1:51 PM
> To: sigtran

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 7 Sep 2001 12:58:35 -0700 (PDT)

--- "Brian F. G. Bidulock" <[email-masked]>
> John,
Why should M3UA worry
> about them?

We should keep in mind that we are trying to design
to what we think users will need, and tailoring our
models accordingly.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 14:59:34 -0500

John,

I have Q.701/4.2 (03/93) which reads:

  4.2  User location in system structure

  A potential user fo the transport service is typically included in the
  system structure by provision of a separate User Part.  This requires
  allocation of a service indicator code, the specification of which is
  part of both the Message Transfer Part and User Part concerned.

  As an alternative, a potential user may be catered for, together with
  other similar users, by an already existing or new User Part.  In such
  a case the discrimination between messages belonging to this potential
  user and the other similar users is an internal matter within the User
  Part concerned.  It then follow that all messages belonging to such a
  User Part are necessarily handled, e.g. as regards routing, in a uniform
  manner by the Message Transfer Part.

I think that this is pretty clear that the concept of an
MTP-SAP includes SI.

--brian

John Schantz wrote:                                          (Fri, 07 Sep 2001 11:22:03)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:01:50 -0500

John,

Your nodes do not have to comply with the M3UA draft if you don't
want to interoperate with other nodes.

--brian

John Schantz wrote:                                          (Fri, 07 Sep 2001 11:31:18)

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

---

---

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

John,

In the M3UA model, and ASP does not "have" a PC.  Only an AS
"has" as PC.

--brian

John Schantz wrote:                                          (Fri, 07 Sep 2001 11:35:51)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:06:02 -0500

John,

An SS7 node also has the route (linkset) upon which the message
arrives to place the RL in context.  It is only in the context
of the link upon which a message is received that an SS7 can
fully interpret the NI bits in the RL.

If the ASP does not know the route (RC) that the message arrives
on, it is also incapable of interpreting the NI bits in the
RL.  You want to use NA for this.  RC will do.

--brian

John Schantz wrote:                                          (Fri, 07 Sep 2001 11:40:56)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:12:58 -0500

Ken,

Ken Morneault wrote:                                          (Fri, 07 Sep 2001 15:03:03)
> NA, only RL/NA is needed to demux traffic.

If you are using RL/NA to demux traffic at the ASP you are applying
a RK whether you want to call it that or not.  What is the problem
with numbering the results of this demuxing operation and using the
values for RC?  Then demux can be on the basis of RC and you don't
need to do RL/NA RK analysis for demux?

If you really want to do it the RL/NA way, destroy the information
contained in the RC using RC -> NA and then reperform the RK analysis
which has already been provided for you by the SG.

RC in the message is sufficient.

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

---

---

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

Tolga,

If the interface is per NA, set RC == NA and there is no problem.
RK analysis is not required at the ASP because RK == NA == RC.

--brian

Asveren, Tolga wrote:                                    (Fri, 07 Sep 2001 13:46:36)
> Brian,
> 
> I know your approach to this question, I just want to clarify that other
> implementations can get here into problems by filling RC. If the interface
> is per NA, then filling RC based on it will be impossible, unless an
> analysis is done on the message -because as you have said RC is more
> granular than NA-. And this analysis would require RK info.
> 
>     Tolga
> 

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:17:14 -0500

Ken,

If you are splitting traffic to multiple AS at the  ASP
you need RC or use NA/RL as a RK.  RC is sufficient to
avoid provisioning RK at the ASP.  NA is not.  With NA
RK's must be defined in terms of NA/RL combinations to
identify the AS to which the traffic is bound.  The only
case where NA will suffice to have no RK provisioned at
the ASP is when there is one AS.  But then neither NA nor
RC is required (they are both implicit to the association).

So which is it?  Are you talking about the case where NA/RL
is used to split traffic between AS (which is precisely a
RK) or the case where there is only one big AS and you neither
need NA nor RC because they are implicit?

--brian

Ken Morneault wrote:                                          (Fri, 07 Sep 2001 15:05:16)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 15:26:46 -0500

Lyndon,

Are you proposing that we tear open the SG/AS model and change
it at this juncture?  Particularly when it has been shown to be
completely adequate?

My point was that if there is an implementation which doesn't
want to follow an RFC for the sake of not following RFC, there
is nothing that can be done for them.

It has basically been shown that John can always either rely on
the RC => NA relationship to derive NA in any case he wants.
Designing an implementation to just place NA in the message and
just use NA is just plain foolish from the point of view of
interoperability.

It is clear that the requirement for interoperability on RC is
that RC MUST be placed in DATA and SNMM messages when not implicit
to the association.

An implementation which chooses to place NA and not RC in the
message where RC is required risks interoperability problems that
the M3UA draft cannot help the implementation with.

An implementation of M3UA which chooses to violate the
interoperability requirements of the draft are on their own.
This is not a case of catering to need, but a case of catering
to whim.

--brian

Lyndon Ong wrote:                                          (Fri, 07 Sep 2001 12:58:35)

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

---

---

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

Dan,

NA only is not sufficient in SNMM.  ASPTM procedures need to be
applied to SNMM as well as DATA.

--brian

Dan Brendes wrote:                                            (Fri, 07 Sep 2001 09:29:36)

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

---

---

From: Dan Brendes <[email-masked]>
Date: Fri, 7 Sep 2001 17:26:37 -0400

Brian -

OK, so you're saying you only want to receive a DUNA on AS which are active?
That still doesn't answer my question as far as the SG knowing which RC I'm
supposed to indicate to the ASP in the DUNA.

Can we stick w/ the example I started for a second...

There are 6 routing keys for the assoc with routing keys spread across 3
networks, lets assume they are all dpc only keys, and the assoc sent asp-active
for each RC
RC        DPC       NA        STATUS
1         1-1-1          1         Active
2         2-2-2          1         Active
3         3-3-3          1         Active
4         1-1-1          2         Active
5         1-1-1          3         Active
6         1-1-1          4         Active

Now a DPC, say 4-4-4 in NA=1 goes inactive.  I want to send you a DUNA(4-4-4, in
NA=1).
How exactly do you suggest I fill in the RC parameter in the message?

"Brian F. G. Bidulock" <[email-masked]> on 09/07/2001 04:27:57 PM

To:   "sigtran" <[email-masked]>
cc:   [email-masked] (bcc: Dan Brendes/Raleigh/TEKELEC)
Subject:  Re: [M3UA Issue #2]: Add RC and/or NA in DATA msg

>applied to SNMM as well as DATA.

Brian -

OK, so you're saying you only want to receive a DUNA on AS which are active?  I
can buy that, but that still doesn't answer my question as far as the SG knowing
which RC I'm supposed to indicate to the ASP in the DUNA.

Can we stick w/ the example I started for a second...

There are 6 routing keys for the assoc with routing keys spread across 3
networks, lets assume they are all dpc only keys, and the assoc sent asp-active
for each RC
RC        DPC       NA        STATUS
1         1-1-1          1         Active
2         2-2-2          1         Active
3         3-3-3          1         Active
4         1-1-1          2         Active
5         1-1-1          3         Active
6         1-1-1          4         Active

Now a DPC, say 4-4-4 in NA=1, goes inactive.  I want to send you a DUNA(4-4-4,
in NA=1).
How exactly do you suggest the SG fill in the RC parameter in the message?

In m3uav8, The DUNA message contains the following parameters:
     Network Appearance       Optional
     Affected Destinations    Mandatory
     INFO String                   Optional
Many people on the list, yourself included, are advocating changing this to:
     Routing Context          Mandatory
     Affected Destinations    Mandatory
     INFO String                   Optional

Again, how do you suggest the SG fill in the RC parameter in the message?
The RC parm has tag=6, len=?, and a list of 32bit rc

Option #1 - Am I supposed to send an RC parm with all six RC in it?
0x0606         // tag=6, len=6 dwords
0x0001         // rc1
0x0002         // rc2
0x0003         // rc3
0x0004         // rc4
0x0005         // rc5
0x0006         // rc6

Option #2 - Or am I supposed to send an RC parm with only the 3 RC with the same
NA value as the Concerned Pt Code that is no longer available?
0x0603         // tag=6, len=3 dwords
0x0001         // rc1 since rc1 has na=1 which matches the 4-4-4 cpc
0x0002         // rc2 since rc2 has na=2 which matches the 4-4-4 cpc
0x0003         // rc3 since rc3 has na=3 which matches the 4-4-4 cpc

If your answer is Option #1, and M3UA is changed so that DUNA no longer has the
NA parm (only the RC parm), the message does not contain the fact that NA=1 for
the 4-4-4 CPC.  The ASP does not know whether the concerned pt code was in NA=1,
NA=2, or NA=3.

If your answer is Option #2, what is the point of the SG side echoing back to
the ASP the fact that RC1 thru RC3 are active, an the ASP side having to dig
into the routing key data for those RC to find the NA.

Sounds to me like what you really need is the same parameter content for the
DUNA as in m3uav3 (affected dpc + na + info), but the stipulation that the DUNA
is only sent over an association which is active for at least 1 routing context.
So again, I assert that all that is needed is NA.

Dan

Dan Brendes wrote:                                            (Fri, 07 Sep 2001
09:29:36)

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

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Sep 2001 16:28:47 -0500

Brian,

When I say other implementations, what I mean is, implementations which use the same entity for SS7 user part processing for ASs, which have the same DPC+NA. Those can't fill RC, if the RKs in their system is finer than PC (unless they do an analysis).

    Tolga 

> Sent: Friday, September 07, 2001 4:08 PM
> To: sigtran
> > > > > > > If NA is not sent you don't have to support both 
> models and
> > > > > > > your implementation would be simpler...
> > > > > > >

---

---

From: Dan Brendes <[email-masked]>
Date: Fri, 7 Sep 2001 17:46:49 -0400

sorry for sending this twice, but I meant to delete the reply at the top of the
previous reply...

Brian -

Dan

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

---

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 17:11:42 -0500

Dan,

Dan Brendes wrote:                                            (Fri, 07 Sep 2001 17:26:37)
> Now a DPC, say 4-4-4 in NA=1 goes inactive.  I want to send you a
> DUNA(4-4-4, in NA=1).  How exactly do you suggest I fill in the RC
> parameter in the message?

I think you are referring to the case where the transfer-
prohibited has occured pertaining to a routeset belonging
equally to DPC 1-1-1, 2-2-2 and 3-3-3.  This is not the general
case as has already been demonstrated: the DUNA(4-4-4/1) could
pertain to DPC 1-1-1 without pertaining to DPC 2-2-2 and 3-3-3.)
I will assume that your example is for the specific case where
the SG offers the identical set of routsets to each DPC 1-1-1,
2-2-2, and 3-3-3 (because you have labelled them with identical
NA values and thus they belong to the same network parition
under the current definition of NA).

I will add SI and OPC columns to the table, even though in your
example, they appear to be wildcarded.

In the case which you present,

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Active
  2     1    *   *       2-2-2              Active
  3     1    *   *       3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

you would place RCs 1, 2 and 3 in the message.

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Active
  2     1    *   *       2-2-2              Active
  3     1    *   *       3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

you would put RC 1 and 3 only in the message.

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Active
  2     1    *   *       2-2-2              Inactive
  3     1    *   3-*-*   3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

you would put only RC 1 in the message.

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Inactive
  2     1    *   *       2-2-2              Inactive
  3     1    *   3-*-*   3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

you would not send the message.

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1,2-2-2,3-3-3  Active
  2     2    *   *       1-1-1              Active
  3     3    *   *       1-1-1              Active
  4     4    *   *       1-1-1              Active

you would place RC 1 (and RC == NA) in the message.

That is how things already work in SUA.

--brian

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

---

---

From: Dan Brendes <[email-masked]>
Date: Fri, 7 Sep 2001 17:48:12 -0400

sorry for sending this twice, but I meant to delete the reply at the top of the
previous reply...see below

Brian -

Dan

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

---

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 7 Sep 2001 15:35:22 -0700 (PDT)

Brian,

Whoa, there is no RFC for M3UA yet, and we are
still trying to reach agreement on the model.

I agree that RC can be used to achieve the same
results that John wants with NA, but with some added
overhead that he doesn't want.  And judging
from the responses, this is not a whim on the
side of any one person, there are a number of
people implementing that way.

If we can reach agreement to include RC whenever
this is required and not implicit, won't that be
satisfactory for your purposes, even if NA is
included as well?  That should satisfy both sides,
and I think John and co. are willing to go with this.

The one case I can think of where we might want
an alternative to a specific RC is the SNMM case,
when the message applies to multiple RCs, it
might make sense to have a "wildcard" RC 
behavior to distribute to all AS's instead of
having to specify a list (related to Dan's 
comment).

Cheers,

Lyndon (hoping to get the spec out the door)

--- "Brian F. G. Bidulock" <[email-masked]>

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 17:43:54 -0500

Dan,

Dan Brendes wrote:                                            (Fri, 07 Sep 2001 17:46:49)
> How exactly do you suggest the SG fill in the RC parameter in the message?

Answered in previous response.  Filling in RC is rather trivial.

>      Affected Destinations    Mandatory

Actually it is:
       Routing Context          Optional

There is no need to send RC when it is implied by the association (i.e.,
there is only one AS on the asssociation).

> 0x0003         // rc3 since rc3 has na=3 which matches the 4-4-4 cpc

Above answered in previous note.

> the 4-4-4 CPC.  The ASP does not know whether the concerned pt code was in
> NA=1, NA=2, or NA=3.

I wouldn't recommend blindly placing every RC value in the message.

> into the routing key data for those RC to find the NA.

The reason for sending the RC values is that the SG can be configured to
offer different routesets to different ASP point codes in the same Network.
Either the SG specifies which RCs to which the DUNA applies or the ASP
will need to be provisioned with SG network attachment specific information
(which routesets are offered to which ASP signalling points based on A, B/D,
and F-link attachment to the SS7 network).  It is unworkable to provision
SG-specific network attachment specific information at the ASP.

Do you see what I am getting at here?

> is only sent over an association which is active for at least 1 routing context.

This is not true when the SG offers different routsets to different RCs.

Take your example again:

  RC     NA     SI     OPC     DPC     AS/ASP State
  1      1      *      *       1-1-1   Active
  2      1      *      *       2-2-2   Active
  3      1      *      *       3-3-3   Active
  4      2      *      *       1-1-1   Active
  5      3      *      *       1-1-1   Active
  6      4      *      *       1-1-1   Active

Now, say that the SG only offers F-link attachment between DPC 4-4-4/1 and
DPC 3-3-3/1, but offers B/D-link attachment to DPC 1-1-1/1 and 3-3-3/1.
Under the current definition of NA, it would be necessary to do as follows
to distinguish these two SPMCs (where DUNA applies):

  RC     NA     SI     OPC     DPC     AS/ASP State
  1      1      *      *       1-1-1   Active
  2      1      *      *       2-2-2   Active
  3      5 <-   *      *       3-3-3   Active
  4      2      *      *       1-1-1   Active
  5      3      *      *       1-1-1   Active
  6      4      *      *       1-1-1   Active

This shows two things:  when SS7 link configuration changes
are made at the SG, NA values must change; and, if NA is used
only in SNMM, the ASP must be statically provisioned based on
the SS7 link configuration at the SG.  Neither of these is
acceptable from an administrative standpoint.

Note that no change in RC assignment was required because
RC is never coarser than an SPMC/CPC (one of the conditions
placed on RK is that it not span SPMC).

NI+CPC would work but the NA = NI+CPC proposals were firmly
rejected.  It just so happens that RC => NI+CPC as well.

Thus RC is always sufficient and NA would be unworkable.

> So again, I assert that all that is needed is NA.

Neither the ASP nor the SGP can determine if an SNMM message was
late-delivered based on NA.  That is, they cannot perform ASPTM
procedures based on NA.  NA is not sufficient, but RC is.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 17:54:08 -0500

Lyndon,

Lyndon Ong wrote:                                          (Fri, 07 Sep 2001 15:35:22)
> and I think John and co. are willing to go with this.

John was saying that his implementation would use NA only
and would never include RC.  That does not strike me as
a basis for interoperability.

Given that RC is required in DATA and SNMM where not
implicit, NA is not required.

If you say that an implementation MAY include NA also
if it wishes to, I don't see the difference between
that and RC only.  The only implementation which would
need NA in the message is one which simply doesn't want
to internally map RC to NA.

What I do not agree to is any statement requiring an
implementation to also place NA where RC has been
provided.

John and Ken are saying that NA would be required in
the message either instead of RC, or along with RC.
As the only time that this does not place an additional
provisioning burden on the ASP is when NA == RC, there
is no reason to name it any differently than RC.

In all circumstances where NA is sufficient, one can
set RC == NA.  Therefore, only RC is necessary in the
messages.

> having to specify a list (related to Dan's 

See response to Dan's comments.

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 7 Sep 2001 16:42:21 -0700 (PDT)

You've lost me slightly on this, see below...

> DPC 3-3-3/1, but offers B/D-link attachment to DPC

B/D-link attachment BETWEEN 1-1-1/1 and 3-3-3/1?
Aren't these IP entities in Dan's table?

In any case, I'm sure I missed it much earlier -
but why would an SG offer different attachment
relationships to different AS's within the same
network?  Is this desirable?

Thanks,

Lyndon

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 7 Sep 2001 17:05:28 -0700 (PDT)

> implementation to also place NA where RC has been

What if we try to specify conditions on sending
RC and NA, e.g.:

-- send RC if there are multiple AS's configured
at the ASP

-- send NA if there are multiple signaling networks
attached to the SG and routing label information 
may be non-unique

Would that satisfy people?

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 19:18:05 -0500

Tolga,

That is rather implementation dependent, but what is the purpose
of defining granular AS (RC) when the only RK one needs is based
on NA+DPC?  Such an implementation need only define RK == NA+DPC
and thus need only assign RC on an NA+DPC basis?

Such as in Dan's example:

The SG sets message sent to 1-1-1/1 with RC 1.  The ASP
sets messages sent from 1-1-1/1 with RC 1.

Where's the problem?

--brian

Asveren, Tolga wrote:                           (Fri, 07 Sep 2001 16:28:47)
> Brian,
> 
> When I say other implementations, what I mean is, implementations which use
> the same entity for SS7 user part processing for ASs, which have the same
> DPC+NA. Those can't fill RC, if the RKs in their system is finer than PC
> (unless they do an analysis).
> 
>     Tolga 
> 

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

---

---

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

Lyndon,

This is the case presented in example already:

                         SG                        ASP
                  __________________          ______________
4-4-4/1          /          3-3-3/1 \        /              \
 _____           |             ___  |        |     _____    |
|/   \| F-links  |            /   \ |  RC3   |    |     |   |
|     |__________|____________|SEP|_|________|____| AS3 |   |
|\___/|          |            \___/ |        |    |_____|   |
                 |                  |        |              |
                 |          2-2-2/1 |        |              |
                 |             ___  |        |     _____    |
                 |   _____    /   \ |  RC2   |    |     |   |
      ___________|__|     |___|SEP|_|________|____| AS2 |   |
                 | /| STP |\  \___/ |        |    |_____|   |
       B/D-links |/ |_____| \       |        |              |
                 /     |    1-1-1/1 |        |              |
                /|     |      \___  |        |     _____    |
               / |     |      /   \ |  RC1   |    |     |   |
              /  |     |      |SEP|_|________|    | AS1 |   |
             /   |     |      \___/ |        |    |_____|   |
            /    \_____|____________/        \______________/
           /           |
                       | C-links
                       |

Lyndon Ong wrote:                   (Fri, 07 Sep 2001 16:42:21)
> Aren't these IP entities in Dan's table?

Pardon me.  See the diagram.  B/D-Link attachment to 1-1-1/1 and
2-2-2/1.

In the diagram, an F-link failure will result in DUNA(4-4-4/1),
but this duna must only be sent to AS1 (labelled with RC1).  AS2
and AS3 still have connectivity to 4-4-4/1.

If RC is not in SNMM, it will be impossible for the ASP to
distinguish DUNA(4-4-4/1) as a result of F-link failure
(applicable to AS1) from a DUNA(4-4-4/1) as a result of B/D-link
failure (applicable to AS2 and AS3).

The only NA solution would be to number NAs differently so that
we have 3-3-3/5 and 2-2-2/1 and 1-1-1/1.  Then the two
situations are distinguished as DUNA(4-4-4/5) for F-link failure
and DUNA(4-4-4/1) for B/D-link failure.  This means that NA
would need to be numbered based on Network/Attachment pushing
SG-configuration specifics into the ASP.

By using just RC, the two cases are automatically distinguished
by RC: F-link failure is DUNA(4-4-4, RC=3) and B/D-link failure
is DUNA(4-4-4, RC=1,2).

> network?  Is this desirable?

M3UA does not currently restrict it.  These represent multiple
SPMCs per network.  There is no need to restrict this case
because RC handles it nicely.  NA does not.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Sep 2001 19:16:17 -0500

Lyndon,

Lyndon Ong wrote:                   (Fri, 07 Sep 2001 17:05:28)
> attached to the SG and routing label information 

The routing label information is never non-unique when
RC is required in the message.  The routing label
information is never non-unique then RC is not required
in the message (except REG REQ).

This equates to never send NA in DATA or SNMM.

> Would that satisfy people?

Yes, removing NA from DATA and SNMM would be fine.

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 10 Sep 2001 07:44:42 -0500

Brian,

Of course there is no problem, as long as one knows, that his route keys are
limited to PC granularity, if he uses one SS7 entity for all messages
belonging to the same PC. I just want to make sure, that when people decide
to put RC in DATA messages, they think carefully how to fill it in ASP-to-SG
direction, so afterwards we don't need to do the whole discussion again. In
fact I also want that it is stated clearly that RC should be filled in both
directions. Mostly the discussions are about only about SG-to-ASP case.

      Tolga

> Sent: Friday, September 07, 2001 8:18 PM
> To: sigtran

---

---

From: [email-masked]
Date: Mon, 10 Sep 2001 09:44:07 -0400

Lyndon,

Works for me.

Barry Nagelberg

Lyndon Ong <[email-masked]>
09/07/01 08:05 PM
Please respond to sigtran

Cheers,

Lyndon

---

---

From: Dan Brendes <[email-masked]>
Date: Tue, 11 Sep 2001 11:37:18 -0400

Brian -
Please see comments below (marked w/ DAB).
In summary it is my opinion that NA is still a better choice than RC in the SNMM
messages.

"Brian F. G. Bidulock" <[email-masked]> on 09/07/2001 06:11:42 PM

Dan,

17:26:37)

--------------
DAB (start) -

I believe the example you're trying to cite is a very specific example that does
not reflect actual STP implementations and does not reflect the more common
case.  What you're depending on is an example of an STP that supports multiple
routing entries to the same DSTN, which routing entry to use for routing each
MSU being based on the originator of that MSU into the STP.

You are describing an SS7 DSTN Routing table at the SG that looks something
like:

entry#    DSTN      ORIGINATOR           LS        COST
1         4-4-4          1-1-1/2-2-2          1         10
2         4-4-4          3-3-3                2         10

which is needed to support the figure you drew...

                         SG                        ASP

STPs do not support the type of routing you are citing in this table (at least
the ones I know of).  The ORIGINATOR column does not exist.

Brian, can you cite 1 specific STP implementation that does support this????

I don't claim to be an expert on F links.  I've been discussing this
configuration off the list with another sigtran person and here are his comments
regarding this example...

>Brian has noted this configuration before.  I didn't think it was
>overly realistic even though I have seen some SEPs in Europe
>that have F-links and B/D links.  However, the B/D links
>and F-links have different NI values because B/D links go
>into National Carrier (i.e. DT) and F-links interconnect
>switches in a second tier provider.
>
>It seems clear that NA/CPC in DUNA/DAVA and NA in Data
>is sufficient to cover even the case that Brian desires.

If the above is true, the SS7 DSTN routing table is really more like:

entry#    DSTN      LS        COST
1         4-4-4/ITUN     1         10
2         4-4-4/ITUI     2         10

and the 2 destination entries are regarding 2 different point codes (since they
are different NI/NA values).  Now this is something STPs support, and something
that matches my point regarding the DUNA...all that is needed is the CPC=4-4-4
and the NA.

DAB (end)
--------------

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Active
  2     1    *   *       2-2-2              Active
  3     1    *   *       3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Active
  2     1    *   *       2-2-2              Active
  3     1    *   *       3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

--------------
DAB (start) -

i think you meant to mark the status=Inactive on the 2nd row.  wow, i guess
you're not perfect after all (sorry, i couldn't help but poke a little fun given
the antagonistic tone of so many of your emails).

DAB (end)
--------------

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Active
  2     1    *   *       2-2-2              Inactive
  3     1    *   3-*-*   3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

In the following case:

  RC    NA   SI  OPC     DPC                STATUS
  1     1    *   *       1-1-1              Inactive
  2     1    *   *       2-2-2              Inactive
  3     1    *   3-*-*   3-3-3              Active
  4     2    *   *       1-1-1              Active
  5     3    *   *       1-1-1              Active
  6     4    *   *       1-1-1              Active

In the following case:

  RC    NA   SI  OPC     DPC                STATUS

--------------
DAB (start) -

Again, all of this is simply a waste of CPU cycles on the SG.  All the ASP needs
is info from the SG regarding the Concerned Point Code and the NA (so you know
which network the CPC was in).
It should be the ASPs job to deliver the DUNA to the ASs that are affected.

As far as TrafficMgmt requirements, I think it is reasonable that the SG only
send the DUNA over associations that are ASP-Active for at least 1 RC (although
it is still unclear to me how this fits into the MTP Restart scenarios, it would
be ok to send the DUNA during MTP Restart even if there are no RC active?  but
not ok in the normal case?  and there is no signal from the sg->asp that says
mtp restart is stopping/starting?).  Beyond that, I think all of the filtering
you are proposing is more appropriate for the ASP side of the connection.

DAB (end)
--------------

--brian

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

---

---

---

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

Dan,

Dan Brendes wrote:                                            (Tue, 11 Sep 2001 11:37:18)
[snip]

The SG is not just an STP.  The STP in the diagram does not
have routing for 3-3-3/1 at all.

> Brian, can you cite 1 specific STP implementation that does support this????

Pure STPs don't support this because pure STP's don't support F-links.
Switches (MSCs, SSPs) including the transfer fucntion, on the other hand
do support this arrangement.  In that case, typically datafill for
the switch includes routing tables for *each* PC represented into the
network by the switch.  That is, there is not an ORIGINATOR column,
there are separate routing tables per SEP point code.

> regarding this example...

Existing switches support this arrangement.  There is nothing stopping
a switch from having multiple point codes assigned (the SEP in the
diagram), having the transfer function (the STP in the diagram), and
being multiply connected to associated and quasi-associated networks.

Neither SS7 nor M3UA currently preclude this arrangement.

Are you saying that we should restrict M3UA so that it cannot
support an MGC in the same arrangement as are supported by
a legacy telephone switch?

> >switches in a second tier provider.

Consider the wireless network which is quasi-associated internally
yet has MSCs which also connect to a fully associated national
network.  Same scenario, as above, but one NI value.

> >is sufficient to cover even the case that Brian desires.

Yes, I agree.  But there is no CPC in SNMM and proposals to
include CPC (or make NA a CPC to reduce administrative burder)
have been rejected.

> that matches my point regarding the DUNA...all that is needed is the CPC=4-4-4

Stick to the example.  Of course if you change the example things
will look different.

> DAB (end)

Yes, I meant to put Inactive in the second row.

> Again, all of this is simply a waste of CPU cycles on the SG.

Implementation specific.  There is no need to waste CPU cycles, RC is
still sufficient.

> All the ASP needs is info from the SG regarding the Concerned Point Code and
> the NA (so you know which network the CPC was in).

There is no CPC parameter in SNMM and a proposal for one was rejected.

> It should be the ASPs job to deliver the DUNA to the ASs that are affected.

As shown, the ASP is not always in the position to perform this determination
without being provisioned with SS7 network configuration specific data.

> be ok to send the DUNA during MTP Restart even if there are no RC active?

Current MTP restart and ASPTM procedures do not allow sending SNMM to
inactive RCs (see thread: MTP Restart).  To determine which RCs are
active the SG already has a list of RCs: to generate NA from RC takes
one hash lookup which must already be performed for ASPTM procedures
at the ASP.

> but not ok in the normal case?  and there is no signal from the sg->asp that
> says mtp restart is stopping/starting?).

See thread: MTP Restart.

> Beyond that, I think all of the filtering you are proposing is more
> appropriate for the ASP side of the connection.

It is less efficient for the ASP to do this because the SG has already
performed the filtering based on RC.  By using RC only, the ASP need
not redo the filtering that the SG has already performed.  Also, by
using RC only the ASP need not provision yet another value which must
be agreed between ASP and SG (the NA, which includes embedded CPC for
the cases described).

--brian

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

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 11 Sep 2001 15:54:09 -0400

Please see comments below marked KAM.

Ken

>network.  Same scenario, as above, but one NI value.

[KAM]  This does not mean that they would have to have the same NA
value as NA does not map 1:1 to NI.

>include CPC (or make NA a CPC to reduce administrative burder)

[KAM] I don't remember CPC in SNMM being rejected as a consensus 
opinion of the WG.

>Stick to the example.  Of course if you change the example things

[KAM] Regardless CPC/NA would be sufficient.

>be agreed between ASP and SG (the NA, which includes embedded CPC for

[KAM] of course, as mentioned many times, there are ASPs that do not
desire to provision RC because it would mean provisioning RKs also 
on the ASP.  With RC/RK on ASP there is alot more duplicated 
information that must be agreed between ASP and SG.

---

---

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

Ken,

Ken Morneault wrote:                                          (Tue, 11 Sep 2001 15:54:09)
[snip]

> value as NA does not map 1:1 to NI.

Yes, but these values separate from NI would need to be
agreed on (statically provisioned) between SG and ASP.
Also, they would need to be reprovisioned at both SG
and ASP when the network configuration at the SG changes.
That is unacceptable.  RC has a dynamic registration
procedure and does not need to change with network
configuration at the SG (as shown in the example).

> [KAM] I don't remember CPC in SNMM being rejected as a consensus 

It was proposed and strongly rejected that NA == ID/CPC.  It
was proposed to alleviate the static provisioning burder on 
NA values.  It was also proposed that NA == ID and CPC be
added to SNMM.  Neither of these proposals has been included
in a draft.  I don't recall that you supported either.

> [KAM] Regardless CPC/NA would be sufficient.

CPC/NA is not sufficient for ASPTM and MTP Restart procedures.
Because RC => SPMC and RC => NA, RC is always sufficient.
It is not the case that NA/CPC => RC, so RC is still required
for ASPTM and must be placed in SNMM where not implicit.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 11 Sep 2001 13:42:57 -0700 (PDT)

> It was proposed and strongly rejected that NA ==
> ID/CPC.  

Just to be clear, CPC in SNMM has not been formally
proposed.  NA==ID/CPC was what was objected to in
Issue 1 of the Issues List.

L. Ong

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 11 Sep 2001 13:57:36 -0700 (PDT)

Folks,

I'd like to continue to push the idea below to see
if it's sufficiently painful to all sides to be a
possible compromise. 

At least the behavior of the SG will be reasonably
consistent.  

The proposal below is for the SG-to-ASP direction,
as far as the ASP-to-SG direction, there seems not be
a requirement that RC be sent (Tolga I'm sure
will disagree, but that's what I'm gathering from
the list discussion).

Comments?

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 16:22:31 -0500

Lyndon,

I proposed CPC in SNMM in the Network Appearance thread.
But it is moot, since CPC cannot imply RC, but RC implies
CPC.  Where RC is included, neither NA nor CPC are required.

--brian

Lyndon Ong wrote:                                          (Tue, 11 Sep 2001 13:42:57)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 16:28:15 -0500

Lyndon,

Lyndon Ong wrote:                                          (Tue, 11 Sep 2001 13:57:36)

> > attached to the SG and routing label information 

It is not clear from this when NA would be required
in DATA and SNMM.  The routing label information may
always be uniquely determined from RC.  Perhaps an
example of when NA would be required to be included
when RC is in the message would help clarify what
is meant.

It is clear that RC must be included in DATA and
SNMM where not implicit to the association (i.e.,
there are multiple AS's configured at the ASP).

> will disagree, but that's what I'm gathering from

I agree with Tolga, RC is required in both directions
where not implicit to the association.  ASPTM procedures
are applied at both the SG and the ASP.  RC is required
in both directions to perform ASPTM procedures.

--brian

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

---

---

From: [email-masked]
Date: Tue, 11 Sep 2001 17:26:41 -0400

Lyndon,

Your assumption about no requirement for the ASP-to-SG direction is 
incorrect. In fact, this was the only reason that I finally supported 
Brian's suggestion to add RC to the Data message.

Section 4.2.3.4 states "If the SGP or IPSP receives any Data messages before an ASP Active message 
is received, the SGP or IPSP MAY discard them."

The inclusion of the RC in the Data message will make it much quicker for 
the SGP to verify that an ASP Active message has been received for the RC 
that corresponds to the Data message.

Having said all that, I again voice my support for your proposal below. 
Just add ASP-to-SG.

Barry Nagelberg
Software Engineer
RadiSys, Corp.

09/11/01 04:57 PM

Folks,

Comments?

Cheers,

Lyndon

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

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 11 Sep 2001 14:48:08 -0700 (PDT)

I'm saying send NA in the multiple network case, even
if RC carries the equivalent information.  This 
shouldn't be a great deal of overhead, since NA is
known at the SG and ASP if in fact NA is required.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 17:03:04 -0500

Lyndon,

Lyndon Ong wrote:                   (Tue, 11 Sep 2001 14:48:08)
> known at the SG and ASP if in fact NA is required.

It is a great deal: unfortunately, NA values must be
agreed between SG and ASP and statically provisioned
at both before they can be included in a message.  There
is no registration procedure for an ASP to obtain NA
values from the SG.

When NA is derived from RC and does not appear in these
messages, the ASP can use whatever values it wants for
NA (i.e., the values of NA do not have to agree with any
SG or any other ASP for that matter).

Requiring an implementation to place NA in DATA and
SNMM along with RC thus require the implementation to
statically provision NA values which are not necessary.
Placing such unnecessary static provisioning burdens on
an implementation is unacceptable on priniciple.

I you want to way "MAY place NA in DATA and SNMM" that's
one thing; if you want to say "SHOULD" or "MUST" that is
another.  "SHOULD" or "MUST" is unacceptable on the
principle that the draft should not force an implementation
to include unnecessary information in messages.

--brian

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 11 Sep 2001 17:17:29 -0500

Brian,

1) If ones goal is to not have any statical provisioning (using REGREQ for RKs), then still NA in REGREQ is necessary, so even in this case NA should be provisioned.
2) If we think for the case where RC is statically provisioned, I think it is true that NA is not needed and does not need to be provisioned but probably it is acceptable to provision it, in this scenario we already define RC statically, so NA will be one more parameter.

But in general I agree with you, that when RC is there, there is always a way to do everything without a need of NA (except for REGREQ). According to me, that it is not needed is a more strong argument than it will need to be statically provisioned.

   Tolga

> Sent: Tuesday, September 11, 2001 6:03 PM
> To: sigtran

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 11 Sep 2001 15:25:03 -0700 (PDT)

Brian,

> is no registration procedure for an ASP to obtain NA

If NA is required, it will be a component of
the Routing Key, why isn't that known at the ASP?

How does the ASP register Routing Keys in a
multiple network case, if 
it does not have agreement on NA and point codes
are non-unique?  How does the SG interpret the
point codes in the Reg Req?

> SG or any other ASP for that matter).

?? I missed your point here.  Why would you use
any value for NA?  It's an optional parameter in
registration.

>"SHOULD" or "MUST" is unacceptable on the

I'm trying to find a compromise that will allow
both sides to interoperate.  Whether or not it is 
"unacceptable" is open for discussion, but if
the alternative is no specification, this seems
similarly "unacceptable".  

You were asking for an interoperable solution,
this puts the burden on sending systems but
allows greater interoperability with receiving
systems.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 18:09:28 -0500

Tolga,

I understand and agree with your comments; however, when NA is used
only in REG REQ it is used in conjunction with the DPC/SPMC and can
take on the NA == PC numbering space definition.  That way, there is
only a short list of NA values to provision and they can be given
relatively global assignment across a group of SG/ASPs.  Such as:

   NA  0  -  ITU PC numbering
   NA  1  -  ANSI/NANP PC numbering
   NA  2  -  Spain National PC numbering
   NA  3  -  Belgium National PC numbering

When used in DATA and SNMM, however, NA takes on a CPC meaning and
is dependent upon specific SG SS7 network configuration.

If CPC were to be added SNMM, NA reduces to the role of the NI bits
in the routing lable.

I agree, however, that it is sufficient (and simpler) just to place
RC only in DATA and SNMM and use NA for Point Code numbering space
in REG REQ.

I resist an implementation being forced to statically provision some
ugly NA == Network Context/Attacment values between ASP and SG.

--brian

Asveren, Tolga wrote:                            (Tue, 11 Sep 2001 17:17:29)
>
> Brian,
> 
> 1) If ones goal is to not have any statical provisioning (using REGREQ for
> RKs), then still NA in REGREQ is necessary, so even in this case NA should
> be provisioned.
>
> 2) If we think for the case where RC is statically provisioned, I think it
> is true that NA is not needed and does not need to be provisioned but
> probably it is acceptable to provision it, in this scenario we already
> define RC statically, so NA will be one more parameter.
> 
> But in general I agree with you, that when RC is there, there is always a
> way to do everything without a need of NA (except for REGREQ). According to
> me, that it is not needed is a more strong argument than it will need to be
> statically provisioned.
> 
>    Tolga
> 

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 18:21:02 -0500

Lyndon,

Lyndon Ong wrote:                                          (Tue, 11 Sep 2001 15:25:03)
> the Routing Key, why isn't that known at the ASP?

It is know at the ASP, just not necessarily using
the same *values* as at the SG.  Example:

        SG                   ASP
     NA    RC             RC    NA
     -----------------------------
      1     1             1     5
      1     2             2     5
      2     3             3     41
      2     4             4     41
      3     5             5     12

Placing it in the messages forces SG and ASP to
use the same set of values.

> point codes in the Reg Req?

RL non-unique and PC non-unique are two different
things.  If NA is restricted to REG REQ only, then
it can take on the interpretation "Point Code Numbering
Space".  If NA is placed in SNMM and DATA, it must
take on the current Network Id/Attachment definition
which embeds CPC in the value.  The former is trivial
to administer, the later is imposing.

> any value for NA?  It's an optional parameter in

I meant if the implementation needs an NA internally,
it can generate its values by inference from RC and
those values need not be coordinated externally.

> allows greater interoperability with receiving

Greatest ineroperability will be achieved by removing
NA from SNMM and DATA.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Tue, 11 Sep 2001 16:30:24 -0700 (PDT)

> use the same set of values.

If SG and ASP do not use the same
set of values for NA, it seems like NA
would be just an internal variable.

> to administer, the later is imposing.

That sounds hopeful, my understanding is
that people supporting NA want the former, 
rather than the latter.

> Greatest ineroperability will be achieved by

This currently seems to be out of the range of
"rough consensus"...

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Sep 2001 21:23:17 -0500

Lyndon,

Lyndon Ong wrote:                   (Tue, 11 Sep 2001 16:30:24)
> would be just an internal variable.

A value which does not need to be coordinated
externally is indeed an internal value.

> > which embeds CPC in the value.  The former is
> > trivial to administer, the later is imposing.
>

Even with the former, RC will always do and,
for statically provisioned RC values,
provisioning NA values (trivial or not) is
not necessary.

It is an error in logic to say that an SG or
ASP will always have the value of NA at hand
to place in the message.  Implementations
cannot be required to support static provisioning
of NA values (RKMM procedures are OPTIONAL).

--brian

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

---

---

From: Dan Brendes <[email-masked]>
Date: Wed, 12 Sep 2001 08:08:47 -0400

Brian - a couple comments below...

"Brian F. G. Bidulock" <[email-masked]> on 09/11/2001 07:09:28 PM

Tolga,

   NA  0  -  ITU PC numbering

DAB - I'm not sure where/how/why you jumped to the conclusion that 'NA takes on
a CPC meaing' when used in DATA and SNMM.  In a DATA message if na=2 was
included in the M3UA formating, doesn't it just clarify that the DATA message is
formatted according to the Spain National PC numbering rules and pertains to
OPCs/DPCs in the Spain PC space?  What CPC are you talking about?  In an SNMM
message, say DUNA, doesn't the na=2 just clarify that the affected destination
is in the Spain PC space?

DAB - I don't think anyone is advocating adding a CPC to the SNMM (and I'm not
sure which PC you think should be the CPC).  I believe this misinterpretation
started from my email when I used ConcernedPC to refer to the PC that is no
longer available (which is the SS7 terminology for the field in the TFP that
refers to the PC that is no longer available).  'ConcernedPC' from my earlier
emails is equivalent to 'Affected Destination' in the m3ua terminology which is
already in the SNMM.  I'm sorry for any confusion resulting from my choice of
terms.

DAB - You've already shown in another example that regardless of whether dynamic
provisioning or static provisioning is used, both the SG and the ASP side need
to be using the same RC value for the same RK.  The same goes with NA.  This is
just one more thing that needs to be configured.  No one said configuration was
easy.  Get over it.

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Sep 2001 12:13:40 -0500

Dan,

Dan Brendes wrote:                                            (Wed, 12 Sep 2001 08:08:47)
[snip]
> is in the Spain PC space?

Current M3UAv8 defintiion can take on CPC meaning (Network Id/Attachment) to
handle the example case.  This was discussed at great length on the thread
"Network Appearance".

> DAB - I don't think anyone is advocating adding a CPC to the SNMM (and I'm
> not sure which PC you think should be the CPC).  I believe this
> misinterpretation started from my email when I used ConcernedPC to refer to
> the PC that is no longer available (which is the SS7 terminology for the
> field in the TFP that refers to the PC that is no longer available).
> 'ConcernedPC' from my earlier emails is equivalent to 'Affected Destination'
> in the m3ua terminology which is already in the SNMM.  I'm sorry for any
> confusion resulting from my choice of terms.

I am using concerned PC in the SS7 sense (the one that wishes to know the
status, not the one whose status changes).  See thread "Network Appearance."
Adding CPC to SNMM to allow NA to become Network Id has been discussed at
length in that thread.

> just one more thing that needs to be configured.  No one said configuration was

Unnecessary configuration cannot be required.  Get rid of it.

--brian

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

---