Subject: [SUA issue 14] SG Relay Problems

From: [email-masked]
Date: Tue, 14 Aug 2001 09:46:31 +0300

-----Original Message-----
From: ext Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 06 August, 2001 22:59
To: Loughney John (NRC/Helsinki); Lyndon Ong
Subject: Fwd: SUA6: SG Relay Problems

Attached is an SUA Last Call issue:

Changes and additions required for decoupled operation.

--brian

From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: SUA6: SG Relay Problems
Date: Fri, 29 Jun 2001 13:19:24 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
List-Unsubscribe: <mailto:[email-masked]>
Content-Type: text/plain

Hi all,

Let's wrap some things up for the SG :

1. Reassembly of XUDT at SG : I think everyone agrees on that now. To deal
with link/routeset failures, can everyone agree on following procedure ?

"If a SG is operated in mated pair configuration, and it receives a
non-first XUDT segment for which no reassembly process exists, it should
pass on this segment to it's mate; if the segment was already received from
the mated SG or if no mated SG is available, the return on error procedures
must be invoked."

2. Coupling of connection sections at SG : let's see if we can reach a
compromise ...

The CR message can contain information (e.g. GT, SSN) based on which an
AS/ASP is selected. This information is no longer present in subsequent CO
messages. Therefor, in order to provide seemless SS7 - IP interworking,
coupling of connection sections is required in the SG when :

- the SG acts as SEP : in this case SUA is used to provide the interface
between SCCP on the SG and the SCCP-user on the ASP.

- the SG acts as STP, and the AS/ASP cannot be derived from the received
SCCP-CO message, or the SEP cannot be derived from the received SUA-CO
message.

To avoid coupling, we need SS7 address info (at least a PC) in all SUA-CO
messages (CODT etc.) ! If we want coupling of connection sections optional
at the SG, we need to update the SUA-CO messages in this respect.

BTW: are we going to work with routing contexts instead of network
appearance now in each SUA-CL and CO message ? If so, this could be used for
mapping to a SEP in case of "no coupling" at the SG. To me this sounds like
a good idea for 2 reasons :

- the network appearance parameter definition is still rather shaky
- the routing context could well provide the same (and more) functionality

3. SCON : yes, there are multiple congestion levels (0 -> 7)

4. Concerning DRST : let's see if I get it straight ... this is to signal to
concerned/neighbouring nodes that a SG/SUA-relay node from a mated pair has
lost connectivity to a SEP/SUA-end node and routing should preferably
continue over the other mate. The other mate will receive a DUNA instead of
a DRST, and when he loses connectivity to the same endpoint as well, both
SGs will send DUNA to their neighbours.

Since SGs can consist of several SGPs (and would be modelled as such in the
ASP to guard SCTP connectivity), the SSNM messages (DUNA, DAVA, SCON, DRST),
when received from any of these SGPs, should be regarded as valid for the
entire SG.

Regards,

____________________________

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

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

------_=_NextPart_000_01C12488.F48721A7--

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