Re: M3UA: ASP Route Availability to SG/STP

Hello Howard,

yes, I am suggesting having another SCTP association carrying corresponding
traffic.

Regards

/Ilie

On Tue, Sep 2, 2008 at 5:27 PM, Howard May <[email protected]> wrote:

>  Hi Ilie,
>
>
>
> Are you suggesting there should be two associations, one for the ASP <->
> SGP relationship and one for the IPSP <-> IPSP relationship, or should there
> be one association and the ASP presumes that messages for the SG/STP may be
> sent as soon as the AS is active?
>
>
>
>
>
>
>   ------------------------------
>
> *From:* Ilie Glib [mailto:[email protected]]
> *Sent:* 02 September 2008 16:11
> *To:* Howard May
> *Cc:* [email protected]; [email protected]
>
> *Subject:* Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
>
>
> Hello Folks,
>
>
>
> I would say that this specific case is an example of IPSP to IPSP
> communication, where one of IPSPs is collocated with SGP.
>
> So, it shall be another IPSP to IPSP relation (and corresponding SCTP
> association) which will cary signalling.
>
>
>
> Regards
>
>
>
> /Ilie
>
>
>
>
> On Tue, Sep 2, 2008 at 4:59 PM, Howard May <[email protected]>
> wrote:
>
> Hi Brian,
>
> Thanks for your response but I'm still unclear whether when the AS
> becomes active M3UA should immediately consider the route to the SG/STP
> as available or whether it should wait for a DAVA. I'm also unclear
> whether the SG should respond to DAUD concerning the SG/STPs Point Code
> or not.
>
> Best Regards
>
> Howard
>
>
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
>
> > Sent: 02 September 2008 15:05
> > To: Howard May
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > Howard,
> >
>
> > I didn't say that an MTP-User at a signalling point receives an
> > MTP-PAUSE for its own point code.  What I was saying is that an
> > MTP-User at a signalling point can always generate an MTP-TRANSFER
> > primitive for a given destination regardless of whether it has
> > received an MTP-PAUSE for that destination.
>
> My concern is not with the MTP3 User but rather whether M3UA at the ASP
> should consider the route to the SG/STP as available.
>
> While an MTP user may generate MTP-TRANSFER primitives after receiving
> an MTP-PAUSE I'm not sure that either ISUP or SCCP should.
>
> Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user
> should wait for an MTP_RESUME and in the mean time is not allowed to
> send messages to that signalling point.
>
> Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP
> cannot send messages to the affected exchange.
>
>
> >
> > Also, SG do not issue DAUD, so what did you mean by "see whether
> > the SG responds with DAUD"?
>
> This was a typo, I meant to say DUNA.
>
>
> >
> > DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this
> > situation, and they represent the status of the signalling point
> > in the SS7 network.  MTP does not send MTP-RESUME or MTP-PAUSE
> > for its own signalling point code.
> >
> > Precisely when M3UA sends a DAVA and DUNA however, is largely
> > part of the NIF and out of scope of the RFC.  Achieving
> > transparency with SS7 requires first a knowledge of how SS7
> > behaves.
> >
> > --brian
> >
> > Howard May wrote:                            (Tue, 02 Sep 2008
> 04:47:26)
> > > Hi,
> > >
> > > MTP normally generates PAUSE and RESUME indications for Routes it
> > > maintains to remote signalling points. In this situation the
> signalling
> > > point in question is it's own signalling point for which it does not
> > > normally have a route defined nor generate PAUSE and RESUME
> indications.
> > > Consequently I don't believe it is normal for MTP to generate a
> PAUSE or
> > > RESUME for this signalling point as you have described.
> > >
> > > Also I would expect the MTP User on the ASP to have some method
> other
> > > than generating User Messages to determine the route availability.
> Is it
> > > really the case that they have to send user messages to the SG and
> wait
> > > and see whether the SG responds with DAUD?
> > >
> > > I would expect either one or the other of the following to be
> followed.
> > >
> > > 1) Presume available:
> > > If the AS is active then M3UA on the ASP presumes the route to the
> > > SG/STP is available and generates a RESUME to the AS.
> > >
> > > 2) Treat like any other Route:
> > > The AS does not presume the route to the SG/STP is available but
> must
> > > treat the Signalling Point like any other by generating DAUD and
> > > responding to DAVA and DUNA messages.
> > >
> > > Cheers
> > >
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > Sent: 01 September 2008 18:03
> > > To: Howard May
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > >
> > > Howard,
> > >
> > > In general, there is nothing stopping an MTP User from sending a
> > > message for a destination, event if it has received an MTP-PAUSE.
> > > Therefore, an ASP can send a message to 'Alpha' regardless of
> > > whether it has received DUNA or DAVA.  MTP at the SG should treat
> > > the ASP like any ohter MTP user or MTP peer and reissue a DUNA
> > > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable
> > > destination, or once every T8 for a peer arrangement).
> > >
> > > --brian
> > >
> > >
> > > Howard May wrote:                            (Mon, 01 Sep 2008
> 10:56:53)
> > > >
> > > >    Hi, I would value some clarification on the following:
> > > >
> > > >
> > > >    Does the M3UA protocol provision for any situation whereby an
> ASP
> > > can
> > > >    route messages for point code `Alpha' to an SG without first
> > > receiving
> > > >    a DAVA for point code `Alpha' from the SG. Specifically if the
> SG
> > > >    terminates messages for PC `Alpha' does M3UA presume the route
> to
> > > >    `Alpha' from the ASP is available as soon as the ASP becomes
> active
> > > on
> > > >    that SG (without the reception of DAVA)?
> > > >
> > > >
> > > >    Or put slightly differently:
> > > >
> > > >    When connecting to an SG/STP such as shown in Figure 1 of RFC
> 4666
> > > >    should the ASP presume to receive DAVA and DUNA indications for
> the
> > > >    Point Code of STP1 in the same manner as it would for any other
> > > Route
> > > >    or is the Point Code of STP1 different? Should the ASP presume
> the
> > > >    Point Code of STP1 is available as soon as the ASP is active on
> > > SG1?
> > > >
> > > >
> > > >    Best Regards
> > > >
> > > >
> > > >    Howard
> > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email protected]
> > > http://www.openss7.org/
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran
>
>
>
>
> --
> Ilie
>



-- 
Ilie

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran