Subject: RE: SUA version 5

From: Verwimp Gery <[email-masked]>
Date: Thu, 5 Apr 2001 16:59:26 +0200

Hello John,

(Hope this time the sigtran list accepts it)
Here are some proposals to deal with the SUA issues that have come up. BTW,
can we get a sneak-preview version of the draft and organize a conference
call to nail any missing items ?

Here it goes: 

1. Definition of Network Appearance.

Norm came up with one (see mailing list), and I also ventured a possibility
:

"An SS7 domain where the SG is known as a single entity (single signalling
point code) by SS7 management."

2. Use of source and destination reference numbers in the SG (section 1.3.2)
: see attachment (changebars).

3. Loadsharing and allocation of TCAP messages.

Section 1.3.1.1 must be changed, because "unambiguous ASP address" doesn't
work : this supposes assigning a GT to every ASP, and further routing based
on GT in the SS7 network. This would not work in the US, since only TC_Query
messages are routed on GT there ... see attachment.

4. SCCP Management :

- removal of SSNM - SCMG (and DUPU)
- extension of DUNA, DAVA, SCON messages with an SSN parameter TLV to
indicate status of subsystems.

Procedures :

SCCP management procedures are terminated/initiated on the SG as per the
ITU-T Q.714 recommendations. Point code or subsystem status indications are
offered to the ASPs via DAVA, DUNA or SCON messages in the following cases :

- to the ASP which requests this information with a DAUD message,
- to all ASPs in an AS which is marked as "concerned" at the SG for the
specific PCs or SSNs.

SUA and ASP management procedures are terminated/initiated on the SG as per
this document. However, when an AS is marked as serving all traffic for a
specified SSN in one of the SG's network appearances, SCCP management at the
SG will be triggered to initiate local and remote broadcast of subsystem
(un)availability to the concerned SS7 destinations.

5. SUA connection fail-over :

No corresponding requirement exists for the SCCP (yet). To support this,
probably the functionality of protocol class 3 is required (acknowledged
CODT transport) in order to changeover to a new ASP (and SCTP association).

6. Some issues regarding when a PC is mandatory or optional :

section 3.3.2 (3.9.2 in your document) : see changebars

Hope this fills up some gaps in the SUA draft ...

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 6 maart 2001 20:58
To: [email-masked]
Subject: SUA version 5

Hi all,

I've submittend a new version of SUA to the IETF editor.  It should 
be in a mailbox near you soon.

The major changes:
1)	Some assumptions in 1.3.x about what is needed for an SUA relay
	function.
2)	DUPU message removed (duplicated with SCMG message)
3)	Section 3.9.2.3 Global Title parameter cleaned-up.
4)	Section 3.9.2.7 Hostname parameter cleaned-up.
5)	Section 5.x Examples cleaned-up (somewhat)
6)	Message Routing Scenarios section deleted (redundant with 
	expanded section 1.3.x)

To do:
1)	Align with current M3UA
2)	Do we handle routing keys?
3)	Editorial cleanup.

With any luck, all the major issues have been dealt with.  I hope
to re-issue this draft after the Minneapolis meeting & then it 
should be ready for last call.

thanks,
John

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