Subject: RE: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 12 Oct 2005 14:56:47 -0400

Tolga,

[tolga]:I think what you are proposing should be fine. BTW, I may be
missing something but it seems to me that only RC should do it in terms
of communicating ASP congestion to SG.

Yes, I'm seeming to believe that RC should do it also. 

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tolga Asveren
Sent: Wednesday, October 12, 2005 2:26 PM
To: [email-masked]
Subject: RE: [Sigtran] Recommendation for SUA modifications

Lincoln,

I believe, if people are not standing behind it, a new draft does not
have much meaning. It is nice to be architecturally correct, and IMO ASP
congestion in the context of an AS is similar to ASP being
ACTIVE/INACTIVE hence suitable to be handled with an ASPTM-. OTOH, a
solution is better than no solution, and yours is a practicall approach
with minimal changes.

I think what you are proposing should be fine. BTW, I may be missing
something but it seems to me that only RC should do it in terms of
communicating ASP congestion to SG.

My personal preference would be if possible defining a new ASPTM,
otherwise doing necessary changes to use SCON to communciate ASP
congestion to SG.

   Thanks,
   Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2005 2:30 PM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] Recommendation for SUA modifications
>
>
> Tolga,
>
> I have no objection to a new draft.  Personally, I think what I am 
> proposing is rather simple and solves the problem that currently does 
> not have a solution.  And if there is no objection from the majority 
> of the SIGTRAN community, then we can make a very minor change to the 
> SUA recommendations and my problem is solved.
>
> However, if you want to do something more expansive like a new draft 
> and it solves the problem also, even though implementing new messages 
> is more work, it's fine with me.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tolga Asveren
> Sent: Wednesday, October 12, 2005 2:02 PM
> To: [email-masked]
> Subject: RE: [Sigtran] Recommendation for SUA modifications
>
> Brian,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Wednesday, October 12, 2005 1:45 PM
> > To: Haresign Lincoln
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: Re: [Sigtran] Recommendation for SUA modifications
> >
> >
> > Lincoln,
> >
> > Please see comments inline.
> >
> > Haresign Lincoln wrote:                         (Wed, 12 Oct 2005
> > 11:02:09)
> >
> > --X-snip-X--
> > >
> > >    Parameters
> > >      Routing Context               Optional
> > > |    Affected Point Code           Conditional *1
> > >      SSN                           Optional *1
> > >      Congestion Level              Mandatory
> > >      SMI                           Optional
> > >      Info String                   Optional
> > >
> > >
> > > |  Note 1:    For an SCON from the SG to an ASP, when the SSN
> > is included,
> > >               the SCON message corresponds to the SCCP N-STATE
> > primitive.
> > >               When the SSN is not included, the SCON message
> corresponds
> > >               to the SCCP N-PCSTATE primitive reporting signalling
> point
> > >               or network congestion status.
> > >
> > > |             When the SCON is from the ASP to the SG, the
> > affected point
> > > |             code is an optional parameter.  The SG, if 
> > > | necessary,
> can
> > > |             determine the affected PC from the Routing Context.
> > >
> > --X-snip-X--
> >
> > The SG cannot determine the PC of messages comming from the ASP by
> > Routing Context.   If you think that it can, please detail one
> procedure
> > that the SG can follow to associate a Point Code with this message 
> > when it is received from an ASP.
> >
> > Please bear in mind that an ASP is not restricted to sending 
> > messages from the source address that it has registered to receive
messages.
> > For example, if ASP A registers AS 1 with Routing key PC 111 and SSN

> > 5, obtaining RC 1, it is permitted to send messages with source 
> > address PC 333 SSN 7 labelled with RC 1.  There is no restriction in

> > the ASP->SG direction for SCON either.
> [TOLGA]I have a different opinion here based on 4.3.4.3 ASP Active 
> Procedures section.
> "The ASP SHOULD NOT send Data or SSNM
> messages for the related Routing Context(s) before receiving an ASP 
> Active Ack message, or it will risk message loss."
> I know it is not a "MUST NOT" but still it is nota good thing to do 
> unless one is aware of consequences and happy with them.
> >
> > So if the SG cannot get the OPC for the outgoing SS7 message from 
> > the SCON, where is it going to get it from?
> >
> > --X-snip-X--
> > >
> > >    Parameters
> > >      Routing Context               Optional
> > > |    Source Address                Optional *1
> > > |    Affected Point Code           Conditional *1
> > > |    SSN                           Conditional *1
> > >      Congestion Level              Mandatory
> > >      SMI                           Optional
> > >      Info String                   Optional
> > >
> > >
> > > |  Note 1:    For an SCON from the SG to an ASP, when the SSN
> > is included,
> > >               the SCON message corresponds to the SCCP N-STATE
> > primitive.
> > >               When the SSN is not included, the SCON message
> corresponds
> > >               to the SCCP N-PCSTATE primitive reporting signalling
> point
> > >               or network congestion status.
> > >
> > > |             When the SCON is from the ASP to the SG, the ASP can
> use
> > > |             the source address parameter instead of the Affected
> Point
> > > |             Code parameter.  This is used mainly in the case 
> > > | when
> the
> > > |             Routing Keys associated with the ASP may not
> > include a point
> > > |             code and/or an SSN.  The SG should be able to
> > derive the affected
> > > |             PC from the registration information and take any
> actions
> > > |             that might be appropriate to for subsystem 
> > > | congestion
> in
> > > |             the network.
> > > |
> > > |             If the ASP is sending Source Address, it is not
> > necessary to
> > > |             send SSN and/or Affected Point Code as this
> information is
> > > |             either contained in the source address, or can be
> > derived at
> > > |             the SG.
> > >
> >
> >
> > When developing the RFC we considered using Source Address in the 
> > SCON; however, as neither the N-STATE or N-PCSTATE can contain a 
> > Global Title, we rejected using the Source Address.  The situation 
> > has
> not changed.
> >
> > I strongly disagree with both proposals.  The motiviation behind 
> > them is to modify the SCON message to attempt something that it was 
> > never intended to do: communicate ASP congestion.  SCON is intended 
> > for SS7 congestion only.
> >
> > If you want to develop enhancements for ASP congestion control, 
> > please
>
> > write an extension draft detailing the new protocol elements 
> > required and their usage.  It might be easier to modify or 
> > participate in Kamesh's draft.
> [TOLGA]I would think a new draft could be a better approach, if there 
> is consensus in the WG for it. I personally would like to see 
> something like ASPCONG etc...OTOH, if we don't define a new message, 
> the need to know about ASP congestion states does not disappear, and 
> overloading SCON semantics seem to be a practical approach. What do 
> the others think, does a new draft have a chance of survival?
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> ______________________________________________________________________
>   This email message has been scanned by PineApp Mail-Secure and has 
> been found clean.
>
>
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Oct 2005 17:26:49 -0600

Haresign,

Haresign Lincoln wrote:                                                           (Wed, 12 Oct 2005 14:56:47)
> Yes, I'm seeming to believe that RC should do it also. 

It won't for a multiple point code SG unless you register the routing key
with a point code, in which case the ASP knows its point code and can easily
populate it in SCON and other messages.

--brian

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