Subject: Re:[M3UA Issue #2] NA and/or RC ...was RE: [M3UA Issue 1] Netw ork Appearance Sematics / Format - POLL - POLL - POLL

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

Hi Gery, 

You forgot one case:

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

4) No multiplexing of several RKs/RCs, spanning several NAs

RC optional and NA Required in both directions if it is not defined inside the RK.

Cheers // Javier.

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Thursday, September 27, 2001 3:43 PM
> To: sigtran
> Subject: RE: [M3UA Issue 1] Network Appearance Sematics / 
> Format - POLL
> - POLL - POLL
> 
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Verwimp Gery [mailto:[email-masked]]
> > Sent: Thursday, September 27, 2001 4:36 AM
> > To: sigtran
> > Subject: RE: [M3UA Issue 1] Network Appearance Sematics / 
> > Format - POLL
> > - POLL - POLL
> > 
> > 
> > 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.
> [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)
> > 
> > 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.
> > 
> [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.
> > 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]
> > ____________________________________
> > 
> > 
> 
> 
> ---
> 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: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 27 Sep 2001 16:07:11 +0200

I think I set the wrong subject !!  :))
Let's try again...

Cheers // Javier.

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]] 
Sent: Thursday, September 27, 2001 12:39 PM
To: 
Subject: RE: [M3UA Issue #4] Payload Format - poll

Hi Gery, 

First of all, allow me to rename the subject....  :-)

Secondly, I completely agree with your view but adding the same text about RC as in 1):

  3) IPSP <-> IPSP : RC mandatory, when traffic for more than 1 IPS is multiplexed over the association, otherwise optional. No NA whatsoever.

where IPS is to IPSP the same as AS to ASP.

Cheers // Javier.

> Sent: Thursday, September 27, 2001 10:36 AM
> To: sigtran
> Well, just to signal I'm still looking at this too, and I didn't see a
> definitive answer.
> 
> 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/
> > 
> > 
> > ---
> > [email-masked]
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with 
> Yahoo! Messenger.
> http://im.yahoo.com
> 
> 
> ---
> [email-masked]

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

---