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

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 28 Feb 2002 11:12:00 -0800

Folks,

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

BTW, on the RC vs. NA item the draft states that 
sending NA is not required in the context of a
single network, although it may be configured to
be present "for the use of the receiver".  If the
receiver is not expecting NA, I would think ideally
it should be ignored.

We could have left NA as mandatory (at one point
there was a proposal to make both NA/RC mandatory, but
we could not reach consensus on this.)  As optional,
one side can always include NA and the other side 
must be capable of handling this.

Cheers,

Lyndon

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 1:45 AM
To: [email-masked]
Subject: [Sigtran] M3UA plugtest - Day 3 summary

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 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.

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.

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.

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.

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?

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

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

---

From: "Schantz, John" <[email-masked]>
Date: Thu, 28 Feb 2002 16:53:40 -0600

-----Original Message-----
From: Schantz, John 
Sent: Thursday, February 28, 2002 9:29 AM
To: 'Ken Morneault'
Subject: RE: [Sigtran] M3UA plugtest - Day 3 summary

Comments below.  John

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 3:45 AM
To: [email-masked]
Subject: [Sigtran] M3UA plugtest - Day 3 summary

1)  Audit (DAUD)

 Examples:

         ASP                                    SG

         ASP                                    SG

         ASP                                    SG

         ASP                                    SG

[jls]  The usual understanding in most (all) telecom standards is that
if a parameter is not needed for handling a message by the receiver, it
is NOT processed! it is ignored!  I assume that multiple networks are
not involved so there is no need for an NA to be defined.  I think it is
OK to send a "blank" NA.  BUT in this scenario, the node receiving the
messages with NA should be ignoring this parameter since it not
currently needed for handling the message.  PS.  The same is true with
RC.  If a receiving node does not need the RC for handling a message, it
can ignore it&;)