RE: [Dcpel] Purpose of a diffserv control plane

"Hancock, Robert" <robert.hancock@roke.co.uk> Tue, 08 November 2005 18:29 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYDc-0006il-1X; Tue, 08 Nov 2005 13:29:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYDa-0006id-Tq for dcpel@megatron.ietf.org; Tue, 08 Nov 2005 13:29:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24232 for <dcpel@ietf.org>; Tue, 8 Nov 2005 13:28:48 -0500 (EST)
Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYTP-00042e-28 for dcpel@ietf.org; Tue, 08 Nov 2005 13:45:38 -0500
Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id jA8ISbWA019656; Tue, 8 Nov 2005 18:28:37 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHY1X8; Tue, 8 Nov 2005 18:33:27 -0000
MIME-Version: 1.0
Content-class: urn:content-classes:message
Subject: RE: [Dcpel] Purpose of a diffserv control plane
Date: Tue, 08 Nov 2005 18:28:28 -0000
Message-ID: <00ba01c5e492$39d1b510$b66c34d1@comm.ad.roke.co.uk>
Thread-Topic: [Dcpel] Purpose of a diffserv control plane
Thread-Index: AcXkkulgz1x4zWgwSPWPdjPNRAyQug==
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "Pulliam, Jeffrey S" <jeffrey.s.pulliam@lmco.com>, Kathleen Nichols <nichols@pollere.com>, dcpel@ietf.org
X-MailScanner-rsys001x: Found to be clean
X-MailScanner-From: robert.hancock@roke.co.uk
X-Spam-Score: 0.5 (/)
X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e
Cc:
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>
Content-Type: multipart/mixed; boundary="===============1977883033=="
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

Hi Jeff, Kathie,

I think the problem that I am having (and maybe some others) in
following this discussion is that the problem scope is potentially
so enormous that it is difficult to work out how to start 
discussing it, and commonplace for discussions to proceed at cross
purposes because people are talking about different bits of it.

Kathie's prior mail described this activity as the diffserv analogy
of moving from static routes to RIP. However, if the model is of
network-level controller nodes which manage groups of routers, a
closer analogy (to my mind) would be moving from static routes to
inter-domain MPLS. (I'm not saying this approach is wrong, just 
trying to stress that it is quite a leap.) There is also a terminological
problem, that words like 'signaling' or 'control function' mean
very specific things to some people, but to others are extremely 
broad.

My very crude take on what Jeff describes below is that one can 
imagine 5 different components to the problem, i.e.
1) a language for describing the services that are requested
2) logic for deciding whether and how to implement the requests
3) a protocol mechanism for initiating requests with domains
and carrying requests between them
4) interaction with AAA (especially authorisation/accounting) 
functions to support the decision process
5) protocol mechanisms to implement the decision in the forwarding
plane

Now my question is whether the purpose of DCPEL is to work specifically
on some or all of these, or whether initially it is to work on
understanding how they fit together (or on some similar decomposition).
Note that at least (3), (4) and (5) could all be described as 
'signalling', and (2)-(4) as 'control functions'; OTOH I got the
impression last night (maybe incorrectly) that Scott at least was 
mainly interested in (1).

Or have I missed the point entirely?

Robert H.

ps. see you at lunch :-)

> -----Original Message-----
> From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] 
> On Behalf Of Pulliam, Jeffrey S
> Sent: 08 November 2005 03:25
> To: Kathleen Nichols; dcpel@ietf.org
> Subject: [Dcpel] Purpose of a diffserv control plane
> 
> 
> 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
> Dcpel@ietf.org
> https://www1.ietf.org/mailman/listinfo/dcpel
> 
_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel