draft-ietf-diffserv-tunnels-00.txt   draft-ietf-diffserv-tunnels-01.txt 
Differentiated Services WG D. Black Differentiated Services WG D. Black
INTERNET-DRAFT EMC Corporation INTERNET-DRAFT EMC Corporation
Document: draft-ietf-diffserv-tunnels-00.txt February 2000
Differentiated Services and Tunnels Differentiated Services and Tunnels
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
Internet-Drafts are working documents of the Internet Engineering areas, and its working groups. Note that other groups may also
Task Force (IETF), its areas, and its working groups. Note that distribute working documents as Internet-Drafts.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before September, 2000. draft will expire before December, 2000. Distribution of this draft
is unlimited.
Distribution of this draft is unlimited.
1. Abstract 1. Abstract
This draft considers the interaction of Differentiated Services This draft considers the interaction of Differentiated Services
(diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms. (diffserv) [RFC-2474, RFC-2475] with IP tunnels of various forms.
The discussion of tunnels in the diffserv architecture [RFC-2475] The discussion of tunnels in the diffserv architecture [RFC-2475]
has been found to provide insufficient guidance to tunnel designers provides insufficient guidance to tunnel designers and implementers.
and implementers. With the aim of providing such guidance, this This document describes two conceptual models for the interaction of
document describes two conceptual models for the interaction of
diffserv with IP tunnels and employs them to explore the resulting diffserv with IP tunnels and employs them to explore the resulting
configurations and combinations of functionality. An important configurations and combinations of functionality. An important
consideration is how and where it is appropriate to perform diffserv consideration is how and where it is appropriate to perform diffserv
traffic conditioning in the presence of tunnel encapsulation and traffic conditioning in the presence of tunnel encapsulation and
decapsulation. A few simple mechanisms are also proposed that limit decapsulation. A few simple mechanisms are also proposed that limit
the complexity that tunnels would otherwise add to the diffserv the complexity that tunnels would otherwise add to the diffserv
traffic conditioning model; these mechanisms are also generally traffic conditioning model. Security considerations for IPsec
useful in situations where more general traffic conditioning is tunnels limit the possible functionality in some circumstances.
inappropriate or unavailable. Security considerations for IPsec
tunnels may place limits on possible functionality in some
circumstances.
2. Conventions used in this document 2. Conventions used in this document
An IP tunnel encapsulates IP traffic in another IP header as it 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 passes through the tunnel; the presence of these two IP headers is a
defining characteristic of IP tunnels. The inner IP header is that defining characteristic of IP tunnels, although there may be
of the original traffic; an outer IP header is attached and detached additional headers inserted between the two IP headers. The inner
at tunnel endpoints. In general, intermediate network nodes between IP header is that of the original traffic; an outer IP header is
tunnel endpoints operate solely on the outer IP header, and hence attached and detached at tunnel endpoints. In general, intermediate
diffserv-capable intermediate nodes can only access and modify the network nodes between tunnel endpoints operate solely on the outer
DSCP field in the outer IP header (e.g., for an encrypted tunnel, IP header, and hence diffserv-capable intermediate nodes access and
interior nodes cannot access the inner IP header). The terms modify only the DSCP field in the outer IP header. The terms
"tunnel" and "IP tunnel" are used interchangeably in this document. "tunnel" and "IP tunnel" are used interchangeably in this document.
For simplicity, we do not consider issues raised by tunnels other For simplicity, this document does not consider tunnels other than
than IP tunnels (i.e., where there is no encapsulating IP header), IP tunnels (i.e., for which there is no encapsulating IP header),
such as MPLS paths and "tunnels" formed by encapsulation in layer 2 such as MPLS paths and "tunnels" formed by encapsulation in layer 2
(link) headers. (link) headers, although the conceptual models and approach
described here may be useful in understanding the interaction of
This document considers tunnels to be unidirectional; bi-directional diffserv with such tunnels.
tunnels are composed of two unidirectional tunnels carrying traffic
in opposite directions between the same pair of 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 neither requires nor forbids any form of
route pinning.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
Text in square brackets labeled "Author's note:" (e.g., [Author's This analysis considers tunnels to be unidirectional; bi-directional
note: this is a note from the author.]) is editorial in nature and tunnels are considered to be composed of two unidirectional tunnels
will be addressed in a future version of this document. 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.
3. Diffserv and Tunnels Overview 3. Diffserv and Tunnels Overview
Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003] Tunnels range in complexity from simple IP-in-IP tunnels [RFC-2003]
to complex multi-protocol tunnels, such as IP in PPP in L2TP in 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 IPsec transport mode [RFC-1661, RFC-2401, RFC-2661]. The most
general tunnel configuration is one in which the tunnel is not end- 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 to-end, i.e., the ingress and egress nodes are not the source and
destination nodes for traffic carried by the tunnel. If the ingress destination nodes for traffic carried by the tunnel; such a tunnel
or egress nodes do coincide with the end-to-end source or may carry traffic with multiple sources and destinations. If the
destination, the result is a simplified configuration to which much ingress node is the end-to-end source of all traffic in the tunnel,
of the analysis and recommendations in this document are applicable. 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 A primary concern for differentiated services is the use of the
Differentiated Services Code Point (DSCP) in the IP header; see Differentiated Services Code Point (DSCP) in the IP header [RFC-
[RFC-2474, RFC-2475] for more extensive descriptions of the DSCP 2474, RFC-2475]. The diffserv architecture permits intermediate
field and the diffserv architecture. The diffserv architecture nodes to examine and change the value of the DSCP, which may result
permits intermediate nodes to examine and change the value of the in the DSCP value in the outer IP header being modified between
DSCP, which may result in the DSCP value in the outer IP header tunnel ingress and egress. When a tunnel is not end-to-end, there
being modified between tunnel ingress and egress. When a tunnel is are circumstances in which it may be desirable to propagate the DSCP
not end-to-end, there are circumstances in which it may be desirable and/or some of the information that it contains to the outer IP
to propagate the DSCP and/or some of the information that it header on ingress and/or back to inner IP header on egress. The
contains to the outer IP header on ingress and/or back to inner IP current situation facing tunnel implementers is that [RFC-2475]
header on egress. The current situation facing tunnel implementers offers incomplete guidance. Guideline G.7 in Section 3 is an
is that [RFC-2475] offers some incomplete guidance, and guideline example, as some PHB specifications have followed it by explicitly
G.7 for PHB specification in Section 3 of that RFC is based on over- specifying the PHBs that may be used in the outer IP header for
simplified assumptions about how tunnels are deployed with respect tunneled traffic. This is overly restrictive; for example, if a
to DS domain boundaries. The EF PHB specification [RFC-2598] may be specification requires that the same PHB be used in both the inner
too specific (in 20/20 hindsight) because its requirement to use EF and outer IP headers, traffic conforming to that specification
in the outer header of tunneled EF packets (based on guideline G.7) cannot be tunneled across domains or networks that do not support
is unworkable in domains that do not support EF, and excludes other that PHB. A more flexible approach that should be used instead is
techniques for conditioning tunneled EF traffic. 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 This document proposes an approach in which traffic conditioning is
performed in series with tunnel ingress or egress processing, not in performed in series with tunnel ingress or egress processing, rather
parallel. This approach does not create any additional paths that than in parallel. This approach does not create any additional
transmit information across a tunnel endpoint, as all diffserv paths that transmit information across a tunnel endpoint, as all
information is contained in the DSCPs in the IP headers. The IPsec diffserv information is contained in the DSCPs in the IP headers.
architecture [RFC-2401] requires that this be the case to preserve The IPsec architecture [RFC-2401] requires that this be the case to
security properties at the egress of IPsec tunnels, but this preserve security properties at the egress of IPsec tunnels, but
approach also avoids introducing out-of-band inputs to diffserv this approach also avoids complicating diffserv traffic conditioning
traffic conditioner blocks, which would complicate them. Diffserv blocks by introducing out-of-band inputs. A consequence of this
domain boundaries can then be positioned as appropriate for the set approach is that the last sentence of Guideline G.7 in Section 3 of
of traffic conditioning blocks and tunnel processing modules. One [RFC-2475] becomes moot because there are no tunnel egress diffserv
configuration of interest involves a diffserv domain boundary that components that have access to both the inner and outer DSCPs.
passes through (i.e., divides) a network node; it is acceptable to
split such a boundary to create a DMZ-like region between the An additional advantage of this traffic conditioning approach is
domains that contains the tunnel ingress or egress processing. that it places no additional restrictions on the positioning of
Diffserv traffic conditioning is not appropriate for such a DMZ-like diffserv domain boundaries with respect to traffic conditioning and
region, as that traffic conditioning is part of the operation and tunnel encapsulation/decapsulation components. An interesting class
management of one or more diffserv domains. 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.
4. Conceptual Models for Diffserv Tunnels 4. Conceptual Models for Diffserv Tunnels
There are two important conceptual traffic conditioning models for This analysis introduces two conceptual traffic conditioning models
IP tunnels. For clarity, the initial discussion of these models for IP tunnels based on an initial discussion that assumes a fully
assumes a fully diffserv-capable network. Configurations in which diffserv-capable network. Configurations in which this is not the
this is not the case are taken up in Section 4.2. case are taken up in Section 4.2.
4.1 Conceptual Models for Fully DS-capable Configurations 4.1 Conceptual Models for Fully DS-capable Configurations
The first conceptual model is a uniform model that views IP tunnels The first conceptual model is a uniform model that views IP tunnels
as artifacts of the end to end path from a traffic conditioning as artifacts of the end to end path from a traffic conditioning
standpoint; tunnels may be necessary mechanisms to get traffic to standpoint; tunnels may be necessary mechanisms to get traffic to
its destination(s), but have no significant impact on traffic its destination(s), but have no significant impact on traffic
conditioning. In this model, any packet has exactly one DS Field conditioning. In this model, any packet has exactly one DS Field
that is used for traffic conditioning at any point, namely the DS that is used for traffic conditioning at any point, namely the DS
Field in the outermost IP header; any others are ignored. Field in the outermost IP header; any others are ignored.
skipping to change at page 4, line 18 skipping to change at page 4, line 12
the inner IP header at decapsulation. Use of this model allows IP the inner IP header at decapsulation. Use of this model allows IP
tunnels to be configured without regard to diffserv domain tunnels to be configured without regard to diffserv domain
boundaries because diffserv traffic conditioning functionality is boundaries because diffserv traffic conditioning functionality is
not impacted by the presence of IP tunnels. not impacted by the presence of IP tunnels.
The second conceptual model is a pipe model that views an IP tunnel 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 as hiding the nodes between its ingress and egress so that they do
not participate fully in traffic conditioning. In this model, a not participate fully in traffic conditioning. In this model, a
tunnel egress node uses traffic conditioning information conveyed tunnel egress node uses traffic conditioning information conveyed
from the tunnel ingress by the DSCP value in the inner header, and from the tunnel ingress by the DSCP value in the inner header, and
ignores (i.e., discards) the DSCP value in the outer header. This ignores (i.e., discards) the DSCP value in the outer header. The
model cannot completely hide traffic conditioning within the tunnel, pipe model cannot completely hide traffic conditioning within the
as the effects of dropping and shaping at intermediate tunnel nodes tunnel, as the effects of dropping and shaping at intermediate
may be visible at the tunnel egress and beyond. This model is tunnel nodes may be visible at the tunnel egress and beyond.
particularly appropriate to configurations in which the ingress and
egress nodes belong to the same diffserv domain but the IP tunnel
may pass through other domains; virtual private networks (VPNs) may
be configured in this fashion. In this class of configurations, the
DSCP values from the ingress node are valid at the egress node
because both nodes are in the same diffserv domain. Other uses of
the pipe model (i.e., for configurations in which the tunnel ingress
and egress nodes are not in the same diffserv domain) SHOULD employ
an inter-domain TCA (Traffic Conditioning Agreement) between the
diffserv domains containing the tunnel ingress and egress nodes in
order to specify the required egress traffic conditioning.
The pipe conceptual model is also appropriate for situations in The pipe model has traffic conditioning consequences when the
which the DSCP carries information that is within the tunnel. For ingress and egress nodes are in different diffserv domains. In such
example, if transit between two domains is purchased via a tunnel a situation, the egress node must perform traffic conditioning to
that uses the EF PHB [RFC-2598], the drop precedence information in ensure that the traffic exiting the tunnel has DSCP values
the AF PHB DSCP values [RFC-2597] will be destroyed unless something acceptable to the egress diffserv domain (see Section 6 of the
is done to preserve it; an IP tunnel is one possible preservation diffserv architecture [RFC-2475]). An inter-domain TCA (Traffic
mechanism. A tunnel that crosses one or more non-diffserv domains Conditioning Agreement) between the diffserv domains containing the
between its DS-capable endpoints may experience a similar tunnel ingress and egress nodes may be used to reduce or eliminate
information destruction phenomenon due to the limited set of DSCP egress traffic conditioning. Complete elimination of egress traffic
codepoints that are compatible with such domains. 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.
4.2 Considerations for Partially DS-capable Configurations 4.2 Considerations for Partially DS-capable Configurations
If only the tunnel egress node is DS-capable, [RFC-2475] requires If only the tunnel egress node is DS-capable, [RFC-2475] requires
the egress node to perform any edge traffic conditioning needed by the egress node to perform any edge traffic conditioning needed by
the diffserv domain for tunneled traffic entering from outside the the diffserv domain for tunneled traffic entering from outside the
domain. If the egress node would not otherwise be a DS edge node, domain. If the egress node would not otherwise be a DS edge node,
one way to meet this requirement is to perform edge traffic one way to meet this requirement is to perform edge traffic
conditioning at an appropriate upstream DS edge node or nodes within conditioning at an appropriate upstream DS edge node or nodes within
the tunnel, and copy the DSCP value from the outer IP header to the the tunnel, and copy the DSCP value from the outer IP header to the
inner IP header as part of tunnel decapsulation processing. A inner IP header as part of tunnel decapsulation processing; this
second alternative discards the outer DSCP value as part of applies the uniform model to the portion of the tunnel within the
decapsulation processing, reducing the resulting traffic egress node's diffserv domain. A second alternative is to discard
conditioning problem and requirements to those of an ordinary DS the outer DSCP value as part of decapsulation processing, reducing
ingress node. This employs the pipe model of a tunnel and hence the the resulting traffic conditioning problem and requirements to those
adjacent upstream node for DSCP marking purposes is the tunnel of an ordinary DS ingress node. This applies the pipe model to the
ingress node, not the immediately upstream intermediate tunnel node. 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 If only the tunnel ingress node is DS-capable, [RFC-2475] requires
that traffic emerging from the tunnel be compatible with the network that traffic emerging from the tunnel be compatible with the network
at the tunnel egress. If tunnel decapsulation processing discards at the tunnel egress. If tunnel decapsulation processing discards
the outer header's DSCP value without changing the inner header's the outer header's DSCP value without changing the inner header's
DSCP value, then the DS-capable tunnel ingress node MUST set the DSCP value, the DS-capable tunnel ingress node is obligated to set
inner header's DSCP to a value compatible with the network at tunnel the inner header's DSCP to a value compatible with the network at
egress. The value 0 (DSCP of 000000) is used for this purpose by a the tunnel egress. The value 0 (DSCP of 000000) is used for this
number of existing tunnel implementations. If the egress network purpose by a number of existing tunnel implementations. If the
implements IP precedence as specified in [RFC-791], then some or all egress network implements IP precedence as specified in [RFC-791],
of the eight class selector DSCP codepoints defined in [RFC-2474] then some or all of the eight class selector DSCP codepoints defined
are usable. DSCP codepoints other than the class selectors SHOULD in [RFC-2474] may be usable. DSCP codepoints other than the class
NOT be used for this purpose, as correct operation under these selectors are not generally suitable for this purpose, as correct
circumstances involves diffserv functionality at the DS-incapable operation would usually require diffserv functionality at the DS-
tunnel egress node. incapable tunnel egress node.
5. Ingress Functionality 5. Ingress Functionality
As described in Section 3 above, this draft is based on an approach As described in Section 3 above, this analysis is based on an
in which diffserv functionality and/or out-of-band communication approach in which diffserv functionality and/or out-of-band
paths are not placed in parallel with tunnel encapsulation communication paths are not placed in parallel with tunnel
processing. This model allows three possible locations for traffic encapsulation processing. This allows three possible locations for
conditioners with respect to tunnel encapsulation processing, as traffic conditioning with respect to tunnel encapsulation
shown in the following diagram that depicts the flow of IP headers processing, as shown in the following diagram that depicts the flow
through tunnel encapsulation: of IP headers through tunnel encapsulation:
+--------- [2 - Outer] -->> +--------- [2 - Outer] -->>
/ /
/ /
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->> >>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
Traffic conditioning at [1 - Before] and [2 - Outer] is logically Traffic conditioning at [1 - Before] is logically separate from the
separate from the tunnel, as it is not impacted by the presence of tunnel, as it is not impacted by the presence of tunnel
tunnel encapsulation. Tunnel designs and specifications SHOULD encapsulation, and hence should be allowed by tunnel designs and
permit diffserv traffic conditioning at these locations. Such specifications. Traffic conditioning at [2 - Outer] may interact
conditioning can be performed by standard diffserv traffic with tunnel protocols that are sensitive to packet reordering; such
conditioning components, such as [Author's note: TBD based on tunnels may need to limit the functionality at [2 - Outer] as
further diffserv WG efforts], and can be viewed as independent of discussed further in Section 5.1. In the absence of reordering
the tunnel (e.g., [1 - Before] can be viewed as separate traffic sensitivity, no additional restrictions should be necessary,
conditioning that takes place prior to tunnel ingress). 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 SHOULD NOT be utilized for In contrast, the [3 - Inner] location is difficult to utilize for
traffic conditioning because it requires functionality that reaches traffic conditioning because it requires functionality that reaches
inside the packet to operate on the inner IP header. This is inside the packet to operate on the inner IP header. This is
difficult in general, and is impossible for IPsec tunnels and any impossible for IPsec tunnels and any other tunnels that are
other tunnels that are encrypted or employ cryptographic integrity encrypted or employ cryptographic integrity checks. Hence traffic
checks. Hence traffic conditioning at [3 - Inner] can only be conditioning at [3 - Inner] can often only be performed as part of
performed as part of tunnel encapsulation processing, complicating tunnel encapsulation processing, complicating both the encapsulation
both the encapsulation and traffic conditioning implementations. In and traffic conditioning implementations. In many cases, the
many cases, the desired functionality can be achieved via a desired functionality can be achieved via a combination of traffic
combination of traffic conditioners in the other two locations, both conditioners in the other two locations, both of which can be
of which can be specified and implemented independently of tunnel specified and implemented independently of tunnel encapsulation.
encapsulation processing
An exception for which traffic conditioning functionality is An exception for which traffic conditioning functionality is
necessary at [3 - Inner] occurs when the tunnel egress is not DS- necessary at [3 - Inner] occurs when the DS-incapable tunnel egress
capable and discards the outer IP header. Setting the inner DSCP to discards the outer IP header as part of decapsulation processing,
0 as part of encapsulation addresses most of these cases, and and hence the DSCP in the inner IP header must be compatible with
implementations MAY support setting the inner DSCP to one of the the egress network. Setting the inner DSCP to 0 as part of
class selector DCSP codepoint values, as these are valid for encapsulation addresses most of these cases, and the class selector
networks that support IP precedence. This level of functionality DCSP codepoint values are also useful for this purpose, as they are
(set the DSCP to one of the class selector codepoint values) is also valid for networks that support IP precedence [RFC-791].
generally appropriate for other traffic conditioning locations in
configurations that do not support more general traffic conditioning
at those locations.
The following table summarizes the achievable relationships among The following table summarizes the achievable relationships among
the Before (B), outer (O), and inner (I) DSCP values and the the before (B), outer (O), and inner (I) DSCP values and the
corresponding locations of traffic conditioning logic. corresponding locations of traffic conditioning logic.
Relationship Traffic Conditioning Location(s) Relationship Traffic Conditioning Location(s)
------------ -------------------------------- ------------ --------------------------------
B = I = O No traffic conditioning required B = I = O No traffic conditioning required
B != I = O [1 - Before] B != I = O [1 - Before]
B = I != O [2 - Outer] B = I != O [2 - Outer]
B = O != I Limited support as part of encapsulation: B = O != I Limited support as part of encapsulation:
I can be set to 000000 or possibly one of I can be set to 000000 or possibly one of
the class selector code points. the class selector code points.
B != I != O Some combination of the above three cases. B != I != O Some combination of the above three scenarios.
A combination of [1 - Before] and [2 - Outer] is applicable in many A combination of [1 - Before] and [2 - Outer] is applicable to many
cases that fit one of the last two lines of the table, and this cases covered by the last two lines of the table, and may be
combination is RECOMMENDED in preference to deploying functionality preferable to deploying functionality at [3 - Inner]. Traffic
at [3 - Inner]. Implementers are cautioned that traffic
conditioning may still be required for purposes such as rate and conditioning may still be required for purposes such as rate and
burst control even if DSCP values are not changed. burst control even if DSCP values are not changed.
[Author's note: Is the above table useful?] 5.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
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. The additional management complexity introduced
by multiple tunnels should be considered in determining whether and
where to deploy them.
5.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.
6. Egress Functionality 6. Egress Functionality
As described in Section 3 above, this draft is based on an approach As described in Section 3 above, this analysis is based on an
in which diffserv functionality and/or out-of-band communication approach in which diffserv functionality and/or out-of-band
paths are not placed in parallel with tunnel encapsulation communication paths are not placed in parallel with tunnel
processing. This allows three possible locations for traffic encapsulation processing. This allows three possible locations for
conditioners with respect to tunnel decapsulation processing, as traffic conditioners with respect to tunnel decapsulation
shown in the following diagram that depicts the flow of IP headers processing, as shown in the following diagram that depicts the flow
through tunnel encapsulation: of IP headers through tunnel decapsulation:
>>----[5 - Outer]-------------+ >>----[5 - Outer]-------------+
\ \
\ \
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->> >>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
Traffic conditioning at [5 - Outer] and [6 - After] is logically Traffic conditioning at [5 - Outer] and [6 - After] is logically
separate from the tunnel, as it is not impacted by the presence of separate from the tunnel, as it is not impacted by the presence of
tunnel decapsulation. Tunnel designs and specifications SHOULD tunnel decapsulation. Tunnel designs and specifications should
permit diffserv traffic conditioning at these locations. Such allow diffserv traffic conditioning at these locations. Such
conditioning can be performed by standard diffserv traffic conditioning can be viewed as independent of the tunnel, i.e.,
conditioning components, such as [Author's note: TBD based on [5 - Outer] is traffic conditioning that takes place prior to tunnel
further diffserv WG efforts], and can be viewed as independent of egress, and [6 - After] is traffic conditioning that takes place
the tunnel (e.g., [6 - After] can be viewed as separate traffic after egress decapsulation. An important exception is that the
conditioning that takes place after tunnel egress). An important configuration of a tunnel (e.g., the absence of traffic conditioning
exception is that the configuration of a tunnel (e.g., the absence at tunnel ingress) and/or the diffserv domains involved may require
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 specifications SHOULD include the ability to require
that all traffic exiting a tunnel pass through diffserv traffic that all traffic exiting a tunnel pass through diffserv traffic
conditioning. 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 SHOULD NOT be employed for In contrast, the [4 - Inner] location is difficult to employ for
traffic conditioning because it requires reaching inside the packet traffic conditioning because it requires reaching inside the packet
to operate on the inner IP header. Unlike the [3 - Inner] case for to operate on the inner IP header. Unlike the [3 - Inner] case for
encapsulation, there is no need for functionality to be performed encapsulation, there is no need for functionality to be performed at
here, as diffserv traffic conditioning can be appended to the tunnel [4- Inner], as diffserv traffic conditioning can be appended to the
decapsulation (i.e., performed at [6 - After]). tunnel decapsulation (i.e., performed at [6 - After]).
6.1 Egress DSCP Selection 6.1 Egress DSCP Selection
The elimination of parallel functionality and data paths from The elimination of parallel functionality and data paths from
decapsulation causes a potential loss of information. As shown in decapsulation causes a potential loss of information. As shown in
the diagram in Section 6, decapsulation combines and reduces two the above diagram, decapsulation combines and reduces two DSCP
DSCP values to one DSCP value, losing information in the most values to one DSCP value, losing information in the most general
general case, even if arbitrary functionality is allowed. Beyond case, even if arbitrary functionality is allowed. Beyond this,
this, allowing arbitrary functionality poses a structural problem, allowing arbitrary functionality poses a structural problem, namely
namely that the DSCP value from the outer IP header would have to be 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 presented as an out-of-band input to the traffic conditioning block
at [6 - After], complicating the traffic conditioning model. at [6 - After], complicating the traffic conditioning model.
To avoid such complications, we adopt the simpler approach of To avoid such complications, the simpler approach of statically
statically selecting either the inner or outer DSCP value at selecting either the inner or outer DSCP value at decapsulation is
decapsulation, leaving the full generality of traffic conditioning recommended, leaving the full generality of traffic conditioning
functionality to be implemented at [5 - Outer] and/or [6 - After]. functionality to be implemented at [5 - Outer] and/or [6 - After].
Tunnels SHOULD support static selection of one or the other value at Tunnels should support static selection of one or the other DSCP
tunnel egress. The rationale for this approach is that of the two value at tunnel egress. The rationale for this approach is usually
DSCP values, usually only one of them contains useful information, only one of the two DSCP values contains useful information. The
with the other being of little value, and the conceptual model used conceptual model for the tunnel provides a strong indication of
for the tunnel provides a strong indication as to which one contains which one contains useful information; the outer DSCP value usually
the useful information. In general, the outer DSCP value contains contains the useful information for tunnels based on the uniform
the useful information for tunnels based on the uniform model, and model, and the inner DSCP value usually contains the useful
the inner DSCP value contains the useful information for tunnels information for tunnels based on the pipe model. IPsec tunnels are
based on the pipe model. IPsec tunnels are usually based on the usually based on the pipe model, and for security reasons are
pipe model, and for security reasons MUST default to selecting the required to select the inner DSCP value; they should not be
outer DSCP value and SHOULD not select the inner DSCP value in the configured to select the outer DSCP value in the absence of an
absence of an adequate security analysis of the resulting risks and adequate security analysis of the resulting risks and implications.
implications.
6.2 Egress DSCP Selection Case Study 6.2 Egress DSCP Selection Case Study
As a sanity check on the simpler approach proposed above (i.e., in As a sanity check on the egress DSCP selection approach proposed
Section 6), this subsection considers a situation in which a more above, this subsection considers a situation in which a more complex
complex approach might be required. Statically choosing a single approach might be required. Statically choosing a single DSCP value
DSCP value is a poor match to situations in which both DSCPs are may not work well when both DSCPs are carrying information that is
carrying information that is needed to perform traffic conditioning relevant to traffic conditioning.
(i.e., at [6 - After]) correctly.
As an example, we consider a situation in which two different AF As an example, consider a situation in which different AF groups
groups [RFC-2597] are being used by the two domains at the tunnel [RFC-2597] are used by the two domains at the tunnel endpoints, and
endpoints, and there is an intermediate domain along the tunnel that there is an intermediate domain along the tunnel using RFC 791 IP
uses RFC 791 IP precedences that is transited by setting the DSCP to precedences that is transited by setting the DSCP to zero. This
zero. This situation is shown in the following IP header flow situation is shown in the following IP header flow diagram where I
diagram where I is the tunnel ingress node, E is the tunnel egress is the tunnel ingress node, E is the tunnel egress node and the
node and the vertical lines are domain boundaries. The node at the vertical lines are domain boundaries. The node at the left-hand
left-hand vertical line sets the DSCP in the outer header to 0 in vertical line sets the DSCP in the outer header to 0 in order to
order to obtain compatibility with the middle domain: obtain compatibility with the middle domain:
| | | |
+-----|-------------------|------+ +-----|-------------------|------+
/ | | \ / | | \
>>-----------I-------|-------------------|--------E---------->> >>-----------I-------|-------------------|--------E---------->>
| | | |
Ingress DS Domain RFC 791 Egress DS domain Ingress DS Domain RFC 791 Egress DS domain
IP Precedence IP Precedence
Domain Domain
In this situation, the DS edge node for the egress domain (i.e., the In this situation, the DS edge node for the egress domain (i.e., the
node at the right-hand vertical line) can select the appropriate AF node at the right-hand vertical line) can select the appropriate AF
group (e.g., via an MF classifier), but cannot reconstruct the drop group (e.g., via an MF classifier), but cannot reconstruct the drop
precedence information that was removed from the outer header when precedence information that was removed from the outer header when
it transited the RFC 791 domain (although it can construct new it transited the RFC 791 domain (although it can construct new
information via metering and marking). The original drop precedence information via metering and marking). The original drop precedence
information is preserved in the inner IP header's DSCP, and could be information is preserved in the inner IP header's DSCP, and could be
combined with the AF class selection communicated via the outer IP combined at the tunnel egress with the AF class selection
header's DSCP. The marginal benefit of being able to reuse the communicated via the outer IP header's DSCP. The marginal benefit
original drop precedence information as opposed to constructing new of being able to reuse the original drop precedence information as
drop precedence markings does not appear to justify the additional opposed to constructing new drop precedence markings does not
complexity that would be introduced into tunnel egress traffic justify the additional complexity introduced into tunnel egress
conditioners. traffic conditioners by making both DSCP values available to traffic
conditioning at [6 - After].
[Author's note: Last sentence is an open issue for WG discussion.]
7. Diffserv and Protocol Translators 7. Diffserv and Protocol Translators
A related issue involves protocol translators, of which a specific A related issue involves protocol translators, including those
example are those employing the Stateless IP/ICMP Translation employing the Stateless IP/ICMP Translation Algorithm [RFC-2765].
Algorithm [RFC-2765]. These translators are not tunnels because These translators are not tunnels because they do not add or remove
they do not add or remove a second IP header to/from packets (e.g., a second IP header to/from packets (e.g., in contrast to IPv6 over
in contrast to IPv6 over IPv4 tunnels [RFC-1933]) and hence do not IPv4 tunnels [RFC-1933]) and hence do not raise concerns of
raise concerns of information propagation between inner and outer IP information propagation between inner and outer IP headers. The
headers. The primary interaction between translators and diffserv primary interaction between translators and diffserv is that the
is that the translation boundary is likely to also be a diffserv translation boundary is likely to also be a diffserv domain boundary
domain boundary (e.g., the IPv4 and IPv6 domains may have different (e.g., the IPv4 and IPv6 domains may have different policies for
policies for traffic conditioning and DSCP usage), and hence such traffic conditioning and DSCP usage), and hence such translators
translators SHOULD permit the insertion of diffserv edge node should allow the insertion of diffserv edge node processing
processing (i.e., including traffic conditioning) both before and (including traffic conditioning) both before and after the
after the translation processing. translation processing.
8. Security Considerations 8. Security Considerations
The security considerations for the diffserv architecture discussed The security considerations for the diffserv architecture discussed
in [RFC-2474, RFC-2475] apply when tunnels are present; readers are in [RFC-2474, RFC-2475] apply when tunnels are present. One of the
referred to those documents for further information. One of the requirements is that a tunnel egress node in the interior of a
requirements noted there is that a tunnel egress node in the diffserv domain is the DS ingress node for traffic exiting the
interior of a diffserv domain is the DS ingress node for traffic tunnel, and is responsible for performing appropriate traffic
exiting the tunnel, and is responsible for performing appropriate conditioning. The primary security implication is that the traffic
traffic conditioning. The primary security implication is that the conditioning is responsible for dealing with theft- and denial-of-
traffic conditioning is responsible for dealing with theft- and service threats posed to the diffserv domain by traffic exiting from
denial-of-service threats posed to the diffserv domain by traffic the tunnel. The IPsec architecture [RFC-2401] places a further
exiting from the tunnel. The IPsec architecture [RFC-2401] places a restriction on tunnel egress processing; the outer header is to be
further restriction on tunnel egress processing; the outer header discarded unless the properties of the traffic conditioning to be
MUST be discarded unless the properties of the traffic conditioning applied are known and have been adequately analyzed for security
that will be applied are known and have been adequately analyzed for vulnerabilities. This includes both the [5 - Outer] and [6 - After]
security vulnerabilities. This includes both the [5 - Outer] and traffic conditioning blocks on the tunnel egress node, if present,
[6 - After] traffic conditioning blocks on the tunnel egress node, and may involve traffic conditioning performed by an upstream DS-
if present, and may involve traffic conditioning performed by an edge node that is the DS domain ingress node for the encapsulated
upstream DS-edge node that is the DS domain ingress node for the tunneled traffic.
encapsulated tunneled traffic.
9. References 9. References
[RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51, [RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for [RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996. IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003, [RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003,
October 1996. October 1996.
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC-2401] S. Kent and R. Atkinson, "Security Architecture for the [RFC-2401] S. Kent and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition [RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition
of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
[RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and [RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, "An Architecture for Differentiated Services", RFC 2475, W. Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998. December 1998.
skipping to change at page 10, line 26 skipping to change at page 11, line 35
[RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited [RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999. Forwarding PHB", RFC 2598, June 1999.
[RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, [RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661, and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999. August 1999.
[RFC-2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm [RFC-2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765. February, 2000. (SIIT)", RFC 2765. February, 2000.
[Author's note: This needs to be extended by additional tunnel RFC
references. The references section of the Tunnel MIB RFC (RFC 2667)
provides a good starting point.]
10. Acknowledgments 10. Acknowledgments
Some of this material is based on discussions with Brian Carpenter, Some of this material is based on discussions with Brian Carpenter,
and in particular his presentation on this topic to the diffserv WG and in particular his presentation on this topic to the diffserv WG
during the summer 1999 IETF meeting in Oslo. Credit is also due to during the summer 1999 IETF meeting in Oslo. Credit is also due to
a people working on tunnel specifications [Author's note: names may a number of people working on tunnel specifications who have
appear here in a future version] who have discovered limitations of discovered limitations of the diffserv architecture [RFC-2475] in
the diffserv architecture RFC (2475) in the area of tunnels. Their the area of tunnels. Their patience with the time it has taken to
kind patience with the time it has taken to address this set of address this set of issues is greatly appreciated. Finally, this
issues has been greatly appreciated. Finally, this material has material has benefited from discussions within the diffserv WG, both
benefited from discussions within the diffserv WG, and the in meetings and on the mailing list -- the contributions of
contributions of participants in those discussions are gratefully participants in those discussions are gratefully acknowledged.
acknowledged.
11. Author's Address 11. Author's Address
David L. Black David L. Black
EMC Corporation EMC Corporation
42 South St. 42 South St.
Hopkinton, MA 01748 Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140 Phone: +1 (508) 435-1000 x75140
Email: black_david@emc.com Email: black_david@emc.com
 End of changes. 45 change blocks. 
293 lines changed or deleted 351 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/