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

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 27 Sep 2001 12:43:49 -0500

Hi Javier,

Related with 4), you have added:
If one RK is not allowed to span more than one network, how is it possible
that one association carries traffic of more than one network but just one
RK? (If it is agreed that RK can span more than one network, then I agree
with you)

> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Thursday, September 27, 2001 10:34 AM
> To: sigtran
> Subject: Re:[M3UA Issue #2] NA and/or RC ...was RE: [M3UA Issue 1] Net
> work Appearance Sematics / Format - POLL - POLL - POLL
> 
> 
> Resend...
> 
> -----Original Message-----
> From: Javier Pastor-Balbas (ECE) 
> Sent: Thursday, September 27, 2001 3:57 PM
> To: [email-masked]'
> Subject: Re:[M3UA Issue #2] NA and/or RC ...was RE: [M3UA Issue 1]
> Network 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]