Subject: Re: [Sigtran] M3UA plugtest - Day 3 summary

From: Ken Morneault <[email-masked]>
Date: Sat, 02 Mar 2002 05:16:04 -0500

Pls see below.

Ken

At 12:05 PM 2/28/2002 -0600, Brian F. G. Bidulock wrote:
>Ken,
>
>Please see comments below...
>
>Ken Morneault wrote:                                          (Thu, 28 Feb 2002 04:44:54)
>> 
>> 
>> Here are the issues raised on Day 3 of the plugtest:
>> 
>> 
>> 1)  Audit (DAUD)
>> 
>> There is a weak point in the current Audit procedure (Section
>> 4.5.3) in regards to congestion state.  The SCON is only
>> sent if the SS7 destination is congested.  
>
>The spec doesn't say this.  It says that the SCON MUST be
>sent when an SS7 destination is congested and the SG maintains
>congestion states.  If the destination is not congested
>(or unknown) it can do what it wants.  An implementation
>can always send SCON(0) if it wants.

Well, that's the point.  There is interest in specifying what 
the SG should do in the not congested/unknown cases.
The preference of the plugtest participants is shown in the
flows below.

>> 
>> The SG maintains the congested state:  Congested/-
>> Uncongested/Unknown (ITU International only) and the
>> available state: DRST/DUNA/DAVA state.  When the
>> Audit occurs, the SG should send both pieces of
>> state information.
>> 
>>  Examples:
>> 
>>      SG state:  Uncongested/Available
>> 
>>          ASP                                    SG
>>                  --------- DAUD --------------->
>>                  <------- SCON (0) -----------
>>                  <------- DAVA-----------------
>> 
>>      SG state:  Congested (2) /Available
>> 
>>          ASP                                    SG
>>                  --------- DAUD --------------->
>>                  <------- SCON (2) -----------
>>                  <------- DAVA-----------------
>> 
>>      SG state:  Unknown (ITU International network) /Available
>> 
>>          ASP                                    SG
>>                  --------- DAUD --------------->
>>                  <------- DAVA-----------------
>> 
>>      SG state:  Uncongested/Unvailable
>> 
>>          ASP                                    SG
>>                  --------- DAUD --------------->
>>                  <------- DUNA-----------------
>> 
>> 
>> 2)  Length of Routing Key Parameter in Registration Message
>> 
>> The length of the Routing Key parameter should include all
>> bytes of the subparameters (even padding bytes in subparameters)
>> that it contains.
>
>I concur.
>
>> 
>> 3)  Dynamic Registration not supported
>> 
>> RIght now the text indicates the SG should return Error (unsupported
>> message type).  Prefer to have a specific error code indicating
>> dynamic registration not supported.
>
>It seems a minor thing at this point.

Yes, something that could easily be handled in an implementation
guide.  

First, it seems more logical to return "Error - Unsupported Msg Class".
Second, a note could be added that under "Error -Unsup Msg Class"
and "Error - Unsup Msg Type" that the received message header
MUST be put into the Diag field.

>> 
>> 4)  SCON for International ITU
>> 
>> Clarifications among the participants that for International
>> ITU the SCON will be sent without a Congestion Indication
>> Parameter because a congestion level is not available.
>
>We went to great lengths in the WG to keep protocol dependencies
>out of the M3UA layer.  How is an M3UA implementation to know
>when a Cong Ind must by sytactically included in the message
>when it does not know what protocol variant it is transporting?
>
>If Cong Ind become and optional parameter, when it is missing
>it need to describe ASNI Level 0 for ANSI so that the imp does
>not need to know the protocol variant when syntax checking the
>received message.  The draft chose to go the other way: make
>the Cong Ind parameter mandatory and set it to 0 for ITU, rather
>than make it optional and have it indicate level 0 when missing.

I don't see this in the draft.  The draft states the Cong Ind parameter
is optional and would not be included for ITU - International.

>I see no need to reverse this now.  Perhaps the Imp Guide could
>mention that an implementation might want to treat a missing
>Cong Ind as Cong Ind = 0 rather than rejecting the message, but
>Cong Ind is a mandatory parameter and must be sent in the
>message.

I'm not against Cong Ind being mandatory (again, currently
it is optional).  Just need to specify ITU-International treatment.

>> 
>> 5)  Statement in SCON text should be clarified
>> 
>> Section 3.4.4 states the SG can send SCON in response
>> to a DATA or DAUD "as appropriate".  There should be
>> a reference to what "as appropriate" means.  In the
>> case of DAUD, the reference would be Section 4.5.3.
>> In the case of DATA, the reference would be MTP
>> specs.
>
>We changed this to "as appropriate" because it is the NIF that
>determines when SCON is sent in reponse to DATA or DAUD.
>The NIF is not specified in M3UA.  In the case of DAUD, the
>SG NIF might not (or might) maintain congestion states.
>The same is true for DATA.  An MTP reference would be of little
>use because the handling of congestion indication between the
>MTP-User and MTP are rather different depending on the variant.
>Also, there was much dicussion about sending SCON in repsonse
>to SCTP congestion as well as nodal congestion.  In short
>SCON is necessary for interworking with the SS7 network and
>the M3UA draft does not specify that interworking.
>
>That's what "as approapriate" means.
>
>> 
>> 6)  RC and NA in DATA msg can be misleading.
>> 
>> This issue was brought up because of a scenario with
>> no NA defined.  One implementation was sending 
>> DATA messages with RC and NA (even though
>> NA was undefined).  The other implementation
>> was throwing away the DATA messages because
>> NA was invalid.  However, the rest of the DATA
>> message including the RC was valid.  Should
>> "semi-mandatory" RC have priority over NA?
>
>I mentioned the possibiltiy of this conflict during the
>RC/NA dicussions and Lydon an some others were of the
>belief that such a conflict couldn't occur. :)
>
>RC should not take priority over NA in this case.  The
>message is simply invalid.

Since it is an optional parameter, it would make more sense
for NA to be ignored (since its optional) if the receiver does
not support NA or does not have NA configured.

>--brian
>
>
>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/sigtran
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/ 

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

---

From: [email-masked]
Date: Thu, 7 Mar 2002 18:00:35 +0200

Hi Lydon,

> Any volunteers to draft up an "implementor's guide"
> for M3UA?  Seems like there are some good notes to
> catch here.

I'm not volunteering ... but also I think we should
try to catch some info (which may be general to all
UAs) into a comment document.

John