📄 rfc2746.txt
字号:
(type 3 tunnel). In our scheme the association is created when a
tunnel entry point first sees an end-to-end session's RESV message
and either sets up a new tunnel session, or adds to an existing
tunnel session. This new association must be conveyed to Rexit, so
that Rexit can reserve resources for the end-to-end sessions inside
the tunnel. This information includes the identifier and certain
parameters of the tunnel session, and the identifier of the end-to-
end session to which the tunnel session is being bound. In our
scheme, all RSVP sessions between the same two routers Rentry and
Rexit will have identical values for source IP address, destination
IP address, and destination UDP port number. An individual session is
identified primarily by the source port value.
We identified three possible choices for a binding mechanism:
1. Define a new RSVP message that is exchanged only between two
tunnel end points to convey the binding information.
2. Define a new RSVP object to be attached to end-to-end PATH
messages at Rentry, associating the end-to-end session with one
of the tunnel sessions. This new object is interpreted by Rexit
associating the end-to-end session with one of the tunnel
sessions generated at Rentry.
3. Apply the same UDP encapsulation to the end-to-end PATH
messages as to data packets of the session. When Rexit
decapsulates the PATH message, it deduces the relation between
the source UDP port used in the encapsulation and the RSVP
session that is specified in the original PATH message.
Terzis, et al. Standards Track [Page 7]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
The last approach above does not require any new design. However it
requires additional resources to be reserved for PATH messages (since
they are now subject to the tunnel reservation). It also requires a
priori knowledge of whether Rexit supports RSVP over tunnels by UDP
encapsulation. If Rentry encapsulates all the end-to-end PATH
messages with the UDP encapsulation, but Rexit does not understand
this encapsulation, then the encapsulated PATH messages will be lost
at Rexit.
On the other hand, options (1) and (2) can handle this case
transparently. They allow Rexit to pass on end-to-end PATHs received
via the tunnel (because they are decapsulated normally), while
throwing away the tunnel PATHs, all without any additional
configuration. We chose Option (2) because it is simpler. We
describe this object in the following section.
Packet exchanges must follow the following constraints:
1. Rentry encapsulates and sends end-to-end PATH messages over the
tunnel to Rexit where they get decapsulated and forwarded
downstream.
2. When a corresponding end-to-end RESV message arrives at Rexit,
Rexit encapsulates it and sends it to Rentry.
3. Based on some or all of the information in the end-to-end PATH
messages, the flowspec in the end-to-end RESV message and local
policies, Rentry decides if and how to map the end-to-end
session to a tunnel session.
4. If the end-to-end session should be mapped to a tunnel session,
Rentry either sends a PATH message for a new tunnel session or
updates an existing one.
5. Rentry sends a E2E Path containing a SESSION_ASSOC object
associating the end-to-end session with the tunnel session
above. Rexit records the association and removes the object
before forwarding the Path message further.
6. Rexit responds to the tunnel PATH message by sending a tunnel
RESV message, reserving resources inside the tunnel.
7. Rentry UDP-encapsulates arriving packets only if a
corresponding tunnel session reservation is actually in place
for the packets.
Terzis, et al. Standards Track [Page 8]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
2.3.1. SESSION_ASSOC Object
The new object, called SESSION_ASSOC, is defined with the following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SESSION object (for the end-to-end session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender FILTER-SPEC (for the tunnel session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION_ASSOC Object
Length
This field contains the size of the SESSION_ASSOC object in bytes.
Class
Should be 192.
Ctype
Should be sent as zero and ignored on receipt.
SESSION object
The end-to-end SESSION contained in the object is to be mapped to
the tunnel session described by the Sender FILTER-SPEC defined
below.
Sender FILTER-SPEC
This is the tunnel session that the above mentioned end-to-end
session maps to over the tunnel. As we mentioned above, a tunnel
session is identified primarily by source port. This is why we use
a Sender Filter-Spec for the tunnel session, in the place of a
SESSION object.
Terzis, et al. Standards Track [Page 9]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
2.3.2. NODE_CHAR Object
There has to be a way (other than through configuration) for Rexit to
communicate to Rentry the fact that it is a tunnel endpoint
supporting the scheme described in this document. We have defined for
this reason a new object, called NODE_CHAR, carrying this
information. If a node receives this object but does not understand
it, it should drop it without producing any error report. Objects
with Class-Num = 10bbbbbb (`b' represents a bit), as defined in the
RSVP specification [RFC2205], have the characteristics we need. While
for now this object only carries one bit of information, it can be
used in the future to describe other characteristics of an RSVP
capable node that are not part of the original RSVP specification.
The object NODE_CHAR has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
This field contains the size of the NODE_CHAR object in bytes. It
should be set to eight.
Class
An appropriate value should be assigned by the IANA. We propose
this value to be 128.
Ctype
Should be sent as zero and ignored on receipt.
T bit
This bit shows that the node is a RSVP-tunnel capable node.
When Rexit receives an end-to-end reservation, it appends a NODE_CHAR
object with the T bit set, to the RESV object, it encapsulates it and
sends it to Rentry. When Rentry receives this RESV message it deduces
that Rexit implements the mechanism described here and so it creates
or adjusts a tunnel session and associates the tunnel session to the
end-to-end session via a SESSION_ASSOC object. Rentry should remove
the NODE_CHAR object, before forwarding the RESV message upstream. If
Terzis, et al. Standards Track [Page 10]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
on the other hand, Rentry does not support the RSVP Tunnels mechanism
it would simply ignore the NODE_CHAR object and not forward it
further upstream.
3. Implementation
In this section we discuss several cases separately, starting from
the simplest scenario and moving to the more complex ones.
3.1. Single Configured RSVP Session over an IP-in-IP Tunnel
Treating the two tunnel endpoints as a source and destination host,
one easily sets up a FF-style reservation in between. Now the
question is what kind of filterspec to use for the tunnel
reservation, which directly relates to how packets get encapsulated
over the tunnel. We discuss two cases below.
3.1.1. In the Absence of End-to-End RSVP Session
In the case where all the packets traversing a tunnel use the
reserved resources, the current IP-in-IP encapsulation could be used.
The RSVP session over the tunnel would simply specify a FF style
reservation (with zero port number) with Rentry as the source address
and Rexit as the destination address.
However if only some of the packets traversing the tunnel should
benefit from the reservation, we must encapsulate the qualified
packets in IP and UDP. This allows intermediate routers to use
standard RSVP filterspec handling, without having to know about the
existence of tunnels.
Rather than supporting both cases we choose to simplify
implementations by requiring all data packets using reservations to
be encapsulated with an outer IP and UDP header. This reduces special
case checking and handling.
3.1.2. In the Presence of End-to-End RSVP Session(s)
According to the tunnel control policies, installed through some
management interface, some or all end-to-end RSVP sessions may be
allowed to map to the single RSVP session over the tunnel. In this
case there is no need to provide dynamic binding information between
end-to-end sessions and the tunnel session, given that the tunnel
session is unique and pre-configured, and therefore well-known.
Binding multiple end-to-end sessions to one tunnel session, however,
raises a new question of when and how the size of the tunnel
reservation should be adjusted to accommodate the end-to-end sessions
Terzis, et al. Standards Track [Page 11]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
mapped onto it. Again the tunnel manager makes such policy decision.
Several scenarios are possible. In the first, the tunnel reservation
is never adjusted. This makes the tunnel the rough equivalent of a
fixed-capacity hardware link. In the second, the tunnel reservation
is adjusted whenever a new end-to-end reservation arrives or an old
one is torn down. In the third, the tunnel reservation is adjusted
upwards or downwards occasionally, whenever the end-to-end
reservation level has changed enough to warrant the adjustment. This
trades off extra resource usage in the tunnel for reduced control
traffic and overhead.
We call a tunnel whose reservation cannot be adjusted a "hard pipe",
as opposed to a "soft pipe" where the amount of resources allocated
is adjustable. Section 5.2 explains how the adjustment can be carried
out for soft pipes.
3.2. Multiple Configured RSVP Sessions over an IP-in-IP Tunnel
It is straightforward to build on the case of a single configured
RSVP session over a tunnel by setting up multiple FF-style
reservations between the two tunnel endpoints using a management
interface. In this case Rentry must carefully encapsulate data
packets with the proper UDP port numbers, so that packets belonging
to different tunnel sessions will be distinguished by the
intermediate RSVP routers. Note that this case and the one described
before describe what we call type 2 tunnels.
3.2.1. In the Absence of End-to-End RSVP Session
Nothing more needs to be said in this case. Rentry classifies the
packets and encapsulates them accordingly. Packets with no
reservations are encapsulated with an outer IP header only, while
packets qualified for reservations are encapsulated with a UDP header
as well as an IP header. The UDP source port value should be properly
set to map to the corresponding tunnel reservation the packet is
supposed to use.
3.2.2. In the Presence of End-to-End RSVP Session(s)
Since in this case, there is more than one RSVP session operating
over the tunnel, one must explicitly bind each end-to-end RSVP
session to its corresponding tunnel session. As discussed
previously, this binding will be provided by the new SESSION_ASSOC
object carried by the end-to-end PATH messages.
Terzis, et al. Standards Track [Page 12]
RFC 2746 RSVP Operation Over IP Tunnels January 2000
3.3. Dynamically Created Tunnel RSVP Sessions
This is the case of a type 3 tunnel. The only differences between
this case and that of Section 4.2 are that:
- The tunnel session is created when a new end-to-end session
shows up.
- There is a one-to-one mapping between the end-to-end and tunnel
RSVP sessions, as opposed to possibly many-to-one mapping that
is allowed in the case described in Section 4.2.
4. RSVP Messages handling over an IP-in-IP Tunnel
4.1. RSVP Messages for Configured Session(s) Over A Tunnel
Here one or more RSVP sessions are set up over a tunnel through a
management interface. The session reservation parameters never
change for a "hard pipe" tunnel. The reservation parameters may
change for a "soft pipe" tunnel. Tunnel session PATH messages
generated by Rentry are addressed to Rexit, where they are processed
and deleted.
4.2. Handling of RSVP Messages at Tunnel Endpoints
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -