Subject: [Diffserv] BA draft

From: Dan Grossman <[email-masked]>
Date: Wed, 12 Apr 2000 13:56:57 -0400

Yesterday, I mentioned having discussed some ideas that Brian concerning the 
BA draft.  It is becoming increasingly clear that these ideas need to be 
discussed on the list at the same time as the other issue with the definition 
of BA, especially since that discussion is going off into the weeds.

Since Adelaide, I've also had a chance to think some more about this, and will 
mix some of those thoughts with what we discussed.  Brian is free to disagree 
with and/or repudiate any or all of the following.  

The problem as I now see it is that we seem to agree that we need a framework 
for an amphibious bird that has a long flat beak, waddles on webbed feet and 
quacks --- but we're not allowed to call it a duck :-).  So be it.  The -00 BA 
draft tried to dance around the problem by appropriating another concept and 
redefining it halfway (as Scott pointed out yesterday, and I was trying to 
point out in Adelaide).  This did nothing but confuse matters.  The concept of 
the following is to retain the meaning of BA as we presently know it.  It then 
creates a new term that contains "BA" to really mean edge-to-edge service; The 
latter is in the interest of not having to revise the charter, or violate the 
taboo against defining services. 

New terms (sorry):
Behavior Aggregate Class (BA Class):  A set of rules, characteristics,
parameters and assumptions which, together, define the treatment accorded to
a **type** of edge to edge BA  or cloud BA.  A BA class defines
the service (see definition of service in RFC 2475) provided by a single DS
domain  to a Link BA or Cloud BA.

Link Behavior Aggregate (Link BA):  a collection of packets with the same DS
codepoint crossing a link in a particular direction.  Referred to
as a BA in RFC 2475.

Edge-to-edge Behavior aggregate (E-E BA): a collection of packets with the
same DS codepoint [or whatever :-)] crossing a DS domain from one [or more?] DS
ingress node to one [or more?] DS egress node.

Cloud Behavior Aggregate (Cloud BA) :  the set of packets with the
same DS codepoint crossing a DS domain from [choice: (the set of
all ingress nodes to the set of all egress nodes) |  (from a set of ingress
nodes to an egress node) |  (from a set of ingress nodes to a set of egress
nodes?)]  [having at least one common link BA?]

Brian and I couldn't decide whether the cloud BA concept was useful.  I had 
trouble defining the thing;  the hangup has to do with topological scope.

The next version of the draft would start with these definitions and
define a format for specification of BA classes.  We make it clear that a BA
class is definitely edge-to-edge or within a cloud, and not an end-to-end
service, and only covers those elements of service that relate to Diffserv,
and especially not business stuff.  We also say that although E-E BAs having 
the same BA class can be concatenated across multiple DS domains to offer a 
multidomain service, that service can't  necessarily be said to be of that BA 
class (notsure I agree completely with this statement, but the draft seems 
headed in that direction).   We somehow relax the statement about measurable,
quantifiable characteristics -- for example, we could say that these may be
absolute or relative, qualitative or quantitative, objectives with
statistical bounds and generally reflect back the wording in RFC 2475 and
the limits of networks' ability to engineer for absolute bounds.   Also,
additional text (perhaps a section) is needed regarding topological
considerations on characteristics.   We probably would want to allow a
unidirectional multicast E-E BA (although how this would interact with IGMP,
multicast routing et al, I have no idea, yet).  

Dan

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/