From sigtran-bounces@ietf.org Mon Sep 1 07:58:38 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0F03A6A1F; Mon, 1 Sep 2008 07:58:38 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6C33A6877 for ; Mon, 1 Sep 2008 07:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.345 X-Spam-Level: *** X-Spam-Status: No, score=3.345 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 yYUJb-Gkr1sq for ; Mon, 1 Sep 2008 07:58:36 -0700 (PDT) Received: from EICONMTL.eicon.com (unknown [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 29A203A69EA for ; Mon, 1 Sep 2008 07:57:13 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Sep 2008 10:56:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 10:56:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M3UA: ASP Route Availability to SG/STP Thread-Index: AckMQvjLAByAUx8IQY2xfO1fh3qWoQ== From: "Howard May" To: X-OriginalArrivalTime: 01 Sep 2008 14:56:54.0893 (UTC) FILETIME=[F96EC1D0:01C90C42] Subject: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116043916==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============2116043916== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90C42.F91D483A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C90C42.F91D483A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would value some clarification on the following: =20 Does the M3UA protocol provision for any situation whereby an ASP can route messages for point code `Alpha' to an SG without first receiving a DAVA for point code `Alpha' from the SG. Specifically if the SG terminates messages for PC `Alpha' does M3UA presume the route to `Alpha' from the ASP is available as soon as the ASP becomes active on that SG (without the reception of DAVA)? =20 Or put slightly differently:=20 When connecting to an SG/STP such as shown in Figure 1 of RFC 4666 should the ASP presume to receive DAVA and DUNA indications for the Point Code of STP1 in the same manner as it would for any other Route or is the Point Code of STP1 different? Should the ASP presume the Point Code of STP1 is available as soon as the ASP is active on SG1? =20 Best Regards =20 Howard ------_=_NextPart_001_01C90C42.F91D483A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, I would value = some clarification on the following:

 

Does the M3UA = protocol provision for any situation whereby an ASP can route messages for point = code `Alpha' to an SG without first receiving a DAVA for point code `Alpha' = from the SG. Specifically if the SG terminates messages for PC `Alpha' does M3UA = presume the route to `Alpha' from the ASP is available as soon as the ASP = becomes active on that SG (without the reception of = DAVA)?

 

Or put slightly = differently:

When connecting to = an SG/STP such as shown in Figure 1 of RFC 4666 should the ASP presume to receive = DAVA and DUNA indications for the Point Code of STP1 in the same manner as it = would for any other Route or is the Point Code of STP1 different? Should the = ASP presume the Point Code of STP1 is available as soon as the ASP is active = on SG1?

 

Best Regards

 

Howard

------_=_NextPart_001_01C90C42.F91D483A-- --===============2116043916== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --===============2116043916==-- From sigtran-bounces@ietf.org Mon Sep 1 10:02:56 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356FB3A6956; Mon, 1 Sep 2008 10:02:56 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6818A3A6956 for ; Mon, 1 Sep 2008 10:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 cXyTEoPimC8Y for ; Mon, 1 Sep 2008 10:02:54 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 651003A686C for ; Mon, 1 Sep 2008 10:02:54 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:kaZGQj73qMn18OEdTupWm18umajWPY1z@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id m81H2tpp000635; Mon, 1 Sep 2008 11:02:55 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:LEX4mAq7E1ZDafG7z8IY/GycOnKk1CNW@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id m81H2tLh019827; Mon, 1 Sep 2008 11:02:55 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id m81H2sg0019826; Mon, 1 Sep 2008 11:02:54 -0600 Date: Mon, 1 Sep 2008 11:02:54 -0600 From: "Brian F. G. Bidulock" To: Howard May Message-ID: <20080901170254.GA19609@openss7.org> Mail-Followup-To: Howard May , sigtran@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Howard, In general, there is nothing stopping an MTP User from sending a message for a destination, event if it has received an MTP-PAUSE. Therefore, an ASP can send a message to 'Alpha' regardless of whether it has received DUNA or DAVA. MTP at the SG should treat the ASP like any ohter MTP user or MTP peer and reissue a DUNA (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable destination, or once every T8 for a peer arrangement). --brian Howard May wrote: (Mon, 01 Sep 2008 10:56:53) > > Hi, I would value some clarification on the following: > > > Does the M3UA protocol provision for any situation whereby an ASP can > route messages for point code `Alpha' to an SG without first receiving > a DAVA for point code `Alpha' from the SG. Specifically if the SG > terminates messages for PC `Alpha' does M3UA presume the route to > `Alpha' from the ASP is available as soon as the ASP becomes active on > that SG (without the reception of DAVA)? > > > Or put slightly differently: > > When connecting to an SG/STP such as shown in Figure 1 of RFC 4666 > should the ASP presume to receive DAVA and DUNA indications for the > Point Code of STP1 in the same manner as it would for any other Route > or is the Point Code of STP1 different? Should the ASP presume the > Point Code of STP1 is available as soon as the ASP is active on SG1? > > > Best Regards > > > Howard > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Sep 2 01:47:39 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1693F3A6B85; Tue, 2 Sep 2008 01:47:39 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CCD3A6B86 for ; Tue, 2 Sep 2008 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.673 X-Spam-Level: X-Spam-Status: No, score=0.673 tagged_above=-999 required=5 tests=[AWL=2.672, 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 2Z2ICm8qu7GF for ; Tue, 2 Sep 2008 01:47:37 -0700 (PDT) Received: from EICONMTL.eicon.com (eiconmtl.eicon.com [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 345FA28C181 for ; Tue, 2 Sep 2008 01:47:22 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 04:47:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 04:47:26 -0400 Message-ID: In-Reply-To: <20080901170254.GA19609@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckMVJXGgWOgcuflQZW6Vf5iGVsIVgAgIyQg References: <20080901170254.GA19609@openss7.org> From: "Howard May" To: X-OriginalArrivalTime: 02 Sep 2008 08:47:29.0064 (UTC) FILETIME=[87FB6A80:01C90CD8] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi, MTP normally generates PAUSE and RESUME indications for Routes it maintains to remote signalling points. In this situation the signalling point in question is it's own signalling point for which it does not normally have a route defined nor generate PAUSE and RESUME indications. Consequently I don't believe it is normal for MTP to generate a PAUSE or RESUME for this signalling point as you have described. Also I would expect the MTP User on the ASP to have some method other than generating User Messages to determine the route availability. Is it really the case that they have to send user messages to the SG and wait and see whether the SG responds with DAUD? I would expect either one or the other of the following to be followed. 1) Presume available: If the AS is active then M3UA on the ASP presumes the route to the SG/STP is available and generates a RESUME to the AS. 2) Treat like any other Route: The AS does not presume the route to the SG/STP is available but must treat the Signalling Point like any other by generating DAUD and responding to DAVA and DUNA messages. Cheers -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: 01 September 2008 18:03 To: Howard May Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP Howard, In general, there is nothing stopping an MTP User from sending a message for a destination, event if it has received an MTP-PAUSE. Therefore, an ASP can send a message to 'Alpha' regardless of whether it has received DUNA or DAVA. MTP at the SG should treat the ASP like any ohter MTP user or MTP peer and reissue a DUNA (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable destination, or once every T8 for a peer arrangement). --brian Howard May wrote: (Mon, 01 Sep 2008 10:56:53) > > Hi, I would value some clarification on the following: > > > Does the M3UA protocol provision for any situation whereby an ASP can > route messages for point code `Alpha' to an SG without first receiving > a DAVA for point code `Alpha' from the SG. Specifically if the SG > terminates messages for PC `Alpha' does M3UA presume the route to > `Alpha' from the ASP is available as soon as the ASP becomes active on > that SG (without the reception of DAVA)? > > > Or put slightly differently: > > When connecting to an SG/STP such as shown in Figure 1 of RFC 4666 > should the ASP presume to receive DAVA and DUNA indications for the > Point Code of STP1 in the same manner as it would for any other Route > or is the Point Code of STP1 different? Should the ASP presume the > Point Code of STP1 is available as soon as the ASP is active on SG1? > > > Best Regards > > > Howard > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Sep 2 07:05:14 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D5C28C15F; Tue, 2 Sep 2008 07:05:14 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6164728C15F for ; Tue, 2 Sep 2008 07:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 aB+6YHgwsnxs for ; Tue, 2 Sep 2008 07:05:12 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 3BB293A6ACE for ; Tue, 2 Sep 2008 07:05:12 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:w6kY6yDKHZLyfnc7/XI0dYAy4couRVeb@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id m82E4juI022528; Tue, 2 Sep 2008 08:04:45 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:15H1Y4N8mAMAM9JDK9USaq0bmQtt8p1D@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id m82E4iUO025838; Tue, 2 Sep 2008 08:04:44 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id m82E4idR025837; Tue, 2 Sep 2008 08:04:44 -0600 Date: Tue, 2 Sep 2008 08:04:44 -0600 From: "Brian F. G. Bidulock" To: Howard May Message-ID: <20080902140444.GA24137@openss7.org> Mail-Followup-To: Howard May , sigtran@ietf.org References: <20080901170254.GA19609@openss7.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Howard, I didn't say that an MTP-User at a signalling point receives an MTP-PAUSE for its own point code. What I was saying is that an MTP-User at a signalling point can always generate an MTP-TRANSFER primitive for a given destination regardless of whether it has received an MTP-PAUSE for that destination. Also, SG do not issue DAUD, so what did you mean by "see whether the SG responds with DAUD"? DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this situation, and they represent the status of the signalling point in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE for its own signalling point code. Precisely when M3UA sends a DAVA and DUNA however, is largely part of the NIF and out of scope of the RFC. Achieving transparency with SS7 requires first a knowledge of how SS7 behaves. --brian Howard May wrote: (Tue, 02 Sep 2008 04:47:26) > Hi, > > MTP normally generates PAUSE and RESUME indications for Routes it > maintains to remote signalling points. In this situation the signalling > point in question is it's own signalling point for which it does not > normally have a route defined nor generate PAUSE and RESUME indications. > Consequently I don't believe it is normal for MTP to generate a PAUSE or > RESUME for this signalling point as you have described. > > Also I would expect the MTP User on the ASP to have some method other > than generating User Messages to determine the route availability. Is it > really the case that they have to send user messages to the SG and wait > and see whether the SG responds with DAUD? > > I would expect either one or the other of the following to be followed. > > 1) Presume available: > If the AS is active then M3UA on the ASP presumes the route to the > SG/STP is available and generates a RESUME to the AS. > > 2) Treat like any other Route: > The AS does not presume the route to the SG/STP is available but must > treat the Signalling Point like any other by generating DAUD and > responding to DAVA and DUNA messages. > > Cheers > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: 01 September 2008 18:03 > To: Howard May > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > Howard, > > In general, there is nothing stopping an MTP User from sending a > message for a destination, event if it has received an MTP-PAUSE. > Therefore, an ASP can send a message to 'Alpha' regardless of > whether it has received DUNA or DAVA. MTP at the SG should treat > the ASP like any ohter MTP user or MTP peer and reissue a DUNA > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable > destination, or once every T8 for a peer arrangement). > > --brian > > > Howard May wrote: (Mon, 01 Sep 2008 10:56:53) > > > > Hi, I would value some clarification on the following: > > > > > > Does the M3UA protocol provision for any situation whereby an ASP > can > > route messages for point code `Alpha' to an SG without first > receiving > > a DAVA for point code `Alpha' from the SG. Specifically if the SG > > terminates messages for PC `Alpha' does M3UA presume the route to > > `Alpha' from the ASP is available as soon as the ASP becomes active > on > > that SG (without the reception of DAVA)? > > > > > > Or put slightly differently: > > > > When connecting to an SG/STP such as shown in Figure 1 of RFC 4666 > > should the ASP presume to receive DAVA and DUNA indications for the > > Point Code of STP1 in the same manner as it would for any other > Route > > or is the Point Code of STP1 different? Should the ASP presume the > > Point Code of STP1 is available as soon as the ASP is active on > SG1? > > > > > > Best Regards > > > > > > Howard > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Sep 2 07:59:06 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367053A6A96; Tue, 2 Sep 2008 07:59:06 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0815B3A6A7E for ; Tue, 2 Sep 2008 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.834 X-Spam-Level: X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 WN2Ao5fUltur for ; Tue, 2 Sep 2008 07:59:04 -0700 (PDT) Received: from EICONMTL.eicon.com (unknown [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id BF32C3A6A0A for ; Tue, 2 Sep 2008 07:59:03 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 10:59:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 10:59:07 -0400 Message-ID: In-Reply-To: <20080902140444.GA24137@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNBNxzL6R37BrTSbyyJeu3P/MAqAABBVdg References: <20080901170254.GA19609@openss7.org> <20080902140444.GA24137@openss7.org> From: "Howard May" To: X-OriginalArrivalTime: 02 Sep 2008 14:59:09.0540 (UTC) FILETIME=[741A0240:01C90D0C] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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 > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: 02 September 2008 15:05 > To: Howard May > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > Howard, > > I didn't say that an MTP-User at a signalling point receives an > MTP-PAUSE for its own point code. What I was saying is that an > MTP-User at a signalling point can always generate an MTP-TRANSFER > primitive for a given destination regardless of whether it has > received an MTP-PAUSE for that destination. My concern is not with the MTP3 User but rather whether M3UA at the ASP should consider the route to the SG/STP as available. While an MTP user may generate MTP-TRANSFER primitives after receiving an MTP-PAUSE I'm not sure that either ISUP or SCCP should. Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user should wait for an MTP_RESUME and in the mean time is not allowed to send messages to that signalling point. Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP cannot send messages to the affected exchange. > > Also, SG do not issue DAUD, so what did you mean by "see whether > the SG responds with DAUD"? This was a typo, I meant to say DUNA. > > DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this > situation, and they represent the status of the signalling point > in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE > for its own signalling point code. > > Precisely when M3UA sends a DAVA and DUNA however, is largely > part of the NIF and out of scope of the RFC. Achieving > transparency with SS7 requires first a knowledge of how SS7 > behaves. > > --brian > > Howard May wrote: (Tue, 02 Sep 2008 04:47:26) > > Hi, > > > > MTP normally generates PAUSE and RESUME indications for Routes it > > maintains to remote signalling points. In this situation the signalling > > point in question is it's own signalling point for which it does not > > normally have a route defined nor generate PAUSE and RESUME indications. > > Consequently I don't believe it is normal for MTP to generate a PAUSE or > > RESUME for this signalling point as you have described. > > > > Also I would expect the MTP User on the ASP to have some method other > > than generating User Messages to determine the route availability. Is it > > really the case that they have to send user messages to the SG and wait > > and see whether the SG responds with DAUD? > > > > I would expect either one or the other of the following to be followed. > > > > 1) Presume available: > > If the AS is active then M3UA on the ASP presumes the route to the > > SG/STP is available and generates a RESUME to the AS. > > > > 2) Treat like any other Route: > > The AS does not presume the route to the SG/STP is available but must > > treat the Signalling Point like any other by generating DAUD and > > responding to DAVA and DUNA messages. > > > > Cheers > > > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: 01 September 2008 18:03 > > To: Howard May > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > Howard, > > > > In general, there is nothing stopping an MTP User from sending a > > message for a destination, event if it has received an MTP-PAUSE. > > Therefore, an ASP can send a message to 'Alpha' regardless of > > whether it has received DUNA or DAVA. MTP at the SG should treat > > the ASP like any ohter MTP user or MTP peer and reissue a DUNA > > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable > > destination, or once every T8 for a peer arrangement). > > > > --brian > > > > > > Howard May wrote: (Mon, 01 Sep 2008 10:56:53) > > > > > > Hi, I would value some clarification on the following: > > > > > > > > > Does the M3UA protocol provision for any situation whereby an ASP > > can > > > route messages for point code `Alpha' to an SG without first > > receiving > > > a DAVA for point code `Alpha' from the SG. Specifically if the SG > > > terminates messages for PC `Alpha' does M3UA presume the route to > > > `Alpha' from the ASP is available as soon as the ASP becomes active > > on > > > that SG (without the reception of DAVA)? > > > > > > > > > Or put slightly differently: > > > > > > When connecting to an SG/STP such as shown in Figure 1 of RFC 4666 > > > should the ASP presume to receive DAVA and DUNA indications for the > > > Point Code of STP1 in the same manner as it would for any other > > Route > > > or is the Point Code of STP1 different? Should the ASP presume the > > > Point Code of STP1 is available as soon as the ASP is active on > > SG1? > > > > > > > > > Best Regards > > > > > > > > > Howard > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Sep 2 08:11:53 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D94D28C105; Tue, 2 Sep 2008 08:11:53 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE9328C105 for ; Tue, 2 Sep 2008 08:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gWchUcWB5sJr for ; Tue, 2 Sep 2008 08:11:50 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by core3.amsl.com (Postfix) with ESMTP id 3B5F23A68CE for ; Tue, 2 Sep 2008 08:11:50 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so1863981wra.17 for ; Tue, 02 Sep 2008 08:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=rJNqBHk/DnN1LDyrAjHrlkv0TP9A28V0P8MzkUV20Q0=; b=KnYB3QOEY4PFtdwA9Z1FcKxJ6MsX46choEsgx/rIwffmRlHP/Cee+Ay9mZNNdyzhkI prAWYXj61xi5ytr7xV2jRBIs+ZeIEzhgfYITELS4WyeWUulZD8IZCJPMaUKPhdfsp5DF qTW8BaNSoKvJmqwKkY+OZf+Pq1kDA8TZuEj8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=t+cI14RlYxDUO3Ld6GvAeIkNCkVWkPBIFemL972RcP0TzEuYuWDBiC7JN/dhM1DueX d2K9EC+QhH0R7yxyfnb4zT5JUeav+Ea7lX4XCCfaaKcdefWSjdfvQZfUgOsr5QLbx24U bqMmKMb+lBeC9fA5ZFFhI23QWAaDjicEgNcco= Received: by 10.90.26.9 with SMTP id 9mr9514503agz.53.1220368276470; Tue, 02 Sep 2008 08:11:16 -0700 (PDT) Received: by 10.90.118.2 with HTTP; Tue, 2 Sep 2008 08:11:15 -0700 (PDT) Message-ID: <17b146d60809020811x60683e42j7238ac143fd40ca1@mail.gmail.com> Date: Tue, 2 Sep 2008 17:11:15 +0200 From: "Ilie Glib" To: "Howard May" In-Reply-To: MIME-Version: 1.0 References: <20080901170254.GA19609@openss7.org> <20080902140444.GA24137@openss7.org> Cc: bidulock@openss7.org, sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132070743==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1132070743== Content-Type: multipart/alternative; boundary="----=_Part_10276_11203838.1220368276448" ------=_Part_10276_11203838.1220368276448 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks, I would say that this specific case is an example of IPSP to IPSP communication, where one of IPSPs is collocated with SGP. So, it shall be another IPSP to IPSP relation (and corresponding SCTP association) which will cary signalling. Regards /Ilie On Tue, Sep 2, 2008 at 4:59 PM, Howard May wrote: > 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 > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: 02 September 2008 15:05 > > To: Howard May > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > Howard, > > > > I didn't say that an MTP-User at a signalling point receives an > > MTP-PAUSE for its own point code. What I was saying is that an > > MTP-User at a signalling point can always generate an MTP-TRANSFER > > primitive for a given destination regardless of whether it has > > received an MTP-PAUSE for that destination. > > My concern is not with the MTP3 User but rather whether M3UA at the ASP > should consider the route to the SG/STP as available. > > While an MTP user may generate MTP-TRANSFER primitives after receiving > an MTP-PAUSE I'm not sure that either ISUP or SCCP should. > > Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user > should wait for an MTP_RESUME and in the mean time is not allowed to > send messages to that signalling point. > > Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP > cannot send messages to the affected exchange. > > > > > Also, SG do not issue DAUD, so what did you mean by "see whether > > the SG responds with DAUD"? > > This was a typo, I meant to say DUNA. > > > > > DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this > > situation, and they represent the status of the signalling point > > in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE > > for its own signalling point code. > > > > Precisely when M3UA sends a DAVA and DUNA however, is largely > > part of the NIF and out of scope of the RFC. Achieving > > transparency with SS7 requires first a knowledge of how SS7 > > behaves. > > > > --brian > > > > Howard May wrote: (Tue, 02 Sep 2008 > 04:47:26) > > > Hi, > > > > > > MTP normally generates PAUSE and RESUME indications for Routes it > > > maintains to remote signalling points. In this situation the > signalling > > > point in question is it's own signalling point for which it does not > > > normally have a route defined nor generate PAUSE and RESUME > indications. > > > Consequently I don't believe it is normal for MTP to generate a > PAUSE or > > > RESUME for this signalling point as you have described. > > > > > > Also I would expect the MTP User on the ASP to have some method > other > > > than generating User Messages to determine the route availability. > Is it > > > really the case that they have to send user messages to the SG and > wait > > > and see whether the SG responds with DAUD? > > > > > > I would expect either one or the other of the following to be > followed. > > > > > > 1) Presume available: > > > If the AS is active then M3UA on the ASP presumes the route to the > > > SG/STP is available and generates a RESUME to the AS. > > > > > > 2) Treat like any other Route: > > > The AS does not presume the route to the SG/STP is available but > must > > > treat the Signalling Point like any other by generating DAUD and > > > responding to DAVA and DUNA messages. > > > > > > Cheers > > > > > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: 01 September 2008 18:03 > > > To: Howard May > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > > > Howard, > > > > > > In general, there is nothing stopping an MTP User from sending a > > > message for a destination, event if it has received an MTP-PAUSE. > > > Therefore, an ASP can send a message to 'Alpha' regardless of > > > whether it has received DUNA or DAVA. MTP at the SG should treat > > > the ASP like any ohter MTP user or MTP peer and reissue a DUNA > > > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable > > > destination, or once every T8 for a peer arrangement). > > > > > > --brian > > > > > > > > > Howard May wrote: (Mon, 01 Sep 2008 > 10:56:53) > > > > > > > > Hi, I would value some clarification on the following: > > > > > > > > > > > > Does the M3UA protocol provision for any situation whereby an > ASP > > > can > > > > route messages for point code `Alpha' to an SG without first > > > receiving > > > > a DAVA for point code `Alpha' from the SG. Specifically if the > SG > > > > terminates messages for PC `Alpha' does M3UA presume the route > to > > > > `Alpha' from the ASP is available as soon as the ASP becomes > active > > > on > > > > that SG (without the reception of DAVA)? > > > > > > > > > > > > Or put slightly differently: > > > > > > > > When connecting to an SG/STP such as shown in Figure 1 of RFC > 4666 > > > > should the ASP presume to receive DAVA and DUNA indications for > the > > > > Point Code of STP1 in the same manner as it would for any other > > > Route > > > > or is the Point Code of STP1 different? Should the ASP presume > the > > > > Point Code of STP1 is available as soon as the ASP is active on > > > SG1? > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Howard > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > > > > > -- > > > Brian F. G. Bidulock > > > bidulock@openss7.org > > > http://www.openss7.org/ > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > -- Ilie ------=_Part_10276_11203838.1220368276448 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello Folks,
 
I would say that this specific case is an example of IPSP to IPSP communication, where one of IPSPs is collocated with SGP.
So, it shall be another IPSP to IPSP relation (and corresponding SCTP association) which will cary signalling.
 
Regards
 
/Ilie

 
On Tue, Sep 2, 2008 at 4:59 PM, Howard May <howard.may@dialogic.com> wrote:
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


> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@ietf.org
> Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
> Howard,
>
> I didn't say that an MTP-User at a signalling point receives an
> MTP-PAUSE for its own point code.  What I was saying is that an
> MTP-User at a signalling point can always generate an MTP-TRANSFER
> primitive for a given destination regardless of whether it has
> received an MTP-PAUSE for that destination.

My concern is not with the MTP3 User but rather whether M3UA at the ASP
should consider the route to the SG/STP as available.

While an MTP user may generate MTP-TRANSFER primitives after receiving
an MTP-PAUSE I'm not sure that either ISUP or SCCP should.

Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user
should wait for an MTP_RESUME and in the mean time is not allowed to
send messages to that signalling point.

Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP
cannot send messages to the affected exchange.

>
> Also, SG do not issue DAUD, so what did you mean by "see whether
> the SG responds with DAUD"?

This was a typo, I meant to say DUNA.

>
> DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this
> situation, and they represent the status of the signalling point
> in the SS7 network.  MTP does not send MTP-RESUME or MTP-PAUSE
> for its own signalling point code.
>
> Precisely when M3UA sends a DAVA and DUNA however, is largely
> part of the NIF and out of scope of the RFC.  Achieving
> transparency with SS7 requires first a knowledge of how SS7
> behaves.
>
> --brian
>
> Howard May wrote:                            (Tue, 02 Sep 2008
04:47:26)
> > Hi,
> >
> > MTP normally generates PAUSE and RESUME indications for Routes it
> > maintains to remote signalling points. In this situation the
signalling
> > point in question is it's own signalling point for which it does not
> > normally have a route defined nor generate PAUSE and RESUME
indications.
> > Consequently I don't believe it is normal for MTP to generate a
PAUSE or
> > RESUME for this signalling point as you have described.
> >
> > Also I would expect the MTP User on the ASP to have some method
other
> > than generating User Messages to determine the route availability.
Is it
> > really the case that they have to send user messages to the SG and
wait
> > and see whether the SG responds with DAUD?
> >
> > I would expect either one or the other of the following to be
followed.
> >
> > 1) Presume available:
> > If the AS is active then M3UA on the ASP presumes the route to the
> > SG/STP is available and generates a RESUME to the AS.
> >
> > 2) Treat like any other Route:
> > The AS does not presume the route to the SG/STP is available but
must
> > treat the Signalling Point like any other by generating DAUD and
> > responding to DAVA and DUNA messages.
> >
> > Cheers
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran@ietf.org
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > Howard,
> >
> > In general, there is nothing stopping an MTP User from sending a
> > message for a destination, event if it has received an MTP-PAUSE.
> > Therefore, an ASP can send a message to 'Alpha' regardless of
> > whether it has received DUNA or DAVA.  MTP at the SG should treat
> > the ASP like any ohter MTP user or MTP peer and reissue a DUNA
> > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable
> > destination, or once every T8 for a peer arrangement).
> >
> > --brian
> >
> >
> > Howard May wrote:                            (Mon, 01 Sep 2008
10:56:53)
> > >
> > >    Hi, I would value some clarification on the following:
> > >
> > >
> > >    Does the M3UA protocol provision for any situation whereby an
ASP
> > can
> > >    route messages for point code `Alpha' to an SG without first
> > receiving
> > >    a DAVA for point code `Alpha' from the SG. Specifically if the
SG
> > >    terminates messages for PC `Alpha' does M3UA presume the route
to
> > >    `Alpha' from the ASP is available as soon as the ASP becomes
active
> > on
> > >    that SG (without the reception of DAVA)?
> > >
> > >
> > >    Or put slightly differently:
> > >
> > >    When connecting to an SG/STP such as shown in Figure 1 of RFC
4666
> > >    should the ASP presume to receive DAVA and DUNA indications for
the
> > >    Point Code of STP1 in the same manner as it would for any other
> > Route
> > >    or is the Point Code of STP1 different? Should the ASP presume
the
> > >    Point Code of STP1 is available as soon as the ASP is active on
> > SG1?
> > >
> > >
> > >    Best Regards
> > >
> > >
> > >    Howard
> >
> > > _______________________________________________
> > > Sigtran mailing list
> > > Sigtran@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@openss7.org
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran



--
Ilie
------=_Part_10276_11203838.1220368276448-- --===============1132070743== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --===============1132070743==-- From sigtran-bounces@ietf.org Tue Sep 2 08:28:09 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DCB28C1A2; Tue, 2 Sep 2008 08:28:09 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F233A689A for ; Tue, 2 Sep 2008 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=1.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jUNlL-AI7XrS for ; Tue, 2 Sep 2008 08:28:03 -0700 (PDT) Received: from EICONMTL.eicon.com (eiconmtl.eicon.com [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 306B528C1BE for ; Tue, 2 Sep 2008 08:27:29 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 11:27:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 11:27:33 -0400 Message-ID: In-Reply-To: <17b146d60809020811x60683e42j7238ac143fd40ca1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNDibXpMWaLtO3SG+om7PGHXIkDQAAW0/Q References: <20080901170254.GA19609@openss7.org> <20080902140444.GA24137@openss7.org> <17b146d60809020811x60683e42j7238ac143fd40ca1@mail.gmail.com> From: "Howard May" To: "Ilie Glib" X-OriginalArrivalTime: 02 Sep 2008 15:27:35.0482 (UTC) FILETIME=[6CEC19A0:01C90D10] Cc: bidulock@openss7.org, sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1404468695==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1404468695== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90D10.6C84C862" This is a multi-part message in MIME format. ------_=_NextPart_001_01C90D10.6C84C862 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ilie, =20 Are you suggesting there should be two associations, one for the ASP <-> SGP relationship and one for the IPSP <-> IPSP relationship, or should there be one association and the ASP presumes that messages for the SG/STP may be sent as soon as the AS is active? =20 =20 =20 ________________________________ From: Ilie Glib [mailto:ilie.glib@googlemail.com]=20 Sent: 02 September 2008 16:11 To: Howard May Cc: bidulock@openss7.org; sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP =20 Hello Folks, =20 I would say that this specific case is an example of IPSP to IPSP communication, where one of IPSPs is collocated with SGP.=20 So, it shall be another IPSP to IPSP relation (and corresponding SCTP association) which will cary signalling. =20 Regards =20 /Ilie =20 On Tue, Sep 2, 2008 at 4:59 PM, Howard May wrote: 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 > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: 02 September 2008 15:05 > To: Howard May > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > Howard, > > I didn't say that an MTP-User at a signalling point receives an > MTP-PAUSE for its own point code. What I was saying is that an > MTP-User at a signalling point can always generate an MTP-TRANSFER > primitive for a given destination regardless of whether it has > received an MTP-PAUSE for that destination. My concern is not with the MTP3 User but rather whether M3UA at the ASP should consider the route to the SG/STP as available. While an MTP user may generate MTP-TRANSFER primitives after receiving an MTP-PAUSE I'm not sure that either ISUP or SCCP should. Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user should wait for an MTP_RESUME and in the mean time is not allowed to send messages to that signalling point. Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP cannot send messages to the affected exchange. > > Also, SG do not issue DAUD, so what did you mean by "see whether > the SG responds with DAUD"? This was a typo, I meant to say DUNA. > > DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this > situation, and they represent the status of the signalling point > in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE > for its own signalling point code. > > Precisely when M3UA sends a DAVA and DUNA however, is largely > part of the NIF and out of scope of the RFC. Achieving > transparency with SS7 requires first a knowledge of how SS7 > behaves. > > --brian > > Howard May wrote: (Tue, 02 Sep 2008 04:47:26) > > Hi, > > > > MTP normally generates PAUSE and RESUME indications for Routes it > > maintains to remote signalling points. In this situation the signalling > > point in question is it's own signalling point for which it does not > > normally have a route defined nor generate PAUSE and RESUME indications. > > Consequently I don't believe it is normal for MTP to generate a PAUSE or > > RESUME for this signalling point as you have described. > > > > Also I would expect the MTP User on the ASP to have some method other > > than generating User Messages to determine the route availability. Is it > > really the case that they have to send user messages to the SG and wait > > and see whether the SG responds with DAUD? > > > > I would expect either one or the other of the following to be followed. > > > > 1) Presume available: > > If the AS is active then M3UA on the ASP presumes the route to the > > SG/STP is available and generates a RESUME to the AS. > > > > 2) Treat like any other Route: > > The AS does not presume the route to the SG/STP is available but must > > treat the Signalling Point like any other by generating DAUD and > > responding to DAVA and DUNA messages. > > > > Cheers > > > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: 01 September 2008 18:03 > > To: Howard May > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > Howard, > > > > In general, there is nothing stopping an MTP User from sending a > > message for a destination, event if it has received an MTP-PAUSE. > > Therefore, an ASP can send a message to 'Alpha' regardless of > > whether it has received DUNA or DAVA. MTP at the SG should treat > > the ASP like any ohter MTP user or MTP peer and reissue a DUNA > > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable > > destination, or once every T8 for a peer arrangement). > > > > --brian > > > > > > Howard May wrote: (Mon, 01 Sep 2008 10:56:53) > > > > > > Hi, I would value some clarification on the following: > > > > > > > > > Does the M3UA protocol provision for any situation whereby an ASP > > can > > > route messages for point code `Alpha' to an SG without first > > receiving > > > a DAVA for point code `Alpha' from the SG. Specifically if the SG > > > terminates messages for PC `Alpha' does M3UA presume the route to > > > `Alpha' from the ASP is available as soon as the ASP becomes active > > on > > > that SG (without the reception of DAVA)? > > > > > > > > > Or put slightly differently: > > > > > > When connecting to an SG/STP such as shown in Figure 1 of RFC 4666 > > > should the ASP presume to receive DAVA and DUNA indications for the > > > Point Code of STP1 in the same manner as it would for any other > > Route > > > or is the Point Code of STP1 different? Should the ASP presume the > > > Point Code of STP1 is available as soon as the ASP is active on > > SG1? > > > > > > > > > Best Regards > > > > > > > > > Howard > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --=20 Ilie ------_=_NextPart_001_01C90D10.6C84C862 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ilie,

 

Are you suggesting there should be = two associations, one for the ASP <-> SGP relationship and one for the = IPSP <-> IPSP relationship, or should there be one association and the ASP = presumes that messages for the SG/STP may be sent as soon as the AS is = active?

 

 

 

From: Ilie Glib [mailto:ilie.glib@googlemail.com]
Sent: 02 September 2008 = 16:11
To: Howard May
Cc: bidulock@openss7.org; sigtran@ietf.org
Subject: Re: [Sigtran] = M3UA: ASP = Route Availability to SG/STP

 

Hello Folks,

 

I would say that this specific case is an example of IPSP to = IPSP communication, where one of IPSPs is collocated with SGP. =

So, it shall be another IPSP to IPSP relation (and = corresponding SCTP association) which will cary signalling.

 

Regards

 

/Ilie


 

On Tue, Sep 2, 2008 at 4:59 PM, Howard May <howard.may@dialogic.com> wrote:

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



> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=

> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@ietf.org
> Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
> Howard,
>

> I didn't = say that an MTP-User at a signalling point receives an
> MTP-PAUSE for its own point code.  What I was saying is that = an
> MTP-User at a signalling point can always generate an = MTP-TRANSFER
> primitive for a given destination regardless of whether it has
> received an MTP-PAUSE for that = destination.

My concern is not with the MTP3 User but rather whether M3UA at = the ASP
should consider the route to the SG/STP as available.

While an MTP user may generate MTP-TRANSFER primitives after = receiving
an MTP-PAUSE I'm not sure that either ISUP or SCCP should.

Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The = user
should wait for an MTP_RESUME and in the mean time is not allowed to
send messages to that signalling point.

Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP
cannot send messages to the affected = exchange.


>
> Also, SG do not issue DAUD, so what did you mean by "see = whether
> the SG responds with DAUD"?

This was a typo, I meant to say = DUNA.


>
> DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in = this
> situation, and they represent the status of the signalling = point
> in the SS7 network.  MTP does not send MTP-RESUME or = MTP-PAUSE
> for its own signalling point code.
>
> Precisely when M3UA sends a DAVA and DUNA however, is largely
> part of the NIF and out of scope of the RFC.  Achieving
> transparency with SS7 requires first a knowledge of how SS7
> behaves.
>
> --brian
>
> Howard May wrote: =                         =    (Tue, 02 Sep 2008
04:47:26)
> > Hi,
> >
> > MTP normally generates PAUSE and RESUME indications for Routes = it
> > maintains to remote signalling points. In this situation = the
signalling
> > point in question is it's own signalling point for which it = does not
> > normally have a route defined nor generate PAUSE and = RESUME
indications.
> > Consequently I don't believe it is normal for MTP to generate = a
PAUSE or
> > RESUME for this signalling point as you have described.
> >
> > Also I would expect the MTP User on the ASP to have some = method
other
> > than generating User Messages to determine the route = availability.
Is it
> > really the case that they have to send user messages to the SG = and
wait
> > and see whether the SG responds with DAUD?
> >
> > I would expect either one or the other of the following to = be
followed.
> >
> > 1) Presume available:
> > If the AS is active then M3UA on the ASP presumes the route to = the
> > SG/STP is available and generates a RESUME to the AS.
> >
> > 2) Treat like any other Route:
> > The AS does not presume the route to the SG/STP is available = but
must
> > treat the Signalling Point like any other by generating DAUD = and
> > responding to DAVA and DUNA messages.
> >
> > Cheers
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> > Sent: 01 September 2008 18:03
> > To: Howard = May
> > Cc: sigtran@ietf.org
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to = SG/STP
> >
> > Howard,
> >
> > In general, there is nothing stopping an MTP User from sending = a
> > message for a destination, event if it has received an = MTP-PAUSE.
> > Therefore, an ASP can send a message to 'Alpha' regardless = of
> > whether it has received DUNA or DAVA.  MTP at the SG = should treat
> > the ASP like any ohter MTP user or MTP peer and reissue a = DUNA
> > (once for every 8 or 10 MTP-TRANSFER primitives for the = unavailable
> > destination, or once every T8 for a peer arrangement).
> >
> > --brian
> >
> >
> > Howard May wrote: =                       =      (Mon, 01 Sep 2008
10:56:53)
> > >
> > >    Hi, I would value some clarification on the following:
> > >
> > >
> > >    Does the M3UA protocol provision for any = situation whereby an
ASP
> > can
> > >    route messages for point code `Alpha' to an = SG without first
> > receiving
> > >    a DAVA for point code `Alpha' from the SG. Specifically if the
SG
> > >    terminates messages for PC `Alpha' does M3UA presume the route
to
> > >    `Alpha' from the ASP is available as soon as = the ASP becomes
active
> > on
> > >    that SG (without the reception of DAVA)?
> > >
> > >
> > >    Or put slightly differently:
> > >
> > >    When connecting to an SG/STP such as shown = in Figure 1 of RFC
4666
> > >    should the ASP presume to receive DAVA and = DUNA indications for
the
> > >    Point Code of STP1 in the same manner as it = would for any other
> > Route
> > >    or is the Point Code of STP1 different? = Should the ASP presume
the
> > >    Point Code of STP1 is available as soon as = the ASP is active on
> > SG1?
> > >
> > >
> > >    Best Regards
> > >
> > >
> > >    Howard
> >
> > > _______________________________________________
> > > Sigtran mailing list
> > > Sigtran@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@openss7.org
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran<= /o:p>




--
Ilie

------_=_NextPart_001_01C90D10.6C84C862-- --===============1404468695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --===============1404468695==-- From sigtran-bounces@ietf.org Tue Sep 2 09:04:03 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C5B3A6BC8; Tue, 2 Sep 2008 09:04:03 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30073A6AA7 for ; Tue, 2 Sep 2008 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 fhXBlGFPy28w for ; Tue, 2 Sep 2008 09:04:01 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id A7C783A69F1 for ; Tue, 2 Sep 2008 09:04:00 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:wH52XiEtng1mvsnamze15Sa4lQPRI3lb@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id m82G2sK6024504; Tue, 2 Sep 2008 10:02:54 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:7h9TTEdGLNcmPiMQNekzjTTNVRgr1iCT@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id m82G2sZf030013; Tue, 2 Sep 2008 10:02:54 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id m82G2rcA030012; Tue, 2 Sep 2008 10:02:53 -0600 Date: Tue, 2 Sep 2008 10:02:53 -0600 From: "Brian F. G. Bidulock" To: Howard May Message-ID: <20080902160253.GA28729@openss7.org> Mail-Followup-To: Howard May , sigtran@ietf.org References: <20080901170254.GA19609@openss7.org> <20080902140444.GA24137@openss7.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Sep 2 09:06:29 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A2728C175; Tue, 2 Sep 2008 09:06:29 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640F33A6AA7 for ; Tue, 2 Sep 2008 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 fQ9Qn+3UrRz1 for ; Tue, 2 Sep 2008 09:06:26 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by core3.amsl.com (Postfix) with ESMTP id 95D803A6AF3 for ; Tue, 2 Sep 2008 09:06:22 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so1885754wra.17 for ; Tue, 02 Sep 2008 09:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=q/tSh2nZv+KxWGpDTmMK/Sa9tcFNE2R14uCOwmM063I=; b=GT50L4+4poZoa7UcoBb5e+bsPus5GATp84kadhksK+IT4o9ghQFBRlJan+7upYOmVb Rk3ASTzoTgv2Ejg/bXLNlJblnJ/O/9Uh8a4AtFQ05BsbvkADJIuyejvq3zpmNzFDyQpO TVPq5gQYOlLoi9f/1mRoj8mRhhU6KjLIfbf+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=S51F1dNDvimONxKTy+3CNEV+6YgOdO1Xb52TAtG9IOkQekT4t8Gn1yPdLJPR/fS0X8 ePoezP8XzJisrZQWr9n9XeprRDVIIboHSnbidAHNj07a85CHEW/ptTR9tAR5NpKQetqF sxrct13jyYE1Sf4vHbNFv7frz+tWhhPrtNeOw= Received: by 10.90.87.7 with SMTP id k7mr9744539agb.101.1220371554139; Tue, 02 Sep 2008 09:05:54 -0700 (PDT) Received: by 10.90.118.2 with HTTP; Tue, 2 Sep 2008 09:05:54 -0700 (PDT) Message-ID: <17b146d60809020905g785ccd04v4d109d38e6e11fe6@mail.gmail.com> Date: Tue, 2 Sep 2008 18:05:54 +0200 From: "Ilie Glib" To: "Howard May" In-Reply-To: MIME-Version: 1.0 References: <20080901170254.GA19609@openss7.org> <20080902140444.GA24137@openss7.org> <17b146d60809020811x60683e42j7238ac143fd40ca1@mail.gmail.com> Cc: bidulock@openss7.org, sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1831594378==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1831594378== Content-Type: multipart/alternative; boundary="----=_Part_11653_8333149.1220371554134" ------=_Part_11653_8333149.1220371554134 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Howard, yes, I am suggesting having another SCTP association carrying corresponding traffic. Regards /Ilie On Tue, Sep 2, 2008 at 5:27 PM, Howard May wrote: > Hi Ilie, > > > > Are you suggesting there should be two associations, one for the ASP <-> > SGP relationship and one for the IPSP <-> IPSP relationship, or should there > be one association and the ASP presumes that messages for the SG/STP may be > sent as soon as the AS is active? > > > > > > > ------------------------------ > > *From:* Ilie Glib [mailto:ilie.glib@googlemail.com] > *Sent:* 02 September 2008 16:11 > *To:* Howard May > *Cc:* bidulock@openss7.org; sigtran@ietf.org > > *Subject:* Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > Hello Folks, > > > > I would say that this specific case is an example of IPSP to IPSP > communication, where one of IPSPs is collocated with SGP. > > So, it shall be another IPSP to IPSP relation (and corresponding SCTP > association) which will cary signalling. > > > > Regards > > > > /Ilie > > > > > On Tue, Sep 2, 2008 at 4:59 PM, Howard May > wrote: > > 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 > > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: 02 September 2008 15:05 > > To: Howard May > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > Howard, > > > > > I didn't say that an MTP-User at a signalling point receives an > > MTP-PAUSE for its own point code. What I was saying is that an > > MTP-User at a signalling point can always generate an MTP-TRANSFER > > primitive for a given destination regardless of whether it has > > received an MTP-PAUSE for that destination. > > My concern is not with the MTP3 User but rather whether M3UA at the ASP > should consider the route to the SG/STP as available. > > While an MTP user may generate MTP-TRANSFER primitives after receiving > an MTP-PAUSE I'm not sure that either ISUP or SCCP should. > > Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user > should wait for an MTP_RESUME and in the mean time is not allowed to > send messages to that signalling point. > > Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP > cannot send messages to the affected exchange. > > > > > > Also, SG do not issue DAUD, so what did you mean by "see whether > > the SG responds with DAUD"? > > This was a typo, I meant to say DUNA. > > > > > > DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this > > situation, and they represent the status of the signalling point > > in the SS7 network. MTP does not send MTP-RESUME or MTP-PAUSE > > for its own signalling point code. > > > > Precisely when M3UA sends a DAVA and DUNA however, is largely > > part of the NIF and out of scope of the RFC. Achieving > > transparency with SS7 requires first a knowledge of how SS7 > > behaves. > > > > --brian > > > > Howard May wrote: (Tue, 02 Sep 2008 > 04:47:26) > > > Hi, > > > > > > MTP normally generates PAUSE and RESUME indications for Routes it > > > maintains to remote signalling points. In this situation the > signalling > > > point in question is it's own signalling point for which it does not > > > normally have a route defined nor generate PAUSE and RESUME > indications. > > > Consequently I don't believe it is normal for MTP to generate a > PAUSE or > > > RESUME for this signalling point as you have described. > > > > > > Also I would expect the MTP User on the ASP to have some method > other > > > than generating User Messages to determine the route availability. > Is it > > > really the case that they have to send user messages to the SG and > wait > > > and see whether the SG responds with DAUD? > > > > > > I would expect either one or the other of the following to be > followed. > > > > > > 1) Presume available: > > > If the AS is active then M3UA on the ASP presumes the route to the > > > SG/STP is available and generates a RESUME to the AS. > > > > > > 2) Treat like any other Route: > > > The AS does not presume the route to the SG/STP is available but > must > > > treat the Signalling Point like any other by generating DAUD and > > > responding to DAVA and DUNA messages. > > > > > > Cheers > > > > > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: 01 September 2008 18:03 > > > To: Howard May > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP > > > > > > Howard, > > > > > > In general, there is nothing stopping an MTP User from sending a > > > message for a destination, event if it has received an MTP-PAUSE. > > > Therefore, an ASP can send a message to 'Alpha' regardless of > > > whether it has received DUNA or DAVA. MTP at the SG should treat > > > the ASP like any ohter MTP user or MTP peer and reissue a DUNA > > > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable > > > destination, or once every T8 for a peer arrangement). > > > > > > --brian > > > > > > > > > Howard May wrote: (Mon, 01 Sep 2008 > 10:56:53) > > > > > > > > Hi, I would value some clarification on the following: > > > > > > > > > > > > Does the M3UA protocol provision for any situation whereby an > ASP > > > can > > > > route messages for point code `Alpha' to an SG without first > > > receiving > > > > a DAVA for point code `Alpha' from the SG. Specifically if the > SG > > > > terminates messages for PC `Alpha' does M3UA presume the route > to > > > > `Alpha' from the ASP is available as soon as the ASP becomes > active > > > on > > > > that SG (without the reception of DAVA)? > > > > > > > > > > > > Or put slightly differently: > > > > > > > > When connecting to an SG/STP such as shown in Figure 1 of RFC > 4666 > > > > should the ASP presume to receive DAVA and DUNA indications for > the > > > > Point Code of STP1 in the same manner as it would for any other > > > Route > > > > or is the Point Code of STP1 different? Should the ASP presume > the > > > > Point Code of STP1 is available as soon as the ASP is active on > > > SG1? > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Howard > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > > > > > -- > > > Brian F. G. Bidulock > > > bidulock@openss7.org > > > http://www.openss7.org/ > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > > > > -- > Ilie > -- Ilie ------=_Part_11653_8333149.1220371554134 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello Howard,
 
yes, I am suggesting having another SCTP association carrying corresponding traffic.
 
Regards
 
/Ilie

On Tue, Sep 2, 2008 at 5:27 PM, Howard May <howard.may@dialogic.com> wrote:

Hi Ilie,

 

Are you suggesting there should be two associations, one for the ASP <-> SGP relationship and one for the IPSP <-> IPSP relationship, or should there be one association and the ASP presumes that messages for the SG/STP may be sent as soon as the AS is active?

 

 

 

From: Ilie Glib [mailto:ilie.glib@googlemail.com]
Sent: 02 September 2008 16:11
To: Howard May
Cc: bidulock@openss7.org; sigtran@ietf.org


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

 

Hello Folks,

 

I would say that this specific case is an example of IPSP to IPSP communication, where one of IPSPs is collocated with SGP.

So, it shall be another IPSP to IPSP relation (and corresponding SCTP association) which will cary signalling.

 

Regards

 

/Ilie


 

On Tue, Sep 2, 2008 at 4:59 PM, Howard May <howard.may@dialogic.com> wrote:

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



> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]

> Sent: 02 September 2008 15:05
> To: Howard May
> Cc: sigtran@ietf.org
> Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
>
> Howard,
>

> I didn't say that an MTP-User at a signalling point receives an
> MTP-PAUSE for its own point code.  What I was saying is that an
> MTP-User at a signalling point can always generate an MTP-TRANSFER
> primitive for a given destination regardless of whether it has
> received an MTP-PAUSE for that destination.

My concern is not with the MTP3 User but rather whether M3UA at the ASP
should consider the route to the SG/STP as available.

While an MTP user may generate MTP-TRANSFER primitives after receiving
an MTP-PAUSE I'm not sure that either ISUP or SCCP should.

Section 7.22 of Q.711 explains that on receipt of an MTP-PAUSE The user
should wait for an MTP_RESUME and in the mean time is not allowed to
send messages to that signalling point.

Section 2.14 of Q.764 explains that on receipt of an MTP_PAUSE ISUP
cannot send messages to the affected exchange.


>
> Also, SG do not issue DAUD, so what did you mean by "see whether
> the SG responds with DAUD"?

This was a typo, I meant to say DUNA.


>
> DAVA and DUNA are equivalent to MTP-RESUME and MTP-PAUSE in this
> situation, and they represent the status of the signalling point
> in the SS7 network.  MTP does not send MTP-RESUME or MTP-PAUSE
> for its own signalling point code.
>
> Precisely when M3UA sends a DAVA and DUNA however, is largely
> part of the NIF and out of scope of the RFC.  Achieving
> transparency with SS7 requires first a knowledge of how SS7
> behaves.
>
> --brian
>
> Howard May wrote:                            (Tue, 02 Sep 2008
04:47:26)
> > Hi,
> >
> > MTP normally generates PAUSE and RESUME indications for Routes it
> > maintains to remote signalling points. In this situation the
signalling
> > point in question is it's own signalling point for which it does not
> > normally have a route defined nor generate PAUSE and RESUME
indications.
> > Consequently I don't believe it is normal for MTP to generate a
PAUSE or
> > RESUME for this signalling point as you have described.
> >
> > Also I would expect the MTP User on the ASP to have some method
other
> > than generating User Messages to determine the route availability.
Is it
> > really the case that they have to send user messages to the SG and
wait
> > and see whether the SG responds with DAUD?
> >
> > I would expect either one or the other of the following to be
followed.
> >
> > 1) Presume available:
> > If the AS is active then M3UA on the ASP presumes the route to the
> > SG/STP is available and generates a RESUME to the AS.
> >
> > 2) Treat like any other Route:
> > The AS does not presume the route to the SG/STP is available but
must
> > treat the Signalling Point like any other by generating DAUD and
> > responding to DAVA and DUNA messages.
> >
> > Cheers
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> > Sent: 01 September 2008 18:03
> > To: Howard May
> > Cc: sigtran@ietf.org
> > Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP
> >
> > Howard,
> >
> > In general, there is nothing stopping an MTP User from sending a
> > message for a destination, event if it has received an MTP-PAUSE.
> > Therefore, an ASP can send a message to 'Alpha' regardless of
> > whether it has received DUNA or DAVA.  MTP at the SG should treat
> > the ASP like any ohter MTP user or MTP peer and reissue a DUNA
> > (once for every 8 or 10 MTP-TRANSFER primitives for the unavailable
> > destination, or once every T8 for a peer arrangement).
> >
> > --brian
> >
> >
> > Howard May wrote:                            (Mon, 01 Sep 2008
10:56:53)
> > >
> > >    Hi, I would value some clarification on the following:
> > >
> > >
> > >    Does the M3UA protocol provision for any situation whereby an
ASP
> > can
> > >    route messages for point code `Alpha' to an SG without first
> > receiving
> > >    a DAVA for point code `Alpha' from the SG. Specifically if the
SG
> > >    terminates messages for PC `Alpha' does M3UA presume the route
to
> > >    `Alpha' from the ASP is available as soon as the ASP becomes
active
> > on
> > >    that SG (without the reception of DAVA)?
> > >
> > >
> > >    Or put slightly differently:
> > >
> > >    When connecting to an SG/STP such as shown in Figure 1 of RFC
4666
> > >    should the ASP presume to receive DAVA and DUNA indications for
the
> > >    Point Code of STP1 in the same manner as it would for any other
> > Route
> > >    or is the Point Code of STP1 different? Should the ASP presume
the
> > >    Point Code of STP1 is available as soon as the ASP is active on
> > SG1?
> > >
> > >
> > >    Best Regards
> > >
> > >
> > >    Howard
> >
> > > _______________________________________________
> > > Sigtran mailing list
> > > Sigtran@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sigtran
> >
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@openss7.org
> > http://www.openss7.org/
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran




--
Ilie




--
Ilie
------=_Part_11653_8333149.1220371554134-- --===============1831594378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --===============1831594378==-- From sigtran-bounces@ietf.org Tue Sep 2 12:29:19 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621563A6A39; Tue, 2 Sep 2008 12:29:19 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6C53A6AC4 for ; Tue, 2 Sep 2008 12:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 dhI9x4TsjoyX for ; Tue, 2 Sep 2008 12:29:17 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id D73603A680A for ; Tue, 2 Sep 2008 12:29:16 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m82JTJ1v023876; Tue, 2 Sep 2008 15:29:19 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 15:28:45 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7014ACC44@sonusmail04.sonusnet.com> In-Reply-To: <20080902160253.GA28729@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFYsHvc+PhS2FS0q5SNW0kkzsdAAG8N6g References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org> <20080902160253.GA28729@openss7.org> From: "Asveren, Tolga" To: , "Howard May" Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org one comment inline. Thanks, Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf > Of Brian F. G. Bidulock > Sent: Tuesday, September 02, 2008 12:03 PM > To: Howard May > Cc: sigtran@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. [TOLGA]For this type of scenario I still consider SG as hosting/terminating the MTP3 for the ASP PC. This preserves the M3UA interface as mimicking MTP3/MTP3-User interface. > > 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@openss7.org > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 03:01:19 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7C33A6C63; Wed, 3 Sep 2008 03:01:19 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FED3A6C6C for ; Wed, 3 Sep 2008 03:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 hwiS+Hq8RWgz for ; Wed, 3 Sep 2008 03:01:17 -0700 (PDT) Received: from EICONMTL.eicon.com (unknown [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 6291B3A6BDD for ; Wed, 3 Sep 2008 03:00:56 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 06:01:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 06:00:59 -0400 Message-ID: In-Reply-To: <20080902160253.GA28729@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFA References: <20080901170254.GA19609@openss7.org> <20080902140444.GA24137@openss7.org> <20080902160253.GA28729@openss7.org> From: "Howard May" To: X-OriginalArrivalTime: 03 Sep 2008 10:01:03.0126 (UTC) FILETIME=[F9619360:01C90DAB] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@openss7.org] > Sent: 02 September 2008 17:03 > To: Howard May > Cc: sigtran@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@openss7.org > http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 05:21:18 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEF93A6940; Wed, 3 Sep 2008 05:21:18 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699473A6857 for ; Wed, 3 Sep 2008 05:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 vFdl1WYjMYnO for ; Wed, 3 Sep 2008 05:21:16 -0700 (PDT) Received: from ns6.comverse.com (ironport.comverse.com [192.118.49.220]) by core3.amsl.com (Postfix) with ESMTP id EA7F73A6929 for ; Wed, 3 Sep 2008 05:21:12 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.32,320,1217797200"; d="scan'208";a="198624978" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 08:20:10 -0400 Message-ID: <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoA= References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org> From: "Haresign Lincoln" To: "Howard May" , Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Howard May Sent: Wednesday, September 03, 2008 6:01 AM To: bidulock@openss7.org Cc: sigtran@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@openss7.org] > Sent: 02 September 2008 17:03 > To: Howard May > Cc: sigtran@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@openss7.org > http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 05:30:08 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F953A6A18; Wed, 3 Sep 2008 05:30:08 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1353A6A18 for ; Wed, 3 Sep 2008 05:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=1.241, 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 EC8mVBUjZ6vE for ; Wed, 3 Sep 2008 05:30:06 -0700 (PDT) Received: from EICONMTL.eicon.com (eiconmtl.eicon.com [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 148C53A6901 for ; Wed, 3 Sep 2008 05:30:05 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 08:29:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 08:29:26 -0400 Message-ID: In-Reply-To: <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8A== References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org> <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> From: "Howard May" To: "Haresign Lincoln" , X-OriginalArrivalTime: 03 Sep 2008 12:29:29.0673 (UTC) FILETIME=[B618CB90:01C90DC0] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@comverse.com] > Sent: 03 September 2008 13:20 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Howard May > Sent: Wednesday, September 03, 2008 6:01 AM > To: bidulock@openss7.org > Cc: sigtran@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@openss7.org] > > Sent: 02 September 2008 17:03 > > To: Howard May > > Cc: sigtran@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@openss7.org > > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 05:36:50 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8127C3A6905; Wed, 3 Sep 2008 05:36:50 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADEE3A6905 for ; Wed, 3 Sep 2008 05:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 xfJxhwlrUPJ6 for ; Wed, 3 Sep 2008 05:36:48 -0700 (PDT) Received: from ns6.comverse.com (ns6.comverse.com [192.118.49.220]) by core3.amsl.com (Postfix) with ESMTP id 3E5D43A6901 for ; Wed, 3 Sep 2008 05:36:47 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.32,320,1217797200"; d="scan'208";a="198626806" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 08:34:52 -0400 Message-ID: <849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmw References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org> <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> From: "Haresign Lincoln" To: "Howard May" , Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@dialogic.com] Sent: Wednesday, September 03, 2008 8:29 AM To: Haresign Lincoln; bidulock@openss7.org Cc: sigtran@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@comverse.com] > Sent: 03 September 2008 13:20 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Howard May > Sent: Wednesday, September 03, 2008 6:01 AM > To: bidulock@openss7.org > Cc: sigtran@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@openss7.org] > > Sent: 02 September 2008 17:03 > > To: Howard May > > Cc: sigtran@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@openss7.org > > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 05:49:42 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9713A6A18; Wed, 3 Sep 2008 05:49:42 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFE33A6901 for ; Wed, 3 Sep 2008 05:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 TNaybA6aVVxe for ; Wed, 3 Sep 2008 05:49:39 -0700 (PDT) Received: from EICONMTL.eicon.com (unknown [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id B6DFF3A6A18 for ; Wed, 3 Sep 2008 05:49:38 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 08:49:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 08:49:44 -0400 Message-ID: In-Reply-To: <849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrA= References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org> <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com> From: "Howard May" To: "Haresign Lincoln" , X-OriginalArrivalTime: 03 Sep 2008 12:49:45.0718 (UTC) FILETIME=[8AEA8960:01C90DC3] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@comverse.com] > Sent: 03 September 2008 13:35 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@dialogic.com] > Sent: Wednesday, September 03, 2008 8:29 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 13:20 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Howard May > > Sent: Wednesday, September 03, 2008 6:01 AM > > To: bidulock@openss7.org > > Cc: sigtran@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@openss7.org] > > > Sent: 02 September 2008 17:03 > > > To: Howard May > > > Cc: sigtran@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@openss7.org > > > http://www.openss7.org/ > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 06:08:30 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252473A6949; Wed, 3 Sep 2008 06:08:30 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0853A6949 for ; Wed, 3 Sep 2008 06:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 pZ3UPHVqp-X6 for ; Wed, 3 Sep 2008 06:08:27 -0700 (PDT) Received: from ns7.comverse.com (ns7.comverse.com [192.118.49.221]) by core3.amsl.com (Postfix) with ESMTP id 29D843A6939 for ; Wed, 3 Sep 2008 06:08:25 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.32,320,1217797200"; d="scan'208";a="75239776" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 09:07:29 -0400 Message-ID: <849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsA== References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org> <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com> From: "Haresign Lincoln" To: "Howard May" , Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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. 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. Regards, Lincoln -----Original Message----- From: Howard May [mailto:howard.may@dialogic.com] Sent: Wednesday, September 03, 2008 8:50 AM To: Haresign Lincoln; bidulock@openss7.org Cc: sigtran@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@comverse.com] > Sent: 03 September 2008 13:35 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@dialogic.com] > Sent: Wednesday, September 03, 2008 8:29 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 13:20 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Howard May > > Sent: Wednesday, September 03, 2008 6:01 AM > > To: bidulock@openss7.org > > Cc: sigtran@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@openss7.org] > > > Sent: 02 September 2008 17:03 > > > To: Howard May > > > Cc: sigtran@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@openss7.org > > > http://www.openss7.org/ > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 06:39:31 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436933A6BAE; Wed, 3 Sep 2008 06:39:31 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0D23A6BAE for ; Wed, 3 Sep 2008 06:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=1.062, 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 tXnzZAi+VmNJ for ; Wed, 3 Sep 2008 06:39:28 -0700 (PDT) Received: from EICONMTL.eicon.com (eiconmtl.eicon.com [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 5438A3A6A3D for ; Wed, 3 Sep 2008 06:39:28 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 09:39:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 09:39:32 -0400 Message-ID: In-Reply-To: <849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7Cbg References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org> <849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> From: "Howard May" To: "Haresign Lincoln" , X-OriginalArrivalTime: 03 Sep 2008 13:39:35.0172 (UTC) FILETIME=[80C50440:01C90DCA] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@comverse.com] > Sent: 03 September 2008 14:07 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@dialogic.com] > Sent: Wednesday, September 03, 2008 8:50 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 13:35 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@dialogic.com] > > Sent: Wednesday, September 03, 2008 8:29 AM > > To: Haresign Lincoln; bidulock@openss7.org > > Cc: sigtran@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@comverse.com] > > > Sent: 03 September 2008 13:20 > > > To: Howard May; bidulock@openss7.org > > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > > > Behalf Of Howard May > > > Sent: Wednesday, September 03, 2008 6:01 AM > > > To: bidulock@openss7.org > > > Cc: sigtran@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@openss7.org] > > > > Sent: 02 September 2008 17:03 > > > > To: Howard May > > > > Cc: sigtran@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@openss7.org > > > > http://www.openss7.org/ > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 3 06:50:07 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EC43A6B48; Wed, 3 Sep 2008 06:50:07 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3402B3A6A61 for ; Wed, 3 Sep 2008 06:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 vRyHCu1aNTzT for ; Wed, 3 Sep 2008 06:50:01 -0700 (PDT) Received: from ns7.comverse.com (unknown [192.118.49.221]) by core3.amsl.com (Postfix) with ESMTP id 000683A6B48 for ; Wed, 3 Sep 2008 06:49:59 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.32,320,1217797200"; d="scan'208";a="75241463" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 09:48:45 -0400 Message-ID: <849535E338E99741B7F7413F73253EDB091B3A13@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7CbgAACKzgA= References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org><849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> From: "Haresign Lincoln" To: "Howard May" , Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Howard May Sent: Wednesday, September 03, 2008 9:40 AM To: Haresign Lincoln; bidulock@openss7.org Cc: sigtran@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@comverse.com] > Sent: 03 September 2008 14:07 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@dialogic.com] > Sent: Wednesday, September 03, 2008 8:50 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 13:35 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@dialogic.com] > > Sent: Wednesday, September 03, 2008 8:29 AM > > To: Haresign Lincoln; bidulock@openss7.org > > Cc: sigtran@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@comverse.com] > > > Sent: 03 September 2008 13:20 > > > To: Howard May; bidulock@openss7.org > > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > > > Behalf Of Howard May > > > Sent: Wednesday, September 03, 2008 6:01 AM > > > To: bidulock@openss7.org > > > Cc: sigtran@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@openss7.org] > > > > Sent: 02 September 2008 17:03 > > > > To: Howard May > > > > Cc: sigtran@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@openss7.org > > > > http://www.openss7.org/ > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 4 05:38:45 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265643A6962; Thu, 4 Sep 2008 05:38:45 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A787C3A6961 for ; Thu, 4 Sep 2008 05:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 zefq4JdLL4L0 for ; Thu, 4 Sep 2008 05:38:42 -0700 (PDT) Received: from EICONMTL.eicon.com (unknown [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id C89623A681D for ; Thu, 4 Sep 2008 05:38:41 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 08:38:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 08:38:13 -0400 Message-ID: In-Reply-To: <849535E338E99741B7F7413F73253EDB091B3A13@us-nj-mail1.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7CbgAACKzgAAJ8JaIA== References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org><849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3A13@us-nj-mail1.comverse.com> From: "Howard May" To: "Haresign Lincoln" , X-OriginalArrivalTime: 04 Sep 2008 12:38:16.0675 (UTC) FILETIME=[1AA0AB30:01C90E8B] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 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. 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. 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). 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@comverse.com] > Sent: 03 September 2008 14:49 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Howard May > Sent: Wednesday, September 03, 2008 9:40 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 14:07 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@dialogic.com] > > Sent: Wednesday, September 03, 2008 8:50 AM > > To: Haresign Lincoln; bidulock@openss7.org > > Cc: sigtran@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@comverse.com] > > > Sent: 03 September 2008 13:35 > > > To: Howard May; bidulock@openss7.org > > > Cc: sigtran@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@dialogic.com] > > > Sent: Wednesday, September 03, 2008 8:29 AM > > > To: Haresign Lincoln; bidulock@openss7.org > > > Cc: sigtran@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@comverse.com] > > > > Sent: 03 September 2008 13:20 > > > > To: Howard May; bidulock@openss7.org > > > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] > On > > > > Behalf Of Howard May > > > > Sent: Wednesday, September 03, 2008 6:01 AM > > > > To: bidulock@openss7.org > > > > Cc: sigtran@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@openss7.org] > > > > > Sent: 02 September 2008 17:03 > > > > > To: Howard May > > > > > Cc: sigtran@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@openss7.org > > > > > http://www.openss7.org/ > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sigtran > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 4 05:54:52 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@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@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9172B3A67F3 for ; 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 ; 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 ; 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@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7CbgAACKzgAAJ8JaIAAIb1og References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org><849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3A13@us-nj-mail1.comverse.com> From: "Haresign Lincoln" To: "Howard May" , Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Howard, I don't agree with you. See my comments below. Regards, Lincoln -----Original Message----- From: Howard May [mailto:howard.may@dialogic.com] Sent: Thursday, September 04, 2008 8:38 AM To: Haresign Lincoln; bidulock@openss7.org Cc: sigtran@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. 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@comverse.com] > Sent: 03 September 2008 14:49 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Howard May > Sent: Wednesday, September 03, 2008 9:40 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 14:07 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@dialogic.com] > > Sent: Wednesday, September 03, 2008 8:50 AM > > To: Haresign Lincoln; bidulock@openss7.org > > Cc: sigtran@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@comverse.com] > > > Sent: 03 September 2008 13:35 > > > To: Howard May; bidulock@openss7.org > > > Cc: sigtran@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@dialogic.com] > > > Sent: Wednesday, September 03, 2008 8:29 AM > > > To: Haresign Lincoln; bidulock@openss7.org > > > Cc: sigtran@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@comverse.com] > > > > Sent: 03 September 2008 13:20 > > > > To: Howard May; bidulock@openss7.org > > > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] > On > > > > Behalf Of Howard May > > > > Sent: Wednesday, September 03, 2008 6:01 AM > > > > To: bidulock@openss7.org > > > > Cc: sigtran@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@openss7.org] > > > > > Sent: 02 September 2008 17:03 > > > > > To: Howard May > > > > > Cc: sigtran@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@openss7.org > > > > > http://www.openss7.org/ > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sigtran > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 4 06:28:07 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC52A3A6954; Thu, 4 Sep 2008 06:28:07 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F5A3A6954 for ; Thu, 4 Sep 2008 06:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=0.955, 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 Ke+YsOfVRtSp for ; Thu, 4 Sep 2008 06:28:00 -0700 (PDT) Received: from EICONMTL.eicon.com (eiconmtl.eicon.com [192.219.17.124]) by core3.amsl.com (Postfix) with ESMTP id 977F53A68E7 for ; Thu, 4 Sep 2008 06:28:00 -0700 (PDT) Received: from pysmail.eicon.com ([192.168.100.101]) by EICONMTL.eicon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 09:27:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 09:27:23 -0400 Message-ID: In-Reply-To: <849535E338E99741B7F7413F73253EDB091E975C@us-nj-mail1.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7CbgAACKzgAAJ8JaIAAIb1ogAACsJyA= References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org><849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3A13@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091E975C@us-nj-mail1.comverse.com> From: "Howard May" To: "Haresign Lincoln" , X-OriginalArrivalTime: 04 Sep 2008 13:27:25.0319 (UTC) FILETIME=[F8280970:01C90E91] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Lincoln, I reassert my view. See my comments below. Regards, Howard > -----Original Message----- > From: Haresign Lincoln [mailto:Lincoln.Haresign@comverse.com] > Sent: 04 September 2008 13:54 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@dialogic.com] > Sent: Thursday, September 04, 2008 8:38 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 14:49 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Howard May > > Sent: Wednesday, September 03, 2008 9:40 AM > > To: Haresign Lincoln; bidulock@openss7.org > > Cc: sigtran@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@comverse.com] > > > Sent: 03 September 2008 14:07 > > > To: Howard May; bidulock@openss7.org > > > Cc: sigtran@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@dialogic.com] > > > Sent: Wednesday, September 03, 2008 8:50 AM > > > To: Haresign Lincoln; bidulock@openss7.org > > > Cc: sigtran@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@comverse.com] > > > > Sent: 03 September 2008 13:35 > > > > To: Howard May; bidulock@openss7.org > > > > Cc: sigtran@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@dialogic.com] > > > > Sent: Wednesday, September 03, 2008 8:29 AM > > > > To: Haresign Lincoln; bidulock@openss7.org > > > > Cc: sigtran@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@comverse.com] > > > > > Sent: 03 September 2008 13:20 > > > > > To: Howard May; bidulock@openss7.org > > > > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] > > On > > > > > Behalf Of Howard May > > > > > Sent: Wednesday, September 03, 2008 6:01 AM > > > > > To: bidulock@openss7.org > > > > > Cc: sigtran@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@openss7.org] > > > > > > Sent: 02 September 2008 17:03 > > > > > > To: Howard May > > > > > > Cc: sigtran@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@openss7.org > > > > > > http://www.openss7.org/ > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 4 06:38:21 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291553A695A; Thu, 4 Sep 2008 06:38:21 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09033A697E for ; Thu, 4 Sep 2008 06:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.210, 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 tFT9EtRJyj9N for ; Thu, 4 Sep 2008 06:38:18 -0700 (PDT) Received: from ns6.comverse.com (ns6.comverse.com [192.118.49.220]) by core3.amsl.com (Postfix) with ESMTP id C29883A67AA for ; Thu, 4 Sep 2008 06:38:16 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.32,320,1217797200"; d="scan'208";a="198779156" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 09:36:46 -0400 Message-ID: <849535E338E99741B7F7413F73253EDB091E97F3@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA: ASP Route Availability to SG/STP Thread-Index: AckNFV2VouXjwXHOTdOGEvhc3dcf+AAj8XFAAAZ0YoAAAEAk8AAAOfmwAABZYrAAANmJsAAA7CbgAACKzgAAJ8JaIAAIb1ogAACsJyAAAMB4YA== References: <20080901170254.GA19609@openss7.org><20080902140444.GA24137@openss7.org><20080902160253.GA28729@openss7.org><849535E338E99741B7F7413F73253EDB091B3932@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3948@us-nj-mail1.comverse.com><849535E338E99741B7F7413F73253EDB091B3983@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091B3A13@us-nj-mail1.comverse.com> <849535E338E99741B7F7413F73253EDB091E975C@us-nj-mail1.comverse.com> From: "Haresign Lincoln" To: "Howard May" , Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: ASP Route Availability to SG/STP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Howard, 4.3.4.3. ASP Active Procedures Anytime after the ASP has received an ASP Up Ack message from the SGP or IPSP, the ASP MAY send an ASP Active message to the SGP, indicating that the ASP is ready to start processing traffic. ........ If the SGP or IPSP receives any Data messages before an ASP Active message is received, the SGP or IPSP MAY discard them. By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive and send traffic for the related Routing Context(s). I can only assume that the SGP will only send an ASP Active ACK if it is ready to start processing traffic. Otherwise, it should not respond. To me, this is clearly specified in the RFC. Regards, Lincoln -----Original Message----- From: Howard May [mailto:howard.may@dialogic.com] Sent: Thursday, September 04, 2008 9:27 AM To: Haresign Lincoln; bidulock@openss7.org Cc: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: ASP Route Availability to SG/STP Hi Lincoln, I reassert my view. See my comments below. Regards, Howard > -----Original Message----- > From: Haresign Lincoln [mailto:Lincoln.Haresign@comverse.com] > Sent: 04 September 2008 13:54 > To: Howard May; bidulock@openss7.org > Cc: sigtran@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@dialogic.com] > Sent: Thursday, September 04, 2008 8:38 AM > To: Haresign Lincoln; bidulock@openss7.org > Cc: sigtran@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@comverse.com] > > Sent: 03 September 2008 14:49 > > To: Howard May; bidulock@openss7.org > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Howard May > > Sent: Wednesday, September 03, 2008 9:40 AM > > To: Haresign Lincoln; bidulock@openss7.org > > Cc: sigtran@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@comverse.com] > > > Sent: 03 September 2008 14:07 > > > To: Howard May; bidulock@openss7.org > > > Cc: sigtran@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@dialogic.com] > > > Sent: Wednesday, September 03, 2008 8:50 AM > > > To: Haresign Lincoln; bidulock@openss7.org > > > Cc: sigtran@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@comverse.com] > > > > Sent: 03 September 2008 13:35 > > > > To: Howard May; bidulock@openss7.org > > > > Cc: sigtran@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@dialogic.com] > > > > Sent: Wednesday, September 03, 2008 8:29 AM > > > > To: Haresign Lincoln; bidulock@openss7.org > > > > Cc: sigtran@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@comverse.com] > > > > > Sent: 03 September 2008 13:20 > > > > > To: Howard May; bidulock@openss7.org > > > > > Cc: sigtran@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@ietf.org [mailto:sigtran-bounces@ietf.org] > > On > > > > > Behalf Of Howard May > > > > > Sent: Wednesday, September 03, 2008 6:01 AM > > > > > To: bidulock@openss7.org > > > > > Cc: sigtran@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@openss7.org] > > > > > > Sent: 02 September 2008 17:03 > > > > > > To: Howard May > > > > > > Cc: sigtran@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@openss7.org > > > > > > http://www.openss7.org/ > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Sep 24 18:47:31 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDB83A6C19; Wed, 24 Sep 2008 18:47:31 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D923A6BFE for ; Wed, 24 Sep 2008 18:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Y3oo3OGUGF4w for ; Wed, 24 Sep 2008 18:47:30 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id DAE2E3A693A for ; Wed, 24 Sep 2008 18:47:29 -0700 (PDT) Received: by gxk9 with SMTP id 9so6492904gxk.13 for ; Wed, 24 Sep 2008 18:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=QWDVTFyjY2LbsT7tmWK8PgbW9jNtjxPP/e8WbYQUrIY=; b=ZZYVK+6dXSd2uuSN3H+aFf4iuvGLrRcOwhVFA5H9nCDuUSZLjiKIK9vbdWN6iTDJzY YrPK68Tr1eblfB1yqUEI8QE/hUWdRbs8EYP1nNmKIvN3e1g9dRjEZURSf/MHzTXb3zhE CSBVTkEoKoUfTH/VpY4kf5bSaJ4aehhOG4CAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=TZomJZ1P39v/TDImMtE96AKPt0TqpUy6JtVjXiEsWRgLGltZpVg0jact/qufgrOL+d gmGfmo+wuBBz2/M/xLt14OlDAbbCe9/XWhzjTGiZVb6zxqpZZewjzdsfqXjxwHvxJwJz O0/Aw+96KbeWgwNShjw2UZNJNUeiIQW41TsAQ= Received: by 10.150.149.19 with SMTP id w19mr12083249ybd.50.1222307256333; Wed, 24 Sep 2008 18:47:36 -0700 (PDT) Received: by 10.150.139.6 with HTTP; Wed, 24 Sep 2008 18:47:36 -0700 (PDT) Message-ID: <7aa8bd9d0809241847o29c3a5a2taa32ce3f8b209897@mail.gmail.com> Date: Thu, 25 Sep 2008 09:47:36 +0800 From: "Pete Kay" To: sigtran@ietf.org MIME-Version: 1.0 Subject: [Sigtran] SS7 to SIP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257320466==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1257320466== Content-Type: multipart/alternative; boundary="----=_Part_87516_30672404.1222307256318" ------=_Part_87516_30672404.1222307256318 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am not sure if this is the right forum for my question. I am looking for way that can guide me in setting up a ss7 to sip linking mechanism between my PSTN E1 line and my SIP switch. Is there any open source lib that I can leverage for this purpose? Thanks for any suggestion. Thanks, Pete ------=_Part_87516_30672404.1222307256318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I am not sure if this is the right forum for my question. 
 
I am looking for way that can guide me in setting up a ss7 to sip linking mechanism between my PSTN E1 line and my SIP switch. 
 
Is there any open source lib that I can leverage for this purpose?
 
Thanks for any suggestion.
 
Thanks,
Pete
------=_Part_87516_30672404.1222307256318-- --===============1257320466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --===============1257320466==-- From sigtran-bounces@ietf.org Sun Sep 28 11:38:18 2008 Return-Path: X-Original-To: sigtran-archive@megatron.ietf.org Delivered-To: ietfarch-sigtran-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213AB3A699D; Sun, 28 Sep 2008 11:38:18 -0700 (PDT) X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628A93A68F3 for ; Sun, 28 Sep 2008 11:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 X8LIPt3NVpZB for ; Sun, 28 Sep 2008 11:38:15 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 75CB53A68A6 for ; Sun, 28 Sep 2008 11:38:15 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so279898ywj.49 for ; Sun, 28 Sep 2008 11:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=qIIIRCVvPG0/ooWCS3HWqjDkXoDIY03CVmdzbfph3d8=; b=M56OzFtkzNG4M91WCElwFKcWv4LrfmZl9c7DX3PUl8CL4NOhvbdTNLixsaexrClceh B5C19kk3Zwq6WvtYuBsa549yfzk6mltXJhgzJNP9DULUUdLb7Qros9Kz/jHVeFYai6pI xDOyn8bhDemkF87w8spcaYxdh63ZbYOMxX3cQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=BJFnHFyRZIysl3RpFmAxCNkFqeUARdJh3H5+5cfcu7fpFNxPVEkopsUabsx6/ZQBNf HxzzzcXWeNdLlYf0CthHWZrWtugdRE+dqOHuiliJ1LsVEReHcdtmd/vkAyvyR4hG23eE GV7EmF8zJgXMKPtiE89vlzxVhD4UvjkBjOBXI= Received: by 10.150.133.18 with SMTP id g18mr6239093ybd.188.1222627110310; Sun, 28 Sep 2008 11:38:30 -0700 (PDT) Received: by 10.150.139.6 with HTTP; Sun, 28 Sep 2008 11:38:30 -0700 (PDT) Message-ID: <7aa8bd9d0809281138j1252ec53ga5100e211dd01a13@mail.gmail.com> Date: Mon, 29 Sep 2008 02:38:30 +0800 From: "Pete Kay" To: sigtran@ietf.org MIME-Version: 1.0 Subject: [Sigtran] Build a SS7 solution with MG and MGC X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238094196==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0238094196== Content-Type: multipart/alternative; boundary="----=_Part_24036_25475222.1222627110309" ------=_Part_24036_25475222.1222627110309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am new to ss7 and I am hoping someone can give me guidance on developing a SS7 solution. I am trying to write some code to bridge SS7 signal to SIP and convert PSTN audio to RTP using MG and MGC. I already have my SIP-based media server running, but I am missing the middle piece, SS7-ISUP-SIP, MG and MGC. Is there any open source library out there that I can use for bridge PSTN with my SIP-based media server? Any suggestion will be greatly appreciated. Thank you for your kind help. Best Regards, Pete ------=_Part_24036_25475222.1222627110309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I am new to ss7 and I am hoping someone can give me guidance on developing a SS7 solution.  I am trying to write some code to bridge SS7 signal to SIP and convert PSTN audio to RTP using MG and MGC.  I already have my SIP-based media server running, but I am missing the middle piece, SS7-ISUP-SIP, MG and MGC. 
 
Is there any open source library out there that I can use for bridge PSTN with my SIP-based media server?
 
Any suggestion will be greatly appreciated.
 
Thank you for your kind help.
 
Best Regards,
Pete
------=_Part_24036_25475222.1222627110309-- --===============0238094196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran --===============0238094196==--