Subject: [Sigtran] Sigtran Plugtest - DAY 2-5

From: Ken Morneault <[email-masked]>
Date: Fri, 05 Sep 2003 05:54:14 -0400

Below are the issues and comments raised during days 2-5
of testing at the Plugtest.

IUA
------

1)  If RFCbis, the Reason and Traffic Mode fields were removed
from ASP Down and ASP Inactive respectively.  Need to add a
sentence to the RFCbis document to indicate that a bis 
implementation should not send "Unexpected Parameter"
for these two cases.  Other

M2UA
---------

1)  The text regarding the "Invalid Interface Identifier" in Section
3.3.3.1 should also indicate that an ASP that receives an 
invalid interface id should send an Error message.

M2PA
---------

1)  In Section 3.1.8.1 of the test spec, does the receipt of 
Processor Outage indicate Ready?

2)  Need to clarify what the value of FSN/BSN should be
during the alignment procedure.  Should the value be 
validated or ignored?

3)  When PO ends, the spec indicates that FSN/BSN must
be sent.  Is there a reason?

SUA
-------

1)  It is recommended that the following sentence be removed from
Section 3.2.1:

Sequence Control is set to 0 for class 0 messages.

Refer to the C-bit described in Q.713, Section 3.17.

2)  Since segmentation of a message may occur in the network, it
is suggested that a spare bit in the first/remain field be used to 
allow the node doing the segmentation store the original protocol class
value so that it can be restored by the node that does reassembly.

3) The GTI value (Section 3.10.2.3) is based on Q.713.  Need to indicate
that ANSI value 1 maps to ITU value 3.  SG's need to account for this
difference between ANSI and ITU.

4) In the Address Indicator description (Section 3.10.2.2), an example
is given regarding the usage of bit 2, value 0.  The example indicates
the DPC should be populated in the Routing Label but not in the
SCCP called party address.  Should this text also apply to the
OPC?

M3UA
---------

1)  Need to draw a picture - will send out later.

2)  Question - is the AS state maintained per SGP or SG.  Vivek
has several subquestions regarding this - I'll ask him to submit
them as follow up.

3)  How to handle NIF Unavailable was removed from IGv05.  There is
a suggestion that we specify how to handle this situation in the IG.

4)  It has been agreed that the AS state be sent in a Notify message 
when an ASP transfers to ASP-INACTIVE (assuming the SG knows which
AS(es) the ASP is configured for).  However, the Status Type "AS State
Change" seems inappropriate.  Suggest a new Status Type.

5)  Why does Network Appearance have to be the first parameter
in the Data message.

6)  Clarify text as to when Notify (ASP Failure) must be sent.  Is
is upon failure (SCTP assoc fails) or any transition to ASP-DOWN state.

7)  Should an Error (Invalid Version) be sent for any message with
invalid version.  Currently, the text indicates it is only sent for
an invalid version in ASP Up message.  Should add text to Section
3.8.1.

8)  In IPSP SE, should the ASP receiving ASP Up/Active Ack
also send Notify messages?  General though is that it should.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Sep 2003 04:24:35 -0600

Ken,

Ken Morneault wrote:                              (Fri, 05 Sep 2003 05:54:14)
[snip]
> Processor Outage indicate Ready?

It indicates that SP A has entered the Aligned-Not-Ready state
per Q.703.  Ready would indicate entering the Aligned-Ready state
of Q.703.

> during the alignment procedure.  Should the value be 

They are not ignored for Q.703.  Q.703 procedures apply where M2PA
has not explicitly modified them.

> be sent.  Is there a reason?

Resynchronization of sequence numbers.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Sep 2003 04:44:27 -0600

Ken,

[snip]
> Sequence Control is set to 0 for class 0 messages.

Why?

> value so that it can be restored by the node that does reassembly.

SUA messages are not segmented.  The segmentation field is only to support
delivery of segmented messages to an ASP from the SS7 network.  Each SUA
CLDT message has a MANDATORY protocol class field.

SCCP needs this C-bit, because it needs to send the segments of a protocol
class 0 (unsequenced) message using protocol class 1 (seqeunced) anyway.
When an SG delivers such a segemented message to an SUA ASP, it places the
original protocol class in the Protocol Class parameter of the CLDT.  Of
course it might be good to send segmeneted messages ordered on the association
between the SG and ASP (SCTP's equivalent of class 1).

There is no need for a C-bit in the Last/Remain field in SUA.

Actually, in discussion it was quetionable whether a) and SG would ever
deliver segmented messages to an ASP, and b) whether any ASP would support it
anyway.

> difference between ANSI and ITU.

The document does not need to indicate what ANSI value maps to what ITU value.
That is a matter for ANSI and ITU.

If you start that you will have to map 97 national protocol variants onto SUA
in the document.  Stating SUA in terms of the International standard only
remains the best course.

> SCCP called party address.  Should this text also apply to the

No.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Sep 2003 05:02:00 -0600

Ken,

[snip]
> has several subquestions regarding this - I'll ask him to submit

Per SGP.  This was agreed long time ago.

> a suggestion that we specify how to handle this situation in the IG.

We agreed to remove it.

> Change" seems inappropriate.  Suggest a new Status Type.

Excellent suggestion.  How about "State Indication" ?  What about failed ASPs?
Does an SG inform newly INACTIVE ASPs in an AS about ASP failures that occured
before it became inactive (and which are still failed)?

> 5)  Why does Network Appearance have to be the first parameter

Because when used it determines the context of all the others.

> is upon failure (SCTP assoc fails) or any transition to ASP-DOWN state.

Only on failure.  If an ASP sends and ASP Down message, it is not considered
failed.  It is considered withdrawn.  Remember that ASP Failure was intended
to allow ASP1 to distinguish between these two situations:

     ________                      ________ 
    |        |                    |        |
    |        |           Failure  |        |
    |  ASP1  |-------X   X--------|  ASP2  |
    |        |                    |        |
    |________|                    |________|
        |                              |    
        |                              |    
        |___________        ___________|    
                    |      |                
                    |      |                
                    |______|                
                   |        |               
                   |        |               
                   |  SGP1  |               
                   |        |               
                   |________|               

     ________                      X_X_X_X_ 
    |        |                    X        X
    |        |                    X        X
    |  ASP1  |-------X   X--------X  ASP2  X
    |        |                    X        X
    |________|            Failure X_X_X_X_XX
        |                              |    
        | <----ASP Failure             |    
        |___________        ___X    X__|    
                    |      |                
                    |      |                
                    |______|                
                   |        |               
                   |        |               
                   |  SGP1  |               
                   |        |               
                   |________|               

If SGP1 sends ASP Failure when ASP2 sends ASP Down in the top diagram, it will
defeat the purpose of distingushing the two scenarios.  ASP Failure is only
sent when (from the SGP's view) the ASP has failed.  Informing ASP1 of this
permits it to determine whether ASP2 has failed utterly or whether it has just
lost communication to it.

> an invalid version in ASP Up message.  Should add text to Section

That's right.  Only for ASP Up.  ASPs are not expected to really need to
spontaneously change versions in the middle of transmissions.

> also send Notify messages?  General though is that it should.

No, the IPSP sending ASP Up/Active Ack sends Notify.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 5 Sep 2003 08:54:34 -0400

Brian,
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brian F. G. Bidulock
> Sent: Friday, September 05, 2003 7:02 AM
> To: Ken Morneault
> Cc: [email-masked]
> Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5
>
>
> Ken,
>
> Ken Morneault wrote:
[TOLGA] Yes.
> > a suggestion that we specify how to handle this situation in the IG.
[TOLGA] Yes, and I don't see the reason why we need to define the behavior
for a failure case, which is very much implementation dependent and outside
of M3UA stack itself.
> Because when used it determines the context of all the others.
[TOLGA]In fact once we discussed, whether RC should be also the first
parameter is a message or not. I would think, we should follow a consistent
approach there, both for NA and RC.

[..snip..]
> No, the IPSP sending ASP Up/Active Ack sends Notify.
[TOLGA] My initial opinion is that it should be sent in both directions,
because semantically sending ASPAC/receiving ASPAC-ACK and receiving
ASPAC/sending ASPAC-ACK are the same from IPSP-SE point of view.