[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-black-diffserv-tunnels) 00 01 02 RFC 2983

Differentiated Services WG                                     D. Black
INTERNET-DRAFT                                          EMC Corporation
Document: draft-ietf-diffserv-tunnels-00.txt              February 2000


                   Differentiated Services and Tunnels

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   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
   document will expire before September, 2000.

   Distribution of this draft is unlimited.

1. Abstract

   This draft 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]
   has been found to provide insufficient guidance to tunnel designers
   and implementers.  With the aim of providing such guidance, this
   document describes two conceptual models for the interaction of
   diffserv with 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; these mechanisms are also generally
   useful in situations where more general traffic conditioning is
   inappropriate or unavailable.  Security considerations for IPsec


Black                                                         [Page 1]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   tunnels may place limits on possible functionality in some
   circumstances.

2. 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.  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 can only access and modify the
   DSCP field in the outer IP header (e.g., for an encrypted tunnel,
   interior nodes cannot access the inner IP header).  The terms
   "tunnel" and "IP tunnel" are used interchangeably in this document.
   For simplicity, we do not consider issues raised by tunnels other
   than IP tunnels (i.e., where there is no encapsulating IP header),
   such as MPLS paths and "tunnels" formed by encapsulation in layer 2
   (link) headers.

   This document considers tunnels to be unidirectional; bi-directional
   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
   note: this is a note from the author.]) is editorial in nature and
   will be addressed in a future version of this document.

3. Diffserv and Tunnels Overview

   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
   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.  If the ingress
   or egress nodes do coincide with the end-to-end source or
   destination, the result is a simplified configuration to which much
   of the analysis and recommendations in this document are applicable.



Black                                                         [Page 2]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   A primary concern for differentiated services is the use of the
   Differentiated Services Code Point (DSCP) in the IP header; see
   [RFC-2474, RFC-2475] for more extensive descriptions of the DSCP
   field and the diffserv architecture.  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 some incomplete guidance, and guideline
   G.7 for PHB specification in Section 3 of that RFC is based on over-
   simplified assumptions about how tunnels are deployed with respect
   to DS domain boundaries.  The EF PHB specification [RFC-2598] may be
   too specific (in 20/20 hindsight) because its requirement to use EF
   in the outer header of tunneled EF packets (based on guideline G.7)
   is unworkable in domains that do not support EF, and excludes other
   techniques for conditioning tunneled EF traffic.

   This document proposes an approach in which traffic conditioning is
   performed in series with tunnel ingress or egress processing, not 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 introducing out-of-band inputs to diffserv
   traffic conditioner blocks, which would complicate them.  Diffserv
   domain boundaries can then be positioned as appropriate for the set
   of traffic conditioning blocks and tunnel processing modules.  One
   configuration of interest involves a diffserv domain boundary that
   passes through (i.e., divides) a network node; it is acceptable to
   split such a boundary to create a DMZ-like region between the
   domains that contains the tunnel ingress or egress processing.
   Diffserv traffic conditioning is not appropriate for such a DMZ-like
   region, as that traffic conditioning is part of the operation and
   management of one or more diffserv domains.

4. Conceptual Models for Diffserv Tunnels

   There are two important conceptual traffic conditioning models for
   IP tunnels.  For clarity, the initial discussion of these models
   assumes a fully diffserv-capable network.  Configurations in which
   this is not the case are taken up in Section 4.2.

4.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

Black                                                         [Page 3]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   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 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.  This
   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.  This model is
   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
   which the DSCP carries information that is within the tunnel.  For
   example, if transit between two domains is purchased via a tunnel
   that uses the EF PHB [RFC-2598], the drop precedence information in
   the AF PHB DSCP values [RFC-2597] will be destroyed unless something
   is done to preserve it; an IP tunnel is one possible preservation
   mechanism.  A tunnel that crosses one or more non-diffserv domains
   between its DS-capable endpoints may experience a similar
   information destruction phenomenon due to the limited set of DSCP
   codepoints that are compatible with such domains.

4.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 or nodes within
   the tunnel, and copy the DSCP value from the outer IP header to the
   inner IP header as part of tunnel decapsulation processing.  A
   second alternative discards the outer DSCP value as part of
   decapsulation processing, reducing the resulting traffic

Black                                                         [Page 4]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   conditioning problem and requirements to those of an ordinary DS
   ingress node.  This employs the pipe model of a tunnel and hence the
   adjacent upstream node for DSCP marking purposes is the tunnel
   ingress node, not 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, then the DS-capable tunnel ingress node MUST set the
   inner header's DSCP to a value compatible with the network at 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]
   are usable. DSCP codepoints other than the class selectors SHOULD
   NOT be used for this purpose, as correct operation under these
   circumstances involves diffserv functionality at the DS-incapable
   tunnel egress node.

5. Ingress Functionality

   As described in Section 3 above, this draft 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 model allows three possible locations for traffic
   conditioners with respect to tunnel encapsulation processing, as
   shown in the following diagram that depicts the flow of IP headers
   through tunnel encapsulation:
                                        +--------- [2 - Outer] -->>
                                       /
                                      /
   >>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>

   Traffic conditioning at [1 - Before] and [2 - Outer] is logically
   separate from the tunnel, as it is not impacted by the presence of
   tunnel encapsulation.  Tunnel designs and specifications SHOULD
   permit diffserv traffic conditioning at these locations.  Such
   conditioning can be performed by standard diffserv traffic
   conditioning components, such as [Author's note: TBD based on
   further diffserv WG efforts], and can be viewed as independent of
   the tunnel (e.g., [1 - Before] can be viewed as separate traffic
   conditioning that takes place prior to tunnel ingress).

   In contrast, the [3 - Inner] location SHOULD NOT be utilized for
   traffic conditioning because it requires functionality that reaches
   inside the packet to operate on the inner IP header.  This is
   difficult in general, and is impossible for IPsec tunnels and any
   other tunnels that are encrypted or employ cryptographic integrity
   checks.  Hence traffic conditioning at [3 - Inner] can 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

Black                                                         [Page 5]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   combination of traffic conditioners in the other two locations, both
   of which can be specified and implemented independently of tunnel
   encapsulation processing

   An exception for which traffic conditioning functionality is
   necessary at [3 - Inner] occurs when the tunnel egress is not DS-
   capable and discards the outer IP header.  Setting the inner DSCP to
   0 as part of encapsulation addresses most of these cases, and
   implementations MAY support setting the inner DSCP to one of the
   class selector DCSP codepoint values, as these are valid for
   networks that support IP precedence.  This level of functionality
   (set the DSCP to one of the class selector codepoint values) is also
   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 Before (B), outer (O), and inner (I) DSCP values and the
   corresponding locations of traffic conditioning logic.

   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 cases.

   A combination of [1 - Before] and [2 - Outer] is applicable in many
   cases that fit one of the last two lines of the table, and this
   combination is RECOMMENDED in preference to deploying functionality
   at [3 - Inner].  Implementers are cautioned that traffic
   conditioning may still be required for purposes such as rate and
   burst control even if DSCP values are not changed.

   [Author's note: Is the above table useful?]

6. Egress Functionality

   As described in Section 3 above, this draft 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
   conditioners with respect to tunnel decapsulation processing, as
   shown in the following diagram that depicts the flow of IP headers
   through tunnel encapsulation:

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

Black                                                         [Page 6]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000

   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
   permit diffserv traffic conditioning at these locations.  Such
   conditioning can be performed by standard diffserv traffic
   conditioning components, such as [Author's note: TBD based on
   further diffserv WG efforts], and can be viewed as independent of
   the tunnel (e.g., [6 - After] can be viewed as separate traffic
   conditioning that takes place after tunnel egress).  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 specifications SHOULD include the ability to require
   that all traffic exiting a tunnel pass through diffserv traffic
   conditioning.

   In contrast, the [4 - Inner] location SHOULD NOT be employed 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
   here, as diffserv traffic conditioning can be appended to the tunnel
   decapsulation (i.e., performed at [6 - After]).

6.1 Egress DSCP Selection

   The elimination of parallel functionality and data paths from
   decapsulation causes a potential loss of information.  As shown in
   the diagram in Section 6, 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.

   To avoid such complications, we adopt the simpler approach of
   statically selecting either the inner or outer DSCP value at
   decapsulation, 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 value at
   tunnel egress.  The rationale for this approach is that of the two
   DSCP values, usually only one of them contains useful information,
   with the other being of little value, and the conceptual model used
   for the tunnel provides a strong indication as to which one contains
   the useful information.  In general, the outer DSCP value contains
   the useful information for tunnels based on the uniform model, and
   the inner DSCP value contains the useful information for tunnels
   based on the pipe model.  IPsec tunnels are usually based on the
   pipe model, and for security reasons MUST default to selecting the
   outer DSCP value and SHOULD not select the inner DSCP value in the

Black                                                         [Page 7]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   absence of an adequate security analysis of the resulting risks and
   implications.

6.2 Egress DSCP Selection Case Study

   As a sanity check on the simpler approach proposed above (i.e., in
   Section 6), this subsection considers a situation in which a more
   complex approach might be required.  Statically choosing a single
   DSCP value is a poor match to situations in which both DSCPs are
   carrying information that is needed to perform traffic conditioning
   (i.e., at [6 - After]) correctly.

   As an example, we consider a situation in which two different AF
   groups [RFC-2597] are being used by the two domains at the tunnel
   endpoints, and there is an intermediate domain along the tunnel that
   uses RFC 791 IP precedences that is transited by setting the DSCP to
   zero.  This situation is shown in the following IP header flow
   diagram where I is the tunnel ingress node, E is the tunnel egress
   node and the vertical lines are domain boundaries.  The node at the
   left-hand vertical line sets the DSCP in the outer header to 0 in
   order to obtain compatibility with the middle domain:

                        |                   |
                  +-----|-------------------|------+
                 /      |                   |       \
   >>-----------I-------|-------------------|--------E---------->>
                        |                   |
      Ingress DS Domain        RFC 791         Egress DS domain
                            IP Precedence
                                Domain

   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
   group (e.g., via an MF classifier), but cannot reconstruct the drop
   precedence information that was removed from the outer header when
   it transited the RFC 791 domain (although it can construct new
   information via metering and marking).  The original drop precedence
   information is preserved in the inner IP header's DSCP, and could be
   combined with the AF class selection communicated via the outer IP
   header's DSCP.  The marginal benefit of being able to reuse the
   original drop precedence information as opposed to constructing new
   drop precedence markings does not appear to justify the additional
   complexity that would be introduced into tunnel egress traffic
   conditioners.

   [Author's note: Last sentence is an open issue for WG discussion.]

7.  Diffserv and Protocol Translators

   A related issue involves protocol translators, of which a specific
   example are those employing the Stateless IP/ICMP Translation
   Algorithm [RFC-2765].  These translators are not tunnels because
   they do not add or remove a second IP header to/from packets (e.g.,

Black                                                         [Page 8]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   in contrast to IPv6 over IPv4 tunnels [RFC-1933]) and hence do not
   raise concerns of information propagation between inner and outer IP
   headers.  The primary interaction between translators and diffserv
   is that the translation boundary is likely to also be a diffserv
   domain boundary (e.g., the IPv4 and IPv6 domains may have different
   policies for traffic conditioning and DSCP usage), and hence such
   translators SHOULD permit the insertion of diffserv edge node
   processing (i.e., including traffic conditioning) both before and
   after the translation processing.

8. Security Considerations

   The security considerations for the diffserv architecture discussed
   in [RFC-2474, RFC-2475] apply when tunnels are present; readers are
   referred to those documents for further information.  One of the
   requirements noted there is that a tunnel egress node in the
   interior of a diffserv domain is the DS ingress node for traffic
   exiting the tunnel, and is responsible for performing appropriate
   traffic conditioning.  The primary security implication is that the
   traffic conditioning is responsible for dealing with theft- and
   denial-of-service threats posed to the diffserv domain by traffic
   exiting from the tunnel.  The IPsec architecture [RFC-2401] places a
   further restriction on tunnel egress processing; the outer header
   MUST be discarded unless the properties of the traffic conditioning
   that will be applied are known and have been adequately analyzed for
   security vulnerabilities.  This includes both the [5 - Outer] and
   [6 - After] traffic conditioning blocks on the tunnel egress node,
   if present, and may involve traffic conditioning performed by an
   upstream DS-edge node that is the DS domain ingress node for the
   encapsulated tunneled traffic.

9. References

   [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, September
   1981.

   [RFC-1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51,
   RFC 1661, July 1994.

   [RFC-1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for
   IPv6 Hosts and Routers", RFC 1933, April 1996.

   [RFC-2003] C. Perkins, "IP Encapsulation within IP,", RFC 2003,
   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
   Internet Protocol", RFC 2401, November 1998.




Black                                                         [Page 9]


ietf-diffserv-tunnels    Diffserv and Tunnels            February 2000
   [RFC-2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition
   of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
   Headers", RFC 2474, December 1998.

   [RFC-2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and
   W. Weiss, "An Architecture for Differentiated Services", RFC 2475,
   December 1998.

   [RFC-2597] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski,
   "Assured Forwarding PHB Group", RFC 2597. June 1999.

   [RFC-2598] V. Jacobson, K. Nichols, and K. Poduri, "An Expedited
   Forwarding PHB", RFC 2598, June 1999.

   [RFC-2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
   and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
   August 1999.

   [RFC-2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm
   (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

   Some of this material is based on discussions with Brian Carpenter,
   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
   a people working on tunnel specifications [Author's note: names may
   appear here in a future version] who have discovered limitations of
   the diffserv architecture RFC (2475) in the area of tunnels.  Their
   kind patience with the time it has taken to address this set of
   issues has been greatly appreciated.  Finally, this material has
   benefited from discussions within the diffserv WG, and the
   contributions of participants in those discussions are gratefully
   acknowledged.

11. Author's Address

   David L. Black
   EMC Corporation
   42 South St.
   Hopkinton, MA   01748
   Phone: +1 (508) 435-1000 x75140
   Email: black_david@emc.com







Black                                                        [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/