Subject: RE: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Fri, 14 Oct 2005 08:33:18 -0400

Brian,

That's your definition.  The RFC says otherwise.

An ASP can congest according to the RFC and according to practical
matters in networks.  We need a mechanism to support ASP congestion.
The RFC has specified one.  A minor change to the RFC allows the cases
that the current RFC has not covered.

And it has no impact on existing SGs since the handling of an SCON is
optional.  

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, October 14, 2005 8:28 AM
To: Haresign Lincoln
Cc: Valerie Gastaud; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Lincoln,

The congestion level only applies to a single point code.  SCCP
maintains a independent congestion level for each point code.

--brian

Haresign Lincoln wrote:                        (Fri, 14 Oct 2005
08:19:02)
> Valerie,
> 
> I think this is a good solution.  Using the RC also addresses the 
> scenario of the ASP supporting multiple point codes (not something 
> that we do, but the RFC supports it).  Since the current SCON message 
> doesn't indicate that multiple point codes can be specified in the 
> SCON, the RC parameter would handle this scenario also.
> 
> Regards,
> Lincoln
> 

--
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: Fri, 14 Oct 2005 06:35:59 -0600

Lincoln,

The RFC does not say otherwise:

3.10.24.  Congestion Level

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0118          |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Congestion Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Congestion Level field: 8-bits (unsigned integer)

   The Congestion Level field contains the level at which congestion has
   occurred.

   When the Congestion Level parameter is included in a SCON message
   that corresponds to an N-PCSTATE primitive, the Congestion Level
   field indicates the MTP congestion level experienced by the local or
   affected signalling point as indicated by the Affected Point Code(s)
   also in the SCON message.  In this case, valid values for the
   Congestion Level field are as follows:

      0  No Congestion or Undefined
      1  Congestion Level 1
      2  Congestion Level 2
      3  Congestion Level 3

   When the Congestion Level parameter is included in a SCON message
   that corresponds to an N-STATE primitive, the Congestion Level field
   indicates the SCCP restricted importance level experienced by the
   local or affected subsystem as indicated by the Affected Point Code
   and Subsystem Number also in the SCON message. In this case, valid
   values for the Congestion Level field range from 0 to 7, where 0
   indicates the least congested and 7 indicates the most congested
   subsystem.

--brian

Haresign Lincoln wrote:                     (Fri, 14 Oct 2005 08:33:18)

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