Subject: RE: [Sigtran] Sigtran Plugtest - DAY 2-5, SUA

From: Niels Koot <[email-masked]>
Date: Wed, 24 Sep 2003 18:35:23 +0200

Brian,

A response on 2), 3) and 4) inserted

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

Draft 15 does not limit segmentation from SGP to ASP only (section 4.7.1)

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

So SUA messages that carry a segment should carry the protocol class of the
complete message, and not the protocol class of the segment as received from
SCCP. I agree that would make the C bit obsolete. This SGP behaviour is
however not clear to me from draft 15, so I think it should be clearified.

I think however that using the same mechanism as SCCP in SUA (i.e. keep the
protocol class of the segment and use the C bit) makes SUA implementations
easier. In that case, only the protocol class determines whether the message
should be sent ordered and whether the "in-sequence-delivery requirement"
for loadsharing applies (section 4.7.2). In your scenario also the
segmentation parameter needs to be taken into account.
 
> 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.

Well, there are SGs that do deliver segmented messages to an ASP and
therefore an ASP combined with this SG needs to support 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.
> 
> 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.
>

Ok, you could put it more general:

Any national GTI value should be mapped to the (best matching) ITU
equivalent.

Point is that ANSI value 1 mapping to ITU value 3 is not done by every SG,
some leave it as 1. So not everybody interprets Draft 15 the same on this
point, in itself enough reason to clearify in my opinion.
 
> > 
> > 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.

Why shouldn't this apply for OPC/CgPA also? The DPC/CdPA is just an example
in draft 15.

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

Niels.

Niels Koot
Consultant / SMSC Development
_________________________________________ 

LogicaCMG

Merweplein 5
3432 GN  Nieuwegein
P.O. Box 261
3430 AG Nieuwegein
The Netherlands
T: +31 (0) 30 210 3333
F: +31 (0) 30 210 3352
E: [email-masked]
www.logicacmg.com

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

---

From: "Yongbing Zhu" <[email-masked]>
Date: Thu, 25 Sep 2003 17:45:46 -0700

Hi!
In RFC 3331,4.2.1 we have the following statement:

All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with
   sequenced delivery to ensure ordering.  All MGMT messages, with the
   exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on
   SCTP stream '0'.  All ASPTM messages SHOULD be sent on the stream
   which normally carries the data traffic to which the message applies.
   BEAT and BEAT Ack messages MAY be sent using out-of-order delivery,
   and MAY be sent on any stream.

For the BEAT and BEAT Ack, does the "any stream" statement include stream
"0"? or any stream other than stream "0"?

Thanks
Yongbing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Sep 2003 18:55:48 -0600

Yongbing,

Yongbing Zhu wrote:                                                               (Thu, 25 Sep 2003 17:45:46)
> "0"? or any stream other than stream "0"?

any includes "0".

--brian

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