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

From: [email-masked]
Date: Fri, 13 Sep 2002 11:28:38 -0400

Hello Brian,

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

Huh?
Are you telling me that an AS/ASP maintains no destination status?
What is the purpose of DAVA, DRST, DUNA, SCON, and DAUD, then?

Actually, I am interested in Tolga's SG-SG draft, but this doesn't apply
to the issue at hand.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 09/13/2002 11:21:11 AM

Please respond to [email-masked]

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

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

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

_______________________________________________
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:48:13 -0600

Jeffrey,

MTP Users never need to maintain congestion or availability status.  Each
time (well, n, 2n, ...) that they send to a destination to which the routeset
is congested or unavailable, they get informed with MTP-STATUS or MTP-PAUSE.
In this way, the MTP User can rely on MTP to maintain congestion and
availability for it rather than attempting to track the MTP state.  This has
always been the case with SS7.  By exporting the MTP/MTP-User interface
between SG and ASP, the same MTP-STATUS, MTP-PAUSE and MTP-RESUME primitives
are provided as SCON/DUPU, DUNA and DAVA, the purpose of which is to carry
the MTP-STATUS, MTP-PAUSE and MTP-RESUME primitives and parameters between
MTP provider (SG) and MTP user (AS).

The purpose of DAUD is, should the MTP User (AS) care about the state of
routesets, it may initialize or resynchronize this state using the DAUD
primitive (in a similar fashion, MTP-RESTART-ENDS implementation dependent
primitive was intended to provide this information if necessary for MTP).
It is there to be used or not to be used to support existing implementations
of SS7 at both the MTP provider (SG) and MTP user (AS).

--brian

[email-masked] wrote:                 (Fri, 13 Sep 2002 11:28:38)