Subject: Re: [Sigtran] Re: M3UA Notify message

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 26 Feb 2003 16:00:29 +0200

Brian,

TOLGA,

TOLGA ASVEREN wrote:
(Wed, 26 Feb 2003 14:20:39)
>
> Brian,
>
>
> TOLGA,
>
> TOLGA ASVEREN wrote:
> (Wed, 26 Feb 2003 12:23:56)
> >
> > Brian,
> >
> >
> >
> >
> > TOLGA,
> >
> > I agree with John Schantz' original objection to this proposal.  The
> Notify
> > message is advisory only and that requiring a response from the ASP to
a
> > Notify message is too drastic a change to the protocol.
> > [TOLGA]I agree that it is not a minor change, especially just before
the
> > text was fozen it was not a good option. That is the reason, why the
> > sentence saying that ASPs SHOULD coordinate among each other number of
> > ACTIVE ASPs is included at the last minute. If people still don't want
to
> > change advisory meaning of NTFY, then for starting traffic, both ASP
and
> > SGP SHOULD wait till n ASPs are ACTIVE. So, MAY for SG should be
changed
> to
> > SHOULD. This change is already done in IG.
>
> You cannot place a "SHOULD" on the SG's interaction with the SS7 network
> (directing traffic).  That is why it says "MAY" and must remain as "MAY".
> [TOLGA]The sentence is, "An SGP or IPSP, upon reception of an ASP Active
> message for the first
>    ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
> active ASP until it determines that there are sufficient resources to
> handle the expected load (e.g., until there are "n" ASPs in state
> ASP-ACTIVE in the AS)." (In IG MAY is changed to SHOULD) It is not about
> directing traffic to SS7 network but to ASPs. Why is this considered as
an
> interaction of SG with SS7 network? Or how is this different than saying

See example from previous note.  The SG needs to interact with SS7 to
direct
traffic to an ASP when an AS first becomes active.  Where else is it to get
the traffic that was previously suppressed?
[TOLGA]Of course SG needs to interact with SS7 network. My point is the
corresponding sentence is about directing traffic to ASP. For example
should it be considered as an intervention to the SG/SS7 relationship that
SG shouldn't divert traffic unless there is one ACTIVE ASP for non n+k
case? I don't think so.

Also, the SG could take immediate action to direct traffic that will not
appear for some time depending on the RK the AS is configured for.  For
example, ISUP will only test remote user part availability periodically.
The SG could direct traffic immediately and the traffic could show up
several
minutes later.
[TOLGA]Yes. But so what?

It is even impossible to talk about the traffic that the SG is "directing"
without giving consideration to SS7 users involved.  The only way the SG
can "direct" any SS7 traffic in this situation is by taking actions within
the scope of SS7 and outside the scope of M3UA.

You cannot say SHOULD.

Leave the RFC as it stands.

> that for non n+k case SGP should not direct traffic unless there is one
> ACTIVE ASP? And as I said, opening the path unidirectionally is not the
> best choice in my opinion and should be avoided.

I already explained to you: there is no "unidirectional path".  This
is not a switch that you turn on an the current flows.
[TOLGA]If SG can send traffic to ASP but ASP can't send to SG, I consider
this as an unidirectional path.

--brian

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 07:24:42 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Wed, 26 Feb 2003 16:00:29)
> The SG could direct traffic immediately and the traffic could show up

A requirement cannot be placed on the SG that is not visible to the ASP
because it is not a requirement for interoperability.  The ASP cannot
tell when the SG directs traffic, so it cannot care.

> this as an unidirectional path.

But the SG is not sending anything; it is only establishing the capability
to send traffic some time in the future after SS7 decides to actually send
something.  If the stimulus is from the ASP, this won't be until the ASP
sends something first.  Also, if the stimulus is from SS7, the ASP is still
under no obligation to process any DATA message received while it is waiting
for n ASPs to start.

What horrible things do you think would happen anyway?

--brian