RE: [Dcpel] Purpose of a diffserv control plane

["Pulliam, Jeffrey S" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, November 10, 2005 7:13 PM
> To: Hancock, Robert
> Cc: Pulliam, Jeffrey S; Kathleen Nichols; [e-mail]
> 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: [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