From Christian.Groves@nteczone.com Sun May 1 18:37:05 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BF6E0664 for ; Sun, 1 May 2011 18:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY+cpw4gwZmm for ; Sun, 1 May 2011 18:37:04 -0700 (PDT) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7521CE062A for ; Sun, 1 May 2011 18:37:04 -0700 (PDT) Received: from ppp118-209-175-155.lns20.mel6.internode.on.net ([118.209.175.155] helo=[192.168.0.2]) by cserver5.myshophosting.com with esmtp (Exim 4.69) (envelope-from ) id 1QGi4I-0007F1-UC; Mon, 02 May 2011 11:36:59 +1000 Message-ID: <4DBE0B20.50106@nteczone.com> Date: Mon, 02 May 2011 11:38:40 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Martin De Nicolas References: <4C9A0A1285A73648BBB8707F62E26A2F50582EFFEF@EUSAACMS0714.eamcs.ericsson.se> <4DB77A6F.7020803@nteczone.com> <126AED987D19E148BBA558BE393ADF15E0F8F53F@ESESSCMS0365.eemea.ericsson.se> In-Reply-To: <126AED987D19E148BBA558BE393ADF15E0F8F53F@ESESSCMS0365.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: Cc: "megaco@ietf.org" Subject: Re: [Megaco] Error in H.248.41 IP Realm Availability package definition? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 01:37:05 -0000 Hello Arturo, People have some time to think about it. As the editor of the H.248.x Implementors' Guide i'll submit a contribution to the July Q.3/16 meeting regarding it. Regards, Christian On 29/04/2011 7:45 PM, Arturo Martin De Nicolas wrote: > Hi Christian, Charlie, > > Thanks for the info. Yes, seems this was unfortunately overlooked. > > At this stage I tend to agree with you, Christian, that it's probably safer to remove the extension. > > I guess this is a good forum for companies to state if they have an opinion. We ourselves may also come back. > > Best regards, > Arturo > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Wednesday, April 27, 2011 4:08 AM > To: megaco@ietf.org > Cc: Arturo Martin De Nicolas > Subject: Re: [Megaco] Error in H.248.41 IP Realm Availability package definition? > > Hello Charlie, cc: Arturo, > > Yes it appears that you are correct the available realms property in the ipra package does cause a conflict. It either should be binary ID 0x0002 or the package extension should be removed in order to address the issue. Ericsson was the original editor of this work item. This Recommendation is also used by Tispan/3GPP so we would need to consider this when deciding on a path to take. > > Removing the extension is probably the safest path to take. Any other opinions? > > Regards, Christian > > On 26/04/2011 6:28 AM, Charlie Ross wrote: >> Hello, >> In H.248.41 Amendment 1, the IP Realm Availability (ipra) package is >> defined as extending the IP Domain Connection (ipdc) package. IP >> Realm Availability has a property, "available realms" (ar), that is >> assigned binary property ID 0x0001. This appears to clash with the >> inherited "realm" property that is assigned property ID 0x0001 in the >> parent IP Domain Connection package. From other examples of package >> extension that I have seen, it seems that the available realms >> property should have been given a binary ID that is unique within the >> IP Realm Availability definition, such as 0x0002. This would allow >> both properties to be referenced through IP Realm Availability >> [package ID: 0x00e0]. >> ipra/realm [0x00e00001] >> ipra/ar [0x00e00001? or 0x00e00002] >> Is this possibly an oversight in the standard or is there some other >> way to distinguish these properties within IP Realm Availability when >> using binary encoding? >> Thanks for your insights, >> /*Charlie Ross*/ >> Media Gateway Design Architect >> Ericsson BCAM Business Unit >> _email_: charlie.ross@ericsson.com >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www.ietf.org/mailman/listinfo/megaco From albrecht.schwarz@alcatel-lucent.com Wed May 4 02:51:56 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B39AE0688 for ; Wed, 4 May 2011 02:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFPATf9YmD+9 for ; Wed, 4 May 2011 02:51:55 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2FE067A for ; Wed, 4 May 2011 02:51:54 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p449pquE032543 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 4 May 2011 11:51:52 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.51]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 4 May 2011 11:51:52 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "megaco@ietf.org" Date: Wed, 4 May 2011 11:51:50 +0200 Thread-Topic: Draft H.248.82 (ex H.248.ECN) - Editorial update proposals Thread-Index: AcwKQOQHyXIDXiX+SOyALumD8C9y1w== Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67345@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D67345FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [Megaco] Draft H.248.82 (ex H.248.ECN) - Editorial update proposals X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:51:56 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D67345FRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable fyi, we are preparing a contribution for editorials, see: http://wftp3.itu.int/av-arch/avc-site/Incoming/AVD-xxx%20H.248.82%20Editori= als_Ed01.doc --_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D67345FRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
f= yi, we are=20 preparing a contribution for editorials, see:
<= A=20 href=3D"http://wftp3.itu.int/av-arch/avc-site/Incoming/AVD-xxx%20H.248.82%2= 0Editorials_Ed01.doc">http://wftp3.itu.int/av-arch/avc-site/Incoming/AVD-xx= x%20H.248.82%20Editorials_Ed01.doc
--_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D67345FRMRSSXCHMBSD_-- From albrecht.schwarz@alcatel-lucent.com Mon May 9 23:24:37 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88CDE06A0 for ; Mon, 9 May 2011 23:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcQ4-X8uACLu for ; Mon, 9 May 2011 23:24:36 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3F4E07E4 for ; Mon, 9 May 2011 23:24:35 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4A6N6Bu026401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 10 May 2011 08:23:06 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.51]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 10 May 2011 08:23:06 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "megaco@ietf.org" Date: Tue, 10 May 2011 08:23:17 +0200 Thread-Topic: AVD-4047 H.248.34 extension proposal - A signalling transport mechanism for Decadic Dialling in H.248.34 Stimulus Analogue Line Package Thread-Index: AcwO2r/UAo9uLus1QPmT/Vzk83u76g== Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620B9D6794B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D6794BFRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "LIU, GARY \(GARY\)" Subject: [Megaco] AVD-4047 H.248.34 extension proposal - A signalling transport mechanism for Decadic Dialling in H.248.34 Stimulus Analogue Line Package X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 06:24:37 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D6794BFRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable fyi, we've submitted a change request to H.248.34 for coming Q.3/16 meeting= : http://wftp3.itu.int/av-arch/avc-site/2009-2012/1107_And/AVD-4047.zip H.248.34 concerns H.248 profiles for residential & access gateways (like e.= g. TISPAN P1 reference point). Gary & Albrecht ALCATEL-LUCENT --_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D6794BFRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
f= yi, we've=20 submitted a change request to H.248.34 for coming Q.3/16=20 meeting:
<= A=20 href=3D"http://wftp3.itu.int/av-arch/avc-site/2009-2012/1107_And/AVD-4047.z= ip">http://wftp3.itu.int/av-arch/avc-site/2009-2012/1107_And/AVD-4047.zip
 
H.248.34 concerns H.248 profiles for=20 residential & access gateways (like e.g. TISPAN P1 reference=20 point).
 
G= ary &=20 Albrecht
ALCATEL-LUCENT
 
--_000_5F7BCCF5541B7444830A2288ABBEBC9620B9D6794BFRMRSSXCHMBSD_-- From bruno.chatras@orange-ftgroup.com Tue May 24 04:29:06 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A490CE0735 for ; Tue, 24 May 2011 04:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEDfjXOs-G4R for ; Tue, 24 May 2011 04:29:06 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id A55CCE0711 for ; Tue, 24 May 2011 04:29:05 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 978768D0003 for ; Tue, 24 May 2011 13:29:44 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8E0EF8B8003 for ; Tue, 24 May 2011 13:29:44 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 13:29:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1A05.C94E8D41" Date: Tue, 24 May 2011 13:29:03 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.64 question Thread-Index: AcwaBckP5xqdw+buRuOuZFB2IRS2FA== From: To: X-OriginalArrivalTime: 24 May 2011 11:29:05.0054 (UTC) FILETIME=[C9D993E0:01CC1A05] Subject: [Megaco] H.248.64 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 11:29:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1A05.C94E8D41 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 A question about H.248.64: Is the IPR mode compatible with the use of properties such as those defined in H.248.52 or H.248.53? If yes, I don't really understand how the MGC can request the MG to use a specific DSCP value for a particular packet for example? Can someone shed light on this? =20 Bruno ------_=_NextPart_001_01CC1A05.C94E8D41 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

A question about H.248.64: =  Is the IPR mode compatible with the use of properties such as those defined in = H.248.52 or H.248.53? If yes, I don’t really understand how the MGC can = request the MG to use a specific DSCP value for a particular packet for example? Can someone shed light on this?

 

Bruno

------_=_NextPart_001_01CC1A05.C94E8D41-- From bruno.chatras@orange-ftgroup.com Tue May 24 04:34:07 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFD0E073A for ; Tue, 24 May 2011 04:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq+zF+JcjY1i for ; Tue, 24 May 2011 04:34:06 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 99DB1E071D for ; Tue, 24 May 2011 04:34:06 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 68A57858009 for ; Tue, 24 May 2011 13:41:08 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 61599858002 for ; Tue, 24 May 2011 13:41:08 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 13:34:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1A06.7C3BD285" Date: Tue, 24 May 2011 13:34:03 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQ== From: To: X-OriginalArrivalTime: 24 May 2011 11:34:05.0201 (UTC) FILETIME=[7CC06010:01CC1A06] Subject: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 11:34:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1A06.7C3BD285 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have two questions about H.248.NATTP2P =20 1) The scope description suggests that this recommendation applies to P2P networks. My understanding is that it also applies to any terminal to terminal traffic within a managed network without application-level intermediary. Is that correct? =20 2) What is the relation with TCP stitching?=20 =20 Bruno =20 ------_=_NextPart_001_01CC1A06.7C3BD285 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have two questions about = H.248.NATTP2P

 

1) The scope description = suggests that this recommendation applies to P2P networks. My understanding is that it also applies to any terminal to terminal traffic within a managed network = without application-level intermediary. Is that correct?

 

2) What is the relation with TCP = stitching?

 

Bruno

 

------_=_NextPart_001_01CC1A06.7C3BD285-- From albrecht.schwarz@alcatel-lucent.com Wed May 25 01:42:22 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5EEE0692 for ; Wed, 25 May 2011 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtuBpanhReWq for ; Wed, 25 May 2011 01:42:20 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7055AE0664 for ; Wed, 25 May 2011 01:42:20 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4P8g6kj023510 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 10:42:19 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 May 2011 10:42:10 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "bruno.chatras@orange-ftgroup.com" , "megaco@ietf.org" Date: Wed, 25 May 2011 10:42:08 +0200 Thread-Topic: H.248.64 question Thread-Index: AcwaBckP5xqdw+buRuOuZFB2IRS2FAArtuQg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [Megaco] H.248.64 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:42:22 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4FRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno, sorry for delay! There are not any straightforward answers because the usage of H.248.52 (& = perhaps H.248.53) implies certain roles. E.g., DSCP marking (using H.248.52): possible roles of an IP node - DS pre-marker - DS edge router - DS interior node (providing DS PHB) ALL existing H.248 Profiles with H.248.52 usage define just the DS pre-mark= er behaviour! Just because there were not any stage 2 requirements for othe= r roles. I guess that this situation is due to the specific location considered for = that H.248 MGs (at the edge, either at access or peering side). Now, I'm not sure what you are looking exactly, hm? Let's consider a "DS interior node" role plus IPR mode. The next question would be whether you are really want a) DS PHB control for individual IP bearer connections? or b) DS PHB control on aggregated level? On a first glance I would conclude that H.248.52 (& .53) togther with H.248= .64 may be applied at the granularity of route levels (aka RIPR contexts). That's already a sufficient baseline in my opinion for scenarios like NAT66= -less plus DS pre-marker, i.e. an H.248 IP-IP MG located between two IPv6 n= etworks (without the enforcement of local NAPT). Regards, Albrecht ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:29 To: megaco@ietf.org Subject: [Megaco] H.248.64 question Hi all, A question about H.248.64: Is the IPR mode compatible with the use of prop= erties such as those defined in H.248.52 or H.248.53? If yes, I don't reall= y understand how the MGC can request the MG to use a specific DSCP value fo= r a particular packet for example? Can someone shed light on this? Bruno --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4FRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bruno,
 
sorry for delay!
 
There are not any straightforward answers becaus= e the=20 usage of H.248.52 (& perhaps H.248.53) implies certain=20 roles.
 
E.g., DSCP marking (using=20 H.248.52):
possible roles of an IP node
- DS pre-marker
- DS edge router
- DS interior node (providing DS=20 PHB)
 
ALL existing H.248 Profiles with H.248.52 usage = define=20 just the DS pre-marker behaviour! Just because there were not any stage 2=20 requirements for other roles.
I guess that this situation is due to the specif= ic=20 location considered for that H.248 MGs (at the edge, either at access or pe= ering=20 side).
 
Now, I'm not sure what you are looking exactly,= =20 hm?
Let's consider a "DS interior node" role plus IP= R=20 mode.
The next question would be whether you are reall= y=20 want
a) DS PHB control for individual IP bearer conne= ctions?=20 or
b) DS PHB control on aggregated=20 level?
 
On a first glance I would conclude that H.248.52= (&=20 .53) togther with H.248.64 may be applied at the granularity of route level= s=20 (aka RIPR contexts).
 
That's already a sufficient baseline in my opini= on for=20 scenarios like NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG locate= d=20 between two IPv6 networks (without the enforcement of local=20 NAPT).
 
Regards,
Albrecht
 
 

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of=20 bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 20= 11=20 13:29
To: megaco@ietf.org
Subject: [Megaco] H.248.64= =20 question

Hi all,

 

A question about H.248.64:  = Is the=20 IPR mode compatible with the use of properties such as those defined in=20 H.248.52 or H.248.53? If yes, I don’t really understand how the MGC= can=20 request the MG to use a specific DSCP value for a particular packet for=20 example? Can someone shed light on this?

 

Bruno

--_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4FRMRSSXCHMBSD_-- From bruno.chatras@orange-ftgroup.com Wed May 25 01:59:35 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C51E06F5 for ; Wed, 25 May 2011 01:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcwnI1JOfWmv for ; Wed, 25 May 2011 01:59:33 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id D8F88E06F3 for ; Wed, 25 May 2011 01:59:32 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8C71F8B8018; Wed, 25 May 2011 11:00:11 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 7B2438B8013; Wed, 25 May 2011 11:00:07 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 10:59:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1ABA.0C90FDD9" Date: Wed, 25 May 2011 10:57:57 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102E444EB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.64 question Thread-Index: AcwaBckP5xqdw+buRuOuZFB2IRS2FAArtuQgAADXECA= References: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> From: To: , X-OriginalArrivalTime: 25 May 2011 08:59:27.0006 (UTC) FILETIME=[0CEDEBE0:01CC1ABA] Subject: Re: [Megaco] H.248.64 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:59:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1ABA.0C90FDD9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does it mean that you can't you mix-up Best Effort traffic with say VoIP = traffic=20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 10:42 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.64 question =20 Bruno, =20 sorry for delay! =20 There are not any straightforward answers because the usage of H.248.52 = (& perhaps H.248.53) implies certain roles. =20 E.g., DSCP marking (using H.248.52): possible roles of an IP node - DS pre-marker - DS edge router - DS interior node (providing DS PHB) =20 ALL existing H.248 Profiles with H.248.52 usage define just the DS = pre-marker behaviour! Just because there were not any stage 2 = requirements for other roles. I guess that this situation is due to the specific location considered = for that H.248 MGs (at the edge, either at access or peering side). =20 Now, I'm not sure what you are looking exactly, hm? Let's consider a "DS interior node" role plus IPR mode. The next question would be whether you are really want a) DS PHB control for individual IP bearer connections? or b) DS PHB control on aggregated level? =20 On a first glance I would conclude that H.248.52 (& .53) togther with = H.248.64 may be applied at the granularity of route levels (aka RIPR = contexts). [BC] So the ds/dscp property would be set on a termination of a RIPR = context rather than the a termination of an IIPR context? If yes, this = need to be stated somewhere, e.g. in H.248.79.... =20 That's already a sufficient baseline in my opinion for scenarios like = NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG located between = two IPv6 networks (without the enforcement of local NAPT). =20 Regards, Albrecht =20 =20 =20 =09 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:29 To: megaco@ietf.org Subject: [Megaco] H.248.64 question Hi all, =20 A question about H.248.64: Is the IPR mode compatible with the use of = properties such as those defined in H.248.52 or H.248.53? If yes, I = don't really understand how the MGC can request the MG to use a specific = DSCP value for a particular packet for example? Can someone shed light = on this? =20 Bruno ------_=_NextPart_001_01CC1ABA.0C90FDD9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does it = mean that you can’t you mix-up Best Effort traffic with say VoIP traffic =

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 10:42
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.64 question

 

Bruno,

 

sorry for delay!

 

There are not any straightforward answers because the = usage of H.248.52 (& perhaps H.248.53) implies certain roles.

 

E.g., DSCP marking (using H.248.52):

possible roles of an IP node

- DS pre-marker

- DS edge router

- DS interior node (providing DS PHB)

 

ALL existing H.248 Profiles with H.248.52 usage define = just the DS pre-marker behaviour! Just because there were not any stage 2 = requirements for other roles.

I guess that this situation is due to the specific = location considered for that H.248 MGs (at the edge, either at access or peering = side).

 

Now, I'm not sure what you are looking exactly, = hm?

Let's consider a "DS interior node" role plus = IPR mode.

The next question would be whether you are really = want

a) DS PHB control for individual IP bearer connections? = or

b) DS PHB control on aggregated level?

 

On a first glance I would conclude that H.248.52 (& = .53) togther with H.248.64 may be applied at the granularity of route levels = (aka RIPR contexts).

[BC] So the ds/dscp property would be set on a termination of a RIPR context rather than the = a termination of an IIPR context? If yes, this need to be stated = somewhere, e.g. in H.248.79….

 

That's already a sufficient baseline in my opinion for = scenarios like NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG located = between two IPv6 networks (without the enforcement of local NAPT).

 

Regards,

Albrecht

 

 

 

From:= megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 2011 13:29
To: megaco@ietf.org
Subject: [Megaco] H.248.64 question

Hi all,

 

A question about H.248.64: =  Is the IPR mode compatible with the use of properties such as those defined in = H.248.52 or H.248.53? If yes, I don’t really understand how the MGC can = request the MG to use a specific DSCP value for a particular packet for example? Can someone shed light on this?

 

Bruno

------_=_NextPart_001_01CC1ABA.0C90FDD9-- From albrecht.schwarz@alcatel-lucent.com Wed May 25 02:02:53 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F33EE06F3 for ; Wed, 25 May 2011 02:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9HC6eKhOirg for ; Wed, 25 May 2011 02:02:53 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id BDD86E06F2 for ; Wed, 25 May 2011 02:02:52 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4P92269018146 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 11:02:49 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 25 May 2011 11:02:40 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "bruno.chatras@orange-ftgroup.com" , "megaco@ietf.org" Date: Wed, 25 May 2011 11:00:59 +0200 Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQ Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:02:53 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7FRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My comments below inline, Albrecht ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, I have two questions about H.248.NATTP2P 1) The scope description suggests that this recommendation applies to P2P n= etworks. My understanding is that it also applies to any terminal to termin= al traffic within a managed network without application-level intermediary.= Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P scenari= o. The draft does not yet provide a link to the applied P2P definition in c= lause 3. More important in my opinion is the reference to the considered e2= e model by Fig. 1. Side question: what's the definition of an application-level intermediary? = Or what kind of specific functios do you have in mind? 2) What is the relation with TCP stitching? [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP stitching", = guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim = H.248 IP-IP MGs, which lead to the requirement in assigning different role = behaviours to the MGs, whereas your referred proprietary technology aims pe= rhaps just a single NAT traversal entity in the bearer path. But I don't kn= ow ... Bruno --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7FRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My comments below inline,
Albrecht

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of=20 bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 20= 11=20 13:34
To: megaco@ietf.org
Subject: [Megaco]=20 H.248.NATTP2P

Hi,

 

I have two questions about=20 H.248.NATTP2P

 

1) The scope description suggests= that=20 this recommendation applies to P2P networks. My understanding is that it = also=20 applies to any terminal to terminal traffic within a managed network with= out=20 application-level intermediary. Is that correct?
[[Schwarz, Albrecht]] Perhaps yes, because that might be al= so a=20 P2P scenario. The draft does not yet provide a link to the applied P= 2P=20 definition in clause 3. More important in my opinion is the referenc= e to=20 the considered e2e model by Fig. 1.

= Side question: what's the d= efinition=20 of an application-level intermediary? Or what kind of specific functios d= o you=20 have in mind?

 

2) What is the relation with TCP= =20 stitching?

= Thus, I may just=20 speculate:

= Draft H.248.NATTP2P conside= rs e2e=20 scenarios with possible multiple interim H.248 IP-IP MGs, which lead= to=20 the requirement in assigning different role behaviours to the MGs, wherea= s=20 your referred proprietary technology aims perhaps just a single NAT= =20 traversal entity in the bearer path. But I don't know=20 ...  

 

 

Bruno

 

--_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7FRMRSSXCHMBSD_-- From bruno.chatras@orange-ftgroup.com Wed May 25 02:43:34 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3DE07DE for ; Wed, 25 May 2011 02:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuM2aYAZyHvC for ; Wed, 25 May 2011 02:43:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0D484E07D9 for ; Wed, 25 May 2011 02:43:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F036BFC4038; Wed, 25 May 2011 11:43:31 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id DFC0EFC4003; Wed, 25 May 2011 11:43:31 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 11:43:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1AC0.34B80650" Date: Wed, 25 May 2011 11:43:30 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQAAFbTVA= References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> From: To: , X-OriginalArrivalTime: 25 May 2011 09:43:31.0771 (UTC) FILETIME=[355508B0:01CC1AC0] Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:43:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1AC0.34B80650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 11:01 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P =20 My comments below inline, Albrecht =20 =09 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, =20 I have two questions about H.248.NATTP2P =20 1) The scope description suggests that this recommendation applies to = P2P networks. My understanding is that it also applies to any terminal = to terminal traffic within a managed network without application-level = intermediary. Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P = scenario. The draft does not yet provide a link to the applied P2P = definition in clause 3. More important in my opinion is the reference to = the considered e2e model by Fig. 1. Side question: what's the definition of an application-level = intermediary? Or what kind of specific functios do you have in mind? [BC] An MSRP relay for example is what I would call an = application-level intermediary =20 2) What is the relation with TCP stitching?=20 [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP = stitching", guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple = interim H.248 IP-IP MGs, which lead to the requirement in assigning = different role behaviours to the MGs, whereas your referred proprietary = technology aims perhaps just a single NAT traversal entity in the bearer = path. But I don't know ... =20 [BC] My understanding of TCP stitching is that both endpoints initiate = a TCP connection towards the MG and the MG joins both connections = together. This requires the MG to convert TCP SYN on one side to = TCP-SYN-ACK on the other side, which means that the MGC has to request = the MG to perform that trick, presumably by setting a termination or = context property to a specific value. So, the purpose of my question was = to know whether this kind of mechanism was covered or will be covered by = H.248.NATTP2P =20 =20 Bruno =20 ------_=_NextPart_001_01CC1AC0.34B80650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 11:01
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.NATTP2P

 

My comments below inline,

Albrecht

 

From:= megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 2011 13:34
To: megaco@ietf.org
Subject: [Megaco] H.248.NATTP2P

Hi,

 

I have two questions about = H.248.NATTP2P

 

1) The scope description = suggests that this recommendation applies to P2P networks. My understanding is that it also applies to any terminal to terminal traffic within a managed network = without application-level intermediary. Is that correct?
[[Schwarz, Albrecht]] Perhaps yes, because that might = be also a P2P scenario. The draft does not yet provide a link to the = applied P2P definition in clause 3. More important in my opinion is the = reference to the considered e2e model by Fig. 1.

Side question: what's the definition of an = application-level intermediary? Or what kind of specific functios do you have in = mind?

[BC] An MSRP relay for example is what I would call an application-level = intermediary

 

2) What is the relation with TCP = stitching?
[[Schwarz, Albrecht]] I'm not aware of any definition = for "TCP stitching", guess this is a marketing term used by a = particular vendor.

Thus, I may just speculate:

Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim H.248 IP-IP MGs, which lead to the requirement in assigning different role behaviours to the MGs, whereas your referred proprietary technology aims perhaps just a single NAT traversal = entity in the bearer path. But I don't know ...  

[BC] My understanding of TCP stitching is that both endpoints initiate a TCP = connection towards the MG and the MG joins both connections together. This requires = the MG to convert TCP SYN on one side to TCP-SYN-ACK on the other side, which = means that the MGC has to request the MG to perform that trick, presumably by = setting a termination or context property to a specific value. So, the purpose = of my question was to know whether this kind of mechanism was covered or will = be covered by H.248.NATTP2P

 

 

Bruno

 

------_=_NextPart_001_01CC1AC0.34B80650-- From albrecht.schwarz@alcatel-lucent.com Wed May 25 03:01:56 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0081EE07D4 for ; Wed, 25 May 2011 03:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS5Ukm0VSpjX for ; Wed, 25 May 2011 03:01:55 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA41E07B1 for ; Wed, 25 May 2011 03:01:54 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4PA0atg006129 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 12:01:52 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 25 May 2011 12:01:39 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "bruno.chatras@orange-ftgroup.com" , "megaco@ietf.org" Date: Wed, 25 May 2011 12:01:38 +0200 Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQAAFbTVAAAOHlwA== Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:01:56 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12FRMRSSXCHMBSD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno, looks like that you are describing "TCP hole punching" according RFC 5128, = =A7 3.4, right? That solution is in scope of H.248.NATTP2P ("In scope of this document are = NAT-T techniques according [IETF RFC 5128].") ... and RFC 5128 is about NATT for P2P. ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Mittwoch, 25. Mai 2011 11:44 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 25 mai 2011 11:01 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P My comments below inline, Albrecht ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, I have two questions about H.248.NATTP2P 1) The scope description suggests that this recommendation applies to P2P n= etworks. My understanding is that it also applies to any terminal to termin= al traffic within a managed network without application-level intermediary.= Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P scenari= o. The draft does not yet provide a link to the applied P2P definition in c= lause 3. More important in my opinion is the reference to the considered e2= e model by Fig. 1. Side question: what's the definition of an application-level intermediary? = Or what kind of specific functios do you have in mind? [BC] An MSRP relay for example is what I would call an application-level in= termediary 2) What is the relation with TCP stitching? [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP stitching", = guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim = H.248 IP-IP MGs, which lead to the requirement in assigning different role = behaviours to the MGs, whereas your referred proprietary technology aims pe= rhaps just a single NAT traversal entity in the bearer path. But I don't kn= ow ... [BC] My understanding of TCP stitching is that both endpoints initiate a TC= P connection towards the MG and the MG joins both connections together. Thi= s requires the MG to convert TCP SYN on one side to TCP-SYN-ACK on the othe= r side, which means that the MGC has to request the MG to perform that tric= k, presumably by setting a termination or context property to a specific va= lue. So, the purpose of my question was to know whether this kind of mechan= ism was covered or will be covered by H.248.NATTP2P Bruno --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12FRMRSSXCHMBSD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bruno,
looks like that you are describing "TCP hole pun= ching"=20 according RFC 5128, =A7 3.4, right?
That solution is in scope of H.248.NATTP2P ("In sco= pe of this=20 document are NAT-T techniques according [IETF RFC=20 5128].")
... and RFC 5128 is about NATT for=20 P2P.
 
 

From: bruno.chatras@orange-ftgroup.co= m=20 [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 25. = Mai=20 2011 11:44
To: Schwarz, Albrecht (Albrecht);=20 megaco@ietf.org
Subject: RE: H.248.NATTP2P

 

 

De : Schwarz, A= lbrecht=20 (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 25 mai 2011 11:01
=C0 : CHATRAS=20 Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE:=20 H.248.NATTP2P

 

My c= omments=20 below inline,

Albr= echt

=  

From:=20 megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf O= f=20 bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai = 2011=20 13:34
To: megaco@ietf.org
Subject: [Megaco]=20 H.248.NATTP2P=

Hi,

 

I have two questions about=20 H.248.NATTP2P

 

1) The scope description sugges= ts that=20 this recommendation applies to P2P networks. My understanding is that i= t=20 also applies to any terminal to terminal traffic within a managed netwo= rk=20 without application-level intermediary. Is that correct?
[[= Schwarz,=20 Albrecht]] Perhaps yes, because that might be also a P2P=20 scenario. The draft does not yet provide a link to the applied P2P= =20 definition in clause 3. More important in my opinion is the refere= nce=20 to the considered e2e model by Fig. 1.

Si= de=20 question: what's the definition of an application-level intermediary? O= r=20 what kind of specific functios do you have in mind?

= [BC] An=20 MSRP relay for example is what I would call an application-level=20 intermediary

 

2) What is the relation with TC= P=20 stitching?
[[= Schwarz,=20 Albrecht]] I'm not aware of any definition for "TCP stitching", gu= ess=20 this is a marketing term used by a particular vendor.=

Th= us, I=20 may just speculate:

Dr= aft=20 H.248.NATTP2P considers e2e scenarios with possible multiple interim H.= 248=20 IP-IP MGs, which lead to the requirement in assigning different ro= le=20 behaviours to the MGs, whereas your referred proprietary=20 technology aims perhaps just a single NAT traversal entity in the= =20 bearer path. But I don't know ...  

= [BC] My=20 understanding of TCP stitching is that both endpoints initiate a TCP=20 connection towards the MG and the MG joins both connections together. T= his=20 requires the MG to convert TCP SYN on one side to TCP-SYN-ACK on the ot= her=20 side, which means that the MGC has to request the MG to perform that tr= ick,=20 presumably by setting a termination or context property to a specific v= alue.=20 So, the purpose of my question was to know whether this kind of mechani= sm=20 was covered or will be covered by H.248.NATTP2P

 

 

Bruno

 

--_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12FRMRSSXCHMBSD_-- From albrecht.schwarz@alcatel-lucent.com Wed May 25 07:40:53 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C709E06FD for ; Wed, 25 May 2011 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUb0zN+d4Wft for ; Wed, 25 May 2011 07:40:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 87433E0655 for ; Wed, 25 May 2011 07:40:51 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4PEdnmG010858 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 16:40:49 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 May 2011 16:40:45 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "bruno.chatras@orange-ftgroup.com" , "megaco@ietf.org" Date: Wed, 25 May 2011 16:40:44 +0200 Thread-Topic: H.248.64 question Thread-Index: AcwaBckP5xqdw+buRuOuZFB2IRS2FAArtuQgAADXECAAC5wBcA== Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E444EB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102E444EB@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEFFRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [Megaco] H.248.64 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:40:53 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEFFRMRSSXCHMBSD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno, not sure I got your point. The MG behaviour may be modeled by using "packet forwarding rules" (and Rul= e =3D {set of conditions for packet identification/classification} + {assoc= iated actions}; R =3D C + A). The 1st set of H.248 packages by H.248.64 (2009) supports following rules, = roughly: I) R =3D "Native forwarding" -> C =3D FIB (RFC 4292) -> A =3D select output plus forwarding or not II) R =3D "Forwarding incl. NAT" -> C =3D ... -> A =3D ... plus NAT III) R =3D "Forwarding incl. basic filtering" -> C =3D ... plus filter conditions -> A =3D ... plus filter actions That's a fairly abstracted summary. Now, I'm guessing that you are considering rules such as: IV) R =3D "Forwarding as DS PHB" or "Forwarding based on IPv4 ToS" ... -> C =3D ... plus DiffServ conditions -> A =3D ... inline with aimed DS PHB (e.g. as DiffServ Edge Router) V) R =3D "Traffic policing + Forwarding" -> C =3D e.g. IP byterate conditions plus ... -> A =3D ... I think that such a rule based description of considered packet operations = would help to clarify a) the requirements first and b) to check whether there are already existing H.248 capabilities or whethe= r extensions might be required. My impression is that we are talking about stage 3 (b) possible solutions b= efore clarifying stage 2 (a) first. Rgds, Albrecht PS Draft H.248.79 touches the topic of "Policy rule based description of packe= t operations" in clause 7.3. It may be noted that ALL known supported funct= ions by H.248 IP-IP MGs may be described by such a rule concept. ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Mittwoch, 25. Mai 2011 10:58 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.64 question Does it mean that you can't you mix-up Best Effort traffic with say VoIP tr= affic De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 25 mai 2011 10:42 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.64 question Bruno, sorry for delay! There are not any straightforward answers because the usage of H.248.52 (& = perhaps H.248.53) implies certain roles. E.g., DSCP marking (using H.248.52): possible roles of an IP node - DS pre-marker - DS edge router - DS interior node (providing DS PHB) ALL existing H.248 Profiles with H.248.52 usage define just the DS pre-mark= er behaviour! Just because there were not any stage 2 requirements for othe= r roles. I guess that this situation is due to the specific location considered for = that H.248 MGs (at the edge, either at access or peering side). Now, I'm not sure what you are looking exactly, hm? Let's consider a "DS interior node" role plus IPR mode. The next question would be whether you are really want a) DS PHB control for individual IP bearer connections? or b) DS PHB control on aggregated level? On a first glance I would conclude that H.248.52 (& .53) togther with H.248= .64 may be applied at the granularity of route levels (aka RIPR contexts). [BC] So the ds/dscp property would be set on a termination of a RIPR contex= t rather than the a termination of an IIPR context? If yes, this need to be= stated somewhere, e.g. in H.248.79.... That's already a sufficient baseline in my opinion for scenarios like NAT66= -less plus DS pre-marker, i.e. an H.248 IP-IP MG located between two IPv6 n= etworks (without the enforcement of local NAPT). Regards, Albrecht ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:29 To: megaco@ietf.org Subject: [Megaco] H.248.64 question Hi all, A question about H.248.64: Is the IPR mode compatible with the use of prop= erties such as those defined in H.248.52 or H.248.53? If yes, I don't reall= y understand how the MGC can request the MG to use a specific DSCP value fo= r a particular packet for example? Can someone shed light on this? Bruno --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEFFRMRSSXCHMBSD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bruno, not sure I got your=20 point.
 
The MG behaviour may be modeled by using "packet= =20 forwarding rules" (and Rule =3D {set of conditions for packet=20 identification/classification} + {associated actions}; R =3D C +=20 A).
 
The 1st set of H.248 packages by H.248.64 (2009)= =20 supports following rules, roughly:
 
I) R =3D "Native forwarding"
    -> C =3D FIB (RFC=20 4292)
    -> A =3D select output plu= s=20 forwarding or not
 
II) R =3D "Forwarding incl. NAT"
    -> C =3D ...=
    -> A =3D ... plus=20 NAT
 
III) R =3D "Forwarding incl. basic=20 filtering"
    -> C =3D ... plus filter=20 conditions
    -> A =3D ... plus filter=20 actions
 
That's a fairly abstracted summary.
 
Now, I'm guessing that you are considering rules= such=20 as:
 
IV) R =3D "Forwarding as DS PHB" or "Forwarding = based on=20 IPv4 ToS" ...
    -> C =3D ... plus DiffServ= =20 conditions
    -> A =3D ... inline with a= imed DS=20 PHB (e.g. as DiffServ Edge=20 Router)
 
V) R =3D "Traffic policing +=20 Forwarding" 
    -> C =3D e.= g. IP=20 byterate conditions plus=20 ... 
    -> A =3D ..= .=20
 
 
I think that such a rule based description of=20 considered packet operations would help to clarify
a) the requirements first
and
b) to check whether there are already existing H= .248=20 capabilities or whether extensions might be required.
 
My impression is that we are talking about stage= 3 (b)=20 possible solutions before clarifying stage 2 (a) first.
 
Rgds, Albrecht
 
PS
Draft H.248.79 touches the topic of "Policy rule based description of packet operations" in=20 clause 7.3. It may be noted that ALL known supported functions by H.248 IP-= IP=20 MGs may be described by such a rule concept.
 
 

From: bruno.chatras@orange-ftgroup.co= m=20 [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 25. = Mai=20 2011 10:58
To: Schwarz, Albrecht (Albrecht);=20 megaco@ietf.org
Subject: RE: H.248.64 question

Does it = mean that=20 you can=92t you mix-up Best Effort traffic with say VoIP traffic=20

 

De : Schwarz, A= lbrecht=20 (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 25 mai 2011 10:42
=C0 : CHATRAS=20 Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.64=20 question

 

Brun= o,

 <= o:p>

sorr= y for=20 delay!

 <= o:p>

Ther= e are=20 not any straightforward answers because the usage of H.248.52 (& perh= aps=20 H.248.53) implies certain roles.

 <= o:p>

E.g.= , DSCP=20 marking (using H.248.52):

poss= ible=20 roles of an IP node

- DS= =20 pre-marker

- DS= edge=20 router

- DS= =20 interior node (providing DS PHB)

 <= o:p>

ALL= =20 existing H.248 Profiles with H.248.52 usage define just the DS pre-marker= =20 behaviour! Just because there were not any stage 2 requirements for other= =20 roles.

I gu= ess=20 that this situation is due to the specific location considered for that H= .248=20 MGs (at the edge, either at access or peering side).

 <= o:p>

Now,= I'm=20 not sure what you are looking exactly, hm?

Let'= s=20 consider a "DS interior node" role plus IPR mode.

The = next=20 question would be whether you are really want

a) D= S PHB=20 control for individual IP bearer connections? or

b) D= S PHB=20 control on aggregated level?

 <= o:p>

On a= first=20 glance I would conclude that H.248.52 (& .53) togther with H.248.64 m= ay be=20 applied at the granularity of route levels (aka RIPR contexts).<= /P>

[B= C] So the=20 ds/dscp property would be set on a termination of a RIPR context rather t= han=20 the a termination of an IIPR context? If yes, this need to be stated=20 somewhere, e.g. in H.248.79=85.

 <= o:p>

That= 's=20 already a sufficient baseline in my opinion for scenarios like NAT66-less= plus=20 DS pre-marker, i.e. an H.248 IP-IP MG located between two IPv6 networks=20 (without the enforcement of local NAPT).

 <= o:p>

Rega= rds,

Albr= echt

 <= o:p>

 <= o:p>

=  

From:=20 megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf O= f=20 bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai = 2011=20 13:29
To: megaco@ietf.org
Subject: [Megaco] H.248.6= 4=20 question=

Hi all,

 

A question about H.248.64: &nbs= p;Is the=20 IPR mode compatible with the use of properties such as those defined in= =20 H.248.52 or H.248.53? If yes, I don=92t really understand how the MGC c= an=20 request the MG to use a specific DSCP value for a particular packet for= =20 example? Can someone shed light on this?

 

Bruno

--_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEFFRMRSSXCHMBSD_-- From bruno.chatras@orange-ftgroup.com Wed May 25 09:04:12 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748C2E071D for ; Wed, 25 May 2011 09:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikcKEHSZvFOA for ; Wed, 25 May 2011 09:04:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id D11A0E0763 for ; Wed, 25 May 2011 09:04:08 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9721D738052; Wed, 25 May 2011 18:05:18 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A54A6738055; Wed, 25 May 2011 18:03:18 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 18:02:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1AF5.14D2BC4E" Date: Wed, 25 May 2011 18:02:00 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102E44824@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.64 question Thread-Index: AcwaBckP5xqdw+buRuOuZFB2IRS2FAArtuQgAADXECAAC5wBcAABJxgg References: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E444EB@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> From: To: , X-OriginalArrivalTime: 25 May 2011 16:02:01.0471 (UTC) FILETIME=[155E40F0:01CC1AF5] Subject: Re: [Megaco] H.248.64 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:04:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1AF5.14D2BC4E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can rephrase my question using the template you have used. Is it = possible for an MGC to request an MG in IPR mode to act according to the = following rule? =20 R =3D Forwarding incl. Packet header modifications -> C =3D ... -> A=3D ... plus modification of the ToS bits =20 If yes, does it have to modify properties of a termination (or stream) = in the IIPR context or of an associated RIPR context? =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 16:41 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.64 question =20 Bruno, not sure I got your point. =20 The MG behaviour may be modeled by using "packet forwarding rules" (and = Rule =3D {set of conditions for packet identification/classification} + = {associated actions}; R =3D C + A). =20 The 1st set of H.248 packages by H.248.64 (2009) supports following = rules, roughly: =20 I) R =3D "Native forwarding" -> C =3D FIB (RFC 4292) -> A =3D select output plus forwarding or not =20 II) R =3D "Forwarding incl. NAT" -> C =3D ... -> A =3D ... plus NAT =20 III) R =3D "Forwarding incl. basic filtering" -> C =3D ... plus filter conditions -> A =3D ... plus filter actions =20 That's a fairly abstracted summary. =20 Now, I'm guessing that you are considering rules such as: =20 IV) R =3D "Forwarding as DS PHB" or "Forwarding based on IPv4 ToS" ... -> C =3D ... plus DiffServ conditions -> A =3D ... inline with aimed DS PHB (e.g. as DiffServ Edge Router) =20 V) R =3D "Traffic policing + Forwarding"=20 -> C =3D e.g. IP byterate conditions plus ...=20 -> A =3D ...=20 =20 =20 I think that such a rule based description of considered packet = operations would help to clarify=20 a) the requirements first=20 and b) to check whether there are already existing H.248 capabilities or = whether extensions might be required. =20 My impression is that we are talking about stage 3 (b) possible = solutions before clarifying stage 2 (a) first. =20 Rgds, Albrecht =20 PS Draft H.248.79 touches the topic of "Policy rule based description of = packet operations" in clause 7.3. It may be noted that ALL known = supported functions by H.248 IP-IP MGs may be described by such a rule = concept. =20 =20 =20 =09 ________________________________ From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Mittwoch, 25. Mai 2011 10:58 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.64 question Does it mean that you can't you mix-up Best Effort traffic with say = VoIP traffic=20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 10:42 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.64 question =20 Bruno, =20 sorry for delay! =20 There are not any straightforward answers because the usage of H.248.52 = (& perhaps H.248.53) implies certain roles. =20 E.g., DSCP marking (using H.248.52): possible roles of an IP node - DS pre-marker - DS edge router - DS interior node (providing DS PHB) =20 ALL existing H.248 Profiles with H.248.52 usage define just the DS = pre-marker behaviour! Just because there were not any stage 2 = requirements for other roles. I guess that this situation is due to the specific location considered = for that H.248 MGs (at the edge, either at access or peering side). =20 Now, I'm not sure what you are looking exactly, hm? Let's consider a "DS interior node" role plus IPR mode. The next question would be whether you are really want a) DS PHB control for individual IP bearer connections? or b) DS PHB control on aggregated level? =20 On a first glance I would conclude that H.248.52 (& .53) togther with = H.248.64 may be applied at the granularity of route levels (aka RIPR = contexts). [BC] So the ds/dscp property would be set on a termination of a RIPR = context rather than the a termination of an IIPR context? If yes, this = need to be stated somewhere, e.g. in H.248.79.... =20 That's already a sufficient baseline in my opinion for scenarios like = NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG located between = two IPv6 networks (without the enforcement of local NAPT). =20 Regards, Albrecht =20 =20 =20 =09 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:29 To: megaco@ietf.org Subject: [Megaco] H.248.64 question Hi all, =20 A question about H.248.64: Is the IPR mode compatible with the use of = properties such as those defined in H.248.52 or H.248.53? If yes, I = don't really understand how the MGC can request the MG to use a specific = DSCP value for a particular packet for example? Can someone shed light = on this? =20 Bruno ------_=_NextPart_001_01CC1AF5.14D2BC4E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I can = rephrase my question using the template you have used. Is it possible for an MGC to = request an MG in IPR mode to act according to the following = rule?

 

R =3D = Forwarding incl. Packet header modifications

-> C =3D …

-> A=3D … plus modification of the ToS = bits

 

If yes, = does it have to modify properties of a termination (or stream) in the IIPR context or = of an associated RIPR context?

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 16:41
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.64 question

 

Bruno, not sure I got your point.

 

The MG behaviour may be modeled by using "packet = forwarding rules" (and Rule =3D {set of conditions for packet identification/classification} + {associated actions}; R =3D C + = A).

 

The 1st set of H.248 packages by H.248.64 (2009) supports following rules, roughly:

 

I) R =3D "Native forwarding"

    -> C =3D FIB (RFC 4292)

    -> A =3D select output plus = forwarding or not

 

II) R =3D "Forwarding incl. NAT"

    -> C =3D ...

    -> A =3D ... plus NAT

 

III) R =3D "Forwarding incl. basic = filtering"

    -> C =3D ... plus filter = conditions

    -> A =3D ... plus filter = actions

 

That's a fairly abstracted summary.

 

Now, I'm guessing that you are considering rules such = as:

 

IV) R =3D "Forwarding as DS PHB" or = "Forwarding based on IPv4 ToS" ...

    -> C =3D ... plus DiffServ = conditions

    -> A =3D ... inline with aimed DS = PHB (e.g. as DiffServ Edge Router)

 

V) R =3D "Traffic policing + = Forwarding" 

    -> C =3D e.g. IP byterate conditions = plus ... 

    -> A =3D ...

 

 

I think that such a rule based description of considered = packet operations would help to clarify

a) the requirements first

and

b) to check whether there are already existing H.248 = capabilities or whether extensions might be required.

 

My impression is that we are talking about stage 3 (b) = possible solutions before clarifying stage 2 (a) first.

 

Rgds, Albrecht

 

PS

Draft H.248.79 touches the topic of "Policy rule based description of packet = operations" = in clause 7.3. It may be noted that ALL known supported functions by H.248 IP-IP = MGs may be described by such a rule concept.

 

 

 

From:= bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 25. Mai 2011 10:58
To: Schwarz, Albrecht (Albrecht); megaco@ietf.org
Subject: RE: H.248.64 question

Does it = mean that you can’t you mix-up Best Effort traffic with say VoIP traffic =

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 10:42
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.64 question

 

Bruno,

 

sorry for delay!

 

There are not any straightforward answers because the = usage of H.248.52 (& perhaps H.248.53) implies certain roles.

 

E.g., DSCP marking (using H.248.52):

possible roles of an IP node

- DS pre-marker

- DS edge router

- DS interior node (providing DS PHB)

 

ALL existing H.248 Profiles with H.248.52 usage define = just the DS pre-marker behaviour! Just because there were not any stage 2 = requirements for other roles.

I guess that this situation is due to the specific = location considered for that H.248 MGs (at the edge, either at access or peering = side).

 

Now, I'm not sure what you are looking exactly, = hm?

Let's consider a "DS interior node" role plus = IPR mode.

The next question would be whether you are really = want

a) DS PHB control for individual IP bearer connections? = or

b) DS PHB control on aggregated level?

 

On a first glance I would conclude that H.248.52 (& = .53) togther with H.248.64 may be applied at the granularity of route levels = (aka RIPR contexts).

[BC] So the ds/dscp property would be set on a termination of a RIPR context rather = than the a termination of an IIPR context? If yes, this need to be stated = somewhere, e.g. in H.248.79….

 

That's already a sufficient baseline in my opinion for = scenarios like NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG located = between two IPv6 networks (without the enforcement of local NAPT).

 

Regards,

Albrecht

 

 

 

From:= megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 2011 13:29
To: megaco@ietf.org
Subject: [Megaco] H.248.64 question

Hi all,

 

A question about H.248.64: =  Is the IPR mode compatible with the use of properties such as those defined in = H.248.52 or H.248.53? If yes, I don’t really understand how the MGC can = request the MG to use a specific DSCP value for a particular packet for example? Can someone shed light on this?

 

Bruno

------_=_NextPart_001_01CC1AF5.14D2BC4E-- From Christian.Groves@nteczone.com Thu May 26 01:30:01 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19E0E06BF for ; Thu, 26 May 2011 01:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkPKpgCs7jxk for ; Thu, 26 May 2011 01:30:01 -0700 (PDT) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BCAE0670 for ; Thu, 26 May 2011 01:30:00 -0700 (PDT) Received: from ppp118-209-101-139.lns20.mel4.internode.on.net ([118.209.101.139] helo=[192.168.0.2]) by cserver5.myshophosting.com with esmtp (Exim 4.69) (envelope-from ) id 1QPVwu-0001kF-B6; Thu, 26 May 2011 18:29:44 +1000 Message-ID: <4DDE0F70.8070207@nteczone.com> Date: Thu, 26 May 2011 18:29:36 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <9ECCF01B52E7AB408A7EB8535264214102E4401C@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CC4@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E444EB@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E44824@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102E44824@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: Cc: megaco@ietf.org Subject: Re: [Megaco] H.248.64 question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:30:02 -0000 Hello Bruno, H.248.64 indicates: 8.3.2 Service-enhanced IPR forwarding Service-enhanced IPR forwarding comprises all functions that may be overlaid on the basic forwarding, e.g., QoS support, traffic control, DiffServ PHBs, policy enforcement (e.g., filtering), traffic metering, etc. There may then be multiple interface IPR contexts, which depend on whether the service was interface- or route-based. and: 9.6.3.1 Creation of a FIB for a context of type "RIPR" "...The MGC may also set properties for service-enhanced IPR forwarding on these terminations...." So yes it is possible to set DSCP depending on the route or interface. Regards, Christian On 26/05/2011 2:02 AM, bruno.chatras@orange-ftgroup.com wrote: > > I can rephrase my question using the template you have used. Is it > possible for an MGC to request an MG in IPR mode to act according to > the following rule? > > R = Forwarding incl. Packet header modifications > > -> C = … > > -> A= … plus modification of the ToS bits > > If yes, does it have to modify properties of a termination (or stream) > in the IIPR context or of an associated RIPR context? > > *De :*Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > *Envoyé :* mercredi 25 mai 2011 16:41 > *À :* CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org > *Objet :* RE: H.248.64 question > > Bruno, not sure I got your point. > > The MG behaviour may be modeled by using "packet forwarding rules" > (and Rule = {set of conditions for packet > identification/classification} + {associated actions}; R = C + A). > > The 1st set of H.248 packages by H.248.64 (2009) supports following > rules, roughly: > > I) R = "Native forwarding" > > -> C = FIB (RFC 4292) > > -> A = select output plus forwarding or not > > II) R = "Forwarding incl. NAT" > > -> C = ... > > -> A = ... plus NAT > > III) R = "Forwarding incl. basic filtering" > > -> C = ... plus filter conditions > > -> A = ... plus filter actions > > That's a fairly abstracted summary. > > Now, I'm guessing that you are considering rules such as: > > IV) R = "Forwarding as DS PHB" or "Forwarding based on IPv4 ToS" ... > > -> C = ... plus DiffServ conditions > > -> A = ... inline with aimed DS PHB (e.g. as DiffServ Edge Router) > > V) R = "Traffic policing + Forwarding" > > -> C = e.g. IP byterate conditions plus ... > > -> A = ... > > I think that such a rule based description of considered packet > operations would help to clarify > > a) the requirements first > > and > > b) to check whether there are already existing H.248 capabilities or > whether extensions might be required. > > My impression is that we are talking about stage 3 (b) possible > solutions before clarifying stage 2 (a) first. > > Rgds, Albrecht > > PS > > Draft H.248.79 touches the topic of "Policy rule based description of > packet operations" in clause 7.3. It may be noted that ALL known > supported functions by H.248 IP-IP MGs may be described by such a rule > concept. > > ------------------------------------------------------------------------ > > *From:*bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > *Sent:* Mittwoch, 25. Mai 2011 10:58 > *To:* Schwarz, Albrecht (Albrecht); megaco@ietf.org > *Subject:* RE: H.248.64 question > > Does it mean that you can’t you mix-up Best Effort traffic with > say VoIP traffic > > *De :*Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > *Envoyé :* mercredi 25 mai 2011 10:42 > *À :* CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org > *Objet :* RE: H.248.64 question > > Bruno, > > sorry for delay! > > There are not any straightforward answers because the usage of > H.248.52 (& perhaps H.248.53) implies certain roles. > > E.g., DSCP marking (using H.248.52): > > possible roles of an IP node > > - DS pre-marker > > - DS edge router > > - DS interior node (providing DS PHB) > > ALL existing H.248 Profiles with H.248.52 usage define just the DS > pre-marker behaviour! Just because there were not any stage 2 > requirements for other roles. > > I guess that this situation is due to the specific location > considered for that H.248 MGs (at the edge, either at access or > peering side). > > Now, I'm not sure what you are looking exactly, hm? > > Let's consider a "DS interior node" role plus IPR mode. > > The next question would be whether you are really want > > a) DS PHB control for individual IP bearer connections? or > > b) DS PHB control on aggregated level? > > On a first glance I would conclude that H.248.52 (& .53) togther > with H.248.64 may be applied at the granularity of route levels > (aka RIPR contexts). > > */[BC] So the ds/dscp property would be set on a termination of a > RIPR context rather than the a termination of an IIPR context? If > yes, this need to be stated somewhere, e.g. in H.248.79…./* > > That's already a sufficient baseline in my opinion for scenarios > like NAT66-less plus DS pre-marker, i.e. an H.248 IP-IP MG located > between two IPv6 networks (without the enforcement of local NAPT). > > Regards, > > Albrecht > > ------------------------------------------------------------------------ > > *From:*megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] *On Behalf Of > *bruno.chatras@orange-ftgroup.com > *Sent:* Dienstag, 24. Mai 2011 13:29 > *To:* megaco@ietf.org > *Subject:* [Megaco] H.248.64 question > > Hi all, > > A question about H.248.64: Is the IPR mode compatible with the > use of properties such as those defined in H.248.52 or > H.248.53? If yes, I don’t really understand how the MGC can > request the MG to use a specific DSCP value for a particular > packet for example? Can someone shed light on this? > > Bruno > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco