Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5 / SUA

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Sep 2003 08:26:34 -0600

Anzile,,

Anzile, Christophe wrote:                                                          (Fri, 05 Sep 2003 14:37:05)
> Brian,
> 
> about 1)
> it's fine to say so for CLDT going from ASP to SGP.
> 
> but in the other way (SGP to ASP), it's just because most SGs (implementing draft-14) 
> do fill this value with the SLS whatever it is class 0 or 1,
> and an ASP based on draft 15 that check this value will send back an error
> [that's actually what happened during the plugtests].

Well, the ASP should follow the principle: be strict in what you send
and forgiving in what you receive.  To do otherwise is asking for
interoperability problems.

I disagreed with the change in SUA-15 because some SUA relay points might wish
to use this value for renegerating load-sharing regardless of protocol class,
but I agree that the receceiver of the Protocol Class 0 message cannot rely on
the distribution of this number and saying that it is set to 0 kinda cancels
that reliance.

I would prefer to have the value populated with SLS SG->ASP, and potentially
ignored for PC 0  ASP->SG and IPSP->IPSP.

Mind you, I brought up about 20 other issues with SUA-15 that haven't been
address yet either...

> 
> I would prefer if this parameter would become mandatory to class 1,2,3 messages
> and optional to class 0 message instead of saying that it is set to 0.

No, no, no.  We agreed to have it mandatory for all protocol classes.  You
cannot change that now.

> (what's the point of sending a parameter that should always be 0 anyway?)

No, it cannot be set to 0.  Responsibility for load-sharing of SLS values is
a responsibility of SCCP to MTP.  When SUA is used as a SUAP in a relay node,
it has the obligations of SCCP to MTP and must set the loadsharing value for
all messages regardless of protocol class.  That is why it was mandatory.

--brian

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

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

---

From: "Anzile, Christophe" <[email-masked]>
Date: Fri, 5 Sep 2003 14:37:05 +0200

Brian,

about 1)

Christophe.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, September 05, 2003 12:44 PM
To: Ken Morneault
Cc: [email-masked]
Subject: Re: [Sigtran] Sigtran Plugtest - DAY 2-5

Ken,

Ken Morneault wrote:                                                                   (Fri, 05 Sep 2003 05:54:14)

[snip]
> 
> 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.

Why?

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

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.

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

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.

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

No.

--brian

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