Subject: Re: [SUA issue 15]: Segmentation/Reassembly/Sequencing ( CL Issues)

From: [email-masked]
Date: Tue, 4 Sep 2001 11:02:47 +0530

Hi ,

I am copying messages from thread "SUAv7:General Comments" that were exchanged
for the CL messages segmentation/reassembly issue.

Following things were discussed and decision needs to be taken for them

1. Should following paragraph be removed from the section 4.1
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.

2. Should ASP be allowed to segment CLDT messages that it sends to SG.
>> Benefits
It may be useful for multiple SG case and for the case when ASP feels
segmentation may not be supported by SG.
>> Issues
How segmentation at ASP will be useful for multiple SG case need to be further
explored ?
As ASP may not have idea of segment size to be used by SCCP so it may involve a
reassembly and re-segmentation at SG.

3. Should segmentation parameter be included in all CLDT messages sent by ASP.
>> Benefits
It may avoid any Interworking issues at SG in case the CLDT message needs to be
segmented at SG. This is similar to SCCP procedures where originating end
includes segmentation parameter in LUDT message when there is a possibility of
message getting segmented at a intermediate node.
>> Issues
Since there is a protocol conversion taking place at SG ( from SUA to SCCP) , it
is not very clear if inclusion of segmentation parameter will avoid Interworking
issues. Considerations also needed for enhancing interface boundary between
NIF/SUA and NIF/SCCP for passing this parameter across from SUA to SCCP.

4.   Should reassembly be supported at ASP.
In case SCCP at SG is a non terminating SCCP,  SCCP will not do reassembly
incoming SCCP messages, for this case we need to decide if reassembly needs to
be done by NIF or by ASP. This case is under consideration with IPSP - IPSP
case.

5. Should SUA implementation perform and allowed to perform segmentation be  in
an IPSP case
>>Benefits
An implementation may very well want to segment long CLDT into pieces
for better SCTP stream HOL blocking and IP fragmentation performance.
Issues
>> In a all IP network  SCTP should be best suited for segmentation/reassembly.
IMO segmentation by application for better SCTP stream HOL blocking and  better
IP fragmentation performance is not a established fact and needs to be proved.

Best Regards,
-Sandeep

Text from the thread ..
********
> 5. Reassembly of pre-segmented CLDTs and re-segmenting :
> Kind of defeats the purpose of having nothing to do at the SG.

If indeed that was required for a particular configuration.  It might
not be so, and the SG might decide to resegment where the ASP has
unnecessarily (and rather incorrectly) segmented in the first place.

> It also introduces an interoperability issue.

What interoperability issue?

********

5. Reassembly of pre-segmented CLDTs and re-segmenting :

Kind of defeats the purpose of having nothing to do at the SG. It also
introduces an interoperability issue.

********

>
> 3. CL segmenting/reassembly :
>
> I agree you have some valuable arguments, but want to note the following
> points.
>
> First of all : the segmentation parameter
>
> +--------+--------+--------+--------+
> |       tag       |    length = 8   |
> +--------+--------+--------+--------+
> |fst.rem.|    segmentation ref.     |
> +--------+--------+--------+--------+
>
> The first/remaining segments field is formatted as follows :
>
> bit 8 (MSB) : indicates whether this is the first segment (1) or not (0)
>
> bits 1-7 : indicate the number of remaining segments, value between 0 and 15
>
> The field would thus be coded 1000 0000 (first, no remaining segments) for a
> non-segmented CLDT.
>
> The segmentation reference field is a 3 byte integer, assigned by the ASP.

This parameter proposal looks good.

> 3.1 ASP -> SG direction : if the CLDTs are pre-segmented, and still don't
> fit into a single XUDT, the SG would have to reassemble and re-segment.
> This cannot be the intention (not even in SCCP) so respond with
> CLDR (segmentation failure).

I agree, but we should leave the implementation to do what it wants
here.  If the implementation wants to reassemble and resegment, let
it.

>
> 3.2 SG -> ASP direction, or IPSP -> IPSP : the destination must support
> reassembly. This is something you'd have to configure, if you want to use
> segmentation.

Sounds like something for an ASP Capabilities parameter in a REG
REQ...

********
> 3. The segmenting/reassembly issues are closed I think.
>
> - for CL, the SUA doesn't segment/reassemble. The SG thus has to reassemble
> all XUDTs before sending CLDT, and vice versa, the ASP has to include a
> segmentation parameter to anticipate segmenting at the SG if the CLDT
> doesn't fit into a single MSU. This avoids a lot of interworking problems,
> and only has the (small) drawback that XUDTs could get missing if routing
> occurs via multiple SGs AND a routing failure occurs. Hence my proposed
> procedure ...

Based on what your are saying here, I don't think we have closed this yet.

I agree with the ASP -> SG direction: the ASP must include segmentation
parameter so that SG can segment, but why cannot an ASP be permitted to
do the segmentation into something similar if it so wishes?  If the ASP knows
that segmentation may be required, can it not be permitted to segment itself?
I agree that the SG must be prepared to segment unsegmented ASP CLDTs based
on the Segmentation parameter (which still needs to be described) in the CLDT
and that if the ASP does not place a segmentation parameter in the CLDT when
necessary that the SG will either UDTS the message with reason segmentation
failure (or some such) or may discard it if return on error is not set.  But
why should an SG not accept presegmented CLDT?  This would permit an ASP
implementation which is worried about segmentation disruption across multiple
SGs to choose to segment messages itself without interoperability impacts.

In the SG -> ASP direction for the backhaul case, it makes sense that the
SG could reassemble segmented (XL)UDT into CLDT, but must it be required to
do so?  When multiple SGs are used, an ASP which is capable of performing
this reassembly itself would not experience distruption of segmentation
across changeovers between SGs.  Although I agree that in normal
configurations the SG SHOULD perform reassembly, it is not so desirable in
multiple SG configurations for decoupled (XL)UDTS which form the initial
BEGIN/INVOKE for ITU-T TCAP transactions.  (For all others a separate
segmentation facility is provided in TCAP).  Certainly it the SG does not
perform reassembly, the ASP should be prepared to either perform the
reassembly itself or reject the message with CLDS or discard.

In the IPSP -> IPSP case, is segmentation precluded?  An implementation
may very well want to segment long CLDT into pieces for better SCTP stream,
HOL blocking and IP fragmentation performance.

Including a full segmentation parameter in CLDT would permit all these
scenarios.  Then, aside from a few careful SHOULDs, in the draft, the
implementation can pretty much do what it likes and multiple SG cases can
be accomodated by the implementation.

Statements which would aid interoperability would be something like: an
SGP/ASP/IPSP MUST be prepared to deal with segmented CLDT (reassembly, CLDS,
etc..); an SGP SHOULD support segmentation of unsegmented CLDT where required;
an ASP SHOULD place segmentation parameter in CLDT where segmentation might be
required at an SGP and MAY always include it; an ASP/SGP/IPSP MAY segment
CLDT.

********

2. Segmenting/Reassembly
====
SCCP at the SG is enhanced (we call this "enhancement" the NIF, by lack of a
better term) to detect that the message is intended for the IP-world and SUA
should be invoked. And vice versa. However, this NIF reassembles incoming XUDTs
so SUA can format a single CLDT, and the NIF segments incoming CLDTs into XUDTs
fitting into the SS7 network. The idea behind it is clear : relieve SUA on the
ASPs from tedious CL segmenting/reassembly issues ! Actually, the NIF contains
every functionality not present in strict SS7 SCCP nor in IP SUA, but is
required in the SG for seamless inter-working. As such only a black-box
description (going in - coming out) can be given, what's inside is totally
implementation dependent.Now, the idea behind the procedure below was that if
the ASP has routes via 2 SGs (redundancy), n-sequence-delivery of the XUDT
segments does not guarantee that each segment will pass the same SG (required
for NIF
reassembly) e.g. due to routing failures. The procedure might be a bit overkill
though, because it assumes :

- SGs know each other as "mated pairs" for this RC => their is an SCTP
association between them,
- their NIFs must be intelligent enough to forward and accept non-first XUDT
segments (as CLDTs)

But I don't have a problem deleting the entire paragraph

********

SUA Interworking at the SG
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.

At SG , any message from SS7 network first reaches SCCP via MTP3. As per SCCP
specifications (section 4.1.1.2.2 of Q.714 and T1.112.4 ), if SCCP receives a
non  first XUDT segment for which no reassembly process exists , SCCP should
discard message.  It is not very clear to me that If SCCP discards the message
how can that message be passed to mated pair ?

********

For the interface between SCCP to NIF and NIF to SUA.,  some approaches can be
a) SCCP passes UDT/XUDT message as such to NIF, NIF converts this and passes
N-UNITDATA request primitive to SUA.
b) SCCP builds and passes N-UNITDATA indication primitive to NIF and NIF passes
the N-UNITDATA request primitive to SUA.
c) SCCP passes UDT/XUDT message as such to NIF and NIF invokes N-UDT request ( a
new interface) primitive of SUA. This will let NIF pass parameters like hop
counter and Segmentation to SUA which are present in the message but not in the
SCCP/SCCP User interface.  This seems necessary also as SCCP at SG is not the
destination SCCP and a segmented XUDT will not be reassembled by SCCP at SG. So
the reassembly can either be done in NIF at SG or these segmented messages can
be passed to ASP and destination SUA reassemble them. If we decide to let
destination ASP do the reassembly some primitive like N-XUDT request is needed
in SUA.

Also allowing/disallowing this case can have impact on segmentation/reassembly
scheme being followed for CL transfer case. If SCCP at SG can be non terminating
SCCP , ASP need to support reassembly but it SCCP at SG can only be terminating
SCCP it will always pass reassembled messages to NIF/SUA and ASP need not to
support reassembly.

"Brian F. G. Bidulock" <[email-masked]> on 09/04/2001 06:19:57 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

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

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:

> 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]

--
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]

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