Subject: Re: [Sigtran] [m3ua]-AS-SG

From: "TOLGA ASVEREN" <[email-masked]>
Date: Tue, 4 Mar 2003 09:31:09 +0200

Brian,

TOLGA ASVEREN wrote:
(Tue, 04 Mar 2003 07:58:04)
>
> Brian,
>
> My point with my explanation why each SGP can be identified only with
SCTP
> addressing from ASP point of view was not to propose implicitly to put a
> parameter or to define a procedure to do otherwise. IMO, there is no need
> for this. Just form two SCTP associations -one for each SGP-, I don't
think
> this is terribly bad.
> Still some comments below.
>
>     Tolga
>
>
>
> Barry.Nagelberg,
>
> [email-masked] wrote:
> (Mon, 03 Mar 2003 13:08:15)
> > "Brian F. G. Bidulock" <[email-masked]>
> > Sent by: [email-masked]
> >  03/03/2003 12:37 PM
> >  Please respond to bidulock
> >
> >
> >         To:     [email-masked]
> >         cc:     [email-masked]
> >         Subject:        Re: [Sigtran] [m3ua]-AS-SG
> >
> >
> > Barry.Nagelberg,
> >
> > [email-masked] wrote: (Mon, 03 Mar 2003 11:18:26)
> > > Brian,
> > >
> > > OK, I agree with you that a parameter to identify the SG could be
> > selected
> > > on an implementation-dependent basis. This, however, would destroy
the
> > > concept of  interoperability.
> >
> > How so?
> >
> > [BN] - Because both the ASP and the SGP must be aware that the chosen
> > parameter is being used to identify the SG.
>
> I don't think so...  Why would the ASP need to know that the SGP is
> using SLS, for example, to select the SG?
> [TOLGA]If ASP is communicating via multiple SGs, it should be able to
> select the SG it wants, reachability of a specific destination might be
> different via each of them.

Where does it say that in the RFC?  (That the AS SHOULD be able to select
an SG???)
[TOLGA]If there are multiple SGs in the configuration, I think it is very
clear that ASP has to select a SG for outgoing traffic. In fact it also
shoud decide from which SG a message is coming from(for SSNM for example).

> This basically also rules out any possiblity to use SLS for that purpose.

I don't see it ruled out at all.  I personaly don't think that it would be
terribly useful, but it is not ruled out.
[TOLGA]It is ruled out. Please see example in my original message. How will
SGP1 handle such a scenario?

> Imagine the scenario where ASP1 uses SG1 and SG2.  PC-A is reachable via
SG1
> but not via SG2.

Who says this has to happen?  The reachability of all remote point codes
via
SG1 and SG2 could be identical.  Don't assume that they are mated STPs.
[TOLGA]The example assumes that SGP acts as part of multiple SGs with
different MTP3. So, nobody can assure that they will have always the same
SS7 connectivity. I think, what you are doing is an assumption -that those
SGs *with different MTP3* have the same reachability inormation about
destinations-. But as I indicated before, this example relies on the wrong
interpreation what SGP is, i.e. it excludes MTP3 part and assumes SGP is
just M3UA-SGP. This is not my view of SGP.

> And let's furthermore assume one wants to use just SGP1 for
> both SG1 and SG2. Now there is one association between SGP1 and ASP1
-O.K.
> this won't work, but the point is to show that it won't work with one
> association-. ASP1 wants to send messages to PC-A and because it is
> reachable via SG1 and because SGP1 is part of SG1 it sends the messages
to
> it. Now let's assume SGP1 is doing loadsharing based on SLS to decide for
> which SG (SG1 or SG2) the message is intended for. In such a case
messages
> with SLS values matching SG2 will be dropped.  Now, one might argue that
> when one speaks of SGP, it also includes level3 logic (MTP3) not just
> M3UA-SGP stack (this is how I see it and IMO also how RFC sees it and
please
> note the above example does not interprete SGP in that way). In such a
case,
> by definition, one SGP can't be part of multiple SGs(countability
argument
> in your message, I agree).

I asked how to count them.  Do you believe that they must be different in
SS7
routing to count them?  I appears so.  I don't see where it says that in
the
RFC either.
(TOLGA]In the RFC you can't find it, because there SGP is both M3UA + MTP3
and so one SGP can be part of only one SG.

> I believe, not to take this into account was one of the reasons, why this
> thread was triggered.  Then one might ask, why I can't use one
association
> for multiple SGPs?

How do you count SGPs?  It think an SGP is the process at the SGP end of an
association; an ASP the process at the ASP end of the association.  But
that
has little bearing on how many SGs an SGP belongs to.  An SG is a logical
thing.  We did not say that there was a 1:1 relationship between SGP and SG
(if we did it might be easier to count SGs, but all of that sort of thing
was moved to an "operational" appendix and made into a simple example, by
our A-Ds I might add.)
[TOLGA]Because of my first explanation, it is impossible that one SGP
belongs to multiple SGs (because there is no way to decide, for which SG a
message is sent to and similarly from which SG a message has arrived). If
one thinks the opposite (for that, one has to interprete SGP as consisting
of just M3UA, otherwise -SGP=M3UA+MTP3- it does not make sense to speak of
SGP belonging to multiple SGs, because multiple SGs mean multiple MTP3,
then you will have different SGP by definition), then SLS loadsharing
between them won't work.

> The above explanation will be still a valid answer I think (just with the
> modification that there are now two SGPs -SGP1 and SGP2-, which are part
of
> SG1 and SG2). And as indicated at the beginning of this message, I don't
> think it is a good idea to introduce some new parameters/mechanism to
reduce
> number of SCTP associations, when we want to use multiple MTP3 entities
for
> SS7 connectivity(IMO, multiple SG scenario is not a good choice with
ASP/SGP
> model anyway, but discussing this belongs not to this thread)

There were those that wanted to restrict the architecture more for clarity
and
simplicity (I wan't one of them) but that idea got appendicitis.  You can
try
putting these restrictions back in the IG, but the IG will never make it
past
draft anyway.
[TOLGA]I think it is pretty much clear that SGP=M3UA+MTP3 and that it does
not make sense to think one SGP belonging to multiple SGs -and furthermore
I think this is a natural result of the definition of SGP rather than a
restriction-. If clarification is necessary, let's add it to IG.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Mar 2003 00:45:20 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Tue, 04 Mar 2003 09:31:09)
> shoud decide from which SG a message is coming from(for SSNM for example).

Where is the requirement in the RFC?

> different MTP3.

Where does it say that different SGs have to have different MTP3?

> So, nobody can assure that they will have always the same SS7 connectivity.

Yes you can, by configuration.

> I think, what you are doing is an assumption -that those SGs *with different
> MTP3* have the same reachability inormation about destinations-.

Where does it say that different SGs have to have different MTP3?  SGs could
be partitions of the same MTP3, or might even have no MTP3 at all.

> But as I indicated before, this example relies on the wrong interpreation
> what SGP is, i.e. it excludes MTP3 part and assumes SGP is just M3UA-SGP.
> This is not my view of SGP.
> 
> 

Not forbidden in the RFC?  Then it is permitted.  Why say it is not?

> message is sent to and similarly from which SG a message has arrived).

Where does it say this in the RFC?

> If one thinks the opposite (for that, one has to interprete SGP as
> consisting of just M3UA, otherwise -SGP=M3UA+MTP3- it does not make sense to
> speak of SGP belonging to multiple SGs, because multiple SGs mean multiple
> MTP3,

Not so.  Where does it say in the RFC that SGs must have different MTP3?

> then you will have different SGP by definition), then SLS loadsharing

I'm sorry but the entire chain of deduction is misplaced so the conclusion
cannot be trusted.

> restriction-. If clarification is necessary, let's add it to IG.

What will it clarify?  The examples in Appendix A?

--brian

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