Browse Prior Art Database

Differentiated Services and Tunnels (RFC2983)

IP.com Disclosure Number: IPCOM000005176D
Original Publication Date: 2000-Oct-01
Included in the Prior Art Database: 2001-Aug-16
Document File: 15 page(s) / 36K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Black: AUTHOR

Abstract

This document considers the interaction of Differentiated Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 9% of the total text.

Network Working Group D. Black Request for Comments: 2983 EMC Corporation Category: Informational October 2000

Differentiated Services and Tunnels

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document considers the interaction of Differentiated Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.

1. Conventions used in this document

An IP tunnel encapsulates IP traffic in another IP header as it passes through the tunnel; the presence of these two IP headers is a defining characteristic of IP tunnels, although there may be additional headers inserted between the two IP headers. The inner IP header is that of the original traffic; an outer IP header is attached and detached at tunnel endpoints. In general, intermediate network nodes between tunnel endpoints operate solely on the outer IP header, and hence diffserv-capable intermediate nodes access and modify only the DSCP field in the outer IP header. The terms "tunnel" and "IP tunnel" are used interchangeably in this document. For simplicity, this document does not consider tunnels other than IP tunnels (i.e., for which there is no encapsulating IP header), such

Black Informational [Page 1]

RFC 2983 Diffserv and Tunnels October 2000

as MPLS paths and "tunnels" formed by encapsulation in layer 2 (link) headers, although the conceptual models and approach described here may be useful in understanding the interaction of diffserv with such tunnels.

This analysis considers tunnels to be unidirectional; bi-directional tunnels are considered to be composed of two unidirectional tunnels carrying traffic in opposite directions between the same tunnel endpoints. A tunnel consists of an ingress where traffic enters the tunnel and is encapsulated by the addition of the outer IP header, an egress where traffic exits the tunnel and is decapsulated by the removal of the outer IP header, and intermediate nodes through which tunneled traffic passes between the ingress and egress. This document does not make any assumptions about routing and forwarding of...