Re: [Dcpel] Dcpel BoF support

Olivier Dugeon <olivier.dugeon@francetelecom.com> Wed, 26 October 2005 10:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiaK-0005p4-76; Wed, 26 Oct 2005 06:32:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiaG-0005oV-Jd for dcpel@megatron.ietf.org; Wed, 26 Oct 2005 06:32:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10253 for <dcpel@ietf.org>; Wed, 26 Oct 2005 06:32:24 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUinO-0004ef-EV for dcpel@ietf.org; Wed, 26 Oct 2005 06:46:15 -0400
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:32:29 +0200
Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:32:29 +0200
Message-ID: <435F5B3D.40706@francetelecom.com>
Date: Wed, 26 Oct 2005 12:32:29 +0200
From: Olivier Dugeon <olivier.dugeon@francetelecom.com>
Organization: France Telecom
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Kathleen Nichols <nichols@pollere.com>
Subject: Re: [Dcpel] Dcpel BoF support
References: <43590931.5080809@francetelecom.com> <435D64E1.4000605@pollere.com>
In-Reply-To: <435D64E1.4000605@pollere.com>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 26 Oct 2005 10:32:29.0726 (UTC) FILETIME=[9108A3E0:01C5DA18]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: quoted-printable
Cc: dcpel@ietf.org
X-BeenThere: dcpel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

Hi Kathleen,

Kathleen Nichols a écrit :

>Olivier Dugeon wrote:
>  
>
[ ... skip ... ]

>>So, do you think the charter must be only focus on DiffServ or could it
>>be open to other QoS enforcement mechanism ? Or, for the strategy, is it
>>preferable to focus on DiffServ, and after the WG created, open the
>>scope to other technology ?
>>    
>>
>
>I'm in favor of keeping the focus limited at any one time, but
>rechartering is fine when some things get done. But what other QoS
>enforcement mechanisms did you have in mind besides diffserv?
>  
>
In fact, inside the EuQoS project, we intend to manage several 
technology (in particular the access part) across a common view of the 
QoS. This why, in our architecture there is 2 view of the Control Plane. 
One which technology independent and manage the inter-domain and the 
other which is technology dependent and manage the intra domain part. 
So, from the DiffServ point of view, this could result to setup 
approriate L2 mechanism in order to provide a DiffServ aware QoS 
mechanism. For example, in xDSL ATM or GE network, the EF class could be 
map to a CBR ATM ATC or a particular VLAN. This could be also apply if 
you intend to used MPLS-DiffServ mechanism.

>  
>
>>I'm also very confident in this attempt since this kind of functions are
>>now studied in various place:
>>
>>- The Multi Switching Forum (MSF) have already identified a such
>>function (Bandwidth Manager) for VoIP. The document was written by
>>Operax people.
>>- The ETSI-TISPAN have almost achieve the specification of the RACS
>>(Resource Allocation Control Subsystem) which embedded the RACF
>>(Resource Allocation Control Function) for the fixed/mobile IMS convergence.
>>- 3Gpp has already specify such function in Release R6 for the IMS (IP
>>Multemedia Subsystem)
>>- The ITU-T NGN Focus Group doing a parallel work as the ETSI, but
>>including the intra domain and in a more general way as the IMS
>>- And recently the DSL Forum has lunch a new Work Item about the Policy
>>Control Framework.
>>
>>Finally, the IETF is the only place where such study is not yet conduct.
>>
>>I not planned to attend the Vancouver meeting, but people from the EuQoS
>>board as well as the France Telecom delegation could attend the BoF.
>>
>>    
>>
>
>It would be nice if someone could attend. We don't have a very long time
>slot, so perhaps we could find some time to get together in addition
>to the BoF.
>  
>
I get answer from FT people. So, normaly someones from FTR&D will attend 
the BoF attempt. From EuQoS, I'm not sure someone could be present.

Regards,

Olivier

>	regards,
>		Kathie
>
>  
>

-- 
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           | mailto:Olivier.Dugeon@francetelecom.com
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85



_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel