Subject: RE: [Sigtran] M3UA implementors guide -- Semi-optional parameters

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 23 May 2002 12:53:22 +0200

John, 

See below...

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, May 23, 2002 1:16 AM
> To: Schantz, John
> Cc: Tolga Asveren; [email-masked]
> Subject: Re: [Sigtran] M3UA implementors guide -- Semi-optional
> parameters
> 
> 
> John,
> 
> I  agree for SG-SG, but disagree for M3UA IG.  RC can never span NA.
> Therefore, where multiple NAs exists, multiple RCs also 
> exists on a single
> association an the RC MUST applies.  As RC implies NA (RC 
> cannot span NA),
> there is never a case where NA can be expected that RC is not 
> required.

Do you agree with the statement above?

Cheers // Javier

> Therefore RC is semi-optional, NA is purely optional.  This 
> is where it was
> left in the RFC and there is no need to change it.
> 
> For SG-SG I don't see much value in having more than one NA 
> multiplexed over a
> single SG-SG association.  Each SG must (anyways) have a 
> point code in the
> same network appearance to communicate in the first place.  
> It is an easy
> matter to have a single NA per association.  Nevertheless, 
> where one wants to
> carry multiple network appearances over an association, or 
> manage multiple
> networks across a single SGPF, there should be a requirement 
> for NA in SG-SG.
> In SG-SG RC is not really required (as SGPFs don't talk to 
> each other about
> users except with DUPU).  We both agreed on this in previous 
> discussions: that
> for peer to peer operation, dividing up a point code was not 
> terribly useful.
> Management on a full point code (and not user parts) is 
> needed for SG-SG
> operation.
> 
> Actually, many of your previous arguments are valid for 
> SG-SG.  I hope that
> you are interested in contributing to the draft.
> 
> Will we see you for the Dallas SIGTRAN lunch on Friday?  
> Anyone who finds
> themselves in the Dallas area on Friday is welcome to attend. 
>  Macaroni
> Grill on Park and Preston.  Drop Tom George a note if you 
> plan to attend.
> 
> --brian
> 
> Schantz, John wrote:                                     
> (Wed, 22 May 2002 16:45:35)
> > Yes, actually in the text where RC is a MUST, there are 
> cases where NA should also a MUST.  Brian did a good job of 
> pushing the MUST for RC but I don't think many people 
> understand the application of NA.  Most SS7-oriented people 
> probably understand the need and use for NA.
> > 
> > Since RC was going to get the "semi-optional" status, I 
> decided that I might as well point out that the same is true 
> of NA.  It would also be applicable to the SG-SG doc. since 
> SG-SG traffic could carry traffic from multiple networks.
> > 
> > John S.
> > 
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Wednesday, May 22, 2002 4:44 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] M3UA implementors guide -- Semi-optional
> > parameters
> > 
> > 
> > Correct me if I am wrong but I thought 3.6 was added to IG, 
> to prevent a
> > confusion because of
> > 
> > 3.3.1
> > Routing Context   Optional
> > 
> > and
> > 
> > Page29:
> > Routing Context:
> > ......
> > Where multiple Routing Keys and Routing Contexts are used 
> across a common
> > association, the Routing Context MUST be sent to identify 
> the traffic flow,
> > ......
> > 
> > In the current draft, a MUST does not exist for Netwok 
> Appearence. So,
> > should it be still considered as semi-optional?
> > 
> >    Tolga
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > > Schantz, John
> 
> > > Sent: Wednesday, May 22, 2002 4:30 PM
> > > To: [email-masked]; [email-masked]; 
> [email-masked];
> > > Javier Pastor-Balbas (ECE)
> > > Subject: [Sigtran] M3UA implementors guide -- 
> Semi-optional parameters
> > >
> > >
> > > I have been off doing other things and I decided to see 
> what was new.
> > >
> > > I noticed that section "3.6 Semi-Optional RC Parameter" left out
> > > "NA".  The same arguments for RC also apply to NA.  If an
> > > association is to carry traffic from more than one network (e.g.,
> > > 2 national ITU networks where SS7 PCs are not unique, or an ANSI
> > > and an ITU network where the PC format and message format are
> > > different), then the NA is required.
> > >
> > > You can easily change the section title to remove "RC" and change
> > > NA's designation from "optional" to "semi-optional".
> > >
> > > John S.
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 23 May 2002 12:51:08 +0200

Hi John, 

What Tolga says is right. It was just a matter of keeping consistency.  :-)

Cheers // Javier.

> Sent: Wednesday, May 22, 2002 11:44 PM
> To: [email-masked]
> association, the Routing Context MUST be sent to identify the 
> traffic flow,
> ......
> 
> In the current draft, a MUST does not exist for Netwok Appearence. So,
> To: [email-masked]; [email-masked]; [email-masked];
> Subject: [Sigtran] M3UA implementors guide -- Semi-optional parameters
>
>
> I have been off doing other things and I decided to see what was new.
>

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 23 May 2002 11:31:02 -0500

Bidulock,,,,

> Sent: Thursday, May 23, 2002 11:01 AM
> To: Schantz, John
> Schantz,,
> (Thu, 23 May 2002 10:05:34)
> > Comments below.
> > 
> > > Sent: Wednesday, May 22, 2002 6:16 PM
> > > To: Schantz, John
> > [John] I agree that RC does not span NA.  It is lower order concept.
> > 
> > > association an the RC MUST applies.  
> > 
> > [John]  Not completely correct.  You could have multiple 
> NAs and NO RCs.  If
> > there were RCs present, NA+RC would (should) be unique.  We 
> should be making
> > these things work together!!!!!!!
> 
> Not possible.  RC cannot span NAs, so an implied RC means 
> that there is only
> one NA on the assocaition.
> 
You need to think about this one again.  If routing is based only on PC, ONLY NA is needed to separate traffic from multiple network appearances.  There is no RC or implied RC.  There is no need for one.  The big boys don't need RC.

> > >As RC implies NA (RC 
> > [John] Two things here.  Don't necessarily agree that RC 
> ==> NA.  I have
> > already given cases where NA is required and RC are NOT 
> used.  If you don't
> > need to split the traffic finer than the PC on the 
> "transport" side you
> > don't ever need RC!  RC is a new concept that has no 
> analogue in SS7.
> 
> That RC ==> NA is even stated in the RFC.  It is a given.

Doesn't matter, RC is not needed.
> 
> > 
> > > Therefore RC is semi-optional, NA is purely optional.
> > 
> > [John]  I disagree.  NA is as much semi-optional as RC.
> 
> That is not the case in the RFC.  We can start the long 
> ladder again for
> backhaul if you want, but the result will be the same.  SG-SG is
> different.  For SG-SG I agree that RC serves no purpose.  RC 
> is MTP-User
> related, not MTP-Peer related.  For backhaul RC is required and NA is
> unnecessary except in REG REQ (an MTP-User knows its network
> appearance).  For peer-to-peer NA is required and RC is unnecessary
> (MTP3 peers don't care much about remote users and uses DUPU to
> communicate user availability).
> 
This doesn't argue away the fact that it should have has the same status as RC.  Note, RC is only optional in RFC too!

> > > This is where it was
> > [John]  Only because I didn't push it like you did for RC.  
> Perhaps now is
> > the time to fix it.
> 
> Nothing to fix.
> 
Other that you have not given an argument as to why it should not be semi-optional.
> > > single SG-SG association.  
> > 
> > [John]  Isn't this up to the network operators to decide!  
> Are you telling
> > them that they can not connect their SGs to more than one network.
> 
> No.  Read what I said.  I said more than one NA per 
> association, not more
> than one NA per SG.
> 
I think you had better re-read your stuff.
> >  
> > > Each SG must (anyways) have a point code in the
> > > matter to have a single NA per association.  
> > 
> > [John]  True an SG must have a PC for each network 
> appearance.  Are you
> > proposing that we NEVER carry traffic from multiple 
> networks on the same
> > association.
> 
> I don't see the use in it.  SNMM is single-network.

Argument by confusion.  I don't think you said anything here.
> 
> > If you could have gotten agreement to this before, we would
> > not be arguing about NA now.
> 
> It was finalized in the last discussion and captured in the RFC.
> 
> >  
> > > Nevertheless, where one wants to
> > [John]  Agreed.  But mixing traffic from multiple networks 
> was already
> > allowed for SG-AS.  If you are saying that only SG-SG can 
> do it then you
> > have to require the SG to split the traffic out and send it 
> on separate
> > associations to the AS.  I'll afraid the cat is already out 
> of the bag.
> 
> This is already supported under backhaul: nothing is missing 
> from the RFC.
> 
> > 
> > [John]  Actually, I'm confused by the DUPU.  Or is this 
> only in the SG
> > backhaul case where the AS does not have the M3UA 
> functionality.  In today's
> > networks, STPs do not generate UPUs.
> 
> When does an AS "not have the M3UA functionality"?  The term AS is
> only defined within the scope of M3UA...
> 
You didn't answer the DUPU question - argument by confusion.
> > Yes
> Glad you could make it: I'll see you there.

It'll be fun.