Subject: FW: SUA bakeoff report 5-9 November

From: [email-masked]
Date: Wed, 14 Nov 2001 09:04:27 +0200

Hi all,

I'd like to thank Lode and Gery for the hard work they put into 
this.  I was unable to attend due to schedule conflicts 
(the Nokia SUA team also ran into visa problems & were unable
to attend).

I will try to start some discussion on the results, but
all in all, things look very good.

best regards,
John

-----Original Message-----
From: ext Coene Lode [mailto:[email-masked]]
Sent: 13 November, 2001 13:00
Subject: SUA bakeoff report 5-9 November

John,

Here are the things we stumbled across during the week. 

(1) Sequence control parameter tag: should it be 0x0116 ? Yes

(2) CORE msg: should the sequence number be mandatory?
the sequence number is only needed for Class3 traffic, so it should be
optional.
the sequence control parameter should be mandatory in the CORE(valid for
class 2 and 3)

(3) Clearer definition of SGP and SG. Can be done via a example showing the
SG and the ASP. 

(4) 2 SGP and 2 ASP connecting to each other in SGP-ASP configuration.
Situation: Are trying to go active in override mode with the same ASP
identifier/routing context. The question is: What should happen? The same
question applies when using different ASP idenitifiers.

(5) Correleation ID: For what is it used??. It is supposed to be send from
SGP to ASP in broadcast mode. It is complex and confusing.
Suggestion: remove it from the draft. Who would want to use this stuff
anyway?

(6) It should be possible to receive SSNM messages in the ASP inactive
state.

(7) Routing context in the DUNA or DAVA:
- If there is a choice, send one msg for every routing context to every ASP
- Routing context shoudl be consistent between real data msg(CLDT, CORE,
CO-DATA ...)
and management msg(the rest). It should be mandatory in all msg or optional
in all msg, not the present situation where it is not present in some
management msg and present in data msg and the rest of management msg.
Suggestion: keep it optional for all msg

(8) How to fill in the routing context in the data msg. In simple cases ,
the Routing context is not used at all and should therefore only be
optional. (meaning you can use it if needed)
Warning: no consensus on this issue, therefore making it optional leaves all
possibilities wide open.

(9) Paragraph 3.9.18: affected pointcode section: 
Send multiple pointcodes -> update this section because it is currently not
possible in SUA to include multiple pointcode.

(10) Should GTI be included in the source and destination address when a
global title is used. 
Suggestion: the GTI must always be included when using Global Title

(11) paragraph 3.10.2 source address paragraph. The sentence is not clear.
it gives the impression that one might byte copy the address from the SCCP
CLG to the SUA source address.
Suggestion for a replacement sentence:
"The source address may conytain the elements of the SCCP calling party
address (see chapter ..) according to the SUA syntax of the different
elements."
Or strike the sentence.

(12)  can the routing context contain multiple values?
- Does not make sense in data msg
- Makes only sense in management msg. Should explicilty say that in the
spec.

(13) Response on a errornous ASP-UP msg.
Response should be a error msg, not a error managmenet blocking -> a
specific error code is not really necessary, it is more or less
implementation dependant.

(14) paragraph 4.3.4.5(line 5909)
Remove the ASP-STANDBY state from the text.

(15) Sequencing of data msgs during a changeover/changeback between
different associations. This is a problem for all User adaptation layers. 
Suggest that this must be handled in a seperate extension draft

I leave it up to you how to bring these issues up on the list.
Thanks for all the work, John.

I have also attached the SUA disector for ethereal, written by Michael
Tuxen.
The only nit we had was that the display for pointcodes was not correct.(but
we know how to read hex, so that wasn't a problem)
Other than that, It worked like a charm. 
Thank you very much for all the support, Michael.

I wish to thank everybody who attended the bakeoff and helped set it up.
Thanks and see you at the next bakeoff.

yours sincerly,
Lode

Siemens atea ICN D CS D
Software development
Atealaan 34
B-2200   Herentals    Belgium
Tel: +32-14-2-52081   Fax: +32-14-2-53212
E-mail: [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]