rfc2983.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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
   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                      [Page 2]

RFC 2983                  Diffserv and Tunnels              October 2000


   A more flexible approach that should be used instead is to describe
   the behavioral properties of a PHB that are important to preserve
   when traffic is tunneled and allow the outer IP header to be marked
   in any fashion that is sufficient to preserve those properties.

   This document proposes an approach in which traffic conditioning is
   performed in series with tunnel ingress or egress processing, rather
   than in parallel.  This approach does not create any additional paths
   that transmit information across a tunnel endpoint, as all diffserv
   information is contained in the DSCPs in the IP headers.  The IPSec
   architecture [RFC 2401] requires that this be the case to preserve
   security properties at the egress of IPSec tunnels, but this approach
   also avoids complicating diffserv traffic conditioning blocks by
   introducing out-of-band inputs.  A consequence of this approach is
   that the last sentence of Guideline G.7 in Section 3 of [RFC 2475]
   becomes moot because there are no tunnel egress diffserv components
   that have access to both the inner and outer DSCPs.

   An additional advantage of this traffic conditioning approach is that
   it places no additional restrictions on the positioning of diffserv
   domain boundaries with respect to traffic conditioning and tunnel
   encapsulation/decapsulation components.  An interesting class of
   configurations involves a diffserv domain boundary that passes
   through (i.e., divides) a network node; such a boundary can be split
   to create a DMZ-like region between the domains that contains the
   tunnel encapsulation or decapsulation processing.  Diffserv traffic
   conditioning is not appropriate for such a DMZ-like region, as
   traffic conditioning is part of the operation and management of
   diffserv domains.

3. Conceptual Models for Diffserv Tunnels

   This analysis introduces two conceptual traffic conditioning models
   for IP tunnels based on an initial discussion that assumes a fully
   diffserv-capable network.  Configurations in which this is not the
   case are taken up in Section 3.2.

3.1 Conceptual Models for Fully DS-capable Configurations

   The first conceptual model is a uniform model that views IP tunnels
   as artifacts of the end to end path from a traffic conditioning
   standpoint; tunnels may be necessary mechanisms to get traffic to its
   destination(s), but have no significant impact on traffic
   conditioning.  In this model, any packet has exactly one DS Field
   that is used for traffic conditioning at any point, namely the DS
   Field in the outermost IP header; any others are ignored.
   Implementations of this model copy the DSCP value to the outer IP
   header at encapsulation and copy the outer header's DSCP value to the



Black                        Informational                      [Page 3]

RFC 2983                  Diffserv and Tunnels              October 2000


   inner IP header at decapsulation.  Use of this model allows IP
   tunnels to be configured without regard to diffserv domain boundaries
   because diffserv traffic conditioning functionality is not impacted
   by the presence of IP tunnels.

   The second conceptual model is a pipe model that views an IP tunnel
   as hiding the nodes between its ingress and egress so that they do
   not participate fully in traffic conditioning.  In this model, a
   tunnel egress node uses traffic conditioning information conveyed
   from the tunnel ingress by the DSCP value in the inner header, and
   ignores (i.e., discards) the DSCP value in the outer header.  The
   pipe model cannot completely hide traffic conditioning within the
   tunnel, as the effects of dropping and shaping at intermediate tunnel
   nodes may be visible at the tunnel egress and beyond.

   The pipe model has traffic conditioning consequences when the ingress
   and egress nodes are in different diffserv domains.  In such a
   situation, the egress node must perform traffic conditioning to
   ensure that the traffic exiting the tunnel has DSCP values acceptable
   to the egress diffserv domain (see Section 6 of the diffserv
   architecture [RFC 2475]).  An inter-domain TCA (Traffic Conditioning
   Agreement) between the diffserv domains containing the tunnel ingress
   and egress nodes may be used to reduce or eliminate egress traffic
   conditioning.  Complete elimination of egress traffic conditioning
   requires that the diffserv domains at ingress and egress have
   compatible service provisioning policies for the tunneled traffic and
   support all of the PHB groups and DSCP values used for that traffic
   in a consistent fashion.  Examples of this situation are provided by
   some virtual private network tunnels; it may be useful to view such
   tunnels as linking the diffserv domains at their endpoints into a
   diffserv region by making the tunnel endpoints virtually contiguous
   even though they may be physically separated by intermediate network
   nodes.

   The pipe model is also appropriate for situations in which the DSCP
   itself carries information through the tunnel.  For example, if
   transit between two domains is obtained via a path that uses the EF
   PHB [RFC 2598], the drop precedence information in the AF PHB DSCP
   values [RFC 2597] will be lost unless something is done to preserve
   it; an IP tunnel is one possible preservation mechanism.  A path that
   crosses one or more non-diffserv domains between its DS-capable
   endpoints may experience a similar information loss phenomenon if a
   tunnel is not used due to the limited set of DSCP codepoints that are
   compatible with such domains.







Black                        Informational                      [Page 4]

RFC 2983                  Diffserv and Tunnels              October 2000


3.2 Considerations for Partially DS-capable Configurations

   If only the tunnel egress node is DS-capable, [RFC 2475] requires the
   egress node to perform any edge traffic conditioning needed by the
   diffserv domain for tunneled traffic entering from outside the
   domain.  If the egress node would not otherwise be a DS edge node,
   one way to meet this requirement is to perform edge traffic
   conditioning at an appropriate upstream DS edge node within the
   tunnel, and copy the DSCP value from the outer IP header to the inner
   IP header as part of tunnel decapsulation processing; this applies
   the uniform model to the portion of the tunnel within the egress
   node's diffserv domain.  A second alternative is to discard the outer
   DSCP value as part of decapsulation processing, reducing the
   resulting traffic conditioning problem and requirements to those of
   an ordinary DS ingress node.  This applies the pipe model to the
   portion of the tunnel within the egress node's diffserv domain and
   hence the adjacent upstream node for DSCP marking purposes is the
   tunnel ingress node, rather than the immediately upstream
   intermediate tunnel node.

   If only the tunnel ingress node is DS-capable, [RFC 2475] requires
   that traffic emerging from the tunnel be compatible with the network
   at the tunnel egress.  If tunnel decapsulation processing discards
   the outer header's DSCP value without changing the inner header's
   DSCP value, the DS-capable tunnel ingress node is obligated to set
   the inner header's DSCP to a value compatible with the network at the
   tunnel egress.  The value 0 (DSCP of 000000) is used for this purpose
   by a number of existing tunnel implementations.  If the egress
   network implements IP precedence as specified in [RFC 791], then some
   or all of the eight class selector DSCP codepoints defined in [RFC
   2474] may be usable.  DSCP codepoints other than the class selectors
   are not generally suitable for this purpose, as correct operation
   would usually require diffserv functionality at the DS-incapable