Subject: RE: [M3UA Issue #4] Payload Format - poll

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

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.

> -----Original Message-----
> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Thursday, September 27, 2001 10: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.
> 
> 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]
> 

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