Previous

Content  

Next

1.1.- Introduction  

The diffserv architecture is based on a network model implemented over a complete Autonomous System (AS) or domain. Being this domain under our administrative control, we can take provisions to establish clear and consistent rules to manage traffic entering and flowing through the networks that conform the domain. If we are an ISP, our domain is used as a transit space for traffic to our customers and users, or inclusive to other ISP domains.
To do what we want, an architecture is implemented, where traffic entering the network at the edges of the domain is classified and assigned to different behavior aggregates. Each aggregate is identified by previously marking header of packets belonging to each behavior, when they enter the domain.
 
Inside the domain, packets belonging to the same behavior aggregate are forwarded according to previous established rules; this way, what we are really doing is creating classes of flows that travel through our networks. Each flow is treated along the domain according to the class to which it belongs. Using this class discrimination, we can have flows class A, B, C, D, etc., where each class receives a different treatment that, previously, we have established what is going to be.
 
Our domain becomes in some kind of discriminatory world, where depending of the class to which each flow belongs it will be treated different, perhaps as a king or queen, perhaps very well, perhaps not so well, or perhaps (for flows we don't want) really bad or very bad.
 
Let us see something graphic to represent what we are talking about; I'm going to ask you for some effort to imagine what I'm trying to draw, because I'm a very bad artist:
 

 
 

The cloud is representing our domain; arrows entering to it are different flows that we are receiving from outside. Flows are of different colors indicating that not all of them are of the same importance or interest for us. Some of them are from customers that pay for class A service, other from customers engage in standard services at lower costs; some flows are from mission critical services that require a special no loss and fast response dispatching; some are from services less critical that can accept some delay and perhaps losses without generating problems to the application they are trying to serve; some are from general but acceptable traffic that we can treat using the best-effort policy; and some are from unidentified places, but we don't want them because they are malicious Trojans, viruses and Spam e-mails that consume our network bandwidth and cause a lot of problems to our users, customers and technical people.
What we are going to do now is zooming one of those places at some edge of our domain where flows are entering to study better the situation on it; again a diagram:

In this example, we have nine flows entering our domain at some edge of it; let us suppose that after a conscientious study of the situation we have decided that these flows can be classified using 3 different classes: the blue class is going to content 3 of the flows, the red class is going to content 4 of the flows and the green class is going to content 2 of the flows. To have some coherence with previous explanations let us suppose that green class is an A or Gold class, blue class is a B or Silver class, and red class is a C or Bronze class. For now it does not matter what gold, silver or bronze class means, just that they are different and have different requirements to be met.
When we classify these 9 flows into 3 classes, and after thinking that they could be 20, 30 or several hundred of them, classified again into 3 classes (or 4, 5 or 10 of them), we are understanding and using one of the basic and more important characteristic of differentiated service: it operates on behavior aggregates. What does it means? That we can have many flows but we classify previously by their behavior, aggregating them in several classes that always are going to be less than the original flows.
What do we get with this? We reduce the flow state information to be required to maintain on each router; instead of having state information for every flow, we reduce dramatically the amount of resources required by managing every class of flow, instead of every flow. As RFC 2386 "A Framework for QoS-based Routing in the Internet" points out: "An important issue in interdomain routing is the amount of flow state to be processed by transit ASs. Reducing the flow state by aggregation techniques must therefore be seriously considered. Flow aggregation means that transit traffic through an AS is classified into a few aggregated stream rather than been routed at the individual flow level". 
 
Okay, but we have to prepare our domain to do that. It has to classify flows entering on it in some manageable number of classes, or behavior aggregates, and afterward, it has to have clear rules for each of these classes to be treated or managed (routed, shaped, policed, dropped, delayed, marked, remarked, forwarded, etc.), when they cross through the domain.
 
What we are talking about for flows entering our domain must be valid too for flows leaving from it. Let us suppose that, as we are an ISP, we can consider ourselves as a black box that do not generate flows directly, but instead, we transport them for our users, customers and other domains. As soon as we are implementing alone this new differentiated service technology, we have to take providence to not damage or confuse other people with packets marked by us. This means that because we are going to mark packets entering our domain to apply our idea of having differentiated service on it, we have also to respect our similar leaving packets going out our domain without any mark; we have to clean it out what we put on packets to do our fantastic experiments; and we are going to do that, beyond a shadow of a doubt.
 
If we are successful with our ideas and we do implement differentiated service in our domain we can try later to reach some deal with our customers to offer these special services by what is called a SLA (Service Level Agreement). SLA will define forwarding services that our customers will receive. Also, we can sign with them what is called a TCA (Traffic Conditioning Agreement) which usually specifies traffic profiles and action to be taken to treat in-profile and out-of-profile packets.
 
And being more prolific, what about if we have some ISP neighbor as inventive as we are and we can extend our concept of differentiated service beyond our domain frontiers? Then, we could sign those SLA and TCA contracts with our peers and forward to them, and receive from them, marked packets that will be treated in both domains following specifics and previously agreed rules.
 
All these ideas that I have outlined have been taken from what the differentiated service architecture is promising the new Internet world is going to be. But, landing again to the real world, let us continue studying how we are going to implement differentiated service. Next step will be to explain in more detail the architecture.
 

   

Previous

Content  

Next