Subject: RE: M3UA07: Network Appearance - on point

From: Lyndon Ong <[email-masked]>
Date: Fri, 17 Aug 2001 09:30:56 -0700

Folks,

Can we get back on issue here?  This thread is on the 
definition of NA.  There have been some views that NA
should revert to the definition in version 6, where it
identifies a "network context", as opposed to an entity.

I would like to hear more views on this - pro and con.
Brian has suggested that this is tied to the RC in the
DATA message issue, I am not sure this is the case and
would also like to hear views on this.

Cheers,

Lyndon
--

On Fri, 17 Aug 2001 10:43:11   Verwimp Gery wrote:
>Hi,
>
>This is also my perception. The whole idea of RK/RC is to separate SS7
>traffic and define a logical AS, so why can't we use RC to distinguish the
>traffic streams at an ASP ???
>
>NA is just part of the RK to help describe an SS7 traffic stream.
>
>____________________________
>
>Gery Verwimp
>> SIEMENS ATEA
>> ICN D CS D5
>> 
>> Tel. : +32 14 25 3424
>Fax : +32 14 25 3212
>mailto:[email-masked]
>____________________________________
>
>
>-----Original Message-----
>From: Brian F. G. Bidulock [mailto:[email-masked]]
>Sent: donderdag 16 augustus 2001 20:06
>To: sigtran
>Subject: Re: M3UA07: Network Appearance
>
>
>Barry,
>
>RC is used by ASPIA to indicate to the SG for which AS it is
>becoming active.  In doing so, the ASP distinguishes to the
>SG which routing keys (and thus traffic flows) for which it is
>going active.
>
>This is generally understood.
>
>--brian
>
>[email-masked] wrote:                (Thu, 16 Aug 2001
>13:39:30)
>> Brian,
>> 
>> I am right. The ASPTM messages are ASPAC, ASPIA, etc. As I said, these are
>> used only to specify for which ASs an ASP is going active or inactive.
>There
>> are NOT used to "distinguish traffic".
>> 
>> Barry Nagelberg
>> Software Engineer
>> RadiSys, Corp.
>> Signaling Products Design Center
>> [email-masked]
>> +1-856-642-9229 x237
>> 
>> 
>> 
>> 
>> 
>> "Brian F. G. Bidulock" <[email-masked]>
>> 08/16/01 01:23 PM
>> Please respond to sigtran
>> 
>>  
>>         To:     "sigtran" <[email-masked]>
>>         cc: 
>>         Subject:        Re: M3UA07: Network Appearance
>> 
>> 
>> Barry,
>> 
>> I think you are overreacting: RC is used in ASPTM to distinguish traffic
>> in M3UA precisely as Gery describes.
>> 
>> --brian
>> 
>> [email-masked] wrote:                (Thu, 16 Aug 2001 
>> 12:32:59)
>> >
>> > Gery,
>> > 
>> > You are wrong. The RC is not used in M3UA for interpretation of point 
>> > codes or SSNs. It is used only to specify for which ASs an ASP is going 
>> > active or inactive, and to specify to which ASs a Notify message from 
>> the 
>> > SG relates. It appears only in the the ASPAC, ASPIA, registration and 
>> NTFY 
>> > messages.
>> > 
>> > Barry Nagelberg
>> > Software Engineer
>> > RadiSys, Corp.
>> > Signaling Products Design Center
>> > [email-masked]
>> > +1-856-642-9229 x237
>> > 
>> > 
>> > 
>> > 
>> > 
>> > Verwimp Gery <[email-masked]>
>> > 08/16/01 11:23 AM
>> > Please respond to sigtran
>> > 
>> > 
>> >         To:     "sigtran" <[email-masked]>
>> >         cc: 
>> >         Subject:        RE: M3UA07: Network Appearance
>> > 
>> > 
>> > Hello everyone,
>> > 
>> > Just to give my 0,02 $ on this already overloaded topic :
>> > 
>> > I guess everyone will agree to the fact that an ASP can register for
>> > several RKs (whatever they may be), and can have multiple SCTP
>> > associations with the same SG, over which messages for these routing
>> > keys can be multiplexed.  This is the most general architecture, no
>> > restrictions implied.
>> > 
>> > For each RK, a RC (simple integer) is agreed between SG and ASP to
>> > enable the ASP to distinguish the traffic, for whatever reason
>> > (interpretation of PC, management messages, SSN, ...). RCs are even
>> > more precise than NAs in this respect, as they may define a subdomain
>> > of an SS7 network.
>> > 
>> > In this RK negotiation (static or dynamic), the NA is also specified
>> > (and only 1, a reasonable RK limitation). This means RC implies the
>> > NA, and thus is more than sufficient information for interpretation of
>> > point codes, SSNs, management messages etc. This approach has been
>> > taken by SUA, and I don't see any valid reason why M3UA couldn't go
>> > the same way.
>> > 
>> > The NA's are agreed between SG and AS providers, as part of the
>> > connectivity arrangement.
>> > 
>> > Monitoring equipment just needs to present PCs in a general format
>> > (integer ?) and may leave the interpretation to a tool (using
>> > configuration data) or human analyst. We don't need any configuration
>> > data in a protocol message, do we ?
>> > 
>> > Best regards,
>> > 
>> > ____________________________
>> > 
>> > Gery Verwimp
>> > > SIEMENS ATEA
>> > > ICN D CS D5
>> > > 
>> > > Tel. : +32 14 25 3424
>> > Fax: +32 14 25 3212
>> > mailto:[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]
>> 
>> 
>> 
>> 
>> 
>> ---
>> You are currently subscribed to sigtran as: [email-masked]
>> To unsubscribe send a blank email to
>[email-masked]
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to
>[email-masked]
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to [email-masked]
>

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

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

---

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

Lyndon,

Please see comments below...

Lyndon Ong wrote:                                          (Fri, 17 Aug 2001 09:30:56)
> identifies a "network context", as opposed to an entity.

It is clearly the point (and the approach taken in SUA which Gery is
expounding) that the definition of NA can revert to network context if
RC is added to all other messages.  As a side effect, NA can be removed
from all messages except the REG REQ.  Because John has a problemw with
this but has no interest in dynamic registration, I would propose that
he assign static RC values at his SG which are identical to the values
he would have statically assigned to the NA parameter.  Because the RC
will appear everywhere that the NA appeared there will be no impact to
his implementation and he can use in his implementation whatever
definition he likes in assigning his RC values.

RC and its role is very much related to the discussion of definition of
Network Appearance, and Gery  and John's discussion is focussing well on
the issues at hand.

> would also like to hear views on this.

Lyndon, I have a proposal which could possibly resolve the situation
altogether:

John (and others?) wish to assign NA to be network id.  Gery, myself
(and others) would like to see RC in DATA for sure and would like to see
RC replace NA in SNMM and DATA.

Here is the proposal: replace NA with RC everywhere except REG REQ.

Now, that looks like the old proposal but here is how it works for John:

Because John is not interested in dynamic registration, all of his
Routing Contexts are statically assigned.  For Johns case, all that he
need do is simply assign the same numeric value to RC as he would have
otherwise assigned to NA.  In John's configurations, where NA == Network
Id is addequate, he merely sets RC == Network Id.

This permits John to do everything he wants without keeping others from
using Routing Context in their configurations as they require.  John can
even assign RC == Network Id. in SUA if he would prefers that
configuration.  John does not demultiplex AS on RC (he routes on entire
point code) and therefore does not need the other capabilities of RC
which would necessitate other than an RC == Network Id assignment.  The
draft does not make any restrictions whatsoever on how RC values are
assigned, permitting RC == Network Id in John's case.  It is quite clear
that an ASP needs to accept any value of RC per SG as long as it is
unique and that (at least in the dynamic registration) the SG is
responsible for assigning the value of RC.

So to sum up: replace NA with RC in all SNMM and DATA messages, leave
NA in REG REQ but indicating Network Id.  If John wants, we can even
include text such as:

  "The SG MAY assign RC to have Network Id values in configurations
  where it is sufficient to do so."

I believe that this will remove all NA-based agruments to placing RC in
SNMM and DATA.  If John wants to support dynamic registration, he can
always echo the NA value provided in the REG REQ back to the ASP as
an RC value in the ack.  For John this allows RC == NA in the restricted
cases he is supporting, but allows others to use it in a wider scope.
It makes M3UA consistent with SUA and removes this M3UA and SUA issue.

This does not address Joyce's passive monitoring concerns, nor the issue
of RL packing, but it does get rid of the NA/RC issue.

Comments?

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

---