Subject: [Dcpel] Dcpel BoF support

From: Olivier Dugeon <[email-masked]>
Date: Fri, 21 Oct 2005 17:28:49 +0200

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:[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: Kathleen Nichols <[email-masked]>
Date: Mon, 24 Oct 2005 15:49:05 -0700

Olivier Dugeon wrote:
> Hi Kahtleen and all,
> 
> I saw some days ago your announce for the Dcpel BoF, and I'm very
> network. 
...

Thanks for an impressive list of reference links!
> 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.
> 
> 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
> 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, this is all quite interesting. Sounds like there are commonalities
to our proposal.

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

> 
> I'm also very confident in this attempt since this kind of functions are
> now studied in various place:
> 
> (Resource Allocation Control Function) for the fixed/mobile IMS convergence.
> 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.

	regards,
		Kathie

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 26 Oct 2005 12:32:29 +0200

Hi Kathleen,

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

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

>slot, so perhaps we could find some time to get together in addition
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

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 26 Oct 2005 09:34:34 -0700

...
> 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".
>>> now studied in various place:

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

	Kathie

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 27 Oct 2005 13:37:13 +0200

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:

> 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.
>
> 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.
>
> a Resource Manager framework with the corresponding 
> interface/protocols around it:
>
> - Topology acquisition
> 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 ?
>
> - And recently the DSL Forum has lunch a new Work Item about the 
> Policy Control Framework.
>
> EuQoS board as well as the France Telecom delegation could attend the BoF.
>
> Best regards,
>
> Olivier Dugeon
>
>-- 
>------------------------------------------------------------------------
>

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 27 Oct 2005 10:18:34 -0700

Paulo Mendes wrote:
...
> flexibility in end-to-end operations. Modularity is always a good

[Kathie]I believe division is the way to go, but I think we need to keep
in mind that we have to make the step from intra- to inter-. This
hasn't seemed all that divergent in the work I've done, but I'm
interested to see others' approaches and concerns. For example,
I think when one constructs in interior control plane, it is
necessary to think about what information  you are willing to
expose to the outside, what you will send and what you will
accept. So I think that sets you up for the inter- step.

<The "you" below refers to Olivier, not to me.>
> qualitative traffic, but also quantitative one.

[Kathie] I really feel the focus should be on a diffserv control plane
for exactly your reasons. I think people like Olivier can perhaps
try to keep us on track not to conflict with other control plane
actions.
<again, the "you" below is Olivier, I think.>
> This distributed approach brings the benefits of higher robustness and

Hmm, I don't think topology acquisition necessarily means "centralized".
After all, routing protocols construct a topology and are distributed.
I've been bothered by the characterization of bandwidth/resource
manager style solutions as "centralized" where I would characterize
them as "network-wide". I think of a diffserv control plane as being
decoupled from the forwarding path but having the network wide awareness
needed to enforce a PDB (so it sounds like we agree here). The actual
entity or entities that implement this can be as "centralized" or
"distributed" as needed.
> differences between all these approaches to see where this BoF would fit.

Okay. Do you mean centralized vs distributed approaches to diffserv
control plane? I would somewhat like to see if we can do something
that can include all of that range, but perhaps that's not possible.

	Kathie