Subject: [Dcpel] Purpose of a diffserv control plane

From: "Pulliam, Jeffrey S" <[email-masked]>
Date: Tue, 08 Nov 2005 03:25:24 -0800

A couple of things - 

- For those interested in follow up, I want to repeat the offer of lunch at the IETF on Tuesday November 8 at 11:30 - in the MacKenzie room.  The room is on the first floor near the meeting registration tables.   

- In hopes of starting a discussion, I would like to try out the following as a starting position for discussion:

The purpose of a diffserv control plane is to provide automated control of the diffserv domain, governed and constrained by policy.  Control functions configure the diffserv domain to deliver services in response to requests.  Requests to the control function are made by users, network operations, and  network management.  The control plane contains necessary  rules and logic to respond to the requests automatically, with resulting actions including actions to configure the network to accept (or reject) the request, and actions to respond to the requestor with status of the request.

Request can originate internal to the diffserv domain, or originate from other network domains. Actions in response to the requests are either actions affecting the internal diffserv domains, or are actions that cross domain boundaries (in the form of requests?).  A quick and dirty simple picture showing the contexts (lots of room for improvement).
                        
Requestors     Control         Actions

            ***********
User<------>*         *<----->Network Configuration
            * Control *
Net Op<---->*  Plane  *
            *         *<----->Response to Requestor
Net mgt<--->***********

What is the role, functions, and constraints of signaling within the diffserv domain?  I would like to revise (or replace) the above to accurately reflect the role of signaling within a diffserv domain.  

Suggestions?

Jeff Pulliam

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

---

From: Steven Van den Berghe <[email-masked]>
Date: Tue, 8 Nov 2005 19:23:38 +0100

Thanks to some timezone difficulties, i had some time this morning to reflect 
on the results of the ops area meeting and tried to identify some interesting 
things that would be useful for dcpel to work on, and aren't afaik tackled in 
the related WGs (NSIS etc). 

One thing that came to mind was differentiated admission control (or control 
plane service differentiation): although services at the dataplane are 
identified by their codepoint, several higher level services could use this 
DSCP-identified transport (e.g. you could have an EF dataplane connectivity 
for multimedia services, but with a business/residential user differentiation 
at the control plane).

I used to play around with a few of these things a while ago (in a TE 
environment, but it is probably marginally applicable to dcpel too). The idea 
was to introduce the concept of a QoS-session, using XACML as a service 
description and access mechanism. Some slides on this work can be found on:
http://www.policy-workshop.org/2004/slides/Berghe-SonarPolicy04.pdf

Regards,
Steven

On Tuesday 08 November 2005 12:25, Pulliam, Jeffrey S wrote:
> A couple of things -
>
> - For those interested in follow up, I want to repeat the offer of lunch at
> the IETF on Tuesday November 8 at 11:30 - in the MacKenzie room.  The room
> is on the first floor near the meeting registration tables.
>
> The purpose of a diffserv control plane is to provide automated control of
> the diffserv domain, governed and constrained by policy.  Control functions
> configure the diffserv domain to deliver services in response to requests. 
> Requests to the control function are made by users, network operations, and
>  network management.  The control plane contains necessary  rules and logic
> to respond to the requests automatically, with resulting actions including
> actions to configure the network to accept (or reject) the request, and
> actions to respond to the requestor with status of the request.
>
> Request can originate internal to the diffserv domain, or originate from
> other network domains. Actions in response to the requests are either
> actions affecting the internal diffserv domains, or are actions that cross
> domain boundaries (in the form of requests?).  A quick and dirty simple
> picture showing the contexts (lots of room for improvement).
>
> What is the role, functions, and constraints of signaling within the
> diffserv domain?  I would like to revise (or replace) the above to
> accurately reflect the role of signaling within a diffserv domain.
>
> Suggestions?
>
> Jeff Pulliam
>
>
>

-- 
Steven Van den Berghe
Department of Information Technology
Ghent University - IBBT - IMEC
http://www.ibcn.intec.ugent.be
Tel: +32 (0) 9 331 49 73
Fax: +32 (0) 9 331 48 99