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

["Howard May" <howard.may at dialogic.com>]

Hi Lincoln,

I reassert my view. See my comments below.

Regards,
Howard

> -----Original Message-----
> From: Haresign Lincoln [mailto:Lincoln.Haresign at comverse.com]
> Sent: 04 September 2008 13:54
> To: Howard May; bidulock at openss7.org
> Cc: sigtran at ietf.org
> 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:howard.may at dialogic.com]
> Sent: Thursday, September 04, 2008 8:38 AM
> To: Haresign Lincoln; bidulock at openss7.org
> Cc: sigtran at ietf.org
> 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:Lincoln.Haresign at comverse.com]
> > Sent: 03 September 2008 14:49
> > To: Howard May; bidulock at openss7.org
> > Cc: sigtran at ietf.org
> > 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: sigtran-bounces at ietf.org [mailto:sigtran-bounces at ietf.org] On
> > Behalf Of Howard May
> > Sent: Wednesday, September 03, 2008 9:40 AM
> > To: Haresign Lincoln; bidulock at openss7.org
> > Cc: sigtran at ietf.org
> > 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:Lincoln.Haresign at comverse.com]
> > > Sent: 03 September 2008 14:07
> > > To: Howard May; bidulock at openss7.org
> > > Cc: sigtran at ietf.org
> > > 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:howard.may at dialogic.com]
> > > Sent: Wednesday, September 03, 2008 8:50 AM
> > > To: Haresign Lincoln; bidulock at openss7.org
> > > Cc: sigtran at ietf.org
> > > 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:Lincoln.Haresign at comverse.com]
> > > > Sent: 03 September 2008 13:35
> > > > To: Howard May; bidulock at openss7.org
> > > > Cc: sigtran at ietf.org
> > > > 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:howard.may at dialogic.com]
> > > > Sent: Wednesday, September 03, 2008 8:29 AM
> > > > To: Haresign Lincoln; bidulock at openss7.org
> > > > Cc: sigtran at ietf.org
> > > > 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:Lincoln.Haresign at comverse.com]
> > > > > Sent: 03 September 2008 13:20
> > > > > To: Howard May; bidulock at openss7.org
> > > > > Cc: sigtran at ietf.org
> > > > > 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: sigtran-bounces at ietf.org
[mailto:sigtran-bounces at ietf.org]
> > On
> > > > > Behalf Of Howard May
> > > > > Sent: Wednesday, September 03, 2008 6:01 AM
> > > > > To: bidulock at openss7.org
> > > > > Cc: sigtran at ietf.org
> > > > > 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:bidulock at openss7.org]
> > > > > > Sent: 02 September 2008 17:03
> > > > > > To: Howard May
> > > > > > Cc: sigtran at ietf.org
> > > > > > 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
> > > > > > bidulock at openss7.org
> > > > > > http://www.openss7.org/
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > Sigtran at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/sigtran
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran at ietf.org
> > https://www.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
Sigtran at ietf.org
https://www.ietf.org/mailman/listinfo/sigtran