Assured Forwarding PHB group is a means for a provider DS domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain.There are four AF classes are defined , where each AF class is in each DS node allocated a certain amount of resources. The IP packets that are under this PHB are assigned by the customer or the provider DS domain into one or more of these AF classes according to the services that the customer has subscribed to.
Again, these packets are marked again in each AF class. Marking is based on one of three possible drop precedence values. These come into the picture when congestion occurs. In case of congestion a congested DS node tries to protect those packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value.
Currently, four classes with three levels of drop precedence in each class are defined. Packet forwarding of packets from one AF class should be done independently of packets in another class. With regards to traffic conditioning actions, the packets are controlled at the domain edge which is carried out by the DS domain. This is done at various levels of drop precedence. This may include packet dropping, shaping, changing the drop precedence of packets etc.
An AF implementation must detect and respond to long-term congestion in terms of minimizing it for each class as well as detecting and responding to it also. RED i.e. Random Early Drop is one such method. This method keeps a check on the buffer in which a certain threshold value is given. If the queue size increases beyond the threshold value then the RED algorithm discards the incoming packets with a probability p. Also care should be taken with the congestion indication feedback to the end nodes so that the level of packet discard at each drop precedence in relation to congestion should not be abrupt but gradual to allow the overall system to reach a stable operating point.
Recommended code points
for the four general AF classes are given below.Care has been taken that
these do not overlap with any other general use PHB groups.
|Class 1||Class 2||Class 3||Class 4|
|Low Drop Precedence||001010||010010||011010||100010|
|Medium Drop Prec.||001100||010100||011100||100100|
|High Drop Precedence||001110||010110||011110||100110|
The mapping of codepoints to PHBs must be configurable. A DS-compliant node must support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications must include a recommended default codepoint, which MUST be unique for codepoints in the standard space. Implementations should support the recommended codepoint-to-PHB mappings in their default configuration.
Packets received with an unrecognized codepoint should be forwarded as if they were marked for the Default behavior , and their codepoints should not be changed. Such packets must not cause the network node to malfunction.
The structure of the
DS field shown above is incompatible with the existing definition of the
IPv4 TOS octet in [RFC791]. The
presumption is that DS domains protect themselves by deploying re-marking boundary nodes, as should networks using the RFC 791.
Precedence designations: Correct operational procedure should follow [RFC791], which states:
The Default PHB must be available in a DS compliant node. This PHB exhibits a best-effort forwarding behaviour available in the present day routers. Packets with this PHB with adhering to any particular policy and will be delivered as a best-effort service. Also care should be taken that these packets should not be led to starvation.The recommended codepoint for the Default PHB is the bit pattern 000000 [RFC2474]. This value must map to a PHB that meets these specifications.
Note:- There is a certain
backward compatibility with respect to the IP Precedence Field: i.e. bits
0-2 of the IPv4 ToS header. The reason being that there are routers that
use the IP Precedence field to select different PHBs.