Subject: [SUA issue 25] section 1.3.1 comments

From: [email-masked]
Date: Tue, 21 Aug 2001 14:05:03 +0300

Hi,

Following were the unresolved issues from the thread.

From Section 1.3.1.1
Address information in CLDT message (e.g. TC_Query) from SGP to ASP,with
association ID = SG-ASP, Stream ID based on SLS and possibly other
parameters,
e.g. OPC or Network ID"
>> In above statement SLS should be replaced with sequence control.

From Section 1.3.1.2
GT Translation yields an "SCCP entity set", which now may contain one or
more
AS's.
1. GT translation does not return "SCCP entity set" but only return single
SCCP
entity.
2. Draft should not recommend hooking SUA into SCCP's GTT function, but
rather
transport the SCCP/SCCP-User interface
per the SIGTRAN architecture.

SCCP at SG receives UDT/XUDT/LUDT message through local MTP3 Parameter
Routing
Indicator is set to Route on GT. Global Title procedure is initiated at
SCCP, GT
translation result in RI = Route on GT. As SCCP does not pass this message
to
its local users , how should/can message of this type be delivered to SUA.

Best Regards,
-Sandeep

[email-masked] on 08/17/2001 12:09:01 AM

To:   Sandeep Mahajan/HSS@HSS, [email-masked]
cc:

Subject:  RE: SUAv7: Basic Doubt : SUA last call Issue

Hi Sandeep,

I cannot parse through this and figure out what your issues
are.  Can you give me a sentence or two for each issue
that you are raising?

Thanks,
John

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 16 August, 2001 10:57
> To: [email-masked]; Loughney John (NRC/Helsinki)
> Subject: SUAv7: Basic Doubt : SUA last call Issue
>
>
>
>
>
> Hi ,
>
> Please consider issue(s) discussed in this thread as SUA last
> call issue.
>
> Best Regards,
> -Sandeep
>
>
> ---------------------- Forwarded by Sandeep Mahajan/HSS on
> 08/16/2001 03:43 PM
> ---------------------------
>
>
> [email-masked] on 08/10/2001 05:21:37 PM
>
> Please respond to [email-masked]
>
> To:   "sigtran" <[email-masked]>
> cc:    (bcc: Sandeep Mahajan/HSS)
>
> Subject:  Re: SUAv7: Basic Doubt
>
>
>
>
>
>
>
> Hi Brian  ,
>
> Please see my comments below.
>
> Thanks and Regards,
> -Sandeep
>
>
>
>
>
> "Brian F. G. Bidulock" <[email-masked]> on 08/10/2001
> 11:58:05 AM
>
> Please respond to [email-masked]
>
> To:   "sigtran" <[email-masked]>
> cc:    (bcc: Sandeep Mahajan/HSS)
>
> Subject:  Re: SUAv7: Basic Doubt
>
>
>
>
> Sandeep,
>
> Please see comments below...
>
> [email-masked] wrote:               (Tue, 07 Aug 2001 18:40:06)
> >
> > Hi,
> >
> > I have a basic doubt regarding the difference between SG as Endpoint
> > Model and SG as Relay Point Model. Would appreciate a clarification!
> >
> > I have considered connectionless message case.  SCCP at SG receives
> > UDT/XUDT/LUDT message through local MTP3. Following three cases are
> > possible
> >
> > 1. Parameter Routing Indicator is set to Route on SSN. In this case
> >    SCCP passes N-UNITDATA indication primitive to local User. Local
> >    User (some inter-working function) after receiving this invokes a
> >    corresponding N-UNITDATA request primitive of SUA. This SUA is
> >    actually a SGP in SIGTRAN Architecture. In SUA AMF is
> used to find
> >    a corresponding Application Server (AS) and from that an Active
> >    Application Server Process (ASP) is calculated. Determine SCTP
> >    association that connects the corresponding SGP and ASP.  Now
> >    choose Stream id for send a CLDT message using that SCTP
> >    association and stream Id.
>
> Sounds ok to me.
>
> >
> > 2. Parameter Routing Indicator is set to Route on GT. Global Title
> >    procedure is initiated at SCCP and it yields Local DPC as SCCP
> >    entity (Result of GT can be either RI = ROUTE on SSN or
> RI = Route
> >    on GT). SCCP passes N-UNITDATA indication primitive to
> local User,
> >    and local user pass the same to SUA, Rest is same as point One.
>
> This is not really the way that SCCP works.  I have from ASNI T1.112
> Figure 2/T1.112.4 SCCP Routing Control Procedures (SCRC) that if
> the result of GT translation is DPC=local and RI=GT for connectionless
> messages that maintenance is informed that a GTT Loop exists and the
> routing failure action is taken (i.e., (XL)UDTS may be
> returned).  Only
> RI=DPC/SSN is permitted as a GTT result for local DPC.
>
> So, your case 2 is ok for RI=DPC/SSN but not ok for RI=GT.
>
> I can't find this in the Q.714 SDLs, but it is clear in the ANSI SDLs.
>
> Sandeep>> Brian , I was aware of this. But I was (am) not
> sure SUA handles the
> case when Global Title Translation at SCCP on SG does not yield final
> destination. I referred to Q.714 and though may be we can use
> it this way as
> SCCP Specs does not clearly disallow it.
>
>
> >
> > 3. Parameter Routing Indicator is set to Route on GT. Global Title
> >    procedure is initiated at SCCP and it yields Non-Local
> DPC as SCCP
> >    entity. SCCP invokes MTP-Transfer request primitive to send this
> >    message to DPC.
>
> Sounds ok.
>
> >
> > Is sequence listed above correct and complete?
>
> Yes, except for the RI=GT case in 2 for ANSI.
>
> > In what category (SG as Endpoint, SG as Relay-point) does case 1, 2
> > and case 3 listed above falls?
>
> For SCCP, cases 1 and 2 are endpoint, case 3 is relay.
>
> > Have I missed any case?
>
> Yes.
>
>   4. The message arrives for a DPC which is not the SG's
> point code (SG
>      as STP case).  The message never makes it to SCCP and is
>      transferred to the DPC in the message by MTP3.
>
> This is similar to case 3 but SCCP is never touched.  Don't ask me how
> that works in SUA, the draft does not properly address it (or case 3
> for that matter).
>
> >
> > >From Section 1.3.1.1
> > "Address information in CLDT message (e.g. TC_Query) from
> SGP to ASP,
> > with association ID = SG-ASP, Stream ID based on SLS and possibly
> > other parameters, e.g. OPC or Network ID"
> >
> > It is not very clear to me how SLS parameter is to be used
> for stream
> > selection?  Do we mean "Sequence control" here?
>
> Yes, but Sequence control == SLS, so the difference is pendantic.
>
> >
> >
a> > >From Section 1.3.1.2
> > "GT Translation yields an "SCCP entity set", which now may
> contain one
> > or more AS's."
> >
> > As per Global Title Procedures (Section 2.4 of Q.714) "SCCP Entity
> > Set" is the output of step 2 of the listed procedures and
> can be used
> > by Step 4 to yield a single SCCP entity to GT user (After
> > consideration like Active/Standby or Load-sharing). So my
> > understanding is that GT never yields "SCCP Entity Set", but always
> > results in a single SCCP entity.
>
> This text is poorly worded.  For your case 1 and 2 above, once the
> N-UNITDATA primitive has arrived at SUA, SUA may then apply the AMF
> to the Called Party Address provided in the primitive to determine
> the AS.  Forget entity sets, the SG doesn't need them.  Let SUA do
> the active/standby and load-sharing after final GTT.
>
> > In the same statement it is not clear, if the term AS's is referring
> > to Application Server (AS) or Application Server Process (ASP).
>
> The statement is unclear in many other respects as well, but it is
> really introductory fluff anyway.
>
> I don't think that the draft should recommend hooking SUA into
> SCCP's GTT function, but rather transport the SCCP/SCCP-User interface
> per the SIGTRAN architecture.
>
> Sandeep>> I completely agree with you on this. On many places
> in draft SUA
> functions are asked to be invoked from within SCCP. I have
> serious objections to
> it. I would prefer to see functionality of SCCP and SUA being
> invoked/used
> through clearly defined Upper and Lower Layer interfaces.
>
>
>
> --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]
>
>
>
>
>
>
>
>
> ---
> 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]