RE: [Megaco] TPKT value for H.248 over TCP
"Sampath Komanduri" <sampathk@cisco.com> Wed, 14 January 2004 18:51 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02784 for <megaco-archive@lists.ietf.org>; Wed, 14 Jan 2004 13:51:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agq6X-0000EX-VC; Wed, 14 Jan 2004 13:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agq6S-0000Dl-I7 for megaco@optimus.ietf.org; Wed, 14 Jan 2004 13:50:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02742 for <megaco@ietf.org>; Wed, 14 Jan 2004 13:50:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agq6Q-0002Am-00 for megaco@ietf.org; Wed, 14 Jan 2004 13:50:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agq5U-00029V-00 for megaco@ietf.org; Wed, 14 Jan 2004 13:49:58 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Agq5H-00027z-00 for megaco@ietf.org; Wed, 14 Jan 2004 13:49:43 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Jan 2004 10:51:19 +0000
Received: from SAMPATHKW2K03 (dhcp-171-71-9-200.cisco.com [171.71.9.200]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0EIn9VM006920; Wed, 14 Jan 2004 10:49:10 -0800 (PST)
Reply-To: sampathk@cisco.com
From: Sampath Komanduri <sampathk@cisco.com>
To: 'Kevin Boyle' <kboyle@nortelnetworks.com>, 'MEGACO list' <megaco@ietf.org>
Subject: RE: [Megaco] TPKT value for H.248 over TCP
Date: Wed, 14 Jan 2004 10:49:09 -0800
Organization: Cisco Systems
Message-ID: <000a01c3dacf$1892b8a0$c80947ab@SAMPATHKW2K03>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C3DA8C.0A70FF40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0DCB7F45@zrtpd0jq.us.nortel.com>
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe>
Kevin, The issue is not with TCP itself. The problem stems from the basis that MEGACO is an ISO application which is designed to run over the OSI stack (7 layer stack), not the TCP/IP stack (5 layer stack, no session or presentation layers). In order to make ISO protocols/applications capable of running over TCP, a "pseudo-header" (or TPKT) in RFC1006 was created. This allowed support for the additional layers not found in the TCP/IP stack. This pseudo-header is found in the application layer of the TCP/IP stack and has no correlation to the functions preformed at the TCP layer. Applications that were designed for the TCP/IP stack do not require this pseudo-header (ex. HTTP or FTP). These applications use other means for delimiting messages (read RFC959 sections 3.4.1 & 3.4.2 for how FTP delimit messages) and as you know have no PDU size limitations (FTP can handle Megabyte file transfers). This essentially restricts the maximum transport protocol data unit (TPDU) size that can be transferred to TCP layer by Megaco application to 65524 octets. TCP, based on the MTU and PMTUD, will segment and re-assemble the TPDU (max. 65524 octets) at transmiting and recieving end. I was asking if we authors of H.248 Annex D can address this issue in the standard itself. One way to do it is bump up the "version" field in TPKT to 4 and use 4 octets to represent the TPDU size. Thanks, Sampath -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Sent: Wednesday, January 14, 2004 10:25 AM To: sampathk@cisco.com; 'MEGACO list' Subject: RE: [Megaco] TPKT value for H.248 over TCP I was under the impression that TCP segmented large packets automatically. Is that not the case? Kevin _____ From: Sampath Komanduri [mailto:sampathk@cisco.com] Sent: Tuesday, January 13, 2004 12:25 PM To: 'MEGACO list' Subject: RE: [Megaco] TPKT value for H.248 over TCP Could the author of Annex D pls. respond? Thanks, Sampath -----Original Message----- From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of Sampath Komanduri Sent: Tuesday, January 06, 2004 8:16 PM To: 'MEGACO list' Subject: [Megaco] TPKT value for H.248 over TCP Importance: High Hi List, I am not sure if this question was already raised in the list. If it was, pls. point me to the discussion and the consensus. According to ANNEX D of H.248.1 protocol, "TPKT, according to <http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to delineate messages within the TCP stream". RFC 1006 limits the size of TPDU to 65524. Replicating the relevant text here for convenience: *************************************************** "A TPKT consists of two parts: a packet-header and a TPDU. The format of the header is constant regardless of the type of packet. The format of the packet-header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vrsn | reserved | packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: vrsn 8 bits This field is always 3 for the version of the protocol described in this memo. packet length 16 bits (min=7, max=65535) This field contains the length of entire packet in octets, including packet-header. This permits a maximum TPDU size of 65531 octets. Based on the size of the data transfer (DT) TPDU, this permits a maximum TSDU size of 65524 octets." ********************************************************* This causes an issue. Based on the wildcard level of Audit and the descriptors involved, this size could easily exceed 64K size (especially if MG and MGC are using Long text format and white spaces in the messages). In few cases, it is possible to return an error code (533: Response exceeds maximum transport PDU size). However, in some cases returning 533 is not an option. Consider for example the following scenario: After an association is DISCONNECTED, MGC may want to get the list of non-null contexts on the gateway using the following command (pls. ignore if there is any mistake in the message and reply construct): !/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}} !/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on} In the best case (i.e. no white-space, no audit descriptor and short format), this allows for an MG to have only 5000 active contexts on the card. Anything more (or any variation in the audit command) will reduce the number of active contexts that an MG can have even with TCP as the transport option. Responding with 533 is not an option here since that would leave MG-MGC in state from where there is no elegant way out (at least from H.248 protocol). How do the gurus' on list suggest we solve this issue? Couple of ideas that come to mind are: 1. Define a Bulk-Audit Package/scheme: As was done for MGCP, define a Bulk-Audit package/scheme especially with support for RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]. This will certainly reduce the cases and scenarios when MG/MGC will run into the issue under discussion but may not eliminate it. 2. Add more information on W- Audit support in the protocol. 3. Introduce RFC 1006 modification (with version field 4) such that "packet length" of packet header in TPKT is 32 bits as opposed to 16 bits. 4. Combination of the above schemes. 5. Anything else? Pls. advice on how this problem can be solved? Thanks, Sampath
- [Megaco] TPKT value for H.248 over TCP Sampath Komanduri
- RE: [Megaco] TPKT value for H.248 over TCP Sampath Komanduri
- RE: [Megaco] TPKT value for H.248 over TCP Kevin Boyle
- RE: [Megaco] TPKT value for H.248 over TCP Raju
- RE: [Megaco] TPKT value for H.248 over TCP Sampath Komanduri
- RE: [Megaco] TPKT value for H.248 over TCP Kevin Boyle
- Re: [Megaco] TPKT value for H.248 over TCP Troy Cauble
- RE: [Megaco] TPKT value for H.248 over TCP Raju
- Re: [Megaco] TPKT value for H.248 over TCP Troy Cauble
- RE: [Megaco] TPKT value for H.248 over TCP Kevin Boyle
- RE: [Megaco] TPKT value for H.248 over TCP Steve Cipolli
- [Megaco] A question about H.248.6 Rashim Anand
- [Fwd: Re: [Megaco] TPKT value for H.248 over TCP] Christian Groves
- Re: [Megaco] TPKT value for H.248 over TCP Christian Groves