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