|
Previous
|
Content |
Next
|
|
|
|
| RFC 2474 define the field to be used on packets to print our mark; this mark will be used afterward to identify to which group the packet marked belongs to. Our discussion will be concentrated in IPV4 packets. Reading from RFC 2474 we have: |
| Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of: |
- setting bits in an IP header field at network boundaries
(autonomous system boundaries, internal administrative boundaries,
or hosts),
- using those bits to determine how packets are forwarded by the
nodes inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.
|
| |
| Well. We touch briefly about this in our initial explanation. They indicate that "the enhancement to the Internet protocol covered by this specification are intended to enable scalable service discrimination without the need of per-flow state and signaling at every hop". We explained above that because our intention was to classify flows to aggregate them in groups before deciding how to forward them, we don't need to control states at routers on a per-flow based granularity but instead using aggregate of flows. This way our architecture will be easily scalable because using a few several aggregate groups we can manage the forwarding of many more individual flows. |
| |
| Also the signaling, this means, classifying and marking, is done at the border routers only (edges of the domain) not requiring to signal at every hop of the domain. This explanation is really very important to the success of any new architecture, because service are scalable, this means, amount of resources required to implement and manage the model are not proportional to the number of flows to be forwarded but instead to some previously defined few "behavior aggregate". |
| |
| After explaining briefly what kind of service could be implemented using the new architecture the specification gives us also some explanation of how they are intending to do that, this means: 1.- setting bits in the IP packets header field at network boundaries. 2.- using those bits to determine how packets are forwarded by the nodes inside the network, and 3.- conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. |
| |
| We talked a little about points 1 and 2, this means, marking the packet when entering the domain by setting some bits in a field (not yet defined) in the IP header and using this mark to decide how to forward the packets inside the domain. But third intention is a new one. We can also conditioning the marked packets at network boundaries in accordance to some requirements or rules to be defined later. We can condition the packets when they are entering the domain (ingress) or when they are leaving it (egress). |
|
|
|
|
| But, what conditioning means? It means preparing the packets to fulfill some rules, perhaps marking them using some previous multi-field (MF) classification (by source and/or destination address, by source and/or destination ports, by protocol, etc.), perhaps shaping or policing them before entering or leaving the domain or perhaps remarking them if they are previously marked. For example, we talked that if our neighbors were not as inventive as we are, we have to clear any mark on packets we made before they leave our domain. This is an example of conditioning packets following a previous requirement or rule (we can't bother our similar with our inventions). |
| |
| Reading again from the specification we have: |
|
| A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity. |
| Well, they are talking about a new term called DS field that we have not defined yet. If we read the RFC specification, for all of us that are not versed in network terminology we find frequently some holes. Before continuing let us to attempt a brief explanation or definition about some terms commonly used when talking about differentiated service. Let's start identifying the DS field. The DS (for
Differentiated Service) field is where we are going to mark our packets. This field is on the IP packet header. A figure can help us to understand this: |
|
|
| Here we have a diagram of the IP header. People who created the differentiated service architecture decided to use the second octet of the header identified in the figure as "8 bit type of service (TOS)" to implement the model, renaming the field as "DS field". In fact this octet had been traditionally used as a medium to signaling type of service to be lent to the packet. They merely redefine the utilization of the field to be incorporated to the new architecture. |
| They also talk about something called a classifier, basically to say that based on content of the DS field the classifier selects packets and applies to each different group of packet aggregation, identify by a distinct DS field, a differentiated treatment in terms of buffer management and packet scheduling. The term classifier, along with some other like dropper, marker, meter, shaper, policer and scheduler are defined in RFC 2475 but because they are needed to understand better what we are studying, let us to jump to it and then come back again. As it was written before problem when you try to follow specifications is that you find some holes than are covered later. Let us try to order things a little to make easier to understand concepts. |
| Reading on RFC 2475 we have: |
| Microflow: a single instance of an application-to-application flow of packets which is identified by source address, source port, destination address, destination port and protocol id. |
| Here we have a traditional definition of a flow between two applications. Any flow is identified by the 5-tuple (src addr, src port, dest addr, dest port, protocol). These 5 pieces of information are located in the IP/TCP/UDP header. Continuing with RFC 2475 we have now: |
| Classifier: an entity which selects packets based on the content of packet headers according to defined rules. |
| MF Classifier: a multi-field (MF) classifier which selects packets based on the content of some arbitrary number of header fields; typically some combination of source address, destination address, DS field, protocol ID, source port and destination port. |
| Basically the classifier is a mechanism that looks at the IP header to get some information that permit to classify the packet in some group. Classifier could use the DS field where we are going to put our mark to select packets. Or it can use a more complex selection using other fields like the source and/or destination address, source and/or destination port, and/or protocol identification. |
| Let us suppose that we want to separate in our domain flows that are TCP from those that are UDP. We know that we have to be very pending about UDP flows. Those flows are unresponsive
(see foot note), this means, when congestion appears they do not adjust automatically its throughput to alleviate the link as TCP does. Because of this they can starve other flows and worse congestion behavior. To approach this problem we decided to implement a classifier on edge routers in our domain that select packets entering to it to classify them into two groups: TCP packets and UDP packets. In this case the classifier looks into the packet header protocol identification to select and classify them before entering our domain. |
| More complex selection and classification can be done. We can select, for example, packets coming from a specific external network or going to a specific internal network or perhaps those that are servicing a special service like ssh, ftp or telnet. The classifier is the mechanism that is in charge to select and classify the packets. When using different fields from the IP/TCP/UDP header to make the classification they are called multi-field (MF) classifiers. |
| But also classifiers can use only the DS field to classify packets. Let us suppose that we mark the UDP flows entering our domain with a specific mark on the DS field (later we are going to see how to mark packets using the DS field). After being marked we let packets enter our domain. At the same time we prepare routers inside the domain (they are called core routers to distinguish them from edge routers located at the domain frontiers) to forward these packets in some way. Then core routers will need to classify packets using the DS field instead of other fields in the IP packet header. |
| What we are talking is state-of-the-art of networking. Do not forget that as RFC 2386 -
"A Framework for QoS-based Routing in the Internet" states:
limiting flow specific information is very important in any routing model to achieve
scalation. This is true for any network model. When limiting per-flow multi-field classification just at edge routers we are walking on this direction; think that except for high speed trunks between domains (where some other model has to be implemented) rest of links are from customers where maximum bandwidth is limited, permiting to control per-flow state classification more easily. |
| From RFC 2475 again: |
| Marking: the process of setting the DS codepoint in a packet based on defined rules; pre-marking, re-marking. |
| Marker: a device that performs marking. |
| Pre-mark: to set the DS codepoint of a packet prior to entry into a downstream DS domain. |
| Re-mark: to change the DS codepoint of a packet, usually performed by a marker in accordance with a TCA. |
| Marking and Marker are self-explanatory. But the specification uses now the expression "DS codepoint" instead of "DS field". What happens is that differentiated service uses only the 6 leftmost bits, from the eight of the DS field, to mark the packets. Bits 0 to 5 are used and bits 6 and 7 are respected. The 6 leftmost bits of the DS field form the DS codepoint. It's very important to not confuse DS field and DS codepoint, also called DSCP. Next figure taken from RFC 2474 clears what we are talking about: |
| The DS field structure is presented below: |
|
|
| |
| In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1') used in this document, the left-most bit signifies bit 0 of the DS field (as shown above), and the right-most bit signifies bit 5. |
| |
| As you can see bits 6 and 7 are unused by differentiated service but used by other technologies to indicate ECN (Explicit Congestion Notification); anyway this theme is out of the scope of this document. |
| |
| Above, when talking about marking, they wrote pre-marking or re-marking. When different domains implementing differentiated service interact to exchange DS packets, they can reach the edge of any domain previously marked in another domain. The packets are pre-marked. If not previously marked by another domain, they could be pre-marked by an edge router of our domain before entering it; these packets are pre-marked too. |
| |
| Also it could be that when those packets reach our domain previously marked in another domain we re-mark them before entering our. The packets are then re-marked. Finally, packets could be re-marked before leaving our domain. For example, if we are implementing differentiated services alone in our domain we have to leave packets not marked before departing from it. Or perhaps, having some agreement with another domain we have to mark or re-mark packets leaving from our domain and going to the former. |
| |
| Reading again from RFC 2475: |
| |
| Metering: the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes. |
| |
| Meter: a device that performs metering. |
|
|
|
|
| Here metering is defined. Normally this process
is implemented, but not limited, at edge routers of domains. The idea is as
follows. We can have some agreement with another domain to accept flows
coming from it subject to some predefined rules or we simply define our own
rules to define the characteristics of flows we are accorded to accept.
Rules are related mainly to flow maximum throughput. Well, to be sure that
these rules are fulfilled and maximum rates are not exceeded we have to
measure those flows before entering our domain. This process called metering
is done by devices called meters. Later we are going to see how these
devices are implemented in the router. |
| Also, depending of the instantaneous state of this process of measuring we have to take some decision of what to do with flows violating our rules. For example, let us suppose that because we want to protect our networks from misbehave flows, one of our rules is that udp flows coming from network 211.32.120/24 must not exceed 1.5 Mbps of throughput when entering our domain. As soon as this rate is not exceeded there is no problem; we simply admit the flows. But when our meters tell us that the throughput is exceeded we have to take some advance to make sure our rules are respected. Metering and meters tell us about flows behavior. To take actions we can implement marking, dropping, policing or shaping. Let us continue reading from RFC 2475 for these definitions. |
| Dropping: the process of discarding packets based on specified rules; policing. |
| Dropper: a device that performs dropping. |
| Policing: the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile. |
| First approach to deal with flows not respecting our rules is to drop them. Dropping is the process of discarding those packets. For example, we can accept all packets up to the maximum rate allowed and discard (drop) all of them exceeding it. Dropper are the devices that perform dropping. Policing comprends the all process of metering and dropping, when trying to enforce our traffic profile. |
| Another approach could be not to drop packets but instead to shape them as much as is possible to cause them to conform our rules. But let us take the definition directly from RFC 2475: |
| Shaping: the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile. |
| Shaper: a device that performs shaping. |
| Definitions are self explanatories. As soon as we have enough buffering capacity we can delay packets to conform the profile previously defined. |
| Combinations of these approaches (metering, marking, dropping and shaping) can be used freely by network administrators to enforce traffic profile entering and leaving administered domains. For example, a hierarchical approach could be to accept and mark with some DSCP, packets up to a predefined rate; then mark with another DSCP, packets from previous rate and up to another higher predefined rate, and finally to drop all packets over this last rate. Inside the domain packets marked with the first DSCP could have a special and fast forwarding treatment with no drop; and packets marked with the second DSCP a restringed treatment where they are dropped following some aleatory selection of them. |
| Let us return back again to the RFC 2474: |
| This document concentrates on the forwarding path component. In the packet forwarding path, differentiated services are realized by mapping the codepoint contained in a field in the IP packet header to a particular forwarding treatment, or per-hop behavior (PHB), at each network node along its path. The codepoints may be chosen from a set of mandatory values defined later in this document, from a set of recommended values to be defined in future documents, or may have purely local meaning. PHBs are expected to be implemented by employing a range of queue service and/or queue management disciplines on a network node's output interface queue: for example weighted round-robin (WRR) queue servicing or drop-preference queue management. |
|
In this paragraph the authors define the term PHB or per-hop behavior. Basically a per-hop behavior (PHB) is a particular forwarding treatment that a group of packets marked with a specific codepoint (DSCP) will going to receive at each network node along its path. It's very important to note that a mapping must be established between the DSCPs and the different PHBs to be defined. Also codepoint (DSCP) are going to be chosen from a set of mandatory to be defined in the own document; PHBs will be implemented using different resources to be offered by routers at network nodes. Those resources are basically queuing management disciplines and we
will see later on how they are implemented. If we continue reading we have: |
| Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. The terms "aggregate" and "behavior aggregate" are used interchangeably in this document. |
| This definition reinforce definitions given above. "Behavior Aggregate" or simply "Aggregate" (or BA) is a collection of packets having the same DSCP. It's very important to say that any "Aggregate" will be, by mapping, assigned to a PHB, but be adviced that more than one BA can be assigned to the same PHB. DHCP-PHB mapping can be a N:1 relationship. |
| Traffic Conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These MAY include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between domains and to condition traffic to receive a differentiated service within a domain by marking packets with the appropriate codepoint in the DS field and by monitoring and altering the temporal characteristics of the aggregate where necessary. |
| Traffic Conditioner: an entity that performs traffic conditioning functions and which MAY contain meters, policers, shapers, and markers. Traffic conditioners are typically deployed in DS boundary nodes (i.e., not in interior nodes of a DS domain). |
| These definitions taken from RFC 2474 round our ideas about differentiated services. Conditioning is a compound process based on metering, policing, shapping and packet marking to be applied to a behavior aggregate. Using traffic conditioning we enforce any previous agreement made between differentiated service domains or our own rules used to differentiate quality of service to be given to different aggregates. Again from RFC 2474: |
| To summarize, classifiers and traffic conditioners are used to select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used to determine which forwarding treatment the packet receives. A behavior aggregate classifier which can select a PHB, for example a differential output queue servicing discipline, based on the codepoint in the DS field SHOULD be included in all network nodes in a DS domain. The classifiers and traffic conditioners at DS boundaries are configured in accordance with some service specification, a matter of administrative policy outside the scope of this document. |
| A new restriction is given in this paragraph; if you define a behavior aggregate identify by a specific DSCP and you map it to a determined PHB, this PHB should be included in all network nodes of the DS domain. Something that common sense indicates. Any packet belonging to a behavior aggregate mapped to a PHB has to encounter at any node its PHB implemented to obtain adecuate forwarding. |
| Let us now to talk a little more about the DS codepoint to complete this theme. Reading from RFC 2474 we have: |
| Implementors should note that the DSCP field is six bits wide. DS-compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. |
| Have a look to the DS field figure somewhere above. First of all, mapping between DSCPs and PHBs must be done against the entire 6-bit DSCP field; this means that partial or individual bits matching is not allowed. DSCP must be consider an atomic value which we can use to enter in a table as an index to get the corresponding per-hop behavior. Also last 2-bits (CU field) must be ignored for PHB selections. |
| A "default" PHB MUST be available in a DS-compliant node. This is the common, best-effort forwarding behavior available in existing routers as standardized in [RFC1812]. When no other agreements are in place, it is assumed that packets belong to this aggregate. Such packets MAY be sent into a network without adhering to any particular rules and the network will deliver as many of these packets as possible and as soon as possible, subject to other resource policy constraints. A reasonable implementation of this PHB would be a queueing discipline that sends packets of this aggregate whenever the output link is not required to satisfy another PHB. A reasonable policy for constructing services would ensure that the aggregate was not "starved". This could be enforced by a mechanism in each node that reserves some minimal resources (e.g, buffers, bandwidth) for Default behavior aggregates. This permits senders that are not differentiated services-aware to continue to use the network in the same manner as today. The impact of the introduction of differentiated services into a domain on the service expectations of its customers and peers is a complex matter involving policy decisions by the domain and is outside the scope of this document. |
| The RECOMMENDED codepoint for the Default PHB is the bit pattern '000000'; the value '000000' MUST map to a PHB that meets these specifications. The codepoint chosen for Default behavior is compatible with existing practice [RFC791]. Where a codepoint is not mapped to a standardized or local use PHB, it SHOULD be mapped to theDefault PHB |
| A default PHB is defined in these paragraphs and it
is associated to the actual "best-effort" behavior. Some common sense tells us that the ultimate service we can provide is at least the actual "best-effort" service; assuming that any other PHB was not established we have to implement our architecture in some way to treat common flows (those not specialy marked) in a previously determined PHB. This PHB does not have any special treatment except that some providence has to be taken to assure that in presence of other priority flows, they can not be starved, to allow the normal flow of them. Normally these providences are taken by controlling maximum bandwidth allowed to priority flows so that resources are left available for "best-effort" flows. |
| |
| Also it's natural to select the codepoint '000000' to be mapped to this "best-effort" PHB. This way we respect other RFCs and common practices. Remember that somewhere above we talked about the necessity to leave our domain departing packets being not marked when not having a special aggreement with other domains. Re-marking those packets with a codepoint '000000' guarantee we are respecting our similars. Observe also that packets not having any predefined codepoint in our implementation have to be associated to this "best-effort" PHB. This way we guarantee to ourself that all flows will be forwarded at least on a "best-effort" policy. If we forgot to assign some flows to a special codepoint they will be treated by our implementation as "best-effort" flows. |
| |
| Let us see now how RFC 2474 authors approach the class definition in DS architecture. Continue reading we have: |
| |
| A specification of the packet forwarding treatments selected by the DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU subfield unspecified, are reserved as a set of Class Selector Codepoints. PHBs which are mapped to by these codepoints MUST satisfy the Class Selector PHB requirements in addition to preserving the Default PHB requirement on codepoint '000000' (Sec. 4.1). |
| |
| To begin defining how DSCP will be used authors define a class selector codepoint. Using the first 3 bits of the DSCP they establish that they are going to be used to identify a class. Every class has its codepoint defined in some way that satisfy the pattern 'xxx000|xx', when talking about the DS field (all 8 bits being considered) or 'xxx000', when talking about DSCP (6 leftmost bits being considered). What all this means? Basically that we can define classes of flow and use a pattern like 'xxx000' to identify them. |
|
|
|
|
| For example, we could invent a new class named "My best friend class" and select a codepoint for it respecting the specification. Something like 101000, or 111000, or 001000, or 110000, etc. Last 3 DSCP bits will be always zero. With this restriction we can have a maximum of 8 classes using the different combination permitted for the three leftmost bits. |
|
Unresponsive flow: When an end-system responds to indications of congestion by reducing the load it generates to try to match the available capacity of the network it is referred to as a responsive. M.A. Parris [12]. |
|
|
|
|
|
Previous
|
Content |
Next
|
