Re: M3UA: ASP Route Availability to SG/STP

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 protected]] 
Sent: Thursday, September 04, 2008 9:27 AM
To: Haresign Lincoln; [email protected]
Cc: [email protected]
Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP

Hi Lincoln,

I reassert my view. See my comments below.

Regards,
Howard

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: 04 September 2008 13:54
> To: Howard May; [email protected]
> Cc: [email protected]
> Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> 
> Howard,
> 
> I don't agree with you.  See my comments below.
> 
> Regards,
> Lincoln
> 
> -----Original Message-----
> From: Howard May [mailto:[email protected]]
> Sent: Thursday, September 04, 2008 8:38 AM
> To: Haresign Lincoln; [email protected]
> Cc: [email protected]
> 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.

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

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

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

> 
> 
> 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).
> 
> [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.
> 
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email protected]]
> > Sent: 03 September 2008 14:49
> > To: Howard May; [email protected]
> > Cc: [email protected]
> > Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > 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 protected] [mailto:[email protected]] On 
> > Behalf Of Howard May
> > Sent: Wednesday, September 03, 2008 9:40 AM
> > To: Haresign Lincoln; [email protected]
> > Cc: [email protected]
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Haresign Lincoln [mailto:[email protected]]
> > > Sent: 03 September 2008 14:07
> > > To: Howard May; [email protected]
> > > Cc: [email protected]
> > > Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > >
> > > 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.
> >
> > Agreed
> >
> > >
> > > 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.
> >
> > 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.
> >
> > >
> > > Regards,
> > > Lincoln
> > >
> > > -----Original Message-----
> > > From: Howard May [mailto:[email protected]]
> > > Sent: Wednesday, September 03, 2008 8:50 AM
> > > To: Haresign Lincoln; [email protected]
> > > Cc: [email protected]
> > > Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > >
> > > 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
> > >
> > >
> > > > -----Original Message-----
> > > > From: Haresign Lincoln [mailto:[email protected]]
> > > > Sent: 03 September 2008 13:35
> > > > To: Howard May; [email protected]
> > > > Cc: [email protected]
> > > > Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > > >
> > > > 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 protected]]
> > > > Sent: Wednesday, September 03, 2008 8:29 AM
> > > > To: Haresign Lincoln; [email protected]
> > > > Cc: [email protected]
> > > > Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > > >
> > > > 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
> > > >
> > > > > -----Original Message-----
> > > > > From: Haresign Lincoln [mailto:[email protected]]
> > > > > Sent: 03 September 2008 13:20
> > > > > To: Howard May; [email protected]
> > > > > Cc: [email protected]
> > > > > Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > > > >
> > > > > 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 protected]
[mailto:[email protected]]
> > On
> > > > > Behalf Of Howard May
> > > > > Sent: Wednesday, September 03, 2008 6:01 AM
> > > > > To: [email protected]
> > > > > Cc: [email protected]
> > > > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> > > > >
> > > > > 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.
> > > > >
> > > > > **********
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > > > > Sent: 02 September 2008 17:03
> > > > > > To: Howard May
> > > > > > Cc: [email protected]
> > > > > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to
SG/STP
> > > > > >
> > > > > > 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
> > > > > > [email protected]
> > > > > > http://www.openss7.org/
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www.ietf.org/mailman/listinfo/sigtran
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/sigtran