Subject: FW: SUA v5 comments

From: Coene Lode <[email-masked]>
Date: Mon, 2 Apr 2001 15:06:57 +0200

And here is another one.

-----Original Message-----
From: Verwimp Gery 
Sent: donderdag 29 maart 2001 17:29
To: [email-masked]'
Cc: [email-masked]
Subject: RE: SUA v5 comments

Hello all,

Some comments on the comments, see below.

Regards,

____________________________

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

-----Original Message-----
From: Ken Morneault [mailto:[email-masked]]
Sent: vrijdag 23 maart 2001 20:19
To: [email-masked]
Cc: [email-masked]
Subject: RE: SUA v5 comments

> > 1.3.1.1 SG as endpoint
> > Functional - The address information for routing a CLDT from SG to ASP
> > indicates that the Destination  Address contains at least an SSN.  The
> > Destination Address field format in 3.9.3/3.9.2 does not list 
> > a Routing
> > Indicator with SSN only, however, only SSN+IP and SSN+PC.  Does this
> > infer that the SG must include an IP address for the ASP in the
> > Destination Address?  I think there should be a "Route on SSN only"
> > routing indicator value.
>
>This is a bit tricky ... it might be possible, depending upon a
>configuration
>that SSN is only needed, but I think that in the case of a distributed
>SSN, we have to have addition information.  If the network element is
>not distributed, then the IP Address / PC colapses to only route on SSN.
>Comments?
>I agree that SSN+PC or SSN+IP may be required by the ASP for
>discrimination when PC and IP are used as part of the routing key.  But
>if we do have an AS using SSN only, then the PC and IP addresses are
>unnecessary.  In this case, when the SG forwards CL traffic to an
>SSN-only ASP, it must include a PC (probably the DPC or SG's PC) or IP
>address (one of the ASP's IP addresses) in the Destination Address
>field.  As long as the ASP ignores the extra information, I have no
>problem.  A clarification on this ASP behavior, or a "Route on SSN only"
>indicator value works for me.   

[GV] : routing is effectively done on PC by MTP or on IP-address by IP; also
in SS7 SCCP, the routing indicator definition states "route on DPC and SSN".
This doesn't mean that the PC or IP must necessarily be present in the
address information itself (see definition of source/destination address
parameters, we may have to update this section). The PC/IP information is
needed in certain circumstances only (e.g. for backrouting from ASP to SS7
SEP via SG) in either source or destination address.
If the SUA can use the source IP address from the SCTP header to backroute
(e.g. CLDR answer to CLDT), fine. Same is true for SCCP making use of the
OPC in the MTP routing label.
With this in mind, I see no need for a separate routing indicator "route on
SSN only", a rewording of the other definitions is sufficient.

> > 1.3.2 
> > Segmentation/Reassembly
> > Clarification - The draft is quite clear that the SG must perform
> > segmentation and reassembly on behalf of the SUA peer for 
> > connectionless
> > data (4.1.2 and 6.3), but connection-oriented processing needs
> > clarification.  If the SG is not required to reassemble the 
> > DT1 packets,
> > then the More-bit must be sent to the SUA ASP.  The Sequence Number
> > parameter (3.9.7) in the CODT (3.3.1) carries the More-bit, but 3.3.1
> > states that it is only present for DT2 data - Note 1.  It seems to me
> > that the reassembly requirements should be consistent between 
> > CL and CO.
>
>Agreed.  I didn't catch the connection-oriented data message, so I will
>remove the more-bit, so that connectionless & connection-oriented are 
>the same & add a note in 4.1.1.
>

[GV] : Not agreed. The CO case is really different from the CL case, in the
sense that you can have a "stream" of DT1's. The ITU-T Q.714 specifies a
limit on the number of XUDT segments (16), but there is no such limit for
number of DT1's with the "more" flag set.
So I propose to leave the option to keep the DT1's as they are, so the SG
may decide what to do with it (maybe reassemble only up to 4 subsequent
DT1's with "more" flag set or just pass on) ... the point being you have to
keep the "more" flag in CODTs even when mapping DT1's.

> > 3.2.1 CLDT
> > Functional/Clarification - Why is there no "Sequence Control" 
> > parameter
> > on a CLDT?  This is set by an SCCP-User on N-UNITDATA.req to 
> > identify a
> > flow or sequence of data that must be delivered in-order to the
> > recipient SCCP.  The sequence control is used by SCCP to assign an SLS
> > so that MTP will 'ensure' sequenced delivery.  Without receiving this
> > parameter from the SUA user, the SG will be forced to assign the same
> > SLS to all connectionless traffic from the same ASP stream to the same
> > destination address.  Maybe this was determined to be feasible.  The
> > ASP, of course,  will receive the Sequence Control from the 
> > originating
> > subsystem, and will be able to ensure sequencing by assigning the
> > traffic to the same stream.
>
>Would we need a seperate parameter for this, or would it be enough
>to mandate that SCTP uses the same stream (& ordered deliver) when
>the sequence delivery is present & that the SG must manage this
>for messages bound to the SS7 network.  What is your feeling?
>My feeling is that a sequence control parameter should be passed to the
>SG to ensure proper SLS distribution in the SS7 network.  It also seems
>architecturally correct to pass all of the SCCP-User parameters to the
>SG.  As you suggest, the SG could perform a stream->SLS mapping, but
>then the ASP must create an appropriate number of streams to properly
>balance SS7 traffic.  The number of streams is negotiated at association
>activation, and cannot currently be added as "flows" are created. 
>Initially, I also anticipate ASPs using only 1 or 2 streams, which will
>not be adequate for proper SLS distribution. 

[GV] : I think I answered this question once before, the point being that
not only streamID must be taken into account to derive an SLS. The same
problem exists in SS7 SCCP relay points : to select an evenly distributed
outgoing SLS even when it cannot be guaranteed that the incoming SLS is
evenly distributed over all possible values.
But, also the OPC (from MTP routing label) or, for ASPs, the (primary) IP
address of the SCTP association can be taken into account, without violating
the in-sequence-delivery requirement. Of course, this supposes a sufficient
number of ASPs or streams "attached" to the SG ... which might not always be
the case, hmmm, but on the other hand I don't think having at least 16
streams in/out is such a burden to implement, even for initial ASP providers
;-).

> > 3.9.2.6 IP Addresses
> > Functional/Editorial - Must both 0x1004 and 0x0804 be 
> > supported for IPv4 addresses, or is there a typo here?
>
>typo.
>

[GV] : for tags of TLV elements within TLVs, I proposed to start numbering
with 0x8001. Other ideas ?

> > 3.9.4 and 3.9.5
> > Functional - The reference numbers are listed as 4-octet numbers, but
> > the reference numbers in SCCP are 3-octets.  Was this difference
> > intentional?    4.1.1 says that 'existing' SCCP may be used to perform
> > coupling of connection sections, but not with this reference number
> > difference.
>
>I've added clarifying text.
>  

[GV] : so in the SG you'll have a leg terminating the SS7 side of the
connection, using 3 byte reference numbers, and a leg terminating the IP
side of the connection, using 4 byte reference numbers. Both legs are linked
in the SG (who won't be confused by the different lengths ... because he has
a reference number of each kind).

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