RFC 2983 (rfc2983) - Page 2 of 14
Differentiated Services and Tunnels
Alternative Format: Original Text Document
RFC 2983 Diffserv and Tunnels October 2000
as MPLS paths and "tunnels" formed by encapsulation in layer 2 (link)
headers, although the conceptual models and approach described here
may be useful in understanding the interaction of diffserv with such
tunnels.
This analysis considers tunnels to be unidirectional; bi-directional
tunnels are considered to be composed of two unidirectional tunnels
carrying traffic in opposite directions between the same tunnel
endpoints. A tunnel consists of an ingress where traffic enters the
tunnel and is encapsulated by the addition of the outer IP header, an
egress where traffic exits the tunnel and is decapsulated by the
removal of the outer IP header, and intermediate nodes through which
tunneled traffic passes between the ingress and egress. This
document does not make any assumptions about routing and forwarding
of tunnel traffic, and in particular assumes neither the presence nor
the absence of route pinning in any form.
2. Diffserv and Tunnels Overview
Tunnels range in complexity from simple IP-in-IP tunnels [RFC 2003]
to more complex multi-protocol tunnels, such as IP in PPP in L2TP in
IPSec transport mode [RFC 1661, RFC 2401, RFC 2661]. The most
general tunnel configuration is one in which the tunnel is not end-
to-end, i.e., the ingress and egress nodes are not the source and
destination nodes for traffic carried by the tunnel; such a tunnel
may carry traffic with multiple sources and destinations. If the
ingress node is the end-to-end source of all traffic in the tunnel,
the result is a simplified configuration to which much of the
analysis and guidance in this document are applicable, and likewise
if the egress node is the end-to-end destination.
A primary concern for differentiated services is the use of the
Differentiated Services Code Point (DSCP) in the IP header [RFC 2474,
RFC 2475]. The diffserv architecture permits intermediate nodes to
examine and change the value of the DSCP, which may result in the
DSCP value in the outer IP header being modified between tunnel
ingress and egress. When a tunnel is not end-to-end, there are
circumstances in which it may be desirable to propagate the DSCP
and/or some of the information that it contains to the outer IP
header on ingress and/or back to inner IP header on egress. The
current situation facing tunnel implementers is that [RFC 2475]
offers incomplete guidance. Guideline G.7 in Section 3 is an
example, as some PHB specifications have followed it by explicitly
specifying the PHBs that may be used in the outer IP header for
tunneled traffic. This is overly restrictive; for example, if a
specification requires that the same PHB be used in both the inner
and outer IP headers, traffic conforming to that specification cannot
be tunneled across domains or networks that do not support that PHB.
Black Informational