[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 routFrom sigtran-bounces at ietf.org Thu Sep 4 05:54:52 2008
Return-Path: <sigtran-bounces at ietf.org>
X-Original-To: sigtran-archive at megatron.ietf.org
Delivered-To: ietfarch-sigtran-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 159CD3A6AFB;
Thu, 4 Sep 2008 05:54:52 -0700 (PDT)
X-Original-To: sigtran at core3.amsl.com
Delivered-To: sigtran at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9172B3A67F3
for <sigtran at core3.amsl.com>; Thu, 4 Sep 2008 05:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Level:
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.263,
BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 4F+z81bEZBoV for <sigtran at core3.amsl.com>;
Thu, 4 Sep 2008 05:54:41 -0700 (PDT)
Received: from ns6.comverse.com (ironport.comverse.com [192.118.49.220])
by core3.amsl.com (Postfix) with ESMTP id EF6343A6A8C
for <sigtran at ietf.org>; Thu, 4 Sep 2008 05:54:39 -0700 (PDT)
X-SBRS: None
X-IronPort-AV: E=Sophos;i="4.32,320,1217797200"; d="scan'208";a="198772456"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 4 Sep 2008 08:53:44 -0400
Message-ID: <849535E338E99741B7F7413F73253EDB091E975C at us-nj-mail1.comverse.com>
In-Reply-To: <E096369D937D3A4DB271B382850C5C5F07D2B58A at pysmail.eicon.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP
Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7CbgAACKzgAAJ8JaIAAIb1og
References: <E096369D937D3A4DB271B382850C5C5F07C81979 at pysmail.eicon.com><20080901170254.GA19609 at openss7.org><E096369D937D3A4DB271B382850C5C5F07C81A4C at pysmail.eicon.com><20080902140444.GA24137 at openss7.org><E096369D937D3A4DB271B382850C5C5F07C81F4F at pysmail.eicon.com><20080902160253.GA28729 at openss7.org><E096369D937D3A4DB271B382850C5C5F07CDB140 at pysmail.eicon.com><849535E338E99741B7F7413F73253EDB091B3932 at us-nj-mail1.comverse.com><E096369D937D3A4DB271B382850C5C5F07CDB245 at pysmail.eicon.com><849535E338E99741B7F7413F73253EDB091B3948 at us-nj-mail1.comverse.com><E096369D937D3A4DB271B382850C5C5F07CDB2B3 at pysmail.eicon.com><849535E338E99741B7F7413F73253EDB091B3983 at us-nj-mail1.comverse.com>
<E096369D937D3A4DB271B382850C5C5F07CDB40D at pysmail.eicon.com>
<849535E338E99741B7F7413F73253EDB091B3A13 at us-nj-mail1.comverse.com>
<E096369D937D3A4DB271B382850C5C5F07D2B58A at pysmail.eicon.com>
From: "Haresign Lincoln" <Lincoln.Haresign at comverse.com>
To: "Howard May" <howard.may at dialogic.com>,
<bidulock at openss7.org>
Cc: sigtran at ietf.org
Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
X-BeenThere: sigtran at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>,
<mailto:sigtran-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran at ietf.org>
List-Help: <mailto:sigtran-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>,
<mailto:sigtran-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sigtran-bounces at ietf.org
Errors-To: sigtran-bounces at ietf.org
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 message 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.
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: [es 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.
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]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 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 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)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 AS, 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
P 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