Subject: RE: SUA v5 comments

From: [email-masked]
Date: Thu, 22 Mar 2001 14:40:15 +0200

Hi Ken,

> Here are some comments on SUA version 5.  
> 
> Also, would you mind acknowledging Michael Wright in 
> Section 10 of the document.  He provided these comments.

Will do - can you relay my comments to Michael?

> 1.3.1/1.3.2
> Editorial - Figures should not be split across the page boundaries.

Of course - I'll get that in the next update.
 
> 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?

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

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

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

> 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.
 
> 4.4.2 AS/ASP Management procedures (may apply to M3UA also)
> Clarification:  How is the INFO string to be processed at the SG on
> ASP-Up and ASP-Active?  Must the SG echo back the same INFO string in
> the ACK, or is it that the INFO strings on request and ACK are
> independent of each other.  Is the same true for ASP-Capabilities on
> ASP-Up and Traffic-Mode-Type on ASP-Active? 
> 
> Note:  My understanding is that the INFO strings are independent, but
> it would be good to clarify in the text.

For the ACKs, the contents of the info string should be the same.  So I've
added text to clarify that.

> 3.4.4  SCON
>
> Assume that SCON will be sync'd between M3UA and SUA.  Also, 
> there's some inconsistency, because the SCON sections shows 
> "Congestion Level" as tag 0x0010, and "Affected PC" as tag 0x000E, 
> but section 3.8 shows:

Agreed & I fixed the tags.

Thanks,
John

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

---

From: Ken Morneault <[email-masked]>
Date: Fri, 23 Mar 2001 14:19:14 -0500

Pls see responses below.

>not distributed, then the IP Address / PC colapses to only route on SSN.

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.   

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

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

---