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

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

Hi Javier,

Not specifying NA in the RK can only mean there is 1 single NA. If not, NA
MUST be specified in the RK !

____________________________

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

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: donderdag 27 september 2001 15:57
To: sigtran
Subject: Re:[M3UA Issue #2] NA and/or RC ...was RE: [M3UA Issue 1] Netw
ork Appearance Sematics / Format - POLL - POLL - POLL

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]

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