Subject: [Sigtran] M3UA: ASP Route Availability to SG/STP

From: "Howard May" <[email-masked]>
Date: Mon, 1 Sep 2008 10:56:53 -0400

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 1 Sep 2008 11:02:54 -0600

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

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

---

From: "Howard May" <[email-masked]>
Date: Tue, 2 Sep 2008 04:47:26 -0400

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-masked]] 
Sent: 01 September 2008 18:03
To: Howard May
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP

Howard,

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 2 Sep 2008 08:04:44 -0600

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)

---

From: "Howard May" <[email-masked]>
Date: Tue, 2 Sep 2008 10:59:07 -0400

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

> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: [email-masked]

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.

> the SG responds with DAUD"?

This was a typo, I meant to say DUNA.

> > >    Does the M3UA protocol provision for any situation whereby an
ASP
> > can
> > >    `Alpha' from the ASP is available as soon as the ASP becomes
active
> > on

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 2 Sep 2008 17:11:15 +0200

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

-- 
Ilie

---

From: "Howard May" <[email-masked]>
Date: Tue, 2 Sep 2008 11:27:33 -0400

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-masked]] 
Sent: 02 September 2008 16:11
To: Howard May
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hello Folks,

Regards

/Ilie

On Tue, Sep 2, 2008 at 4:59 PM, Howard May <[email-masked]>
wrote:

Hi Brian,

Best Regards

Howard

ASP
active

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 2 Sep 2008 10:02:53 -0600

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)

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 2 Sep 2008 18:05:54 +0200

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-masked]> wrote:

> 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-masked]]
> *Sent:* 02 September 2008 16:11
> *To:* Howard May
> *Cc:* [email-masked]; [email-masked]
>
> *Subject:* Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
>
>
> Hello Folks,
>
>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 2 Sep 2008 15:28:45 -0400

one comment inline.

Thanks,
Tolga

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Brian F. G. Bidulock
> Sent: Tuesday, September 02, 2008 12:03 PM
> To: Howard May
> Cc: [email-masked]
[TOLGA]For this type of scenario I still consider SG as
hosting/terminating the MTP3 for the ASP PC. This preserves the M3UA
interface as mimicking MTP3/MTP3-User interface.

---

From: "Howard May" <[email-masked]>
Date: Wed, 3 Sep 2008 06:00:59 -0400

Hi,

I want to ask Sigtran list members / authors opinions about an area of
perceived ambiguity in the M3UA spec.

Brian, at present the reasoning behind your expected ASP behaviour is
based on the MTP3 specs rather than the M3UA specs and an assertion that
M3UA should behave the same. The MTP3 specs clearly identify routes to
adjacent signalling points become available when the direct link set
comes into service at layer 3 (or after restart completes) and the Route
Set Test procedures are not used across the direct link set for the
adjacent signalling point. But the M3UA spec does not define similar
behaviour. M3UA does not seem to discuss any mechanism for route
availability other than reception of DAVA messages.

While I recognise there may be ambiguity, I feel that at present the
specification suggests the adjacent signalling point at the SG/STP
should generate DAVA/DUNA messages and respond to DAUD messages and
should not be presumed to be available following AS Activation.

I am concerned about this perceived ambiguity on account of the
interoperability impact and would value a clear consensus and
clarification as to the expected behaviour.

Best Regards

Howard

**********

Concerning M3UA acting in the role of a restarting MTP. MTP Restart
procedures aim to allow sufficient bandwidth and route synchronisation
prior to the commencement of traffic. They also aim to reduce the time
for restart procedures to complete to allow traffic restart as quickly
as possible. They do this by prohibiting the transfer of traffic in
either direction prior to exchange of TRA messages and by presuming
route availability and exchanging only TFP messages. 

M3UA does not support such mechanisms and so will have to handle traffic
prior to having a fully synchronised routing table risking possible
message loss.

**********

> Sent: 02 September 2008 17:03
> To: Howard May
> Cc: [email-masked]

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 3 Sep 2008 08:20:10 -0400

Howard,

It would seem to me that if the SG responds to an ASP Active message,
that in effect tells the ASP that the SG is available to begin receiving
traffic.  

It's not clear to me.  Are you concerned about the ability of the SG to
begin processing traffic.  Or are you concerned about the
availability/status of all the point codes on the other side of the SG?

Regards,
Lincoln

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Howard May
Sent: Wednesday, September 03, 2008 6:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi,

Best Regards

Howard

**********

**********

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

---

From: "Howard May" <[email-masked]>
Date: Wed, 3 Sep 2008 08:29:26 -0400

Hi Lincoln,

I'm concerned about the availability of the Route to the STP not routes
via the STP. If the STP has point code 'Alpha' then the ASP may have a
route to point code 'Alpha'. It is the availability of this route at the
ASP I am concerned with.

It is clear that routes via the SG/STP will only become active after
receiving DAVA.

Best Regards

> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: 03 September 2008 13:20
> To: Howard May; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> 
> Howard,
>

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 3 Sep 2008 08:34:52 -0400

Howard,

It would seem to me that if the SG acknowledgs the ASP Active message
from the ASP, it implies that the SG is configure and ready to start
receiving traffic from the ASP.  In other words, the M3UA functionality
in the SG can begin to process messages.  This has also been our
experience in networks when interfacing to switches that are acting as
SGs.  

Sometimes we see that the SG does not acknowledge our ASP Active.  This
is usually the case when either the SG is not completely configured and
ready to receive our ASP Active, or the connection is not configured.

I can't imagine why the SG would respond to an ASP Active if it is not
ready to receive traffic.

Regards,
Lincoln

-----Original Message-----
From: Howard May [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2008 8:29 AM
To: Haresign Lincoln; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi Lincoln,

Best Regards

---

From: "Howard May" <[email-masked]>
Date: Wed, 3 Sep 2008 08:49:44 -0400

Hi Lincoln,

I would agree that it is not unlikely that when the SG/STP sends ASP
Active that any user part at the SG/STP is available to receive traffic.

My chief concern is that it is unclear to me whether the M3UA protocol
mandates this.

In the scenario I am concerned with the SG/STP is also acting as an SEP
(perhaps it is providing a GTT service). As such it is offering an SG
service and a distinct SEP service. I could imagine the SG service being
available and not the SEP service.

Best Regards

> Sent: 03 September 2008 13:35
the
> > > A-links) and therefore, as soon as a link in the linkset (in
M3UA's
> > > > whether the SG should respond to DAUD concerning the SG/STPs
Point
> > Code

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 3 Sep 2008 09:07:29 -0400

Howard,

If it is providing GTT service, this is at a layer higher than M3UA/MTP.
If the GTT service (SCCP layer) is not avialable, the SG should respond
with a DUPU upon receipt of a message.  

The MTP restart procedure in the SS7 world does not assure us that the
SCCP layer (GTT functionality) at the STP is available.   I'm not sure
why you are looking for this in the M3UA world.

Regards,
Lincoln

-----Original Message-----
From: Howard May [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2008 8:50 AM
To: Haresign Lincoln; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi Lincoln,

Best Regards

the

M3UA's

Point

---

From: "Howard May" <[email-masked]>
Date: Wed, 3 Sep 2008 09:39:32 -0400

Hi Lincoln,

Comments below. 

This does not address my main concern though which is a perceived
ambiguity in the M3UA specification. Do you feel the specification is
clear about whether the SG/STP (actually SG/STP/SEP) should be presumed
available?

Regards

> Sent: 03 September 2008 14:07

Agreed

> why you are looking for this in the M3UA world.

I'm not. My comments on MTP Restart were in response to comments made by
Brian. I don't believe that the M3UA protocol is able to emulate the
MTP3 restart behaviour. This is not what I'm concerned about right now
though.

> > > It's not clear to me.  Are you concerned about the ability of the
SG
> > to
> > > availability/status of all the point codes on the other side of
the
> > SG?
> > > I want to ask Sigtran list members / authors opinions about an
area
> of
> > > based on the MTP3 specs rather than the M3UA specs and an
assertion
> > that
> > > M3UA should behave the same. The MTP3 specs clearly identify
routes
> to
> > > > 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
as
> a
> > > > the STP, the STP's point code is available.  In SS7, no TFA or
TFP
> > is
can
> > > > association and route traffic to it, dealing, of course, with
any
> > DUNA
> > > > > 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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 3 Sep 2008 09:48:45 -0400

Howard,

It was always my assumption that if the SG responded with an ASP Active
ACK, it was ready.  I never thought otherwise.  I specifically did not
go through the spec to see if this was ambiguous because it seemed
obvious to me.  I can't imagine implementing an SG where the M3UA layer
(which handles the states of point codes) could respond to the ASP
indicating that it is ready when it wasn't really ready.

Regards,
Lincoln 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Howard May
Sent: Wednesday, September 03, 2008 9:40 AM
To: Haresign Lincoln; [email-masked]
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi Lincoln,

Comments below. 

Regards

Agreed

SG
the
area
assertion
routes

that
viewed
as
TFP
can
any
the
the

---

From: "Howard May" <[email-masked]>
Date: Thu, 4 Sep 2008 08:38:13 -0400

Hi Lincoln,

A couple of scenarios where the SG/STP may send ACTIVE_ACK but not wish
to receive traffic for it's Signalling Point is during MTP Restart at
the SG. During Restart the SG/STP is unable to route messages to the
network and the ASP should not route messages to the SG/STP. The other
situation is if the AS is distributed over a number of ASPs and
insufficient ASPs are currently active. In this scenario the SG Should
not route messages to the AS and consequently the AS should be prevented
from routing messages to the SG/STP.

If we do always want the SG/STP to be available (which from the rfc I
don't presume to be the case) then the SG could simply use the DAVA
mechanism. If M3UA introduces an additional mechanism (by which the
Signalling Point is presumed to be available) then the spec must be
clear about this which I don't feel it is (and which is my main
concern).

I don't see any significant improved behaviour by having the route
presumed available as opposed to a DAVA needing to be sent. And in
addition to the issues I've raised above I would add the following two
issues.

1) Having the route to the SG/STP presumed available introduces a
special case for the route requiring additional configuration at the ASP
which would otherwise not be necessary.

2) The network operator administering the SG/STP is now required to
expose additional details of their network, namely the Point Codes used
by the SGs. Operators may wish to hide the structure of their network or
retain the freedom to reassign point codes without reconfiguration of
ASPs.

Best Regards

> Sent: 03 September 2008 14:49
> > > experience in networks when interfacing to switches that are
acting
> > > is usually the case when either the SG is not completely
configured
> > and
> > > via the STP. If the STP has point code 'Alpha' then the ASP may
have
> a
> >
> > > route to point code 'Alpha'. It is the availability of this route
at
> > > > Brian, at present the reasoning behind your expected ASP
behaviour
> > > > comes into service at layer 3 (or after restart completes) and
the
> > > Route
> > > > prior to the commencement of traffic. They also aim to reduce
the
> > time
a
> > > > > 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
> > > > > When an association to an SG/STP becomes available and there
is
> an
> >
> > > > > existing association, or the ASP has sufficient recent
knowledge
> > > > > may still be used to establish the availability of
destinations
> > via
> > > > > case, an association) is available at level 3 directly
connected
> > > > > sent to the SEP on a directly connected A-linkset for the
STP's
> > own

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 4 Sep 2008 08:53:44 -0400

Howard,

I don't agree with you.  See my comments below.

Regards,
Lincoln 

-----Original Message-----
From: Howard May [mailto:[email-masked]] 
Sent: Thursday, September 04, 2008 8:38 AM
To: Haresign Lincoln; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi Lincoln,

A couple of scenarios where the SG/STP may send ACTIVE_ACK but not wish
to receive traffic for it's Signalling Point is during MTP Restart at
the SG. During Restart the SG/STP is unable to route messages to the
network and the ASP should not route messages to the SG/STP. 

[lh] During MTP restart, the level 3 function is avialable to receive
messages destined to it's own point code.  Perhaps you can not route
messages "through" the STP/SG.  But you can certainly send message to
that SG/STP.  If there is some situation where the SG/STP is still
initializing it's L3/M3UA function and it is not prepared to receive
messages destined to it's own point code, it should not yet respond to
an ASP ACTIVE or potentially even an ASP UP.

The other situation is if the AS is distributed over a number of ASPs
and insufficient ASPs are currently active. In this scenario the SG
Should not route messages to the AS and consequently the AS should be
prevented from routing messages to the SG/STP.

[lh]: This is the responsibility of the AS/ASPs.  The SG will never have
knowledge whether there are a sufficient number of ASPs active.  I don't
even know how you would define that.  As soon as the first ASP becomes
ACTIVE, the AS is ACTIVE and ready to receive messages as far as the SG
is concerned.

[lh]: Again, if you don't want the SG/STP to be available, do not
respond to the ASP telling it that you are available.  The DAVA
mechansim is similar to the TFA mechanism.  An STP does not send a TFA
to an adjacent point code telling it that it is available to receive
traffic.  And MTP restart is really designed to have an STP tell it's
neighbors (via TFA and TFP) that other point codes are available that it
routes to.

Best Regards

acting
configured
have
at
behaviour
the

the
a
whenever
available
STP
is
knowledge
destinations
connected
STP's

---

From: "Howard May" <[email-masked]>
Date: Thu, 4 Sep 2008 09:27:23 -0400

Hi Lincoln,

I reassert my view. See my comments below.

Regards,
Howard

> Sent: 04 September 2008 13:54

Q.704 section 9.6.6 says
"All messages received during the restart procedure concerning a local
MTP User (service indicator != 0000 and != 0001) are discarded."

> ACTIVE, the AS is ACTIVE and ready to receive messages as far as the
SG

RFC 4666 section 4.3.4.3

"An SGP or IPSP, upon receipt of an ASP Active message for the first ASP
in a Loadshare AS, MAY choose not to direct traffic to a newly active
ASP until it determines that there are sufficient resources to handle
the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in
the AS).  In this case, the SGP or IPSP SHOULD withhold the Notify
(AS-ACTIVE) until there are sufficient resources."

> > I'm not. My comments on MTP Restart were in response to comments
made
> by
> > > In the scenario I am concerned with the SG/STP is also acting as
an
> > SEP
> > > > Sometimes we see that the SG does not acknowledge our ASP
Active.
> > > This
> > > > I can't imagine why the SG would respond to an ASP Active if it
is
> > not
> > > > > From: [email-masked]
[mailto:[email-masked]]
> > On
> > > > > adjacent signalling points become available when the direct
link
> > set
> > > > > Set Test procedures are not used across the direct link set
for
> > > > > While I recognise there may be ambiguity, I feel that at
present
> > > > > should generate DAVA/DUNA messages and respond to DAUD
messages
> > > > > as possible. They do this by prohibiting the transfer of
traffic
> > in
> > > > > M3UA does not support such mechanisms and so will have to
handle
> > > > traffic
> > > > > > When the first association to an SG/STP pair becomes
available
> > > > > > Nevertheless, the ASP may simply restart traffic to the
SG/STP
> > > > > > 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
> > > > > > Howard May wrote:                            (Tue, 02 Sep
2008
> > > > > 10:59:07)
> > > > > > > as available or whether it should wait for a DAVA. I'm
also
> > > > unclear

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 4 Sep 2008 09:36:46 -0400

Howard,

4.3.4.3.  ASP Active Procedures

   Anytime after the ASP has received an ASP Up Ack message from the SGP
   or IPSP, the ASP MAY send an ASP Active message to the SGP,
   indicating that the ASP is ready to start processing traffic.

........

                                                    If the SGP or IPSP
   receives any Data messages before an ASP Active message is received,
   the SGP or IPSP MAY discard them.  By sending an ASP Active Ack
   message, the SGP or IPSP is now ready to receive and send traffic for
   the related Routing Context(s).

I can only assume that the SGP will only send an ASP Active ACK if it is
ready to start processing traffic.  Otherwise, it should not respond.
To me, this is clearly specified in the RFC.

Regards,
Lincoln

-----Original Message-----
From: Howard May [mailto:[email-masked]] 
Sent: Thursday, September 04, 2008 9:27 AM
To: Haresign Lincoln; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi Lincoln,

Regards,
Howard

Q.704 section 9.6.6 says

RFC 4666 section 4.3.4.3

made
an

Active.
is
link
for
present
messages
traffic
handle
available
SG/STP
is
via
2008
also