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

From: "Schantz, John" <[email-masked]>
Date: Wed, 22 May 2002 16:45:35 -0500

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 May 2002 18:12:36 -0400

In the lack of RC, NA is definitly a MUST for SG-SG for the cases you
described(where traffic for multiple networks is carried over an association
between SGs). Now I saw that I indicated this just for TAL, but I will move
this explanation to 2.3 Network Appearence to make it more clear.

   Tolga

> From: Schantz, John [mailto:[email-masked]]
> Sent: Wednesday, May 22, 2002 5:46 PM
> To: Tolga Asveren; [email-masked]
> 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.
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 22 May 2002 18:16:29 -0500

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

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/