The architecture

Previous

1.4.- The architecture

RFC 2475 deals with architecture of differentiated services. Let us start this part of the study presenting some paragraphs of this specification to continue with our discussion; you will see that reading from it our knowledge about differentiated services will be rounded:

The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single DS codepoint. Within the core of the network, packets are forwarded according to the per-hop behavior associated with the DS codepoint.

All this explanation has been treated for us along this document; nothing new we have here. Traffic entering will be classified and possibly conditioned at the boundaries of our domain and later on assigned to a behavior aggregate according to the mapping relationship between codepoints and PHBs. Within the core of the network packets will be forwarded according to the per-hop behavior associated to each codepoint.

A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and set of PHB groups implemented on each node. A DS domain has a well-defined boundary consisting of DS boundary nodes which classify and possibly condition ingress traffic to ensure that packets which transit the domain are appropriately marked to select a PHB from one of the PHB groups supported within the domain. Nodes within the DS domain select the forwarding behavior for packets based on their DS codepoint, mapping that value to one of the supported PHBs using either the recommended codepoint->PHB mapping or a locally customized mapping [DSFIELD]. Inclusion of non-DS-compliant nodes within a DS domain may result in unpredictable performance and may impede the ability to satisfy service level agreements (SLAs).

Ratification about our knowledge. Observe that they insist in having all nodes in DS-complaint mode; any non-DS-complaint node may result in unpredictable performance. Don't forget that we can protect ourself using the default DSCP ('000000' or not defined) to assign those flows to the "best-effort" behavior aggregate.

A DS domain consists of DS boundary nodes and DS interior nodes. DS boundary nodes interconnect the DS domain to other DS or non-DS-capable domains, whilst DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain.

Observe here that we can connect our domain to other DS or non DS-capable domains; latter case we have to respect our similar leaving packets without any mark. Also, as common sense tells us, interior nodes (core routers) only connect to other interior nodes or to boundary nodes (edge routers) but in the same DS domain. This way our domain is a black-box to external DS-capable or non DS-capable domains.

Interior nodes may be able to perform limited traffic conditioning functions such as DS codepoint re-marking. Interior nodes which implement more complex classification and traffic conditioning functions are analogous to DS boundary nodes.

To protect our scalable capacity it's very important to respect this rule: as soon as is possible interior nodes should perform only limited traffic conditioning; complex conditionings must be left to boundary nodes where, perhaps, lower throughputs make easier to implement them. See RFC 2386 recommendation somewhere above.

DS boundary nodes act both as a DS ingress node and as a DS egress node for different directions of traffic. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any TCA between it and the other domain to which the ingress node is connected. A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains.

DS boundary nodes act as an "ingress" node or an "egress" node depending of the direction of the traffic. In both cases conditioning must be performed to ensure that TCA between domains are respected. When those TCAs don't exist, providence must be taken to ensure that egress traffic does not create problems to other non DS-complaint domains or those DS-complaint not having a special SLA with us.

A differentiated services region (DS Region) is a set of one or more contiguous DS domains. DS regions are capable of supporting differentiated services along paths which span the domains within theregion.

The DS domains in a DS region may support different PHB groups internally and different codepoint->PHB mappings. However, to permit services which span across the domains, the peering DS domains must each establish a peering SLA which defines (either explicitly or implicitly) a TCA which specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains.

Differentiated services are extended across a DS domain boundary by establishing a SLA between an upstream network and a downstream DS domain. The SLA may specify packet classification and re-marking rules and may also specify traffic profiles and actions to traffic streams which are in- or out-of-profile (see Sec. 2.3.2). The TCA between the domains is derived (explicitly or implicitly) from this SLA.

Here we have the first definition of collaborative between differentiated service capable domains. Contiguous DS-capable domains constitute a DS Region. Observe that internally DS domains act as black boxes and their PHB groups and mapping with their codepoints are freely manage by each administrator. But when interacting with other DS-capable domains (services must spam across the domains) SLAs must be established which specifies TCAs indicating how traffic will be conditioned to cross for one domain to another and viceversa.

Also they talk about in-profile or out-of-profile traffic. When SLAs are established between domains the agreement generally include some level where traffic can be considered in-profile or out-of-profile. For example, let's suppose that we sign a SLA establishing that UDP traffic will be accepted under certain conditions up to 3.5 Mbps; above this level UDP traffic will be consider as non-friendly and treated as it (non-friendly) depending on current network condition. Then UDP traffic up to 3.5 Mbps is considered as in-profile and UDP traffic above 3.5 Mbps is considered as out-of-profile and treated according. The final treatment will be depend on current condition of each network; in extreme cases out-of-profile traffic will be totally dropped if required.

Traffic conditioning performs metering, shaping, policing and/or re-marking to ensure that the traffic entering the DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy. The extent of traffic conditioning required is dependent on the specifics of the service offering, and may range from simple codepoint re-marking to complex policing and shaping operations. The details of traffic conditioning policies which are negotiated between networks is outside the scope of this document.

Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header. We define two types of classifiers. The BA (Behavior Aggregate) Classifier classifies packets based on the DS codepoint only. The MF (Multi-Field) classifier selects packets based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other information such as incoming interface.

Nothing new here. Just ratification of what we talked somewhere above. It's very important to note that MF classifiers (where more resources are required but perhaps less throughputs have to be managed) are normally implemented at boundary nodes (edge routers) and BA classifiers (where less resources are required but perhaps more throughputs have to be managed) are normally implemented at interior nodes (core routers). This way we keep network scalability as high as is possible.

A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. It provides rules for determining whether a particular packet is in-profile or out-of-profile. The concept of in- and out-of-profile can be extended to more than two levels, e.g., multiple levels of conformance with a profile may be defined and enforced.

Different conditioning actions may be applied to the in-profile packets and out-of-profile packets, or different accounting actions may be triggered. In-profile packets may be allowed to enter the DS domain without further conditioning; or, alternatively, their DS codepoint may be changed. The latter happens when the DS codepoint is set to a non-Default value for the first time [DSFIELD], or when the packets enter a DS domain that uses a different PHB group or codepoint->PHB mapping policy for this traffic stream. Out-of-profile packets may be queued until they are in-profile (shaped), discarded (policed), marked with a new codepoint (re-marked), or forwarded unchanged while triggering some accounting procedure. Out-of-profile packets may be mapped to one or more behavior aggregates that are "inferior" in some dimension of forwarding performance to the BA into which in-profile packets are mapped.

Here authors explain some interesting concepts: A traffic profile permits us to determine if a packet is in-profile or out-of-profile. The rule must be explicit and clear; for example, we talked above about UDP flows and we established a traffic profile that tells us that up to 3.5 Mbps the traffic is in-profile and above 3.5 Mbps the traffic is out-of-profile.

But, we can have more than two levels; for example, we can establish a new traffic profile as follows: up to 3.5 Mbps traffic is considered in-profile and it will be treated as gold class traffic; from 3.5 Mbps and up to 5.0 Mbps traffic is considered out-of-profile priority-1 and it will be treated as silver class traffic; above 5.0 Mbps traffic is considered as out-of-profile priority-2 and will be treated as bronze class traffic.

For this example (gold, silver and bronze class traffic) different conditioning actions may be applied to each type of them as is explained in the second paragraph of the specification. Conditioning actions to be applied are only limited by the network administrator creativity or necessity. These actions, depending on flow class, include but are not limited to: packets may be allowed to enter without further condition; they may be allowed to enter after some accounting procedure; the DS codepoint could be set (if not previously set), i.e., marking; also it could be changed (if previously set) , i.e., re-marking; out-of-profile packets may be shaped to put them in-profile; or they may be dropped; or re-marked to assign them to a low priority and/or quality behavior aggregate; etc. Possibilities are endless and a very powerful architecture is emerging to handle different environments and/or requeriments.

A traffic conditioner may contain the following elements: meter, marker, shaper, and dropper. A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner. A meter is used (where appropriate) to measure the traffic stream against a traffic profile. The state of the meter with respect to a particular packet (e.g., whether it is in- or out-of-profile) may be used to affect a marking, dropping, or shaping action.

When packets exit the traffic conditioner of a DS boundary node the DS codepoint of each packet must be set to an appropriate value.

Fig. 1.4.1 shows the block diagram of a classifier and traffic conditioner. Note that a traffic conditioner may not necessarily contain all four elements. For example, in the case where no traffic profile is in effect, packets may only pass through a classifier and a marker.

These paragraphs of the specification clears what we saw before when we talked about classifiers, meters, markers, shapers and droppers. The diagram shows a typical DS traffic conditioner and its elements. Conditioners are implemented at edge routers (boundary nodes) or at core routers (interior nodes). A conditioner should have at least a classifier and a marker; in this simple case incoming packets are classified, perhaps using a multi-field (MF) based classification (for example, based in the 5-tuple: source address, source port, destination address, destination port, protocol); then marked (DS codepoint is set) according to each classification and finally allowed to enter the domain. Inside the domain the DS codepoint may be used for DS based classifiers at core router conditioners to implement some other required cascading conditioning.

More complex conditioners implement also a meter that normally takes a measure of the incoming flow throughputs previously classified by classes by the classifier (using a MF classification, for example); for every class the throughput is measured and depending on their values the packets are segregated in different levels of in-profile or out-of-profile packets. Observe then that you can have in the same class different hierarchical levels of aggregation. For each level of aggregation a different action can be taken.

Some aggregations can be simply marked and allowed to enter the domain; or packets can be marked first and then passed through the shaper/dropper for shapping or policying and then allowed to enter the domain. After metering, packets can be passed directly to the shaper/dropper where they are shaped or policied by behavior aggregate and then allowed to enter the domain without having been previously marked; then they will be marked later at core routers (normally this is not done because it spoils differentiated service philosophy). As was said before possibilities are endless and the architecture is very flexible and powerful.

Next the specification defines meters, markers, shapers and droppers; we talked a little about them before but to rounding our knowledge it's a good idea to present here how the RFC 2475 specification approaches a definition of these concepts in a way that is really excellent:

Meters

Traffic meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile specified in a TCA. A meter passes state information to other conditioning functions to trigger a particular action for each packet which is either in- or out-of-profile (to some extent).

Markers

Packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets which are steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet it is said to have "re-marked" the packet.

Shapers

Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets.

Droppers

Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is know as "policing" the stream. Note that a dropper can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets.

Overwhelming. Any additional word is unnecessary.

Next specification makes some advices about where traffic conditioners and MF classifiers have to be located; because it is a very important matter we are going to copy here these paragraphs from the specification and make some comments when required:

Location of Traffic Conditioners and MF Classifiers

Traffic conditioners are usually located within DS ingress and egress boundary nodes, but may also be located in nodes within the interior of a DS domain, or within a non-DS-capable domain.

Observe than traffic conditioners can be located in boundary and/or interior nodes of the domain (we know this already) but also within a non-DS-capable domain; last asseveration implies that we can pre-conditioning flows before entering the DS-capable-domain and this work can be done on non-DS-capable-domains. Later this is explained better.

1. Within the Source Domain

We define the source domain as the domain containing the node(s) which originate the traffic receiving a particular service. Traffic sources and intermediate nodes within a source domain may perform traffic classification and conditioning functions. The traffic originating from the source domain across a boundary may be marked by the traffic sources directly or by intermediate nodes before leaving the source domain. This is referred to as initial marking or "pre-marking".

Consider the example of a company that has the policy that its CEO's packets should have higher priority. The CEO's host may mark the DS field of all outgoing packets with a DS codepoint that indicates "higher priority". Alternatively, the first-hop router directly connected to the CEO's host may classify the traffic and mark the CEO's packets with the correct DS codepoint. Such high priority traffic may also be conditioned near the source so that there is a limit on the amount of high priority traffic forwarded from a particular source.

There are some advantages to marking packets close to the traffic source. First, a traffic source can more easily take an application's preferences into account when deciding which packets should receive better forwarding treatment. Also, classification of packets is much simpler before the traffic has been aggregated with packets from other sources, since the number of classification rules which need to be applied within a single node is reduced.

Since packet marking may be distributed across multiple nodes, the source DS domain is responsible for ensuring that the aggregated traffic towards its provider DS domain conforms to the appropriate TCA. Additional allocation mechanisms such as bandwidth brokers or RSVP may be used to dynamically allocate resources for a particular DS behavior aggregate within the provider's network [2BIT, Bernet]. The boundary node of the source domain should also monitor conformance to the TCA, and may police, shape, or re-mark packets as necessary.

They define here a source domain; this domain generates the traffic and it could be a DS-capable domain or a non-DS-capable domain. It doesn't matter. If the domain is a DS-capable domain traffic can be marked in intermediate nodes or even by the application that generate it; within a non-DS-capable domain traffic could be marked by the application itself. The CEO example shows how traffic could be conditioned by the application with advantages. As closer as is possible to the source it will be better and easier to make the conditioning. The limiting quantity of traffic justify this because less resources are required and a finer granularity can be gained. Finally it is responsability of the source domain, being DS-capable or not, to ensure that traffic leaving from it and going to a DS-capable domain conform the appropriate TCA.

2. At the Boundary of a DS Domain

Traffic streams may be classified, marked, and otherwise conditioned on either end of a boundary link (the DS egress node of the upstream domain or the DS ingress node of the downstream domain). The SLA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the appropriate TCA. However, a DS ingress node must assume that the incoming traffic may not conform to the TCA and must be prepared to enforce the TCA in accordance with local policy.

When packets are pre-marked and conditioned in the upstream domain, potentially fewer classification and traffic conditioning rules need to be supported in the downstream DS domain. In this circumstance the downstream DS domain may only need to re-mark or police the incoming behavior aggregates to enforce the TCA. However, more sophisticated services which are path- or source-dependent may require MF classification in the downstream DS domain's ingress nodes.

If a DS ingress node is connected to an upstream non-DS-capable domain, the DS ingress node must be able to perform all necessary traffic conditioning functions on the incoming traffic.

When conditioning is done at the boundary of a DS domain (at DS egress node when flows are leaving the domain or a DS ingress node when flows are entering the domain) the SLA between the domains should specify which domain has responsibility to assigning traffic streams to behavior aggregates and later conditioning those aggregates, but, a very important consideration has to be taken: no matter where the flows are coming, it is responsibility of the DS ingress node of any DS-capable domain to check (re-check) the entering flows and to be prepared to enforce the TCA in accordance with local policy. This way we protect the DS-capable domain from flows coming to it.

Also, probably, less resources are required to classifying and conditioning traffic in the downstream DS domain. Being closer to the source less aggregation has to be managed over lower throughput flows. Of course it is going to depend of the kind of services to be offered. Finally, as is expected, being the upstream domain a non-DS-capable domain all classification and conditioning must be done, when necessary, at the downstream receiving domain.

3. In non-DS-Capable Domains

Traffic sources or intermediate nodes in a non-DS-capable domain may employ traffic conditioners to pre-mark traffic before it reaches the ingress of a downstream DS domain. In this way the local policies for classification and marking may be concealed.

This paragraph talk about interaction between non-DS-capable domain and DS-capable domains. Some conditioning could be done at the upstream non-DS-capable domain before flows reach and enter the downstream DS-capable domain. Again downstream DS-capable domain has to enforce the TCA to fullfil its local policies.

4. In Interior DS Nodes

Although the basic architecture assumes that complex classification and traffic conditioning functions are located only in a network's ingress and egress boundary nodes, deployment of these functions in the interior of the network is not precluded. For example, more restrictive access policies may be enforced on a transoceanic link, requiring MF classification and traffic conditioning functionality in the upstream node on the link. This approach may have scaling limits, due to the potentially large number of classification and conditioning rules that might need to be maintained.

Normally, as we have seen through our explanations, conditioning is better done at boundary nodes where aggregation is fewer and lower throughput has to be managed. However, when required, deployment of these functions can be done in the interior nodes always having into account to preserve scaling management of the network.

Rest of the RFC 2475 specification is dedicated to the Per-Hop Behavior definition and a long explanation describing guidelines for PHB specifications. To preserve the integrity of the Differentiated Service architecture any PHB to be proposed for standarization should satisfy these guidelines. We are not going to go deeper with this theme and those of you interested in better information are encouraged to have a read to the original RFC 2475 specification. However, we will present some brief approach to the PHB definition taken directly from the specification, with some comments to clear what we are reading.

A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. "Forwarding behavior" is a general concept in this context.

Useful behavioral distinctions are mainly observed when multiple behavior aggregates compete for buffer and bandwidth resources on a node. The PHB is the means by which a node allocates resources to behavior aggregates, and it is on top of this basic hop-by-hop resource allocation mechanism that useful differentiated services may be constructed.

The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of X% of a link (over some reasonable time interval) to a behavior aggregate. This PHB can be fairly easily measured under a variety of competing traffic conditions. A slightly more complex PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity.

Okay. We have to remember that first we classify flows by classes called "Behavior Aggregate" (BA); next we select a DS codepoint to identify each BA. When a flow is entering our domain, we, using our classifier (MF or DS codepoint), classify it into one of our predefined BAs. Depending on the BA selected we mark or re-mark the DS-codepoint on each packet header. Also, probably, we can make some conditioning at this time, mainly to protect ourself from misbehaved flows and trying that everyone entering the domain respect our inner rules. Up to here everything is clear.

But, what happen within the domain with all these flows classified by BA? We need to have some mechanism to assign different treatments because as we stated before each BA will be treated differently; some will be treated as kings or queens, some very well, some not so well, some bad and some really very bad. Our domain is a discriminatory world. Well, these treatments are what Differentiated Service architecture called Per Hop Behavior (PHB). How each BA will be forwarded within our domain it's going to depend of the PHB assigned to the BA. We have here a mapping between the BAs and the PHBs. Every BA is mapped to its corresponding PHB.

How do we define or establish these PHBs or treatments? Really easy, by assigning resources of our domain to each of them. It's like the world; some are crude rich, some are really rich, some just rich, and going down, some are poor, some very poor, and finally some are crude poor. What are the resources we are going to distribute between our PHBs? Basically buffer and bandwidth resources. Authors give also two very simple examples: a PHB which guarantee a minimal bandwidth allocation of X% of the total link bandwidth and another PHB with the same policy but having the possibility of a proportional fair sharing of any excess link capacity.

PHBs may be specified in terms of their resource (e.g., buffer, bandwidth) priority relative to other PHBs, or in terms of their relative observable traffic characteristics (e.g., delay, loss). These PHBs may be used as building blocks to allocate resources and should be specified as a group (PHB group) for consistency. PHB groups will usually share a common constraint applying to each PHB within the group, such as a packet scheduling or buffer management policy.

PHBs are implemented in nodes by means of some buffer management and packet scheduling mechanisms. PHBs are defined in terms of behavior characteristics relevant to service provisioning policies, and not in terms of particular implementation mechanisms. In general, a variety of implementation mechanisms may be suitable for implementing a particular PHB group. Furthermore, it is likely that more than one

PHB group may be implemented on a node and utilized within a domain. PHB groups should be defined such that the proper resource allocation between groups can be inferred, and integrated mechanisms can be implemented which can simultaneously support two or more groups. A PHB group definition should indicate possible conflicts with previously documented PHB groups which might prevent simultaneous operation.

When specifying resource allocation we can use some relative measure between PHBs always based on the total resources available, or we can assign some absolute values. In general it's better to use relative distribution of resources, this way when those resources increment a fair sharing of them can be achieved. On the other hand some upper levels or maximum resource consuming values have to be implemented to be sure that misbehaved flows will not starve our domain behavior.

An example is useful here to clear what we are trying to say: in a boundary node we can have 3 flows that we decided to distribute in this form: A (30%); B (40%); and C (30%). These are relative values based on the total bandwidth available at the boundary node. But also we can establish some absolute limits to these flows; talking about maximum bandwidth permitted we can have: A (3 Mbps); B (1.5 Mbps); and C (2 Mbps). Let's suppose that at some time we can rely on with 4 Mbps at this node; as soon as flows A, B and C can reclaim its right, A can rely on with 1.2 Mbps, B with 1.6 Mbps, and C with 1.2 Mbps. Having all these flows enough throughput to violate their levels then A=1.2 Mbps, B=1.6 Mbps, and C=1.2 Mbps will be the throughput levels.

But, what about when one of these flows is using less of its share bandwidth permitted? This time other flows can reclaim and use this free bandwidth for them. Now upper levels established enter the game. Every flow could, as soon as bandwidth is available, have a higher share of the total bandwidth but the upper levels to be accepted will be: A (3 Mbps); B (1.5 Mbps); and C (2 Mbps).

Staying reading from the specification we have:

As described in [DSFIELD], a PHB is selected at a node by a mapping of the DS codepoint in a received packet. Standardized PHBs have a recommended codepoint. However, the total space of codepoints is larger than the space available for recommended codepoints for standardized PHBs, and [DSFIELD] leaves provisions for locally configurable mappings. A codepoint->PHB mapping table may contain both 1->1 and N->1 mappings.

All codepoints must be mapped to some PHB; in the absence of some local policy, codepoints which are not mapped to a standardized PHB in accordance with that PHB's specification should be mapped to the Default PHB.

The implementation, configuration, operation and administration of the supported PHB groups in the nodes of a DS Domain should effectively partition the resources of those nodes and the inter-node links between behavior aggregates, in accordance with the domain's service provisioning policy. Traffic conditioners can further control the usage of these resources through enforcement of TCAs and possibly through operational feedback from the nodes and traffic conditioners in the domain. Although a range of services can be deployed in the absence of complex traffic conditioning functions (e.g., using only static marking policies), functions such as policing, shaping, and dynamic re-marking enable the deployment of services providing quantitative performance metrics.

[DSFIELD] is the RFC 2474 specification which we have talked above. Refreshing knowledge a mapping exists between a BA identified by its specific DS-codepoint and once of our PHBs. PHBs are descriptions or specifications of how a specific BA will be treated throughout the domain; how much resources are going to be reserved for the BA and which are going to be the rules to be followed to manage it.

Because, probably, the total space of codepoints could be larger than the total space of standardized PHBs the mapping table could contain 1 ® 1 relations or N ® 1 relations. It's very important to have clear that PHB space should be standardized; this means, to propose a new PHB, including the DS-codepoint suggested, the proponent has to follow the specification guidelines outlined in RFC 2475 specification. The proposition has to be revised and approved before being accepted as a standard.

To avoid problems with orphaned BAs every codepoint must be mapped to some PHB, but, when your domain doesn't find a mapping between an entering DS-codepoint and the PHB availability a default PHB must be already implemented to manage these cases. Normally, the default PHB is not more than the always implemented per hop behavior known as "best-effort".

Finally, it is responsibility of the domain administration to implement, configure, operate and manage the domain such that an effectively and fair distribution of available resources can be done at boundary and internal nodes between behavior aggregates to be managed, in accordance with the domain's service provisioning policy. To reach these goals a judicious employment of available tools has to be done to implement the traffic conditioners required for the employment of services, providing quantitive performance metrics.

To step ahead with our study of Differentiated Service architecture we are going to put our eyes on the, up to now, proposed and accepted PHB that exist. These are two: "Assure Forwarding PHB Group" and "Expedited Forwarding PHB". They are specified in RFC 2597 and RFC 2598 specifications, respectively.

Previous

Content

Next