Re: [Dcpel] Purpose of a diffserv control plane

[Paulo Mendes <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Pulliam, Jeffrey S
> > Sent: 08 November 2005 03:25
> > To: Kathleen Nichols; [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dcpel
> >
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Dcpel mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dcpel
>  
>


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