Re: M3UA: ASP Route Availability to SG/STP

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

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