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

From: [email-masked]
Date: Mon, 3 Sep 2001 12:41:56 +0300

Hi Brian,

> 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).

So, in CLDT you would like an additional, optional parameter - 
Segmentation Number?
 
> 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.

Would you like to generate some text for chapter 4 that summizes
the above?

Or review the bottom for comment.

4.1 SCCP - SUA Interworking at the SG

On the SG, the SCCP routing or interworking function determines that the
message is sent to an AS via the SUA stack, based on information in the
incoming message. The SUA Address Mapping Function identifies the
appropriate Application Server (AS) and selects an active ASP from the list
of ASPs servicing this AS. The appropriate ASP can be determined based on
the routing information in the incoming message, local load sharing
information, etc. The appropriate SUA message is then constructed and sent
to the appropriate endpoint, via the correct SCTP association and stream.

For Connectionless Data Transfer (CLDT), the ASPs should include a
Segmentation Number when it sends a large data payload. The SGP MUST take
care of any segmentation / reassembly issues at the border of the SS7 and IP
networks.  The IPSP may not have any knowledge about the requirements
regarding the maximum supported message length of the SS7 network to which
it is sending. 

However, since there is in principle no limit to the use of the more
indicator in SS7 networks, there is still need for connection-oriented
segmentation / reassembly procedures. 

If a SGP 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 SGP or if no mated SGP is available, the return on error
procedures is invoked.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 18:49:57 -0500

John,

Please see the "SUA: General Comments" thread discussion with Gery
for current proposals and resolutions for this issue.  It includes
more than just including a segmentation parameter; however, it is
still clear that a segmentation parameter is required which
parallels the segmentation parameter which is an optional parameter
of LUDT messages.

Please see the other thread for additional details.

--brian

On Mon, 03 Sep 2001, John Loughney wrote:

> You are currently subscribed to sigtran as: [email-masked]

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

---