Subject: RE: Text proposal for multiple SGs

From: Verwimp Gery <[email-masked]>
Date: Mon, 1 Oct 2001 11:55:10 +0200

John,

Will do. Is it ok if I send it by the end of the week ?

____________________________

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: maandag 1 oktober 2001 10:40
To: sigtran
Subject: SUA: Text proposal for multiple SGs

Hi all,

Here is Gery's proposal summarized.  I think that the text isn't completely
clear - Gery, could you fill out the text?

Thanks,
John

Effects on messages:
Optional in ASPAC

3.10.26 TID Label

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Tag = 0x010a         |            Length = 8         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     start     |      end      |         label value           |
   +---------------+---------------+---------------+---------------+

The Start parameter is the start position of label, between 0 (LSB) and 31
(MSB)´.

The End parameter is the  end position of label, between 0 (LSB) and 31
(MSB).

Label value is a 16 bit interger, which is unique across an AS.

3.10.27 DRN Label

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Tag = 0x010b         |            Length = 8         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     start     |      end      |         label value           |
   +---------------+---------------+---------------+---------------+

The Start parameter is the start position of label, between 0 (LSB) and 31
(MSB)´.

The End parameter is the  end position of label, between 0 (LSB) and 31
(MSB).

Label value is a 16 bit interger, which is unique across an AS.

Add to Procedure Text in chapter 4:

The SG can build up and update a distribution table for a certain Routing
Contexts, any time the association is established and/or the ASP goes
active. The SG has to performs some trivial plausibility checks:

- start, end between 0 and 31 (between 0 and 23 for DRN with decoupled
approach)
- 0 < (start - end + 1) <= 16 (label maximum 16-bit)
- start/end values are the same for each ASP which goes active for this RC
- TID resp. DRN label values must be different for each ASP

If any of these checks fail, the ASP cannot go active (neg ack with error
"invalid label"). It is clear from RC (CL, CO or both) which labels must be
present. If it is not required for the SG to perform distribution, no labels
are present in any ASPAC for this RC.

If an ASP is not available, the SG may generate (X)UDTS "routing failure",
if CL with return option is used. For CO, either IT or flow control
procedures are adequate; SG simply has to discard the message.

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

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

---

From: [email-masked]
Date: Mon, 1 Oct 2001 13:50:20 +0300

Gery,

> Will do. Is it ok if I send it by the end of the week ?

Wednesday is preferable, as I am going to send a version
of SUA to the draft editor on Friday, no matter what.

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 3 Oct 2001 10:12:49 +0200

John,

Here's the more complete procedure :

Preliminary :

Within an AS, identified by RK/RC parameters, several loadsharing ASPs may
be active. However, in order to assure the correct processing of TCAP
transactions or SCCP connections, the loadsharing scheme used at the SG must
make sure that messages continuing or ending the transactions/connections
arrive on the same ASP where the initial message (TC_Query, TC_Begin, CR)
was sent to/received from.

When the ASP can be identified uniquely based on RK parameters (e.g. unique
DPC or GT), loadsharing is not required. When the ASPs in the AS share state
or use an internal distribution mechanism, the SG must only take into
account the in-sequence-delivery requirement. If these assumptions cannot be
made, the following general procedure should be supported by both SG and ASP
in a loadsharing environment.

1. Association setup, ASP going active

After association setup and registration, the ASP normally goes active for
each AS it registered for. In the ASPAC message, the ASP includes a TID
and/or DRN label parameter, whichever is applicable for the AS in question.
All the ASPs within the AS must specify a unique label at a fixed position
in the TID or DRN parameter. The same ASPAC message is sent to each SG used
for interworking with the SS7 network.

The SG builds, per RK, a list of ASPs that have registered for it. The SG
can now build up and update a distribution table for a certain Routing
Context, any time the association is (re-)established and the ASP goes
active. The SG has to perform some trivial plausibility checks on the
parameters :

- start, end between 0 and 31 (between 0 and 23 for DRN with decoupled
approach)
- 0 < (start - end + 1) <= 16 (label length maximum 16-bit)
- start/end values are the same for each ASP within a RC
- TID/DRN label values must be unique across the RC

If any of these checks fail, the SG refuses the ASPAC request.

2. Routing and message distribution at the SG

2.1 TCAP traffic

Messages not containing a destination (or "responding") TID, i.e. Query,
Begin, Unidirectional, are loadshared among the available ASPs. Any scheme
permitting a fair load distribution among the ASPs is allowed (e.g. round
robin).
When a destination TID is present, the SG extracts the label and selects the
ASP that corresponds with it.
If an ASP is not available, the SG may generate (X)UDTS "routing failure",
if the return option is used. 

2.2 SCCP CO traffic

Messages not containing a destination reference number (DRN), i.e.
Connection Request, are loadshared among the available ASPs. Any scheme
permitting a fair load distribution among the ASPs is allowed (e.g. round
robin).
When a DRN is present, the SG extracts the label and selects the ASP that
corresponds with it.
If an ASP is not available, the SG discards the message.

3. Multiple SGs, SUA relay function

It is important that each ASP send his unique label (within the AS) to each
SG. For a better robustness against association failures, the SGs may
cooperate to provide alternative routes towards an ASP.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 1 oktober 2001 10:40
To: sigtran
Subject: SUA: Text proposal for multiple SGs

Hi all,

Thanks,
John

Effects on messages:
Optional in ASPAC

3.10.26 TID Label

3.10.27 DRN Label

=========================================
Add to Procedure Text in chapter 4:

---

---

---

From: [email-masked]
Date: Wed, 3 Oct 2001 15:30:26 +0300

Hi all,

Gery has submitted the following text (from 4.7.3 onwards).

Comments?
John

4.7 SCCP - SUA Interworking at the SG

4.7.1 Connectionless Data

The SGP SHOULD NOT attempt to reassemble XL/UDT when it is acting as an
SG/STP.  The ASP SHOULD perform reassembly of XL/UDT in this situation.
 
The SGP SHOULD segment CLDT into XL/UDT.  However, if the SG is acting as an
STP, the ASP SHOULD include the Segmentation parameter and the ASP MAY
segment CLDT.
 
Additionally, ASPs MAY segment CLDT messages, based upon knowledge of
segmentation size supported at the SG(s) to which the ASP has routes.

The IPSP SHOULD NOT segment N-UNITDATA into CLDT.

4.7.2 Connection-Oriented Data

The SGP SHOULD NOT attempt to segment CODT into DT, particularly for class
3. The ASP performs reassembly of CODT messages. The ASP SHOULD be
responsible for segmenting data into CODT of the appropriate size for
DT1/DT2.

The IPSP SHOULD NOT attempt to resegment, or reassemble, into CODT data
received from the local user in a N-DATA request primitive.

The IPSP SHOULD be responsible for any resegmentation or reassembly, which
is required to indicate data, received in CODT messages to the local user in
N-DATA indication primitives.

4.7.3 Support for Loadsharing

Several loadsharing ASPs may be active within an AS, identified by RK/RC
parameters.

However, in order to assure the correct processing of TCAP

When the ASP can be identified uniquely based on RK parameters (e.g. unique
DPC or GT), loadsharing is not required. When the ASPs in the AS share state
or use an internal distribution mechanism, the SG must only take into
account the in-sequence-delivery requirement. In case of SCCP Connection
Oriented traffic, when the coupled approach is used, loadsharing of messages

other than CR is not required. If these assumptions cannot be
made, the following general procedure should be supported by both SG and ASP
in a loadsharing environment.

4.7.3.1 Association Setup, ASP going active

After association setup and registration, an ASP normally goes active for
each AS it registered for. In the ASPAC message, the ASP includes a TID
and/or DRN Label Parameter, if applicable for the AS in question. All the
ASPs within the AS must specify a unique label at a fixed position in the
TID or DRN parameter. The same ASPAC message is sent to each SG used for
interworking with the SS7 network.

- Start and End parameters values are between 0 and 31 for TID
- Start and End parameters values are between 0 and 23 for DRN 
- 0 < (Start - End + 1) <= 16 (label length maximum 16-bit)
- Start values are the same for each ASP within a RC
- End values are the same for each ASP within a RC 
- TID and DRN Label values must be unique across the RC

If any of these checks fail, the SG refuses the ASPAC request and
returns an "Invalid loadsharing label" error.

4.7.4 Routing and message distribution at the SG

4.7.4.1 TCAP traffic

4.7.4.2 SCCP Connection Oriented traffic

Messages not containing a destination reference number (DRN), i.e. a
Connection Request, MAY be loadshared among the available ASPs. The load
distribution mechanism is an implementation  issue. When a DRN is present,
the SG extracts the label and selects the ASP that corresponds with it. If
an ASP is not available, the SG discards the message.

4.7.5 Multiple SGs, SUA relay function

It is important that each ASP send its unique label (within the AS) to each
SGP. For a better robustness against association failures, the SGs MAY
cooperate 
to provide alternative routes towards an ASP.

---

---

From: "Haresign, Lincoln" <[email-masked]>
Date: Wed, 3 Oct 2001 09:49:00 -0400

Hi all,

Perhaps I'm missing something.  But what is wrong with having the SG/STP do
reassembly of XUDT?  This takes the burden off the ASP of performing SCCP
functionality such as running timers to ensure that you receive all packets.
I thought that the GW functionality resided above the SCCP level and
therefore you get reassembly for free.

Why "SHOULD NOT" the SGP attempt to reassemble XUDT packets?

Regards,
Lincoln Haresign

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 8:30 AM
To: sigtran
Subject: FW: Text proposal for multiple SGs

Hi all,

Comments?
John

 

4.7.4.1 TCAP traffic

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 4 Oct 2001 14:48:01 +0200

Hi,

This was the original idea, and the SHOULD NOT is too strong. I´m still in
favor of the idea that the SG takes care of all segmenting/reassembly issues
for CL traffic, with the note that linkset failures may disrupt the
reassembly process on a SG because subsequent segments are sent over the
backup SG.

However, this would be easily mended when the mated SGs could pass such
messages to their mate.

-----Ursprüngliche Nachricht-----
Von: Haresign, Lincoln [mailto:[email-masked]]
Gesendet: Mittwoch, 3. Oktober 2001 15:49
An: sigtran
Betreff: RE: Text proposal for multiple SGs

Hi all,

Regards,
Lincoln Haresign

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 8:30 AM
To: sigtran
Subject: FW: Text proposal for multiple SGs

Hi all,

Comments?
John

 

4.7.4.1 TCAP traffic

---

---

---