Differentiated Services and Tunnels
RFC 2983

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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