Re: 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