RFC 2983 (rfc2983) - Page 2 of 14

Differentiated Services and Tunnels

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