Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: Tolga Asveren <[email-masked]>
Date: Thu, 7 Nov 2002 15:50:45 -0500

Brian,
> > [TOLGA]Why it is "foolish"? For example in the example I 
> gave, which problem
> > cases would happen?
> 
> Because it is foolish.  Again, thrashing between ASPs and 
> resulting message
> missequencing and loss will likely result.
[TOLGA] This might be a problem, unless other procedures are followed. For
example like procedures one needs to follow to prevent missequencing, when a
new ASP goes ACTIVE for an AS. But I agree, congestion status for a
particular ASP might chnage more dynamically.
> 
> > > 
> > > The situation you describe is analogous to signalling 
> links in a link set.
> > [TOLGA] No, IMO it is similar to a case, where one 
> distributes its user
> > parts.
> 
> MTP does not distribut to user entities based on SLS.  MTP 
> distributes over
> signalling links in a link set based on SLS.  SGs distribute 
> to loadshared
> ASPs based on SLS.  The situation is analogous to signalling 
> links in a link
> set.
[TOLGA] IMO it isn't. That loadsharing is based on SLS does not mean that it
is the same like loadsharing between links. If one has distributed user
parts (for regular SS7 case), one can also loadshare between them based on
SLS. This is implementation dependent.
> 
> 
> > > The "nodal" TFC procedures that SCON was intended to 
> parallel do not
> > > permit transfer-restricted or change in routing 
> procedures as a result of
> > > "nodal" TFC when routing to a SEP.
> > [TOLGA] IMO the procedures you are referring to define the 
> relationship
> > between SPMCs and nodes in TDM domain and between SPMCs 
> themselves, not the
> > relationship between SGs and ASPs. 
> 
> But SCON is related to the SPMC, and not the AS.  Therefore, 
> SCON only has
> application in the scope of the SPMC and in terns of SS7 
> network management.
> That is, it is not an "ASP congested" indication, it is a 
> "signalling point"
> congested indication.  Therefore, it has no applicability in 
> the SG/ASP domain
[TOLGA] I agree for this.
> and (even if it weren't foolish) one should not alter ASP 
> loadsharing as a
> result of receiving one.
[TOLGA]How can ASP decide, what is the congestion status of the SPMC? It
can't, so it shouldn't reply with SCON to an incoming message. 
So, are you proposing not to handle ASP congestion at all? Otherwise, how
can SG decide for the congestion level of the SPMC, if ASPs don't inform SGs
about it? 
In any case (having congestion indication from ASP to SG or not to have such
an indication to prevent message missequencing etc...) SCON from ASP to SG
as described currently in RFC (as a response to an incoming message)is not
appropriate.(I think you agree with this)
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Nov 2002 14:01:22 -0700

Tolga,

Tolga Asveren wrote:                                                               (Thu, 07 Nov 2002 15:50:45)
> SLS. This is implementation dependent.

Not so.  Loadsharing based on SLS (or based on something upon which
SLS is derived such as CIC) is the only loadsharing that prevents
missequencing.  Any other basis introduces missequencing.  This is
identical to loadsharing in SS7 within a (combined) link set and
cannot be avoided by calling it "implementation dependent".

> can SG decide for the congestion level of the SPMC, if ASPs don't inform SGs

The ASP doesn't have to decide that the SPMC is congested.  This is 
the sole responsibility of the SG.  The ASP sends SCON to "inform" the
SG about a condition which may contribute to the SG's determination
of SPMC congestion.  That is why the ASP MAY respond with SCON.

> appropriate.(I think you agree with this)

As I said in a previous note, the ASP need only send SCON in response
to an incoming message.  There is no problemw with the RFC in this matter.

--brian

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