RE: [Dcpel] Purpose of a diffserv control plane
"Pulliam, Jeffrey S" <jeffrey.s.pulliam@lmco.com> Sun, 13 November 2005 08:58 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 1EbDgv-00082a-6W; Sun, 13 Nov 2005 03:58:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbDgu-00082T-2k for dcpel@megatron.ietf.org; Sun, 13 Nov 2005 03:58:24 -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 DAA22082 for <dcpel@ietf.org>; Sun, 13 Nov 2005 03:57:52 -0500 (EST)
Received: from mailgw2a.lmco.com ([192.91.147.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbDxc-0005AP-Uf for dcpel@ietf.org; Sun, 13 Nov 2005 04:15:45 -0500
Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id jAD8w7hq021658; Sun, 13 Nov 2005 03:58:08 -0500 (EST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IPV00301Y8V02@lmco.com>; Sun, 13 Nov 2005 00:58:07 -0800 (PST)
Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IPV00K4JY8S5M@lmco.com>; Sun, 13 Nov 2005 00:58:04 -0800 (PST)
Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 13 Nov 2005 00:58:04 -0800
Date: Sun, 13 Nov 2005 00:58:03 -0800
From: "Pulliam, Jeffrey S" <jeffrey.s.pulliam@lmco.com>
Subject: RE: [Dcpel] Purpose of a diffserv control plane
To: Paulo Mendes <mendes@docomolab-euro.com>, "Hancock, Robert" <robert.hancock@roke.co.uk>
Message-id: <CF127EA649E2804ABF97FD457A9FD4B308AE7B01@emss01m10.us.lmco.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-Topic: [Dcpel] Purpose of a diffserv control plane
Thread-Index: AcXmbD/DK4FxPq9LSxuTgmYcnad2kABt4l/A
content-class: urn:content-classes:message
X-OriginalArrivalTime: 13 Nov 2005 08:58:04.0312 (UTC) FILETIME=[5B9E9180:01C5E830]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4
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
Pablo Good start on a requirements document. I suspect we will discuss requirements a lot before this is done. A few comments: I generally agree with your assumptions in the ID you and Kathie drafted, as well as the core requirements. There are points of concern I would like to bring up. - Signaling Protocol Translations I fully concur with use of signaling protocols developed in other efforts in the IETF. In addition to NSIS, we need to recognize RSVP/ARSVP as an appropriate signaling protocol for use in a DiffServ Control Plane. Further, we should give some thought to the possibility that different domains will use different signaling protocols, and that the interdomain control plane function should allow for / provide for translation between signaling protocols. Your draft has the following language that heads in this direction ***SNIP**** from the requirements draft 4.0 Assumptions ... o Existing protocols, such as HTTP, COPS, SNMP, NETCONF, or the NSIS protocol suite. ... 5.2. Intra-domain Control o There must be a common intra-domain interface, allowing network elements to coordinate their actions, independently of the degree of control distribution. This interface can by defined by messages sent over protocols such as COPS, SNMP, or the NSIS protocol suite. ***SNIP*** I recommend including RSVP/ARSVP in both lists of protocols. Also suggest that specification of use of a specific signaling protocol should be constrained to a single domain, or a single relationship between two distinct domains. A domain should be free, and the control plane should enable a domain to interact with other domains over multiple signaling protocols, if necessary. But primarily, I don't want to leave out the RSVP/ARSVP protocol suite, and think we need to leverage the work currently underway focused on effecting precedence and pre-emption, as well as security related issues. You identify two roles a domain can play, provider, and customer. What do you think about subdividing the provider role into access provider, and transit provider? One example of a transit provider is in the assumptions in your draft ***SNIP*** from the requirements draft 4. Assumptions ... o For inter-domain considerations, although not all networks will be DiffServ, all will interact based on the same inter-domain control interface. For instance, backbone networks may be over- provisioned, but they will still offer and negotiate QoS agreements with its neighbors. ... ***SNIP*** The overprovisioned backbone provider will communicate using the DiffServ Control plane mechanisms, but will map all traffic to one of it's offered services, and provide signaled, unimpeded, albeit overprovisioned transit through it's domain as it's contribution to end to end service delivery. The fact that it is an overprovisioned network will be invisible to the neighboring interconnected diffserv domains. Which is ok if that transit meets the allocated portion of the end-to-end spec for the offered diffserv service? Media Dependent Requirements - So another recurring theme that seems to be in the requirements draft is that different domain types will have different requirements that are media dependent. In the draft, you mention mobile networks in a few places, and the need to support mobile networks. It might be useful in the requirements draft to isolate requirements that emerge that are specific to mobile networks. Another network type that would be useful to have addressed in the draft is satellite networks. A satellite network can provide diffserv enabled services, but in the case of the geostationary satellite, will impact the end to end guarantee of latency. A useful requirement that is somewhat specific to satellite networks is that when a network domain in unable to deliver services within the spec for the end to end service, that it make an offer of services to be delivered within a modified spec. For example, in a case where end to end latency requirement is under 150ms, a geostationary satellite network asked to participate might offer services with an additional 260 - 300 ms latency, resulting in an end to end service with 410-460ms latency. I feel the need for a picture, and will take a swing at it and send when complete. More Below Jeff > -----Original Message----- > From: Paulo Mendes [mailto:mendes@docomolab-euro.com] > Sent: Thursday, November 10, 2005 7:13 PM > To: Hancock, Robert > Cc: Pulliam, Jeffrey S; Kathleen Nichols; dcpel@ietf.org > Subject: Re: [Dcpel] Purpose of a diffserv control plane > > 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 [[jeff]] So I support development of an information model for diffserv control plane information, and this is certainly a part of the language in point 1. There are some higher order concepts that we should attack in route to the development of the information model, which includes a list and definition of what should be in the information model, a list of verbs that contains the actions performed by the control plane. > 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. [[jeff]] So this is a little different that Roberts point 2 - but is important. My point, which Robert phrased fairly well, was that the control plane needs to have logic for deciding how to implement the request within the domain, and where necessary, to request services from other domains. This is roughly equivalent to a routing IGP and EGP. I will be able to support a model for the control plane that is agent based, that provides for implementation flexibility. > 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). [[jeff]] Sounds like we concur. As mentioned above, the protocol should be useable between DiffServ domains and "overprovisioned" networks. > 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. [[jeff]] In particular on issues of trust, and use of authentication services provided external to the diffserv control plane. I don't think we want to create our own AAA function unless necessary, and in the case of authentication and authorization, we should allow for use of whatever the domain feels is necessary. > 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!). [[jeff]] So I was in agreement until the last - the control plane either needs to be able to translate a flow oriented requirement into a traffic oriented policy, or something else does. So I expect we will want to discuss this a bit. > > 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. [[jeff]] Agree - > > 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