Re: [Dcpel] Dcpel BoF support

Paulo Mendes <mendes@docomolab-euro.com> Thu, 27 October 2005 11:35 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV62B-00081v-Lk; Thu, 27 Oct 2005 07:35:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV629-00081F-NK for dcpel@megatron.ietf.org; Thu, 27 Oct 2005 07:35:01 -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 HAA22537 for <dcpel@ietf.org>; Thu, 27 Oct 2005 07:34:44 -0400 (EDT)
Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV6FV-00074b-LH for dcpel@ietf.org; Thu, 27 Oct 2005 07:48:50 -0400
Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 27 Oct 2005 13:34:32 +0200
Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Oct 2005 13:34:32 +0200
Message-ID: <4360BBE9.3070207@docomolab-euro.com>
Date: Thu, 27 Oct 2005 13:37:13 +0200
From: Paulo Mendes <mendes@docomolab-euro.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Olivier Dugeon <olivier.dugeon@francetelecom.com>
Subject: Re: [Dcpel] Dcpel BoF support
References: <43590931.5080809@francetelecom.com>
In-Reply-To: <43590931.5080809@francetelecom.com>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Oct 2005 11:34:32.0591 (UTC) FILETIME=[667281F0:01C5DAEA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: 7bit
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 Olivier, Kathleen and all,

It is good to know that the partners in IST EuQoS are planning to 
support this BoF. I was acquainted in joint QoS workshop of EuQoS and 
Mescal with the idea to create one BoF on Resource Management. I think 
that the QoS community will gain in having all the interested parties in 
the same BoF. So, it will be a good exercise to merge, as possible, the 
ideas behind both proposals.

Concerning  the charter, I think that it will be more efficient to 
divide the effort in inter- and intra-domain. The main reason, in my 
opinion is that decoupling inter- and intra- this will bring more 
flexibility in end-to-end operations. Modularity is always a good principle.

You say that your focus in not on DiffServ to enforce QoS in the 
network, but on the definition of a Resource Manager framework. Good, 
but this Resource Management framework can still be defined with two 
modules for inter- and intra-domain, connected by a network interface. 
But, in what concerns the intra-domain resource control, I don't know 
why shouldn't we focus on DiffServ. First, the DiffServ model is clearly 
lacking a control plane; second, other QoS enforcement mechanisms, such 
as MPLS, already define how resources may be controlled. Moreover, I 
still think that DiffServ as a lot of potential, not only to support 
qualitative traffic, but also quantitative one.

Another question is related to the 'topology acquisition' item. This 
means that you think that the control of resources within a DiffServ 
network should be centralized in a "resource manager", which will then 
need to collect topology information? Since a PDB is already defined in 
a distributed way, why not allow the control of resources to be 
distributed, with most of the operations being located at the edges? 
This distributed approach brings the benefits of higher robustness and 
perhaps performance.

In what concerns the other standardization efforts, I would say that it 
would help a lot this BoF, if we had a brief document characterizing the 
differences between all these approaches to see where this BoF would fit.

Cheers,
Paulo

Olivier Dugeon wrote:

> Hi Kahtleen and all,
>
> I saw some days ago your announce for the Dcpel BoF, and I'm very 
> enthousiste about your initiative. Indeed, I'm working for 5 years now 
> in the field of QoS control and especially the control plane of IP 
> network. My past research concern an european IST project named 
> CADENUS (http://www.cadenus.fokus.fraunhofer.de) which aimed to define 
> a QoS framework and also follow on  the TEQUILA one 
> (http://www.ist-tequila.org) . Now I'm involve in a new european 
> project named EuQoS (http://www.euqos.org) which have for goal to 
> study the end-to-end QoS over heterogeneous network. Inside France 
> Telecom, I also conducting projects in this field area, and, inside 
> this scope, have established a great collaboration with Operax people.
>
> In june, we organized a joint QoS workshop with EuQoS and Mescal 
> project. Proceeding of this workshop could be found at 
> http://www.euqos.org/shownews.php?idnews=9 or at 
> http://www.mescal.org/EEQoS/index.html which could give you a good 
> overview of the start of the art of the european research in this 
> area. The conclusion of this workshop was about the creation of a 
> Resource Management BoF for the control plane of IP network. A 
> dedicated mailing list have been created for this purpose to 
> carrefully prepare the BoF since many attemps was unsuccessfull during 
> the past (for example SLS BoF, NSIS off-path and so on). But, this 
> attempt didn't encounter success. So, it was a pleasure to discover 
> your initiative and to joint it.
>
>>From the EuQoS board, many peoples have express their interrest for 
> this BoF. Inside France Telecom, I already got interests from my 
> colleagues for such study, and of course, to support this BoF.
>
> Concerning the charter, in our initiative, we intend to not only focus 
> on DiffServ to enforce QoS in the network. Our goal was more to define 
> a Resource Manager framework with the corresponding 
> interface/protocols around it:
>
> - Topology acquisition
> - Inter Resouce Manager protocol both for intra and inter domain SLS 
> exchange
> - Service request interface
> - Devices configuration which in fact have link to COPS and netconf WG
> - Link to PCE
>
> We have volunteer exclude business aspect as well as the Call 
> Admission Control algorithm which, in our opinion are not in the scope 
> of the IETF. In parallel, and for the framework, we think that we must 
> seperate what is devoted for the provisionning of resources and the 
> usage of the resources itself (i.e. the per flow control). In fact, it 
> could be related to the NSIS off-path BoF attempt which occur some 
> time ago.
>
> 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 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.
>
> Best regards,
>
> Olivier Dugeon
>
>-- 
>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
>  
>


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