Subject: RE: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 13 Oct 2005 14:03:03 -0400

Brian,

What the SG does is implementation dependent.  I'm not sure we should
specify it in the requirement.  Today, the RFC says:

   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
   SUA peer with an SCON message.  When an SG receives a congestion
   message (SCON) from an ASP, and the SG determines that an endpoint is
   now encountering congestion, it MAY trigger congestion procedures of
   the relevant SCCP standard. 

Note the MAY.  In our implementation, we also take actions such as
diverting traffic to non congested ASPs.  But in any case, the RFC
ALLOWS the SCON from ASP to SG.  What the SG wants to do with it is up
the the SG.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 2:00 PM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Haresign,

Haresign Lincoln wrote:
(Thu, 13 Oct 2005 13:52:01)
> Brian,
> 
> There are some applications that do not need to process an N-PCSTATE 
> indication and they will work perfectly fine in the networks.  We are 
> experiencing no problems at all.  If you really want me to give you a 
> real example of an application that works without PCs, I can.

But this is the very indication that you are attempting to generate by
sending SCON from an ASP to an SG.  You are going to ignore it at the
other end.

> 
> Again, I'm am NOT trying to demand that anyone generates an N-PCSTATE 
> message.  I'm trying to use the SCON as described in the RFC today.  I

> want to indicate CONGESTION at an ASP (as described in the RFC).

And the SG will what?  Generate an N-PCSTATE at the remote that you
ignore.

--brian

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

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Oct 2005 17:08:46 -0600

Lincoln,

Haresign Lincoln wrote:                                                           (Thu, 13 Oct 2005 14:03:03)
>    the relevant SCCP standard. 

I am familiar with the passage, I was largely responsible for it
being included in SUA, I wrote the text for M3UA, and was
responsible for the MAY.

Again, we put "MAY trigger" because the congestion procedures of
different National SCCP standards differ.  We put "MAY indicate"
because it is easy to design an SG that does not need the indication
to properly effect SCCP congestion procedures.

If you are implementing for 3GPP, ETSI TS 102 143 is applicable and
says:

 "When an SG receives a congestion message (SCON) from an ASP, and
 the SG determines that an endpoint is now encountering congestion,
 it shall trigger congestion procedures as per ITU-T Recommendation
 Q.714[4]."

No MAY.  But that is fine because ETSI TS 102 143 also restricts the
relevant SCCP protocol to the ETSI modified versions that support
SCCP congestion (but not subsystem congestion).  ETSI TS 102 143
also nicely affirms the intended use of SCON from ASP to SG.

> ALLOWS the SCON from ASP to SG.  What the SG wants to do with it is up

Well, no, not if you are deploying 3GPP in accordance with ETSI
specifications: then, the SG's actions appear to be dictated by
ETSI TS 102 143.

As the ETSI document follows more formal standards body approaches,
I don't belive that it allows an SUA SG in the 3GPP network to do
whatever it wants with the message, unless of course the
implementation is completely internal to an operator's network (in
which case they can do as they please anyway) or there exists a
bilateral agreement to that effect between adminstrative domains
(operators).

--brian

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