Class of Service in PBNs
With Policy Based Networking (PBN) on the way, an interesting question arises as to just what networking equipment will do as they attempt to provide the resources that are authorized in a particular policy. To understand how this will work, it's first necessary to understand the concept of queues.
Queues reside inside networking equipment. It's their job to temporarily hold packets that are passing through them. In addition, queues provide a means of defining priority. A packet stored on a high-priority queue, for example, will leave a piece of equipment sooner than one stored on a lower priority queue. Queues are seen in action every time we visit an airport ticket counter. People in the first class queue will always head off for their departure gate faster than those who are stuck in the coach class queue.
Queues, therefore, a resource that can be manipulated by networking equipment to meet the service level requirements specified in the policy for a user or application. For example, RealPlayer, would get high priority queue treatment -- First Class ticket service -- on a certain day and at a certain time because a company's policy for it indicates that the CEO plans to delivery the quarterly financial results. On a normal day, however, its typical policy description -- Coach Class ticket service -- would mandate that networking equipment give it lower priority queue service to avoid its abuse as an entertainment channel.
In short, queues are the mechanism by which a class-of- service (CoS) traffic prioritization process can be implemented. By assigning traffic to prioritized queues inside networking equipment, policy-defined critical applications or users can get better quality service, such as lower latency than lower-tier applications or users.
This leads to another important question: How does a piece of networking equipment determine a packet's CoS-- as defined in the policy -- and know the queue to which the packet should be assigned? At this point, we're on familiar ground because most of us know the Class of Service indicator is carried within the packet itself. In short, as the packet travels across the network, it carries with it the CoS information that determines the priority of queue service it will receive.
This leaves one last unanswered question: Who puts the Class of Service indicator in the packets? There are two likely candidates for this role: the desktop/server NIC or the L3 Switch.
In the case of the NIC, packets emanating from a desktop or server leave already typed with their CoS categorization and proceed across the network, confident that the networking equipment in their path will give them their authorized queue priority service.
In the case of the L3 switch, things work a bit differently. In this instance, packets leave the desktop or server environment untyped, that is, without their policy determined CoS classification. But on their first encounter with an L3 switch, the packets get typed with a CoS category by a packet-classification process running in the switch. From this point, things are exactly the same as in the case of packets that are CoS typed by the NIC.
This last step -- typing the packets with CoS classification -- completes the circle with regard to describing what networking equipment will do to provide the resources that are mandated by the service level specification defined in the policy. The policy-management infrastructure distributes the time of day and the day of the week CoS information to the desktop, servers or L3 switches. They, in turn, type the packets with the policy- defined CoS information. At each L3 switch or router along the path, a packet is given a queue priority that ensures its original, authorized, policy-defined Class of Service is met. --Sam Alunni is vice president of networking at Sterling Research (Sterling, Mass.). Contact him at [email protected].