RFC 2836 (rfc2836) - Page 2 of 7
Per Hop Behavior Identification Codes
Alternative Format: Original Text Document
RFC 2836 Per Hop Behavior Identification Codes May 2000
In some cases it is necessary or desirable to identify a particular
PHB in a protocol message, such as a message negotiating bandwidth
management or path selection, especially when such messages pass
between management domains. Examples where work is in progress
include communication between bandwidth brokers, and MPLS support of
diffserv.
In certain cases, what needs to be identified is not an individual
PHB, but a set of PHBs. One example is a set of PHBs that must follow
the same physical path to prevent re-ordering. An instance of this
is the set of three PHBs belonging to a single Assured Forwarding
class, such as the PHBs AF11, AF12 and AF13 [RFC 2597].
This document defines a binary encoding to uniquely identify PHBs
and/or sets of PHBs in protocol messages. This encoding MUST be used
when such identification is required.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
1.1. Usage Scenarios
Diffserv services are expected to be supported over various
underlying technologies which we broadly refer to as "link layers"
for the purpose of this discussion. For the transport of IP packets,
some of these link layers make use of connections or logical
connections where the forwarding behavior supported by each link
layer device is a property of the connection. In particular, within
the link layer domain, each link layer node will schedule traffic
depending on which connection the traffic is transported in. Examples
of such "link layers" include ATM and MPLS.
For efficient support of diffserv over these link layers, one model
is for different Behavior Aggregates (BAs) (or sets of Behavior
Aggregates) to be transported over different connections so that they
are granted different (and appropriate) forwarding behaviors inside
the link layer cloud. When those connections are dynamically
established for the transport of diffserv traffic, it is very useful
to communicate at connection establishment time what forwarding
behavior(s) is(are) to be granted to each connection by the link
layer device so that the BAs transported experience consistent
forwarding behavior inside the link layer cloud. This can be achieved
by including in the connection establishment signaling messages the
encoding of the corresponding PHB, or set of PHBs, as defined in this
document. Details on proposed usage of PHB encodings by some MPLS
label distribution protocols (RSVP and LDP) for support of Diff-Serv
over MPLS, can be found in [MPLS-DS].
Brim, et al. Standards Track