Browse Prior Art Database

RSVP Operation Over IP Tunnels (RFC2746)

IP.com Disclosure Number: IPCOM000003343D
Original Publication Date: 2000-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 20 page(s) / 54K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Terzis: AUTHOR [+4]

Abstract

This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.

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

Network Working Group A. Terzis

Request for Comments: 2746 UCLA

Category: Standards Track J. Krawczyk

ArrowPoint Communications

J. Wroclawski

MIT LCS

L. Zhang

UCLA

January 2000

RSVP Operation Over IP Tunnels

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

This document describes an approach for providing RSVP protocol

services over IP tunnels. We briefly describe the problem, the

characteristics of possible solutions, and the design goals of our

approach. We then present the details of an implementation which

meets our design goals.

1. Introduction

IP-in-IP "tunnels" have become a widespread mechanism to transport

datagrams in the Internet. Typically, a tunnel is used to route

packets through portions of the network which do not directly

implement the desired service (e.g. IPv6), or to augment and modify

the behavior of the deployed routing architecture (e.g. multicast

routing, mobile IP, Virtual Private Net).

Many IP-in-IP tunneling protocols exist today. [IP4INIP4] details a

method of tunneling using an additional IPv4 header. [MINENC]

describes a way to reduce the size of the "inner" IP header used in

[IP4INIP4] when the original datagram is not fragmented. The generic

tunneling method in [IPV6GEN] can be used to tunnel either IPv4 or

IPv6 packets within IPv6. [RFC1933] describes how to tunnel IPv6

datagrams through IPv4 networks. [RFC1701] describes a generic

routing encapsulation, while [RFC1702] applies this encapsulation to

IPv4. Finally, [ESP] describes a mechanism that can be used to

tunnel an encrypted IP datagram.

From the perspective of traditional best-effort IP packet delivery, a

tunnel behaves as any other link. Packets enter one end of the

tunnel, and are delivered to the other end unless resource overload

or error causes them to be lost.

The RSVP setup protocol [RFC2205] is one component of a framework

designed to extend IP to support multiple, controlled classes of

service over a wide variety of link-level technologies. To deploy

this technology with maximum flexibility, it is desi...