Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL - POLL - POLL

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 10:35:39 +0200

Hi Lyndon,

Well, just to signal I'm still looking at this too, and I didn't see a
definitive answer.

Your summary of the issue solution seems acceptable to me though, let's see
(DATA and SNMM) :

1) SG -> ASP : RC mandatory, when traffic for more than 1 AS is multiplexed
over the association. NA optional.

2) ASP -> SG : NA mandatory, when traffic for more than 1 SS7 network is
multiplexed over the association. RC optional. NA is probably all the SG
needs to route towards SS7. No big deal for the ASP to just plug it in.

3) IPSP <-> IPSP : RC optional, no NA whatsoever.

Let's do a poll on this one ??

____________________________

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

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: woensdag 26 september 2001 22:09
To: sigtran
Subject: Re: [M3UA Issue 1] Network Appearance Sematics / Format -
CLOSED

Folks,

I had proposed that NA would be required to appear
in DATA and SNMM when needed to distinguish between
network contexts at the SG, just as RC would be
required to appear in DATA and SNMM when needed 
to distinguish between routing contexts at the
ASP, and that seemed to be grudgingly acceptable
to everyone.  

Let's not go back on this.  I have no problem 
trying to refine the definition of NA to be clearer
on when it should be used, especially to keep the
administrative requirements limited as that was
a concern.

Thanks,

L. Ong

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> Greg,
> 
> Whether it is acceptable or not depends on whether
> NA is ever
> required to appear in DATA or SNMM.  If NA only
> appears in REG REQ,
> its definition should not speak to separating
> signalling traffic
> over a common assocation, but should speak to the
> role of
> identifying point-code numbering spaces for
> registration requests.
> 
> Is the "specific SS7 network" only identified by NA
> "together with
> an SPC"?  (SPC is not defined in the draft, but used
> twice here.)
> 
> It is quite unclear whether the definition points to
> point-code
> numbering space or relaxes the definition to permit
> multiple NA
> values within a single point code numbering space.
> 
> Where do we stand with NA in DATA and SNMM?  And,
> what impact would
> this definition have on that?
> 
> --brian
> 
> 
> Greg Sidebottom wrote:                           
> (Wed, 26 Sep 2001 14:34:54)
> >
> > The new NA definition from Javier in an e-mail of
> Sept 13th seems to be
> > accepted as no comments on list:
> > 
> > "Network Appearance - The Network Appearance is a
> local reference (typically
> > an integer) that together with an SPC uniquely
> identifies an SS7 node by
> > indicating the specific SS7 network it belongs to.
> It can be used to
> > distinguish between signalling traffic associated
> with different networks
> > being sent between the SG and the ASP over a
> common SCTP association. An
> > example scenario is where an SG appears as an
> element in multiple separate
> > national SS7 networks and the same SPC value may
> be reused in different
> > networks."
> > 
> > 
> > Cheers
> > 
> 
> -- 
> 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]

__________________________________________________
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: "Alf Heidermark (UAB)" <[email-masked]>
Date: Thu, 27 Sep 2001 10:39:38 +0200

Just a question 

Shall RC be mandatory from SG if the RKs are provisioned in the SG.

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]]
Sent: den 27 september 2001 10:36
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Hi Lyndon,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: woensdag 26 september 2001 22:09
To: sigtran
Subject: Re: [M3UA Issue 1] Network Appearance Sematics / Format -
CLOSED

Folks,

Thanks,

L. Ong

---

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 10:47:34 +0200

Hello Alf,

My understanding is if the REG procedures aren't used, both SG and ASP have
the same RK's provisioned as well as the RC's to identify them.
Communication is going to be difficult otherwise ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Alf Heidermark (UAB) [mailto:[email-masked]]
Sent: donderdag 27 september 2001 10:40
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Just a question 

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]]
Sent: den 27 september 2001 10:36
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Hi Lyndon,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: woensdag 26 september 2001 22:09
To: sigtran
Subject: Re: [M3UA Issue 1] Network Appearance Sematics / Format -
CLOSED

Folks,

Thanks,

L. Ong

---

---

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 27 Sep 2001 08:08:53 -0500

Hi,

Please see comments/questions below.

   Tolga

> Sent: Thursday, September 27, 2001 4:36 AM
> To: sigtran
[TOLGA] What does optional mean exactly? There can be two interpretations:
1) When traffic of more than one network is carried over the same
association it is mandatory, otherwise it is not used at all. (I assume,
this is, what is meant but I want to be sure)
2) That it is used is an option, which will depend on the ASP and SG (maybe
configurable)
> needs to route towards SS7. No big deal for the ASP to just 
[TOLGA]If it is no big deal for ASP to plug in NA, why is it a big deal then
to plug in RC? If one can use different interfaces from M3UA interface to
M3UA for different networks, one can do the same to fill RC without
additional analysis. IMHO, here one of the critical issues is, whether the
case where communication path between two SPCs is open only in one direction
should be allowed or not. If not, then IMHO, RC is necessary for ASP->SG.
> [email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 27 Sep 2001 14:35:04 +0100

Gery,

>needs to route towards SS7. No big deal for the ASP to just plug it in.

Why is only the NA necessary? What about the DPC and SLS so that the SG can 
route to the correct outgoing SS7 link?

Amish

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 15:42:45 +0200

Hi,

Let's rephrase it a bit :

Start=>
1) No multiplexing over SCTP association (i.e. single RK/RC, NA)

No RC or NA required in either direction.

2) Multiplexing of several RK/RCs, but within single NA

RC mandatory in both directions SG->ASP, ASP->SG.

NA not required.

3) Multiplexing of several RK/RCs, spanning several NAs

RC mandatory in both directions SG->ASP, ASP->SG.

NA optional in direction ASP->SG.
<=End

What about this proposal ? Can everybody live with this ?

 Gery

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 15:47:39 +0200

Hello Chana,

This information is present in the MTP routing label, no ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: donderdag 27 september 2001 15:35
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Gery,

Amish

---

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 27 Sep 2001 15:04:32 +0100

Hi Gery,

>This information is present in the MTP routing label, no ?

And the NA is contained in the RC. Right?

Why not have:
2) ASP -> SG : NA or RC mandatory, when traffic for more than 1 SS7 network 
is multiplexed over the association.
or
2) ASP -> SG : RC mandatory, when traffic for more than 1 SS7 network is 
multiplexed over the association. NA optional.

Amish

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 27 Sep 2001 09:10:54 -0500

Hi,

Just a small question below.
 
 Tolga

> Sent: Thursday, September 27, 2001 9:43 AM
> To: sigtran
[TOLGA] Is NA mandatory in direction SG->ASP? Why is it optional for ASP->SG?How can SG know, to whihc network to route the message?

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 16:17:50 +0200

Hi,

Exactly my second proposal !

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: donderdag 27 september 2001 16:05
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Hi Gery,

Why not have:

Amish

---

---

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 27 Sep 2001 07:37:39 -0700

I don't agree.

I still thing RC is always OPTIONAL since it is an alternate routing
parameter to the RL.  Hence, if your implementation uses RL, you will
never need RC even if there are multiple RCs defined.

NA is required in DATA and SNMM when ever there is traffic for multiple
networks involved.  It must be in both direction because both nodes must
have the ability to separate the traffic from a common association.  NA
is NOT contained in RC (no matter what somebody says), by definition, RC
is defined for a set of fixed SS7 MESSAGE parameter values (NA is not
one of them and please don't confuse it with the 2-bit NI parameter).

Hence, we now have:

1)  SG <--> ASP:
        + NA mandatory when traffic for more than one SS7 network is
multiplexed over the association.
        + RC optional, mandatory only if RC is used for routing instead
of RL.  May be used when traffic for multiple ASs is multiplexed over
the association. 

2)  IPSP <--> IPSP:
        + NA mandatory when traffic for more than one SS7 network is
multiplexed over the association. [I don't think you can rule this case
out]
        + RC optional, mandatory only if RC is used for routing instead
of RL [Agreement between nodes is required for the use of RC].

John 

> Sent: Thursday, September 27, 2001 9:05 AM
> To: sigtran
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 17:04:27 +0200

Tolga,

The NA is implied by the RC. However, there are cases where the SG only
requires NA to know how to route the message and doesn't need/want to do RC
analysis (that's how I interpreted previous discussions). The ASP still
passes the RC, so that the SG may return it in a SSNM (or whatever) message
in case of routing errors. In the other direction, the SG needs to determine
the RK/RC anyway to split the traffic over the configured AS's (by
definition of AS).

Sending NA to ASP is not needed, because the ASP wants to do RC analysis (to
know which AS) in any case, regardless of the NA. RC-value = NA can be used
in cases where there is just only 1 RK/RC per SS7 network appearance, if
people think this can save time in the ASP ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: donderdag 27 september 2001 16:11
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Hi,

 Tolga

> NA optional in direction ASP->SG.
[TOLGA] Is NA mandatory in direction SG->ASP? Why is it optional for
ASP->SG?How can SG know, to whihc network to route the message?

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 17:33:48 +0200

Hi John,

Some remarks :

1) Use of RL : this may be true for M3UA, but not for SUA. And on the ASP,
RC (required for AS definition anyway) analysis is  straightforward, instead
of analyzing the RL each time.

2) RC implies NA : by definition of the RK/RC (cannot span several networks,
i.e. SPC numbering spaces), the NA *is* implied. NA is derived from both the
NI bits and incoming linkset on the SG, and accepted as RK parameter. The
restriction is the RK at most contains a single NA parameter value.

3) To ASP, the RC is the parameter that matters. The SG can get NA from the
ASP if it wants.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: donderdag 27 september 2001 16:38
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

I don't agree.

Hence, we now have:

1)  SG <--> ASP:

2)  IPSP <--> IPSP:

John 

---

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 27 Sep 2001 10:22:15 -0500

Hi Gery,

I also agree that NA is implied by RC. What I want to point is that, if it
is mandatory at some cases , then it should be mandatory in both directions.
If we assume that everybody will use RC to find out NA, then why is it
needed for SG->ASP? 
And also some people don't want to do RK analysis on ASP side, so what they
only need is NA, because they will handle all traffic belonging to one
network with the same SS7 entity.
To make it clear, I am here not advocating that RC shouldn't be there, I
believe just RC should be enough but there are also people which don't think
so. If the strategy is to find a solution, which works fine for everybody
then for 3) of your second proposal , there should be NA for SG->ASP, when
traffic of more than one network is carried over the same association. (I
have to say that I don't like the idea to find solutions, which works fine
for different opinions. This document is still a draft, so everybody should
be ready to change his/her design, if the draft is changed. IMHO, it is not
good to restrict ourselves with our current ipmlementations,while discussing
the proposed changes to the draft.)

  Tolga

> Sent: Thursday, September 27, 2001 11:04 AM
> To: sigtran

---

---

From: Amish Chana <[email-masked]>
Date: Thu, 27 Sep 2001 16:58:45 +0100

Gery,

Ah, option 2.

(2) and (3) are acceptable, but I have my doubts with (1).

For (1) I assume the ASP Active and ASP Active Ack will still have the RC. 
Is this correct?

Assuming the above is still sorrect, lets say at some later stage I wish to 
configure another AS. After dynamic registration would we expect both the 
ASP and SGP to start using options (2) and (3).

Let's keep the message format the same across all scenarios not use (1).

Since NA is optional or not required, I think some text is also necessary in 
the drafts to state that the SGP and ASP should be able to process and 
deliver the message irrespective of whether the arriving message includes 
the NA.

Cheers,
Amish

---

---

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

Amish, 

That is supposed to be included in the Routing Label of the MTP3 message that you send along with the DATA mesg.

Cheers // Javier.

> Sent: Thursday, September 27, 2001 3:35 PM
> To: sigtran
> [email-masked]

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 27 Sep 2001 09:15:24 -0700 (PDT)

Hi Gery,

I think Alf is referring to the case that Ken 
Morneault brought up a while back, which is
where there are RKs provisioned at the SG
which are used to route traffic to different
ASPs, but the ASPs themselves are able to
process the traffic sent to them without doing
further discrimination based on an RC, e.g.,
they are not divided up into multiple ASs.

Then you don't need to send the RC, the
routing of traffic is only done at the SG.

Cheers,

Lyndon

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 27 Sep 2001 09:48:58 -0700 (PDT)

Hi folks,

Open, closed, poll poll poll - this is getting 
rather dizzying.  I actually think we should
cool this discussion down until after v9 is
available.

It still seems to me that the simplest set of rules
is to send both NA and RC whenever applicable,
i.e., NA when the SG connects to multiple networks
and needs a modifier to the point code; RC 
whenever the ASP serves multiple ASs and a
context is needed to identify the AS.  To simplify,
we can make this symmetrical for SG->ASP and
ASP->SG.

This leaves everyone able to decide what to process,
at the cost of slightly more administration (for
NA, only in the multi-network case, and you can
choose to use the same NA values across all of 
your nodes) and message length.

Logically, you can argue that the NA and RC are
semantically different, and that while you may
choose to organize separate ASs for each NA, 
there may be a reason to have one AS that
spans multiple NAs, in which case RC = NA is
not possible.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Sep 2001 14:35:30 -0500

Lyndon,

Please see correction below....

Lyndon Ong wrote:                                          (Thu, 27 Sep 2001 09:48:58)
> spans multiple NAs, in which case RC = NA is

Wrong.  You cannot span multiple NAs with an AS.
You can always have RC = NA.  Period.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 27 Sep 2001 13:42:23 -0700 (PDT)

> You can always have RC = NA.  Period.

I think this is debatable.  There is always the
case where no RK is defined at the ASP, there is
only a single AS that handles all messages sent
to it.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Sep 2001 17:25:06 -0500

Lyndon,

Lyndon Ong wrote:                                          (Thu, 27 Sep 2001 13:42:23)
> only a single AS that handles all messages sent

It has nothing to do with whether an RK exists at
the ASP or not.  There is a 1:1 relationship between
RC and RK and RK is not allowed to span NA.
Therefore, it is always possible to establish RKs so
that there is one RK per NA, and thus one RC value
per NA value.  That RC value can equal the NA value.
Plain and simple.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 27 Sep 2001 16:09:29 -0700 (PDT)

Hi Brian,

My point was a little different, just that 
in the case where there 
is no RK configured at the ASP, no RC is sent 
from the SG.  However, you still might want
to send an NA if the ASP handles traffic of
multiple networks.

For RK, I think you are referring to RK being
defined as not spanning across multiple
Signaling Point Management Clusters, and an SPMC
being defined as:

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

But this seems defined around a single SS7 network
case, it's a good question how this is applied in 
a multi-network case.  

At a higher level, though, are we putting a
definition ahead of a need here?
If someone wants to handle multiple NAs
within a single AS, is there a reason to
restrict this from being done?

I'll try to shut up after this, as the thread is
getting overly long...

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Sep 2001 18:43:41 -0500

Lyndon,

Lyndon Ong wrote:                                          (Thu, 27 Sep 2001 16:09:29)
> to send an NA if the ASP handles traffic of

It is precisely so that one does not need to
configure an RK at the ASP that RC is sent.

> case, it's a good question how this is applied in 

Those wishing NA based routing and management
wish to have a single routing and management view
based on NA.  Therefore SPMC = NA = RC.  The SPMC
just has multiple point codes.

> restrict this from being done?

Yes.  Because an AS (MTP-User) is defined only for
a single NA even in the SS7 model.  There is no need
to permit things outside the SS7 model.

--brian

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

---

---

From: Lyndon Ong <[email-masked]>
Date: Thu, 27 Sep 2001 17:38:33 -0700 (PDT)

Hi Brian,

> configure an RK at the ASP that RC is sent.

Oh, I mean where there is only one AS at the ASP,
so you need neither RK nor RC there.

> to permit things outside the SS7 model.

I think we're already somewhat outside the SS7
model ;o)  It's not hard to envision someone
wanting to do this without having to define
multiple ASs.

Cheers,

Lyndon

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 27 Sep 2001 21:02:12 -0500

Lyndon,

Lyndon Ong wrote:                                          (Thu, 27 Sep 2001 17:38:33)
> so you need neither RK nor RC there.

If you don't use RCs for ASs (you have one big AS
at the ASP), use 'em for NAs.  That's the point
of RC = NA.

> wanting to do this without having to define

There has been no need expressed for this.  The
WG discussion on RK [Issue 15] concluded that RK
cannot be allowed to span SPMC (because there is
no concerned point code in the SNMM messages).
Because SPMC cannot span NA, RK cannot span NA
either.

It is difficult to conceive of someone not wanting
to know which SPMCs which SNMMs apply to.

So, I'm sorry, it is always possible to assign RC = NA.

Think of it this way: NA only defines the numbering
space (and format) of the point code.  Because RK and
RC can be assigned on a numbering space basis, RC = NA
is always possible.

Letting RK's, RC's and AS's span NA makes no sense.
Set RC = NA and have one big AS demuxed on NA = RC if
you want to get ridiculous.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 15:47:39 +0200

Hello Chana,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: donderdag 27 september 2001 15:35
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Gery,

Amish

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 28 Sep 2001 12:37:21 +0200

Chana,

Inclusion of RC/NA is discussed for DATA and SSNM messages. Clearly RC is
there in the ASPTM procedures.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: donderdag 27 september 2001 17:59
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Gery,

Ah, option 2.

Cheers,
Amish

---

---

---

From: Amish Chana <[email-masked]>
Date: Fri, 28 Sep 2001 12:16:02 +0100

Gery,

After an ASP active that follows a single previous registration are you 
going to use option (1) because you only have one RK/RC and NA for AS1?

If at a later stage a second registration takes place for AS2 will your 
implementation commence using option (2) or (3) as applicable?

If AS1 then gets deregistered will your implementation revert to option (1)?

Amish
PS. Call me Amish, if you don't mind.

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 28 Sep 2001 13:51:34 +0200

Hi Amish,

Sorry for the name mixup ;)

(1) is a silent agreement between SG and ASP; e.g. the SG can even refuse
the ASP to register for more than 1 AS ...
My implementation is always going to include RC, so to put the dots on the
"i" :

Lyndon e.a. : can we have a vote "for" - "against" ?

>=====
(1) No multiplexing over SG-ASP SCTP association (Single RK - Single NA)
    => RC optional, no NA
      (to humour the people who want to save the 8 RC bytes)

(2) Multiplexing over SCTP association (Multiple RK - Single NA)
    => RC mandatory, no NA

(3) Multiplexing over SCTP association (Multiple RK - Multiple NA)
    => RC mandatory
    => NA optional in ASP->SG direction

Note1 : both SG and ASP can support more than 1 RK and more than 1 NA any
time, but the thing to consider is what's going over a single SCTP
association. So please don't come up with scenario's where SG supports
multiple RKs and the ASP just one : this resolves to case (1) above. And the
case Single RK - Multiple NA is also out of the question (basic
definitions!!!).

Note2 : since the SG must determine the NA from NI bits and incoming linkset
on the SS7 side, it seems no big deal to me to do the same based on incoming
SCTP association (and RC for case 3) on the IP side. For case (3), we can
make an exception to include NA for the SG's convenience if it thinks this
derivation is going to be too complicated.

Note3 : in case (2) the RC is mandatory, also in ASP->SG direction, even if
only to mirror the RC back in management or service messages triggered by
the received message e.g. in case of routing failures detected at the SG.
=====<

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Amish Chana [mailto:[email-masked]]
Sent: vrijdag 28 september 2001 13:16
To: sigtran
Subject: RE: [M3UA Issue 1] Network Appearance Sematics / Format - POLL
- POLL - POLL

Gery,

Amish

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 28 Sep 2001 09:55:03 -0700 (PDT)

Hi Gery,

>       (to humour the people who want to save the 8

Do you believe that there is a (Single RK - Multiple
NA) case?  I guess you do not, but so far
I don't see why this should not be allowed.

If there is a single NA, then I agree it is not 
necessary to carry NA over the association.

>     => NA optional in ASP->SG direction

Is NA sent or not sent in the SG->ASP direction?
I think my proposal was NA mandatory in both
directions, so no options/interoperability issues.

> case Single RK - Multiple NA is also out of the

OK, here's one issue.  What definition rules this
out?  Why should this not be supported?  It seems
like a simple case.

> SCTP association (and RC for case 3) on the IP side.

But this seems to require a separate SCTP association
for each NA.  Is administering an NA such a difficult
thing for people?

Cheers,

Lyndon

---

---

From: Lyndon Ong <[email-masked]>
Date: Fri, 28 Sep 2001 10:22:29 -0700 (PDT)

Hi Brian,

> at the ASP), use 'em for NAs.  That's the point

But the RC is sent as a method of indexing an
AS at the ASP.  If we're ignoring this function
of the RC, what's the difference between doing
this and sending a separate NA?  An NA would be
cleaner, in fact, since it does not imply 
multiple ASs as the structure at the ASP.

> Because SPMC cannot span NA, RK cannot span NA

It's not so clear that an SPMC cannot span NAs.  I
don't think SNMMs will be an issue, as NA is
already in the SNMM.

> RC can be assigned on a numbering space basis, RC =

Sure it's possible, but is it the right thing to do?
Should we design the protocol to restrict an
AS to a single NA, if you can avoid this by 
sending NA as a distinct parameter?  If administering
NA is the concern, maybe we can limit the
range of NA values - presumably the number of networks
that you can attach to at one SG must be fairly
limited.

> Set RC = NA and have one big AS demuxed on NA = RC
> if you want to get ridiculous.

But in this case you are not doing demuxing, if
you were doing demuxing you would have multiple ASs
and multiple RCs and that would make perfect sense.
If you have one big AS, sending an RC does not make
sense, IMHO.

Cheers,

Lyndon

---

---

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

Lyndon,

Lyndon Ong wrote:                                          (Fri, 28 Sep 2001 10:22:29)
> multiple ASs as the structure at the ASP.

So that the SG implementation too stupid to send
RC can use the NA value instead and the ASP receiving
it in the RC can treat it as it would normally treat
an RC.

Otherwise the ASP needs to determine what to do with
the NA value *and* the RC value, whether they conflict,
which overrides which, ...

It is better to use the single field RC.

> don't think SNMMs will be an issue, as NA is

See response to Barry's note.  Also, the reason that
RK and SPMC do not span NA is so that management messages
do not need CPC.  It used to be that they could not
span so much as a destination point code and I was the
only one wanting it to be expaneded to SPMC to allow
for alias point codes.  There is no point in having
RK span SPMC and SPMC span NA.

> > space (and format) of the point code.  Because RK
> > and RC can be assigned on a numbering space basis, RC =
> > NA is always possible.
> 
> sending NA as a distinct parameter?

Those that need NA do not need multiple AS on RC.

> If administering NA is the concern, maybe we can
> limit the range of NA values - presumably the number
> of networks that you can attach to at one SG must be
> fairly limited.

The only way to remove the adminstration burden is
to register the field with IANA and have point-code
numbering spaces apply for global values.  Even still
it is not needed in more than REG REQ.

> If you have one big AS, sending an RC does not make

You forget how strongly those in favor of NA argued
that there was no multiplexing to perform.  Q.701 is
clear that if multiple SI values are passed to the
same MTP-User that it is the user's responsibility to
separate them further.  This is also the case for
PC granularity routing.  When the RC = NA, the traffic
is separated at the AS by examining the RL.

--brian

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

---