📄 rfc2746.txt
字号:
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
Terzis, et al. Standards Track [Page 1]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
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 desirable for tunnels
to act as RSVP-controllable links within the network.
A tunnel, and in fact any sort of link, may participate in an RSVP-
aware network in one of three ways, depending on the capabilities of
the equipment from which the tunnel is constructed and the desires of
the operator.
1. The (logical) link may not support resource reservation or QoS
control at all. This is a best-effort link. We refer to this as
a best-effort or type 1 tunnel in this note.
2. The (logical) link may be able to promise that some overall
level of resources is available to carry traffic, but not to
allocate resources specifically to individual data flows. A
configured resource allocation over a tunnel is an example of
this. We refer to this case as a type 2 tunnel in this note.
3. The (logical) link may be able to make reservations for
individual end-to-end data flows. We refer to this case as a
type 3 tunnel. Note that the key feature that distinguishes
type 3 tunnels from type 2 tunnels is that in the type 3 tunnel
new tunnel reservations are created and torn down dynamically
as end-to-end reservations come and go.
Type 1 tunnels exist when at least one of the routers comprising the
tunnel endpoints does not support the scheme we describe here. In
this case, the tunnel acts as a best-effort link. Our goal is simply
to make sure that RSVP messages traverse the link correctly, and the
presence of the non-controlled link is detected, as required by the
integrated services framework.
When the two end points of the tunnel are capable of supporting RSVP
over tunnels, we would like to have proper resources reserved along
the tunnel. Depending on the requirements of the situation, this
might mean that one client's data flow is placed into a larger
aggregate reservation (type 2 tunnels) or that possibly a new,
Terzis, et al. Standards Track [Page 2]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
separate reservation is made for the data flow (type 3 tunnels).
Note that an RSVP reservation between the two tunnel end points does
not necessarily mean that all the intermediate routers along the
tunnel path support RSVP, this is equivalent to the case of an
existing end-to-end RSVP session transparently passing through non-
RSVP cloud.
Currently, however, RSVP signaling over tunnels is not possible.
RSVP packets entering the tunnel are encapsulated with an outer IP
header that has a protocol number other than 46 (e.g. it is 4 for
IP-in-IP encapsulation) and do not carry the Router-Alert option,
making them virtually "invisible" to RSVP routers between the two
tunnel endpoints. Moreover, the current IP-in-IP encapsulation
scheme adds only an IP header as the external wrapper. It is
impossible to distinguish between packets that use reservations and
those that don't, or to differentiate packets belonging to different
RSVP Sessions while they are in the tunnel, because no distinguishing
information such as a UDP port is available in the encapsulation.
This document describes an IP tunneling enhancement mechanism that
allows RSVP to make reservations across all IP-in-IP tunnels. This
mechanism is capable of supporting both type 2 and type 3 tunnels, as
described above, and requires minimal changes to both RSVP and other
parts of the integrated services framework.
2. The Design
2.1. Design Goals
Our design choices are motivated by several goals.
* Co-existing with most, if not all, current IP-in-IP tunneling
schemes.
* Limiting the changes to the RSVP spec to the minimum possible.
* Limiting the necessary changes to only the two end points of a
tunnel. This requirement leads to simpler deployment, lower
overhead in the intermediate routers, and less chance of failure
when the set of intermediate routers is modified due to routing
changes.
* Supporting correct inter-operation with RSVP routers that have
not been upgraded to handle RSVP over tunnels and with non-RSVP
tunnel endpoint routers. In these cases, the tunnel behaves as a
non-RSVP link.
Terzis, et al. Standards Track [Page 3]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
2.2. Basic Approach
The basic idea of the method described in this document is to
recursively apply RSVP over the tunnel portion of the path. In this
new session, the tunnel entry point Rentry sends PATH messages and
the tunnel exit point Rexit sends RESV messages to reserve resources
for the end-to-end sessions over the tunnel.
We discuss next two different aspects of the design: how to enhance
an IP-in-IP tunnel with RSVP capability, and how to map end-to-end
RSVP sessions to a tunnel session.
2.2.1. Design Decisions
To establish a RSVP reservation over a unicast IP-in-IP tunnel, we
made the following design decisions:
One or more Fixed-Filter style unicast reservations between the two
end points of the tunnel will be used to reserve resources for
packets traversing the tunnel. In the type 2 case, these reservations
will be configured statically by a management interface. In the type
3 case, these reservations will be created and torn down on demand,
as end-to-end reservation requests come and go.
Packets that do not require reservations are encapsulated in the
normal way, e. g. being wrapped with an IP header only, specifying
the tunnel entry point as source and the exit point as destination.
Data packets that require resource reservations within a tunnel must
have some attribute other than the IP addresses visible to the
intermediate routers, so that the routers may map the packet to an
appropriate reservation. To allow intermediate routers to use
standard RSVP filterspec handling, we choose to encapsulate such data
packets by prepending an IP and a UDP header, and to use UDP port
numbers to distinguish packets of different RSVP sessions. The
protocol number in the outer IP header in this case will be UDP.
Figure 1 shows RSVP operating over a tunnel. Rentry is the tunnel
entry router which encapsulates data into the tunnel. Some number of
intermediate routers forward the data across the network based upon
the encapsulating IP header added by Rentry. Rexit is the endpoint
of the tunnel. It decapsulates the data and forwards it based upon
the original, "inner" IP header.
Terzis, et al. Standards Track [Page 4]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
........... ............... .............
: _______ : : _____ :
: | | : : | | :
Intranet :--| Rentry|===================|Rexit|___:Intranet
: |_______| : : |_____| :
..........: : Internet : :...........
:..............
|___________________|
Figure 1. An example IP Tunnel
2.2.2. Mapping between End-to-End and Tunnel Sessions
Figure 2 shows a simple topology with a tunnel and a few hosts. The
sending hosts H1 and H3 may be one or multiple IP hops away from
Rentry; the receiving hosts H2 and H4 may also be either one or
multiple IP hops away from Rexit.
H1 H2
: :
: :
+--------+ +---+ +---+ +---+ +-------+
| | | | | | | | | |
H3... | Rentry |===================================| Rexit |..... H4
| | | | | | | | | |
+--------+ +---+ +---+ +---+ +-------+
Figure 2: An example end-to-end path with
a tunnel in the middle.
An RSVP session may be in place between endpoints at hosts H1 and H2.
We refer to this session as the "end-to-end" (E2E for short) or
"original" session, and to its PATH and RESV messages as the end-to-
end messages. One or more RSVP sessions may be in place between
Rentry and Rexit to provide resource reservation over the tunnel. We
refer to these as the tunnel RSVP sessions, and to their PATH and
RESV messages as the tunnel or tunneling messages. A tunnel RSVP
session may exist independently from any end-to-end sessions. For
example through network management interface one may create a RSVP
session over the tunnel to provide QoS support for data flow from H3
to H4, although there is no end-to-end RSVP session between H3 and
H4.
When an end-to-end RSVP session crosses a RSVP-capable tunnel, there
are two cases to consider in designing mechanisms to support an end-
to-end reservation over the tunnel: mapping the E2E session to an
existing tunnel RSVP session (type 2 tunnel), and dynamically
creating a new tunnel RSVP session for each end-to-end session (type
Terzis, et al. Standards Track [Page 5]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
3 tunnel). In either case, the picture looks like a recursive
application of RSVP. The tunnel RSVP session views the two tunnel
endpoints as two end hosts with a unicast Fixed-Filter style
reservation in between. The original, end-to-end RSVP session views
the tunnel as a single (logical) link on the path between the
source(s) and destination(s).
Note that in practice a tunnel may combine type 2 and type 3
characteristics. Some end-to-end RSVP sessions may trigger the
creation of new tunnel sessions, while others may be mapped into an
existing tunnel RSVP session. The choice of how an end-to-end session
is treated at the tunnel is a matter of local policy.
When an end-to-end RSVP session crosses a RSVP-capable tunnel, it is
necessary to coordinate the actions of the two RSVP sessions, to
determine whether or when the tunnel RSVP session should be created
and torn down, and to correctly transfer error and ADSPEC information
between the two RSVP sessions. We made the following design
decision:
* End-to-end RSVP control messages being forwarded through a
tunnel are encapsulated in the same way as normal IP packets,
e.g. being wrapped with the tunnel IP header only, specifying
the tunnel entry point as source and the exit point as
destination.
2.3. Major Issues
As IP-in-IP tunnels are being used more widely for network traffic
management purposes, it is clear we must support type 2 tunnels
(tunnel reservation for aggregate end-to-end sessions). Furthermore,
these type 2 tunnels should allow more than one (configurable,
static) reservation to be used at once, to support different traffic
classes within the tunnel. Whether it is necessary to support type 3
tunnels (dynamic per end-to-end session tunnel reservation) is a
policy issue that should be left open. Our design supports both
cases.
If there is only one RSVP session configured over a tunnel, then all
the end-to-end RSVP sessions (that are allowed to use this tunnel
session) will be bound to this configured tunnel session. However
when more than one RSVP session is in use over an IP tunnel, a second
design issue is how the association, or binding, between an original
RSVP reservation and a tunnel reservation is created and conveyed
from one end of the tunnel to the other. The entry router Rentry and
the exit router Rexit must agree on these associations so that
Terzis, et al. Standards Track [Page 6]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
changes in the original reservation state can be correctly mapped
into changes in the tunnel reservation state, and that errors
reported by intermediate routers to the tunnel end points can be
correctly transformed into errors reported by the tunnel endpoints to
the end-to-end RSVP session.
We require that this same association mechanism work for both the
case of bundled reservation over a tunnel (type 2 tunnel), and the
case of one-to-one mapping between original and tunnel reservations
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -