Subject: [M3UA Issue #1] NA definition

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

Hi, 

We proposed a modification to the definition since we agree with Barry in that the NA should refer to networks and no to specific end nodes.

In that way, we thought of a modification of the definition in v8 to include this approach. If we only reword the first sentence of v8, the whole definition becomes more exact and clear that v6 (since it explains more in detail), and refers to network identifications as in v6 as well.

Our proposed definition is:

Network Appearance: The Network Appearance is a reference (tipically an integer) that together with an SPC uniquely identifies an SS7 node (Signaling Point Code) by indicating the specific SS7 network it belongs to. It is used for the purposes of logically separating the signalling traffic between the SG and the Application Server Processes over a common SCTP association.  This partitioning is necessary where an SG is logically partitioned to appear as end node elements in multiple separate SS7 networks, in which case there is a separate network appearance for each point code in the SS7 networks.  It is also necessary when an SG is configured as an STP hosting multiple point codes, or when configured as multiple end nodes within the same network, in which case each point code is a separate network appearance.between the SG and the Application Server Processes over a common SCTP Association.  An 
example is where an SG is logically partitioned to appear as an element in four separate national SS7 networks.  A Network Appearance implicitly defines the SS7 Point Code(s), Network Indicator and MTP3 
protocol type/variant/version used within a separate SS7 network.  

Any comments? 

Br // Javier.

> -----Original Message-----
> From: Lyndon Ong [mailto:[email-masked]]
> Sent: Thursday, August 30, 2001 10:17 PM
> To: sigtran
> Subject: Re: M3UA: Proposed Solutions to issues 1, 2, 4, 16
> 
> 
> > Janvier, I didn't ask for a change to defintition of
> > NA.  I asked that
> > NA be assigned as ID + CPC to aid monitoring and
> > administration of
> > values.  This issues is, I beleive, whether NA
> > should revert back to 
> > previous definition.  If it doesn't need to, there
> > is no issue.
> 
> Ideally, folks who are concerned with the v8
> definition of NA (so Javier, John, Barry, any others)
> should make a common proposal and we can see if
> this is acceptable to people.
> 
> Brian, do you have an objection in principle to 
> this, or would you reserve opinion until you see
> a specific proposal?
> 
> Cheers,
> 
> L. Ong
> 
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with 
> Yahoo! Messenger
> http://im.yahoo.com
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

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

---

From: [email-masked]
Date: Fri, 31 Aug 2001 09:23:42 -0400

Javier,

Can we remove the following?

"It is also necessary when an SG is configured as an STP hosting multiple 
point codes, or when configured as multiple end nodes within the same 
network, in which case each point code is a separate network 
appearance.between the SG and the Application Server Processes over a 
common SCTP Association."

Barry Nagelberg

"Javier Pastor-Balbas (ECE)" <[email-masked]>
08/31/01 09:09 AM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        [M3UA Issue #1] NA definition

Hi, 

We proposed a modification to the definition since we agree with Barry in 
that the NA should refer to networks and no to specific end nodes.

In that way, we thought of a modification of the definition in v8 to 
include this approach. If we only reword the first sentence of v8, the 
whole definition becomes more exact and clear that v6 (since it explains 
more in detail), and refers to network identifications as in v6 as well.

Network Appearance: The Network Appearance is a reference (tipically an 
integer) that together with an SPC uniquely identifies an SS7 node 
(Signaling Point Code) by indicating the specific SS7 network it belongs 
to. It is used for the purposes of logically separating the signalling 
traffic between the SG and the Application Server Processes over a common 
SCTP association.  This partitioning is necessary where an SG is logically 
partitioned to appear as end node elements in multiple separate SS7 
networks, in which case there is a separate network appearance for each 
point code in the SS7 networks.  It is also necessary when an SG is 
configured as an STP hosting multiple point codes, or when configured as 
multiple end nodes within the same network, in which case each point code 
is a separate network appearance.between the SG and the Application Server 
Processes over a common SCTP Association.  An 
example is where an SG is logically partitioned to appear as an element in 
four separate national SS7 networks.  A Network Appearance implicitly 
defines the SS7 Point Code(s), Network Indicator and MTP3 
protocol type/variant/version used within a separate SS7 network. 

Any comments? 

Br // Javier.

> this, or would you reserve opinion until you see

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

---

---

From: [email-masked]
Date: Fri, 31 Aug 2001 16:37:32 +0300

Hi Javier,

> Network Appearance: The Network Appearance is a reference 
> (tipically an integer) that together with an SPC uniquely 
> identifies an SS7 node (Signaling Point Code) by indicating 
> the specific SS7 network it belongs to. 

Quick question, by stating that the NA indicates the specific
SS7 network, it seems that you are stating that NA's will need
to be provisioned & that each SS7 network be assigned a static
NA.  I'm sure that you do not mean this, but somehow the
text isn't clear.  Can you clarify it?

John

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 31 Aug 2001 15:39:51 +0200

Hi, 

It is only an example of use for NA. Therefore it can be removed, if you prefer so, without affecting the whole definition.

BR / Javier.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 3:24 PM
> To: sigtran
> Subject: Re: [M3UA Issue #1] NA definition
> 
> 
> Javier,
> 
> (tipically an 

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 31 Aug 2001 15:51:19 +0200

Thanks John, 

Yes, we can clarify it in that way. How about:

Network Appearance: The Network Appearance is a local reference (tipically an integer) that together with an SPC uniquely identifies an SS7 node (Signaling Point Code) by indicating the specific SS7 network it belongs to.[...]

I've just added "local" before "reference" to indicate that SG can assign the NA independently of the rest of the nodes.

BR // javier.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 3:38 PM
> To: sigtran
> Subject: RE: [M3UA Issue #1] NA definition
> 
> 
> Hi Javier,
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 10:50:48 -0500

Javier,

A question.  What makes this different that the M3UAv8 definition?

A comment below...

--brian

Javier Pastor-Balbas (ECE) wrote:   (Fri, 31 Aug 2001 15:09:16)
> that the NA should refer to networks and no to specific end nodes.

Barry objected to one sentence.  We have seen no further objection.

> 
> In that way, we thought of a modification of the definition in v8 to include
> this approach. If we only reword the first sentence of v8, the whole
> definition becomes more exact and clear that v6 (since it explains more in
> detail), and refers to network identifications as in v6 as well.
> 
> (Signaling Point Code) by indicating the specific SS7 network it belongs to.
> It is used for the purposes of logically separating the signalling traffic
> between the SG and the Application Server Processes over a common SCTP
> association.  This partitioning is necessary where an SG is logically
> multiple end nodes within the same network, in which case each point code is
> a separate network appearance.between the SG and the Application Server
> Processes over a common SCTP Association.  An example is where an SG is
> logically partitioned to appear as an element in four separate national SS7
> networks.  A Network Appearance implicitly defines the SS7 Point Code(s),
> Network Indicator and MTP3 protocol type/variant/version used within a
> separate SS7 network.  
> 
> 
> Any comments? 
> 
> 
> 
> Br // Javier.
> 

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 31 Aug 2001 08:57:41 -0700

Javier,
	This seems fine with me, I'm not going to nitpick-it.  Hence, it is
understood that an SG (all SGs connected to the node and the network in
question) will use the same NA in all of the messages passed on by the SG to
the node and for all SNMM about PCs in that network sent to the node.
Hence, it might be better for the node to set the NA or we can just have our
local friendly network operator set the value.

John

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 8:51 AM
> To: sigtran
> Network Appearance: The Network Appearance is a local 
> reference (tipically an integer) that together with an SPC 
> uniquely identifies an SS7 node (Signaling Point Code) by 
> indicating the specific SS7 network it belongs to.[...]
> 
> 
> I've just added "local" before "reference" to indicate that 
> SG can assign the NA independently of the rest of the nodes.
> 
> 
> BR // javier.
> 
> 
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

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

Hi Brian 

It was explained in the mail:

"We proposed a modification to the definition since we agree with Barry in that the NA should refer to networks and no to specific end nodes."

BR // Javier.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 5:51 PM
> To: sigtran
> Cc: [email-masked]

Therefore we can close this point.

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 31 Aug 2001 09:03:56 -0700

Javier,
	I may have spoke to soon.  The last sentence in the def. needs to be
killed:
"A Network Appearance implicitly defines the SS7 Point Code(s),
Network Indicator and MTP3 protocol type/variant/version used within a
separate SS7 network."

Or at least "SS7 Point Code(s)," needs to be killed.  NA should imply NI and
protocol variant for the network.  It does in imply the PCs.

John

> From: Schantz, John 
> Sent: Friday, August 31, 2001 10:58 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 11:17:39 -0500

Javier,

Are you attempting to form the definition so as to restrict NA to one
value per network?

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Fri, 31 Aug 2001 18:00:09)
> "We proposed a modification to the definition since we agree with Barry in
> that the NA should refer to networks and no to specific end nodes."
> 
> 
> BR // Javier.
> 

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

---

---

From: [email-masked]
Date: Fri, 31 Aug 2001 12:20:47 -0400

John,

How about "format of the SS7 Point Code(s)"?

Barry Nagelberg

"Schantz, John" <[email-masked]>
08/31/01 12:03 PM
Please respond to sigtran

Javier,
                 I may have spoke to soon.  The last sentence in the def. 
needs to be
killed:
"A Network Appearance implicitly defines the SS7 Point Code(s),
Network Indicator and MTP3 protocol type/variant/version used within a
separate SS7 network."

Or at least "SS7 Point Code(s)," needs to be killed.  NA should imply NI 
and
protocol variant for the network.  It does in imply the PCs.

John

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 31 Aug 2001 18:19:28 +0200

John, 

Under my point of view, the real important words are included in the first two sentences. The rest of the text try to explain a little more the scenarios where this can be used. The last sentence seems to add confussion instead of clarification. We can kill it.

Thanks // Javier 

> From: Schantz, John [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 6:04 PM
> To: sigtran
> [email-masked]

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 31 Aug 2001 11:25:47 -0700

Sure, I already think that it is implied by the variant but stating it
doesn't hurt.  If I had to handle both old (14-bit) and new (24-bit) China
network formats, I would want to keep the PC addresses and traffic separate.

My objection was that NA never implies a specific PC value.  NA only implies
network specific characteristics like NI, SS7 variant, PC format, PC
numbering plan, etc.

John

> Sent: Friday, August 31, 2001 11:21 AM
> To: sigtran
> >                This seems fine with me, I'm not going to 
> nitpick-it. 
> > Hence, it is

---

---

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

It would not have to be but it does seem to make the most sense if an SG (or
set of SGs) that are "STPing" the traffic to from the same network to
multiple adjacent nodes.  This is especially helpful for SNMM, it would
allow the SG(s) to broadcast SNMM to all adjacent nodes (communicating with
the network) without needing to look up which value of NA it is using for
each adjacent node.  This is also true for regular traffic, messages
received on routes to the network would only need one NA and this NA is
passed onto the adjacent nodes without the need for looking up a specific NA
per adjacent node.  You have to admit, the admin would be a lot simpler.

John

> Sent: Friday, August 31, 2001 11:18 AM
> To: sigtran
> Cc: [email-masked]; [email-masked]

---

---

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

John,

I can accept an NA definition which does not restrict NA to having
one value for one network in all situations.  The case in point is
the multiple PC, multiple network attachment scenario.  This is not
expected to be a common case, but if the NA definition allows the
flexibility to assign multiple values of NA to one network where
required, I don't see a problem.  I would see a problem with a
definition which restricts NA to have one value and one value only.

--brian

On Fri, 31 Aug 2001, John Schantz wrote:

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

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

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 31 Aug 2001 14:48:19 -0500

Brian,

Wouldn't this problem disappear if RC is included in DAVA,DUNA  etc... ? Or what you mean is if RC is not put to those messages, then you want different NAs for different network attachment scenario? Personally, I prefer to include RC in those messages, instead of allowing multiple NA values in the same network.

    Tolga

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 31, 2001 3:36 PM
To: sigtran
Subject: Re: [M3UA Issue #1] NA definition
Importance: High

John,

--brian

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

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 31 Aug 2001 16:30:32 -0500

Tolga,

I also would prefer to include RC.  I also think that resolution
to NA's definition and RC replacing NA in DATA and SNMM are
intertwined.  It would probably be better to decide the other issue
and determine in which messages NA is required (and when) before
trying to narrow its definition.

I believe that RC replaces NA in DATA and SNMM and NA can then be
restricted to just Network Identifier in the REG REQ.  For all
those cases where Network Id is sufficient, RC can be easily set
to the NA value when used in DATA and SNMM.

I don't know on what basis this new NA definition is going to be
applied, but updating the NA definition in M3UAv8 in isolation of
addressing the other issues leaves no option but to keep NA open
to non-unique assignments.

--brian

On Fri, 31 Aug 2001, Asveren, Tolga wrote:

> Brian,
> 
> Wouldn't this problem disappear if RC is included in DAVA,DUNA  etc... ? Or
> what you mean is if RC is not put to those messages, then you want different
> NAs for different network attachment scenario? Personally, I prefer to
> include RC in those messages, instead of allowing multiple NA values in the
> same network.
> 
>     Tolga
> 

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 31 Aug 2001 16:30:57 -0700 (PDT)

Brian,

I'm confused about a couple of things in your message:

-- what are you referring to as Network Identifier
in the Reg Request?  Do you mean Network Indicator
as in the SIO? or do you mean network identifier
(lower case)?

-- why is NA definition intertwined with RC in the 
DATA and SNMM?  I thought that your view was that
RC should replace NA in DATA and SNMM, regardless
of the definition ;o)   Seriously, though, a 
clearer definition of NA should actually help 
clarify the relationship of NA and RC as well.

Cheers,

Lyndon

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> > > > Javier Pastor-Balbas (ECE) wrote:             
>             
> > > > (Fri, 31 Aug 2001 18:00:09)
> > > > > Hi Brian 
> > > > > 
> > > > > "We proposed a modification to the
> definition since we 
> > > > agree with Barry in
> [email-masked]
> [email-masked]
> [email-masked]
> [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: Fri, 31 Aug 2001 19:44:17 -0500

Lyndon,

> as in the SIO? or do you mean network identifier

I mean the Network Appearance parameter which is contained in the
Routing Key parameter.  By network identifier I mean only what is
necessary to put the point codes in the Routing Key into context for
the SG during registration.

For REG REQ a definition of NA as point code numbering space would
do (where point code numbering space implies form of the point code
and distinguishes also between identical values of point codes of
the same form).

In the REG RSP, a Routing Context is returned as a unique value for
a Routing Key by Local-RK-Identifier value.  It is here that the NA
value is linked to a Routing Context.  From here on, both SG and ASP
can always obtain the NA value from the RC value.  This association
of NA value to RC value makes RC always sufficient to imply NA.

For static allocation, the rules for Routing Keys (cannot span SPMC)
ensures that statically allocated RC values also have this
correspondence with NA values.

Thus, when RC is included in DATA and SNMM, NA is not necessary.
For static assignment of RC (when dynamic registration is not used),
the SG and ASP do not have to agree on NA values at all.  They have
already agreed on RC values and can derive their own internal NA
value from the agreed value of RC.  This removes the need for
coordination of NA values between SG and ASP when RC values are
statically allocated, permitting one less value for network
operators to provision (and make mistakes on).

This is why I say that your corner-case example cannot occur under
the current definition of Routing Key.  A Routing Key, thus an RC,
thus an AS is not permitted to span multiple SPMC and thus cannot
span multiple point-code numbering spaces, not can it span multiple
concerned SPMC.  RC is always a sufficient replacement for NA.

> clarify the relationship of NA and RC as well.

If RC replaces NA in DATA and SNMM, as above, I think that NA should
be restricted to a point code numbering space identifier.

If RC does not replace NA in SNMM, then the implementation needs to
distinguish between concerned SPMC at the ASP as well as point code
numbering spaces to accomodate scenarios already presented and as
originally identified as an issue by Norm Glaude.  If RC does not
replace NA in DATA and SNMM, then the NA definition must be relaxed
to accomodate numbering space and concerned SPMC for SNMM.

(Note that proposals for use of CPC in SNMM to accomodate this
 without expanding NA definition were loudly opposed.)

RC also implies concerned SPMC for SNMM.  This is because Routing
Keys are not permitted to span SPMC and the DPC of the SPMC is bound
to the RC value in the REG RSP.  This is again true for static
assignment of RC values.  Even the relaxation on RK rules regarding
DPC for REG REQ proposed by Maria-Cruz does not affect this.  Where
SPMCs have multiple point codes (one real several aliases), it is
not necessary to distinguish SNMM between real and alias point
codes.  The RC to SPMC relationship makes RC always sufficient to
identify the concerned SPMC in SNMM.  (There are numerous additional
reasons for RC in SNMM.)

That is why I say that the issues are entwined.  If RC replaces NA
in SNMM and DATA, NA in REG REQ (the only place it appears) can be
defined as point code numbering space only.  If RC does not replace
NA in SNMM, NA must also identify concerned SPMC.

I haven't heard any cases where RC is not sufficient to replace NA in
everthing but REG REQ (Gery's stated proposal on these issues).
Your corner-case scenario is the closest I have seen, and even that
is not possible given RK definition.

With RC replacing NA in SNMM and DATA, NA only occurs in REG REQ.
The SG and ASP can pretty much agree on values however they please.
It is necessary that the REG REQ NA value uniquely identify point
code numbering space, but it would be even ok to assign NA as an
index number different for evey point code in the system.  So if
RC replaces NA in SNMM and DATA, even the current M3UAv8 defintion
of NA will do.

--brian

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

---