2.4.2.b Assured Forwarding PHB

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
RFC 2474 puts forth an important delineation regarding the DS field. In a DSCP value notation xxxxxx (where x may equal 0 or 1) the left-most bit signifies bit 0 of the field (as shown above), and the right-most bit signifies bit 5. DS-compliant nodes must select PHBs by matching against the entire 6-bit DSCP field, 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 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:

Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value.  DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service.

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.