Re: [Dcpel] Purpose of a diffserv control plane
Paulo Mendes <mendes@docomolab-euro.com> Fri, 11 November 2005 03:01 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 1EaPAR-0000Z5-A9; Thu, 10 Nov 2005 22:01:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaPAP-0000Yx-Aa for dcpel@megatron.ietf.org; Thu, 10 Nov 2005 22:01:29 -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 WAA05937 for <dcpel@ietf.org>; Thu, 10 Nov 2005 22:01:00 -0500 (EST)
Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaPQj-0005GO-TL for dcpel@ietf.org; Thu, 10 Nov 2005 22:18:22 -0500
Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 11 Nov 2005 04:01:09 +0100
Received: from [172.25.56.71] ([172.25.56.71]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 11 Nov 2005 04:01:08 +0100
Message-ID: <43740C2F.5010702@docomolab-euro.com>
Date: Fri, 11 Nov 2005 04:12:47 +0100
From: Paulo Mendes <mendes@docomolab-euro.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Subject: Re: [Dcpel] Purpose of a diffserv control plane
References: <00ba01c5e492$39d1b510$b66c34d1@comm.ad.roke.co.uk>
In-Reply-To: <00ba01c5e492$39d1b510$b66c34d1@comm.ad.roke.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Nov 2005 03:01:09.0017 (UTC) FILETIME=[2A486090:01C5E66C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a492040269d440726bfd84680622cee7
Content-Transfer-Encoding: 7bit
Cc: dcpel@ietf.org
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>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org
Hi Robert and all, Hancock, Robert wrote: > 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. > The major problem that we are trying to tackle is the lack of control over DiffServ domains. More specifically, the possible static configuration of PDBs do not allow any reaction or adjustment to different intra-domain network conditions, policies, or inter-domain relationships. Hence, we need to develop a platform that allows the automatic adjustment of PDBs (IMO, updating the behavior of the edges, and the bandwidth allocated to the PDB). This is the first problem to tackle. Second, even with a platform allowing the control of DiffServ networks, how can we automatically control the interworking between neighbor domains? For this, we need a standard inter-domain interface. These are the two problems that we identified in the I-D about Requirements for DCPEL that Kathie made available before the meeting. We may argue, like we do in that I-D, that the inter-domain interface should be independent from specificities of the intra-domain control plane. In this case it is up to us to decide to develop such interface, while exemplifying its use between DiffServ domains, or to say that we don't care about the problem of inter-domain QoS. It is my opinion that developing a control plane for DiffServ domains is something that its needed, but without the inter-domain interface we are not allowing interworking of DiffServ domains, and so limiting the control of traffic differentiation and QoS in the Internet. Is this too much work to be done? Probably. Is this the functionalities to allow QoS control (including traffic differentiation) in the Internet based upon the DiffServ model? Definitely. So, I see that it is very coherent to define a working plan including the developing of solutions for these two problems, while keeping a clear priority in the work to be done. > 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. > How do you go from intra-domain static routes (I read this as intra-domain, since the context refers to RIP) to inter-domain MPLS? How did MPLS came to the picture? > 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). > Unfortunately I couldn't participate in the Vancouver meeting, so it is difficult for me to comment on reactions to what happened in the meeting. Nevertheless, the I-D that Kathie made available tries to build a starting point for the discussion on the problem statement, assumptions and requirements. Was this document worth of some discussion? About the 5 points that Jeff mentioned, my remote possible opinion is: 1) the need for an Information Model to describe services to be requested and offered between network domains was mentioned in the I-D 2) where to implement the requests: in the I-D we refer as assumption the exiting of network-wide agents (agents with network-wide functionality) and local-agents (such as agents placed at the edges of a network). These are the places to configure due to a set of requests. How to configure them depends on what functionalities we decide to place in these two types of control elements, and on a needed intra-domain interface. 3) The I-D refers the need to develop an inter-domain interface, which will allow signaling between two adjacent domains, based on the Information Model referred in 1). Moreover, this interface should be generic enough to allow its use between DiffServ domains and between end-hosts and a DiffServ domain. (Probably I missed this requirement in the I-D). 4) the interaction with AAA is also referred in the I-D, in which an initial reference to authentication and trust is made, and in which is also said that "Authentication may be a part of the control plane, or may be an accessible external functionality". However, lots of work in the what concerns requirements still needs to be done. 5) The need for a protocol to adjust the PDBs is also mentioned in section 5.4 of the I-D. That section provides a brief example of how a mechanism to implement the decision in the forwarding plane of a DiffServ domain may be done. Nevertheless, as said, we should look at existing protocols that may fit the needed requirements, of part of it (in the latter case, DCPEL may suggest extensions, modifications, etc, to those protocols). For instance, we could analyze how the NSIS proposals could be used for this propose, in order to signal several network elements in the data path (path formed by all routers crossed by data packets) from one ingress to one egress point. To implement the mentioned inter-domain interface, IMO we need signaling decoupled from the data path. And since the elements involved in the signaling process are only the initiator (one element in one domain) and the destination (one element in a neighbor domain), it is not clear if all the functionalities provided by NTLP are needed. So, needs to be analysed how can current proposals for off-path NSIS signalling fit some of the requirements of the DCPEL (intra or inter-domain). I'm saying this since DCPEL aims, IMHO, to analyse network-to-network behaviors (traffic oriented!), and not end-to-end behaviors (flow oriented!). So, answering to your questions. IMO, DCPEL should aim to look at all these issues, since they are all needed to define the control elements of a DiffServ domain. Once more, it is up to us to schedule such work after a good understanding of assumptions and requirements. IMO, we need to discuss the problem statement and scope, the list of assumptions and the requirements for th e DCPEL. This will allow us to clearly define a charter with a coherent work priority. Paulo > 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 > > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel
- [Dcpel] Purpose of a diffserv control plane Pulliam, Jeffrey S
- Re: [Dcpel] Purpose of a diffserv control plane Steven Van den Berghe
- RE: [Dcpel] Purpose of a diffserv control plane Hancock, Robert
- Re: [Dcpel] Purpose of a diffserv control plane Paulo Mendes
- RE: [Dcpel] Purpose of a diffserv control plane Pulliam, Jeffrey S
- RE: [Dcpel] Purpose of a diffserv control plane Roy, Radhika (AEAD)
- Re: [Dcpel] Purpose of a diffserv control plane Paulo Mendes