Re: [Dcpel] Dcpel BoF support

[Olivier Dugeon <[e-mail]>]

Hi Paulo,

Paulo Mendes a écrit :

> 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.

Yes, it is our (the EuQoS people at least) objective.

>
> 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.

Ok, I'm writing a bit faster. I have in mind to built an open framework 
with the DiffServ implementation.  So, skip the term of Resource Manager 
and just keep that the architecture of a such control must be open and 
flexible. If we can achieve a such goal for DiffServ, it could be easy 
to extend it to other technology. I'm agree that DiffServ is lacking of 
a control plane and have great potential. Concerning the quantitative 
support, do you have in mind Admission Control and/or Resource Reservation ?

>
> 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.

Well, under the 'topology acquisition', I'm not thinking about a 
centralized or distributed way of implementation. I'm just refering to 
the quantitative support of QoS with DiffServ. To do this, it is 
necessary to have a minimum knowledge of the controlled network in order 
to perform admission control or resource reservation. Another point is 
device configuration. If the QoS request is not following the data path 
(i.e. coming from a SIP proxy for example) the topology information is 
again mandatory to retrieve the correct ingress node in order to 
configure it.

>
> 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.

If you breifly look at the standardization efforts, you could obsrve 
that they all focus for the moment:

1/ on conversational services (based on SIP)
2/ on access network and especially on xDSL network

So, there is a great opportunity for Dcpel to study data services on 
core network which is completely the scope of the IETF.

Cheers,

Olivier

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



_______________________________________________
Dcpel mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel