Subject: Re: [Dcpel] Dcpel BoF support

From: Olivier Dugeon <[email-masked]>
Date: Wed, 02 Nov 2005 18:54:04 +0100

Hi Kathleen,

Kathleen Nichols a écrit :

Olivier Dugeon wrote:

Kathleen Nichols a écrit :

Olivier Dugeon wrote:

...

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.

Okay, this is of course useful stuff and something we all end up doing
in adapting to a particular network. It seems like it would be useful
if it is possible to have some kind of commonality in how L2 interacts
with L3 diffserv mechansims so that the control plane can be
technology independent. Though this needs to be considered when
designing a network QoS solution, I'm not sure we should put it on
dcpel's work list. At least not immediately. It seems to me that
at some point this might need some kind of sub-category of "Advice
to Link Layer Designers".

I'm also very confident in this attempt since this kind of functions are
now studied in various place:

So, in your opinion, what are the major things Dcpel could *add* to this
work?

From your remarks, I think we need to add a focus on technology
independent control plane with a link to L2. I.e. add a clear
separation between the control part and the device configuration part
in the architecture of the control plane. Concerning the device
configuration, the WG could just focus on DiffServ configuration
through COPS for example and let open configuration of others
technology. IMHO, I think that the WG should be chartered in order to
build an open framework and decline this framework for a use case which
is DiffServ.

Regards,

Olivier

Kathie

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

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

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

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 02 Nov 2005 19:10:27 +0100

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

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 11 Nov 2005 04:10:22 +0100

Hi Oliver,

some comments inline...

Olivier Dugeon wrote:

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

Both. Control of admission of new flows to the aggregate defined by the 
suitable PDB, and allocation of network resources to that PDB as needed. 
The latter issues as to do with the way the communication resources are 
divided between the implemented PDBs.

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

Agree. We have two options. Or the messages needed to updated the 
provision of PDBs follow the data path from ingress to egress (in this 
case the knowledge about the topology is as distributed as the routing), 
or the messages are originated in a element outside the data path (in 
this case, it seems that this element has to have a knowledge about the 
topology, not only from its point of view, but also from the point of 
view of any ingress device in the network).

> core network which is completely the scope of the IETF.

If I can have something else. In the process of defining a possible 
charter, we should not forget that one reason that seems to be 
responsible for the postponing of the QoS issue in the 3GPP is the lack 
of IETF solutions to control QoS, and differentiate traffic, mainly 
between networks.

Paulo