rfc2983.txt

RFC 的详细文档！

   tunnel egress node.

4. Ingress Functionality

   As described in Section 3 above, this analysis is based on an
   approach in which diffserv functionality and/or out-of-band
   communication paths are not placed in parallel with tunnel
   encapsulation processing.  This allows three possible locations for
   traffic conditioning with respect to tunnel encapsulation processing,
   as shown in the following diagram that depicts the flow of IP headers
   through tunnel encapsulation:







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


                                        +--------- [2 - Outer] -->>
                                       /
                                      /
   >>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>

   Traffic conditioning at [1 - Before] is logically separate from the
   tunnel, as it is not impacted by the presence of tunnel
   encapsulation, and hence should be allowed by tunnel designs and
   specifications.  Traffic conditioning at [2 - Outer] may interact
   with tunnel protocols that are sensitive to packet reordering; such
   tunnels may need to limit the functionality at [2 - Outer] as
   discussed further in Section 5.1.  In the absence of reordering
   sensitivity, no additional restrictions should be necessary, although
   traffic conditioning at [2 - Outer] may be responsible for remarking
   traffic to be compatible with the next diffserv domain that the
   tunneled traffic enters.

   In contrast, the [3 - Inner] location is difficult to utilize for
   traffic conditioning because it requires functionality that reaches
   inside the packet to operate on the inner IP header.  This is
   impossible for IPSec tunnels and any other tunnels that are encrypted
   or employ cryptographic integrity checks.  Hence traffic conditioning
   at [3 - Inner] can often only be performed as part of tunnel
   encapsulation processing, complicating both the encapsulation and
   traffic conditioning implementations.  In many cases, the desired
   functionality can be achieved via a combination of traffic
   conditioners in the other two locations, both of which can be
   specified and implemented independently of tunnel encapsulation.

   An exception for which traffic conditioning functionality is
   necessary at [3 - Inner] occurs when the DS-incapable tunnel egress
   discards the outer IP header as part of decapsulation processing, and
   hence the DSCP in the inner IP header must be compatible with the
   egress network.  Setting the inner DSCP to 0 as part of encapsulation
   addresses most of these cases, and the class selector DCSP codepoint
   values are also useful for this purpose, as they are valid for
   networks that support IP precedence [RFC 791].

   The following table summarizes the achievable relationships among the
   before (B), outer (O), and inner (I) DSCP values and the
   corresponding locations of traffic conditioning logic.










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


   Relationship       Traffic Conditioning Location(s)
   ------------       --------------------------------
   B  = I  = O        No traffic conditioning required
   B != I  = O        [1 - Before]
   B  = I != O        [2 - Outer]
   B  = O != I        Limited support as part of encapsulation:
                        I can be set to 000000 or possibly one of
                        the class selector code points.
   B != I != O        Some combination of the above three scenarios.

   A combination of [1 - Before] and [2 - Outer] is applicable to many
   cases covered by the last two lines of the table, and may be
   preferable to deploying functionality at [3 - Inner].  Traffic
   conditioning may still be required for purposes such as rate and
   burst control even if DSCP values are not changed.

4.1 Ingress DSCP Selection and Reordering

   It may be necessary or desirable to limit the DS behavior aggregates
   that utilize an IP tunnel that is sensitive to packet reordering
   within the tunnel.  The diffserv architecture allows packets to be
   reordered when they belong to behavior aggregates among which
   reordering is permitted; for example, reordering is allowed among
   behavior aggregates marked with different Class Selector DSCPs [RFC
   2474].  IPSec [RFC 2401] and L2TP [RFC 2661] provide examples of
   tunnels that are sensitive to packet reordering.  If IPSec's anti-
   replay support is configured, audit events are generated in response
   to packet reordering that exceeds certain levels, with the audit
   events indicating potential security issues.  L2TP can be configured
   to restore the ingress ordering of packets at tunnel egress, not only
   undoing any differentiation based on reordering within the tunnel,
   but also negatively impacting the traffic (e.g., by increasing
   latency).  The uniform model cannot be completely applied to such
   tunnels, as arbitrary mixing of traffic from different behavior
   aggregates can cause these undesirable interactions.

   The simplest method of avoiding undesirable interactions of
   reordering with reordering-sensitive tunnel protocols and features is
   not to employ the reordering-sensitive protocols or features, but
   this is often not desirable or even possible.  When such protocols or
   features are used, interactions can be avoided by ensuring that the
   aggregated flows through the tunnel are marked at [2 - Outer] to
   constitute a single ordered aggregate (i.e., the PHBs used share an
   ordering constraint that prevents packets from being reordered).
   Tunnel protocol specifications should indicate both whether and under
   what circumstances a tunnel should be restricted to a single ordered
   aggregate as well as the consequences of deviating from that
   restriction.  For the IPSec and L2TP examples discussed above, the



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


   specifications should restrict each tunnel to a single ordered
   aggregate when protocol features sensitive to reordering are
   configured, and may adopt the approach of restricting all tunnels in
   order to avoid unexpected consequences of changes in protocol
   features or composition of tunneled traffic.  Diffserv
   implementations should not attempt to look within such tunnels to
   provide reordering-based differentiation to the encapsulated
   microflows.  If reordering-based differentiation is desired within
   such tunnels, multiple parallel tunnels between the same endpoints
   should be used.  This enables reordering among packets in different
   tunnels to coexist with an absence of packet reordering within each
   individual tunnel.  For IPSec and related security protocols, there
   is no cryptographic advantage to using a single tunnel for multiple
   ordered aggregates rather than multiple tunnels because any traffic
   analysis made possible by the use of multiple tunnels can also be
   performed based on the DSCPs in the outer headers of traffic in a
   single tunnel.  In general, the additional resources required to
   support multiple tunnels (e.g., cryptographic contexts), and the
   impact of multiple tunnels on network management should be considered
   in determining whether and where to deploy them.

4.2 Tunnel Selection

   The behavioral characteristics of a tunnel are an important
   consideration in determining what traffic should utilize the tunnel.
   This involves the service provisioning policies of all the
   participating domains, not just the PHBs and DSCPs marked on the
   traffic at [2 - Outer].  For example, while it is in general a bad
   idea to tunnel EF PHB traffic via a Default PHB tunnel, this can be
   acceptable if the EF traffic is the only traffic that utilizes the
   tunnel, and the tunnel is provisioned in a fashion adequate to
   preserve the behavioral characteristics required by the EF PHB.

   Service provisioning policies are responsible for preventing
   mismatches such as forwarding EF traffic via an inadequately
   provisioned Default tunnel.  When multiple parallel tunnels with
   different behavioral characteristics are available, service
   provisioning policies are responsible for determining which flows
   should use which tunnels.  Among the possibilities is a coarse
   version of the uniform tunnel model in which the inner DSCP value is
   used to select a tunnel that will forward the traffic using a
   behavioral aggregate that is compatible with the traffic's PHB.

5. Egress Functionality

   As described in Section 3 above, this analysis is based on an
   approach in which diffserv functionality and/or out-of-band
   communication paths are not placed in parallel with tunnel



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


   encapsulation processing.  This allows three possible locations for
   traffic conditioners with respect to tunnel decapsulation processing,
   as shown in the following diagram that depicts the flow of IP headers
   through tunnel decapsulation:

   >>----[5 - Outer]-------------+
                                  \
                                   \
   >>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>

   Traffic conditioning at [5 - Outer] and [6 - After] is logically
   separate from the tunnel, as it is not impacted by the presence of
   tunnel decapsulation.  Tunnel designs and specifications should allow
   diffserv traffic conditioning at these locations. Such conditioning
   can be viewed as independent of the tunnel, i.e., [5 - Outer] is
   traffic conditioning that takes place prior to tunnel egress, and
   [6 - After] is traffic conditioning that takes place after egress
   decapsulation.  An important exception is that the configuration of a
   tunnel (e.g., the absence of traffic conditioning at tunnel ingress)
   and/or the diffserv domains involved may require that all traffic
   exiting a tunnel pass through diffserv traffic conditioning to
   fulfill the diffserv edge node traffic conditioning responsibilities
   of the tunnel egress node.  Tunnel designers are strongly encouraged
   to include the ability to require that all traffic exiting a tunnel
   pass through diffserv traffic conditioning in order to ensure that
   traffic exiting the node is compatible with the egress node's
   diffserv domain.

   In contrast, the [4 - Inner] location is difficult to employ for
   traffic conditioning because it requires reaching inside the packet
   to operate on the inner IP header.  Unlike the [3 - Inner] case for
   encapsulation, there is no need for functionality to be performed at
   [4- Inner], as diffserv traffic conditioning can be appended to the
   tunnel decapsulation (i.e., performed at [6 - After]).

5.1 Egress DSCP Selection

   The elimination of parallel functionality and data paths from
   decapsulation causes a potential loss of information.  As shown in
   the above diagram, decapsulation combines and reduces two DSCP values
   to one DSCP value, losing information in the most general case, even
   if arbitrary functionality is allowed.  Beyond this, allowing
   arbitrary functionality poses a structural problem, namely that the
   DSCP value from the outer IP header would have to be presented as an
   out-of-band input to the traffic conditioning block at [6 - After],
   complicating the traffic conditioning model.





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


   To avoid such complications, the simpler approach of statically
   selecting either the inner or outer DSCP value at decapsulation is
   recommended, leaving the full generality of traffic conditioning
   functionality to be implemented at [5 - Outer] and/or [6 - After].
   Tunnels should support static selection of one or the other DSCP
   value at tunnel egress.  The rationale for this approach is usually
   only one of the two DSCP values contains useful information.  The
   conceptual model for the tunnel provides a strong indication of which
   one contains useful information; the outer DSCP value usually
   contains the useful information for tunnels based on the uniform
   model, and the inner DSCP value usually contains the useful
   information for tunnels based on the pipe model.  IPSec tunnels are
   usually based on the pipe model, and for security reasons are
   currently required to select the inner DSCP value; they should not be
   configured to select the outer DSCP value in the absence of an
   adequate security analysis of the resulting risks and implications.