[Sigtran] Query regarding capacity of sigtran link

"Abhishek Bhatt" <abhishek.bhatt@telesys.com> Mon, 08 August 2016 10:22 UTC

Return-Path: <abhishek.bhatt@telesys.com>
X-Original-To: sigtran@ietfa.amsl.com
Delivered-To: sigtran@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8C12D5C2 for <sigtran@ietfa.amsl.com>; Mon, 8 Aug 2016 03:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CQJ1dRu8Nei for <sigtran@ietfa.amsl.com>; Mon, 8 Aug 2016 03:22:55 -0700 (PDT)
Received: from smtp104.iad3a.emailsrvr.com (smtp104.iad3a.emailsrvr.com [173.203.187.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C627612D1D5 for <sigtran@ietf.org>; Mon, 8 Aug 2016 03:22:54 -0700 (PDT)
Received: from smtp6.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 07A30E02F1 for <sigtran@ietf.org>; Mon, 8 Aug 2016 06:22:44 -0400 (EDT)
Received: from app21.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F0E49E01A9 for <sigtran@ietf.org>; Mon, 8 Aug 2016 06:22:43 -0400 (EDT)
X-Sender-Id: abhishek.bhatt@telesys.com
Received: from app21.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.1); Mon, 08 Aug 2016 06:22:44 -0400
Received: from telesys.com (localhost [127.0.0.1]) by app21.wa-webapps.iad3a (Postfix) with ESMTP id E356CA173A for <sigtran@ietf.org>; Mon, 8 Aug 2016 06:22:43 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: abhishek.bhatt@telesys.com, from: abhishek.bhatt@telesys.com) with HTTP; Mon, 8 Aug 2016 15:52:43 +0530 (IST)
Date: Mon, 08 Aug 2016 15:52:43 +0530
From: Abhishek Bhatt <abhishek.bhatt@telesys.com>
To: "sigtran@ietf.org" <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20160808155243000000_46239"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
In-Reply-To: <PS1PR04MB172269BA2582F52F16885623DE0E0@PS1PR04MB1722.apcprd04.prod.outlook.c om>
References: <PS1PR04MB172269BA2582F52F16885623DE0E0@PS1PR04MB1722.apcprd04.prod.outlook.c om>
X-Auth-ID: abhishek.bhatt@telesys.com
Message-ID: <1470651763.92914545@webmail.telesys.com>
X-Mailer: webmail/12.5.2-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/sigtran/CRcvvnCwqaqGKmLm3UenBuyeGXI>
Subject: [Sigtran] Query regarding capacity of sigtran link
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sigtran/>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2016 10:22:56 -0000

Hello All,
 
Can you please let me know about the maximum capacity (max traffic) of single sigtran associations (link) for both M3UA link and M2PA link.
What is the maximum CPS a single link can handle ?
 
Thanks & Regards,
Abhishek
 
-----Original Message-----
From: "Pradeep4 Kumar" <pradeep4.kumar@aricent.com>
Sent: Tuesday, July 26, 2016 4:40pm
To: "sigtran@ietf.org" <sigtran@ietf.org>
Subject: [Sigtran] Query regarding the sequence message delivery functionality in M3UA layer




Hi,
 
I had an query regarding the sequence message delivery functionality in M3UA layer.
 
As in the SS7/MTP3 layer there is concept of the controlled re-routing in case of links status un-availability, the controlled re-routing buffer and its time controlled procedure ensures that that are messages are delivered in-sequence.  As explained in the RFC section 8.1.1 of T-REC-Q704 as :
“8.1.1 The objective of the controlled rerouting procedure is to restore the optimal signalling
routing and to minimize mis-sequencing of messages. Therefore, controlled rerouting includes a
time-controlled traffic diversion procedure,” 
 
Now in case of M3UA the same situation can occur, so do we have an similar functionality of controlled re-routing available in M3UA/Sigtran as well?  
If yes please mentioned the RFC section(I could not find any reference in RFC on this topic). ?
 
              IF NO, then what is the reasoning behind not having the controlled re-routing in M3UA/SIGTRAN? Is it so that we don’t need such procedures in IP world and what is the reason for it?
 
 
Best Regards,
Pradeep Kumar
“The world needs HQ (Humanity quotient) more than IQ.”"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."