RE: Recommendation for SUA modifications

Brian,

On the big picture I agree with you that SSNM is meant to be used for SS7
network management, hence SCON is supposed to be used for SS7 congestion
procedures. OTOH, there is a need to notify congestion status of ASPs to SG
and right now it seems like we don't have a solution -actually till now the
supposed solution was relying on SCTP congestion but there are scenarios
where this is not enough/does not work well-. I believe something needs to
be done to address that issue.
a)Either a new ASPTM
b) or overloading SCON

    Thanks,
    Tolga

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Friday, October 14, 2005 9:10 AM
> To: Haresign Lincoln
> Cc: [email protected]; [email protected]; Valerie Gastaud;
> [email protected]
> Subject: Re: [Sigtran] Recommendation for SUA modifications
>
>
> Lincoln,
>
> Haresign Lincoln wrote:
>                 (Fri, 14 Oct 2005 08:48:46)
> > Brian,
> >
> > Are you saying that an ASP can not congest?  I'm not really sure where
> > you are going with this.  The RFC says the following:
> >
> >    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.
> >
> > If this is not true, let me know and we will need to amend the RFC and
> > find another way to handle ASP congestion.  My very first email that
> > started this thread asked the question of whether SCON was valid from
> > ASP to SG.  At the time, you indicated that this was valid. Are you now
> > saying it is valid, but only in limited scenarios?
>
> I tried a good number of times to tell you that SCON was for SCCP and
> Subsystem (N-STATE and N-PCSTATE) congestion only.  This is no different
> in the SG->ASP or ASP->SG directions.  When the ASP sends SCON it is
> indicating SCCP or SCCP Subsystem congestion to the SG depending upon
> whether it places SSN in the message or not.  When there is no SSN in
> the message, it corresponds to MTP congestion (precisely the same
> scenario in which M3UA sends SCON from ASP to SG).  When there is an
> SSN in the message, and SSN is 1, it indicates SCCP Congestion, when
> SSN is other than 1, it indicates SCCP Subsystem Congestion.
>
> >
> > If this is valid, then there are two scenarios that the RFC does not
> > handle:
> >
> > 1) ASP shares the same point code as the SG and is not aware of it's
> > point code.  Meaning the ASP may just be a global title.  Or there could
> > be multiple AS behind the SG with different subsystems but sharing the
> > same point code as the SG.
>
> It will try again: an ASP that is not aware of point codes has no business
> signalling MTP or SCCP congestion levels.  MTP congestion levels are
> maintained on a point code basis.  So are SCCP congestion levels (RIL).
> SCCP subsystem congestion (CL) is also maintained on a point code basis.
>
> If the ASP is unaware of point codes, why is it sending the messages?
>
> Also, in the trivial case where SG an ASP share a single point code, the
> SG with a fully functional SCCP layer is capable of providing all SCCP
> congestion management functions without assistance from the ASP.  It is
> more usable in the multiple SG as STP, and ASP as relay scenarios, where
> the ASP can send SCON independently to each SG.
>
> >
> > 2) ASP is multiple point codes.
> >
> > In the RFC, the handling of the SCON message by the SG is implementation
> > dependent.
>
> No, the handling of the SCON message is clear.  Whether the SG sends
> an SS7 message to the SS7 network is in accordance with the conformances
> that it must meet in that direction that are outside the scope of the SUA
> specification.  Because the SG MAY (in order to meet conformance) send an
> SS7 congestion message, a SCON sent from the ASP clearly MUST have the
> necessary information and be generated under the proper conditions.  The
> description of the message, and its mandatory contents, accomplish this.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>