headers
Brian F. G. Bidulock | 1 May 2002 01:01
Favicon

Re: M3UA/SUA Diagnostic Information parameter

Vince,

I disagee with the "MUST" in the IG.  The "SHOULD" in the RFC
is sufficient as it represents the concensus from a long ladder
of discussion on error reporting which prompted Ken to rewrite
these sections.  We all agreed on the current RFC text.  None
of these view are new.  They were all discussed in arriving at
the RFC text.  Put the message in the Diagnotic.  Fill out the
other ERR parameters as required in the RFC.  No offset is needed.
Where a parameter is the cause, the parameter is included in the
message.  If you want to find out where messages have syntactic
errors, use a packet sniffer.  Etherreal works pretty good a those
things I am told.

--brian

Vince Deters wrote:                                         (Tue, 30 Apr 2002 06:40:44)
> 
> 
> "Brian F. G. Bidulock" wrote:
> 
> > Vince,
> >
> > Vince Deters wrote:                                         (Mon, 29 Apr 2002 22:44:54)
> > > Brian,
> > >
> > > "Brian F. G. Bidulock" wrote:
> > >
> > > > Vince,
> > > >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tuexen | 1 May 2002 11:35
Picon

Re: Future Bakeoffs?

Hi Tom,

M2PA will be tested at the SIGTRAN Bakeoff at ETSI, France, to be held
in the 43rd week of 2002. Companies have already shown interest in
testing M2PA at that event.

If you are are interested in participating it would be good if you could
inform Ken Morneault.

Best regards
Michael

On Sunday, April 28, 2002, at 03:48 AM, Tom George wrote:

> Alcatel had planned to host another M2PA interop. But with the economic
> downturn, it is unlikely we will hold an M2PA interop this year.
>
> When we were planning M2PA Interop I, Brian Bidulock offered to let us
> hold it in his garage. We may have to take him up on the offer for II.
> 8-(
>
> tomG.
>
>
> Sandy Smart wrote:
>>
>> Cisco would welcome the opportunity to participate in M2PA, M3UA, and
>> SUA bakeoffs.
>>
>> Sandy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 1 May 2002 12:01
Favicon

Re: Future Bakeoffs?

Tom,

Tom George wrote:                             (Sat, 27 Apr 2002 20:48:42)
> Alcatel had planned to host another M2PA interop. But with the economic
> downturn, it is unlikely we will hold an M2PA interop this year. 
> 
> When we were planning M2PA Interop I, Brian Bidulock offered to let us
> hold it in his garage. We may have to take him up on the offer for II. 
> 8-(

The offer still stands.  Bring your own T-bone and libations
and I'll even fire up the grill. ;)

--brian

> 
> tomG.
> 
> 
> Sandy Smart wrote:
> > 
> > Cisco would welcome the opportunity to participate in M2PA, M3UA, and
> > SUA bakeoffs.
> > 
> > Sandy
>   [...]
> 
> -- 
> * Tom George          972-519-3168           Tom.George <at> alcatel.com   *
> * PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Morneault | 1 May 2002 17:15
Picon
Favicon

Re: Future Bakeoffs?


Tom, Brian,

Of course, you can also hold a M2PA b <at> keoff in Brian's
garage if there is interest.

Ken

At 11:35 AM 5/1/2002 +0200, Michael Tuexen wrote:
>Hi Tom,
>
>M2PA will be tested at the SIGTRAN Bakeoff at ETSI, France, to be held
>in the 43rd week of 2002. Companies have already shown interest in
>testing M2PA at that event.
>
>If you are are interested in participating it would be good if you could
>inform Ken Morneault.
>
>Best regards
>Michael
>
>On Sunday, April 28, 2002, at 03:48 AM, Tom George wrote:
>
>>Alcatel had planned to host another M2PA interop. But with the economic
>>downturn, it is unlikely we will hold an M2PA interop this year.
>>
>>When we were planning M2PA Interop I, Brian Bidulock offered to let us
>>hold it in his garage. We may have to take him up on the offer for II.
>>8-(
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Morneault | 1 May 2002 17:34
Picon
Favicon

Re: M3UA/SUA Diagnostic Information parameter


The "MUST" was added for invalid message type and
message class errors so that the receiver of the Error
Indication could correlate the error.  This was one of
the outcomes of the plugtest and was discussed on
the list.

Ken

At 06:01 PM 4/30/2002 -0500, Brian F. G. Bidulock wrote:
>Vince,
>
>I disagee with the "MUST" in the IG.  The "SHOULD" in the RFC
>is sufficient as it represents the concensus from a long ladder
>of discussion on error reporting which prompted Ken to rewrite
>these sections.  We all agreed on the current RFC text.  None
>of these view are new.  They were all discussed in arriving at
>the RFC text.  Put the message in the Diagnotic.  Fill out the
>other ERR parameters as required in the RFC.  No offset is needed.
>Where a parameter is the cause, the parameter is included in the
>message.  If you want to find out where messages have syntactic
>errors, use a packet sniffer.  Etherreal works pretty good a those
>things I am told.
>
>--brian
>
>Vince Deters wrote:                                         (Tue, 30 Apr 2002 06:40:44)
>> 
>> 
>> "Brian F. G. Bidulock" wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lamberton, Marc | 2 May 2002 11:00
Picon
Favicon

SUA: GTT function placement

Hi all,

In the SUA draft the GT Translation function is positioned in the "SG as relay-point". This is clear for
inbound messages coming from the SS7 network with "route on GT" in their called address. 

For outbound messages (from AS/ASP to SS7) it might be possible to perform the GTT either in the SG or in the
ASP. In a multiple SG's configuration, it seems that GTT is required in the ASP to perform SG selection; if
the ASP is connected to multiple SG's; the ASP can store the availability of remote PC/SSN thru each SG, and
then use this information to perform SG selection. For outbound messages with "route on GT" in the called
address, the ASP must perform the GTT to derive a PC, and then select a SG capable to reach that PC. 

If the ASP performs a GTT on outbound messages, it would be nice to add the derived PC into the SUA message
called address, and then the SGP uses that PC for the MTP3 DPC. Can we assume that a SGP receiving a message
from an ASP with a called address containing [RI="route on GT" , a GT, and a PC] will not perform its own GTT
and will use that DPC value for the MTP3 header ?

Do you foresee any other issues or advantages to do the GTT in the ASP as well ?

Marc Lamberton
Compaq TPU
marc.lamberton <at> compaq.com
Tel. (33)4 9295 5598
Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 2 May 2002 12:05
Favicon

Re: SUA: GTT function placement

Marc,

GTT is not required in the ASP to perform SG selection, just as it is not
required in an SEP to perform STP selection.  SCCP does not keep track of
the availability of remote subsystems on a per-route (per-STP) basis.  It
is both appropriate and adequate for the ASP to loadshare outgoing requests
with GT only over the available SGs, just as an SEP does to the GTT function
in a mated STP pair.

--brian

Lamberton, Marc wrote:                                 (Thu, 02 May 2002 11:00:44)
> Hi all,
> 
> In the SUA draft the GT Translation function is positioned in the "SG as
> relay-point". This is clear for inbound messages coming from the SS7 network
> with "route on GT" in their called address. 
> 
> For outbound messages (from AS/ASP to SS7) it might be possible to perform
> the GTT either in the SG or in the ASP. In a multiple SG's configuration, it
> seems that GTT is required in the ASP to perform SG selection; if the ASP is
> connected to multiple SG's; the ASP can store the availability of remote
> PC/SSN thru each SG, and then use this information to perform SG selection.
> For outbound messages with "route on GT" in the called address, the ASP must
> perform the GTT to derive a PC, and then select a SG capable to reach that
> PC. 
> 
> If the ASP performs a GTT on outbound messages, it would be nice to add the
> derived PC into the SUA message called address, and then the SGP uses that
> PC for the MTP3 DPC. Can we assume that a SGP receiving a message from an
(Continue reading)

Permalink | Reply | 0 comments |
headers
samahajan | 2 May 2002 13:05

Re: SUA: GTT function placement


Hi Marc,

Please see some comments below ..

Best Regards,
-Sandeep

"Lamberton, Marc" <Marc.Lamberton <at> Compaq.com> on 05/02/2002 03:30:44 PM

To:   sigtran <at> ietf.org
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  [Sigtran] SUA: GTT function placement

Hi all,

In the SUA draft the GT Translation function is positioned in the "SG as
relay-point". This is clear for inbound messages coming from the SS7 network
with "route on GT" in their called address.

For outbound messages (from AS/ASP to SS7) it might be possible to perform the
GTT either in the SG or in the ASP. In a multiple SG's configuration, it seems
that GTT is required in the ASP to perform SG selection; if the ASP is connected
to multiple SG's; the ASP can store the availability of remote PC/SSN thru each
SG, and then use this information to perform SG selection. For outbound messages
with "route on GT" in the called address, the ASP must perform the GTT to derive
a PC, and then select a SG capable to reach that PC.
Sandeep >> This sounds reasonable to me, a small comment
According to section 2.3.2 of Q.714 if SCCP receives message from local User
(Continue reading)

Permalink | Reply | 1 comment |
headers
Garnero, Pierre | 2 May 2002 13:20
Picon
Favicon

RE: SUA: GTT function placement

Brian,

it seems that you assume in your response that each SG will
have exactly the same ss7 network view, that is, they share the
same status for each point code in the ss7 network.
But, may be, this is too restrictive and I suppose that it is
possible to have the following case:
  . one SG see a particular PC (say PC1) as accessible
  . and the other, see the same PC as inaccessible

In this case, it could be interesting for the AS to select
the "right" SG, the one for which PC1 is accessible. And, then, 
the AS must rely on a GT translation to find PC1 and
figures out that a message for PC1 must be forwarded
by a particular SG...

/Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock <at> openss7.org]
> Sent: Thursday, May 02, 2002 12:06 PM
> To: Lamberton, Marc
> Cc: sigtran <at> ietf.org
> Subject: Re: [Sigtran] SUA: GTT function placement
> 
> 
> Marc,
> 
> GTT is not required in the ASP to perform SG selection, just 
> as it is not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 2 May 2002 13:28
Favicon

Re: SUA: GTT function placement

Sandeep,

Please see comments below...

samahajan <at> hss.hns.com wrote:                            (Thu, 02 May 2002 16:35:01)
-X-snip-X-
> 
> > For outbound messages (from AS/ASP to SS7) it might be possible to perform the
> > GTT either in the SG or in the ASP. In a multiple SG's configuration, it seems
> > that GTT is required in the ASP to perform SG selection; if the ASP is connected
> > to multiple SG's; the ASP can store the availability of remote PC/SSN thru each
> > SG, and then use this information to perform SG selection. For outbound messages
> > with "route on GT" in the called address, the ASP must perform the GTT to derive
> > a PC, and then select a SG capable to reach that PC.

> Sandeep >> This sounds reasonable to me, a small comment
> According to section 2.3.2 of Q.714 if SCCP receives message from local User
> with RI = "Route on GT" and point code included in the called address parameter
> is not the local point code, SCCP should send the message to node serving that
> point code. If point code is not included in the address parameter or point code
> included is the local point code translation should be performed in the local
> Node. If we apply the same to SUA also ( which I think we should) GTT may
> conditionally be performed at ASP.

That would be a rather pschyzophrenic GTT function: half performed at ASP,
half performed at SG.  There is no need to perform GTT at the ASP, the CDPA
is sent to the SG and the SG performs GTT.

> > 
> > If the ASP performs a GTT on outbound messages, it would be nice to add the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane