M3UA: ASP Route Availability to SG/STP

[Howard May]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Brian F. G. Bidulock]

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
> Sigtran@...
> https://www.ietf.org/mailman/listinfo/sigtran


--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Howard May]

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:bidulock@...]
Sent: 01 September 2008 18:03
To: Howard May
Cc: sigtran@...
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
> Sigtran@...
> https://www.ietf.org/mailman/listinfo/sigtran


--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Brian F. G. Bidulock]

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.

Also, SG do not issue DAUD, so what did you mean by "see whether
the SG responds with DAUD"?

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:bidulock@...]
> Sent: 01 September 2008 18:03
> To: Howard May
> Cc: sigtran@...
> 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
> > Sigtran@...
> > https://www.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Howard May]

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:bidulock@...]
> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@...
> 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:bidulock@...]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran@...
> > 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
> > > Sigtran@...
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@...
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Ilie Glib]

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 <howard.may@...> 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:bidulock@...]

> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@...
> 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:bidulock@...]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran@...
> > 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
> > > Sigtran@...
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@...
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

--
Ilie

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Howard May]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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:ilie.glib@...]
Sent: 02 September 2008 16:11
To: Howard May
Cc: bidulock@...; sigtran@...
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 <howard.may@...> 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:bidulock@...]

> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@...
> 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:bidulock@...]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran@...
> > 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
> > > Sigtran@...
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@...
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

--
Ilie

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Brian F. G. Bidulock]

Howard,

There are three scenarios:  ASP/SG, multiple SG as STP and IPSP.
I think that you are talking of the multiple SG as STP case.

For the multiple SG as STP scenario, the ASP can be viewed as
a separate SEP with its own signalling point code distinct from
that of the STP point codes.  The associations to the SG/STP can
be viewed as a linkset.  The STP signalling point codes can be
viewed as adjacent STP.  In the normal SS7 case where the SEP is
connected by A-links, the STP signalling point codes are treated
as available whenever a signalling link in the directly connecting
link set is available at level 3, or whenever a routeset to the
STP via the alternate STP is available.

When the first association to an SG/STP pair becomes available to
carry traffic (AS-ACTIVE), the ASP is acting in the role of a
restarting MTP at an SEP.  Instead of traffic restart messages,
the M3UA at the ASP can use the DAUD procedure to effect MTP
restart.  When an association to an SG/STP becomes available and
there is an existing association, or the ASP has sufficient recent
knowledge of routing, the ASP is not a restarting MTP however the
DAUD procedure may still be used to establish the availability
of destinations via the SG/STP before starting or restarting
traffic to the SG/STP.  Nevertheless, the ASP may simply restart
traffic to the SG/STP and handle whatever DUNA messages it
receives as a result of restarting traffic instead of using the
DAUD procedures.

As regards the point code of the STP itself: the ASP is acting
as a directly connected SEP (as though it was connecting using
A-links) and therefore, as soon as a link in the linkset (in
M3UA's case, an association) is available at level 3 directly
connected to the STP, the STP's point code is available.  In
SS7, no TFA or TFP is sent to the SEP on a directly connected
A-linkset for the STP's own point code, only for point codes
available via the STP.

So, yes, the ASP acting as an SEP in a multiple SG as STP case
can assume that once it has an association to the SG/STP and is
AS-ACTIVE for traffic via that SG/STP, it can assume that the
SG/STP's point code is available.  However, the point I was
trying to make is that the ASP can simply assume that any point
code is available via an association and route traffic to it,
dealing, of course, with any DUNA that it receives regarding
the traffic it sends.

--brian


Howard May wrote:                            (Tue, 02 Sep 2008 10:59:07)

> 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

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Ilie Glib]

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 <howard.may@...> 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:ilie.glib@...]
Sent: 02 September 2008 16:11
To: Howard May
Cc: bidulock@...; sigtran@...

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 <howard.may@...> 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:bidulock@...]

> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@...
> 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:bidulock@...]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran@...
> > 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
> > > Sigtran@...
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@...
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

--
Ilie

--
Ilie

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran