Subject: [SUA issue 15]: Segmentation/Reassembly/Sequencing

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

-----Original Message-----
From: ext Brian F. G. Bidulock [mailto:[email-masked]]
Sent: 06 August, 2001 22:52
To: Loughney John (NRC/Helsinki); Lyndon Ong
Subject: Fwd: SUA-06: Segmentation/Reassembly/Sequencing

Attached is an issue for SUA Last Call:

Responsibilities for segmentation/reassembly/sequencing and
the necessitly of a source local segmenetation reference in the
CLDT message.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Subject: SUA-06: Segmentation/Reassembly/Sequencing
From: [email-masked]
To: [email-masked], [email-masked]
Date: Fri, 20 Jul 2001 14:59:24 +0300

John,

The two statements in section 4.1.1 and 4.1.2 need modification to
permit proper operation of segmentation and reassembly in all
protocol classes.  These sections indicate that the SG is
responsible for segmentation and reassembly of messages for all
protocol classes in both directions.

The problems I see are related to decoupled multiple SG
operation.

For class 0 and 1 operation:

Segmentation of CLDT messages into (XL)UDT messages at the SG
requires the use of a source segmentation reference number which the
SG is difficult to impossible for the SG to generate.  Because the
SG is really a transfer node in this case, it should follow the LUDT
procedures from Q.714: i.e., if the ASP generates a message larger
than X-bytes (X is usually 255), it must pass a source segmentation
reference number to the SG with the CLDT message for use in
segmentation.

This means that we need a optional source segmentation reference
parameter in the CLDT message which MUST be included when the data
payload of the CLDT exceeds X-bytes (configurable per Network
Appearance).

For class 2 and 3 operation:

Due to failures in the network, it may not be possible for the SG to
reassemble DT1 or DT2 messages into one large CODT message.
Furthermore, class 2 and 3 *does* also support stream operation
(i.e., non-segmented data transfer) so it may be impossible for
the SG to do "reassembly".  In the multiple SG case, failures
in the network can cause some segments to go to the other SG
making reassembly impossible (the first SG must deliver up the
first segments to the ASP) and the second SG cannot tell where
the beginning of the segment is (no remaining segments).  Also,
this reassembly process at the SG can unreasonably increase data
transfer latencies (to infinity if the more bit is always set).
For class 3 operation, the SG would also need to deal with
sequencing (because the ASP is not given true sequence numbers),
again causing havoc in decoupled operation across multiple SGs
as a result of a changeover in the network.

Because the "reassembly" process (if required at all by the nature
of the connection) is simple (more bit) and this bit is already
provided for in the CODT message, I propose that we make it the
ASPs responsibiliy to reassemble segments (if required) and handle
a partial delivery interface for non-segmented data connections.

For class 3 operation:

If it is the responsibility of the SG to do segmentation of
CODT messages into DT1 or DT2 messages, then it will also have
to perform sequencing (because each segment must be numbered
with a monotonically increasing sequence number).  This causes
all kinds of havoc in the multiple SG scenario when failures
cause a decoupled connection section to pass through the alternate
SG.  The alternate SG will not be able to assign sequence numbers
and the connection will be reset by SCCP peer when it otherwise
would not have.  Also, it would make the sent sequence number
in the CODT message pointless.  Again, as above, the nature of
the SCCP connection may not necessarily delimit messages at all
(i.e., the more bit is always set--like TCP not UDP or SCTP).
Again, transfer latencies to the SS7 network could tend towards
infinity.

Because the "segmentation" process is simple (more bit) and it
is fairly easy to determine the maximum segmentation size, I
propose that we make it the responsibility of the ASP to segment
NSDUs into CODT messages.

Also, because decoupled class 3 connections through multiple
SGs would increase the likelihood of a reset SCCP connection
because of changeover, if the SG is required to handle sequence
numbering, I propose that it be the ASPs responsibility to
handle sequence numbering for multiple SG class 3 operation
and perform resets when required.

To recap:

	o   it is still the SGs responsibility to perform
	    segmentation/reassembly of (XL)UDT messages to
	    and from the ASP, but,

	o   the ASP must include a new source segmentation
	    number in the CLDT message when it sends large
	    data payloads, and,

	o   it becomes the ASPs responsibility to do
	    sequencing/segmenting and segmenting/reassembly in
	    both directions for CODT messages.

--Brian

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

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