Differentiated Services and Tunnels
RFC 2983
Network Working Group D. Black
Request for Comments: 2983 EMC Corporation
Category: Informational October 2000
Differentiated Services and Tunnels
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document considers the interaction of Differentiated Services
(diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms.
The discussion of tunnels in the diffserv architecture (RFC 2475)
provides insufficient guidance to tunnel designers and implementers.
This document describes two conceptual models for the interaction of
diffserv with Internet Protocol (IP) tunnels and employs them to
explore the resulting configurations and combinations of
functionality. An important consideration is how and where it is
appropriate to perform diffserv traffic conditioning in the presence
of tunnel encapsulation and decapsulation. A few simple mechanisms
are also proposed that limit the complexity that tunnels would
otherwise add to the diffserv traffic conditioning model. Security
considerations for IPSec tunnels limit the possible functionality in
some circumstances.
1. Conventions used in this document
An IP tunnel encapsulates IP traffic in another IP header as it
passes through the tunnel; the presence of these two IP headers is a
defining characteristic of IP tunnels, although there may be
additional headers inserted between the two IP headers. The inner IP
header is that of the original traffic; an outer IP header is
attached and detached at tunnel endpoints. In general, intermediate
network nodes between tunnel endpoints operate solely on the outer IP
header, and hence diffserv-capable intermediate nodes access and
modify only the DSCP field in the outer IP header. The terms
"tunnel" and "IP tunnel" are used interchangeably in this document.
For simplicity, this document does not consider tunnels other than IP
tunnels (i.e., for which there is no encapsulating IP header), such
Black Informational [Page 1]
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
Show full document text