Subject: Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD

From: [email-masked]
Date: Fri, 13 Sep 2002 08:10:52 -0400

Hello Brian,

>Precisely:  Your configuration is not supported by the RFC.  If you are
>going to devise a proprietary or non-standard configuration, it really
>doesn't matter what you do.  If interoperability is of concern to you,
>I would advise that you follow the proposed standard.  In the standard
>you have two choices:  (1) the SG terminates MTP3; (2) the SG is not
>connected to an SS7 network and is really an IPSP.

It is not a RFC yet, and yes, when M3UA becomes a RFC, we will comply.

IMO it is unfortunate that this functionality is required for the M3UA
component of the SGP. It is not a function of an SG-STP's MTP3 to
maintain congestion status obtained from TFCs that are not destined
to it, but simply through-switched, as is the case when a TFC arrives
for the ASP, and the SGP and ASP do not share a point code. It is
clear to me (now) that, according to the RFC-to-be, ASP point codes are
virtual and are implicitly shared with the SGP.

Since the ASPs are notified of congestion status, and probably implement
a procedure to handle it (that is, stop sending and begin to audit), a
simpler alternative is to allow them to provide the stimulus for the SGP
to generate RCTs. This allows for remote congestion status to be maintained
in just one place -- the ASP.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 09/12/2002
05:44:54 PM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    [email-masked]
cc:    Tolga Asveren <[email-masked]>, [email-masked]
Subject:    Re: [Sigtran] M3UA IG-01 : SCON in response to DAUD

Jeffrey,

[email-masked] wrote:
(Thu, 12 Sep 2002 16:58:48)
>
> Hello Brian,
>
> >But SS7 does not permit RCT to be generated except in response to TFC.
> >Are you meaning that you are delaying response to DAUD until the next
> >normal RCT cycle?
>
> I am refering to the scenario in which the M3UA SG-STP does
> not share a point code with the M3UA peer. The M3UA ASP sends
> a message via the SG-STP into the SS7 network, and the message
> encounters congestion. A response method TFC is generated, arrives
> at the SG destined to the peer's point code, and is sent out as
> a SCON. (The SG-STP does not capture the TFC and maintain congestion
> status for the destination, nor does it initiate route-set-test on
> behalf of the ASP). The ASP replies with a deviated DAUD. The SG
> generates a RCT and sends it to the congested destination.
>
> And yes, I know that your next response is going to be that the
> SG is supposed to terminate MTP3, and therefore should implement
> route-set-test on behalf of the ASP. I disagree with this, when
> the SG and ASP do not share a point code.

Precisely:  Your configuration is not supported by the RFC.  If you are
going to devise a proprietary or non-standard configuration, it really
doesn't matter what you do.  If interoperability is of concern to you,
I would advise that you follow the proposed standard.  In the standard
you have two choices:  (1) the SG terminates MTP3; (2) the SG is not
connected to an SS7 network and is really an IPSP.

>
> >Then I take it you do not have a problem with the text in the RFC2b?
>
> The fact that it does not require the SG to send a SCON in response
> to a DAUD is good. ;)

I agree.

> Regards,
> Jeff

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Sep 2002 09:21:11 -0600

Jeffrey,

If the ASP keeps track of congestion, it must also keep track of routing.
An ASP that keeps track of congestion, availability, restriction, routing
is no longer an ASP: it is either an SG or an IPSP.  I am somehow not
suprised that you seem to think that all nodes should be SGs.  You might
consider promoting Tolga's SG-SG draft.  This is probably closer to what
you are considering and includes the concept of relay between the SS7 network
and the IP network.

--brian

[email-masked] wrote:                                           (Fri, 13 Sep 2002 08:10:52)