Internet DRAFT - draft-brunner-nsis-rsvp2
draft-brunner-nsis-rsvp2
M. Brunner
Internet Draft R. Greco
Document: draft-brunner-nsis-rsvp2-00.txt NEC
Expires: March 2003 October 2002
Towards RSVP Version 2
<draft-brunner-nsis-rsvp2-00.txt>
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.
Abstract
This memo is a first step towards the design of RSVP Version 2. We
take RSVP Version 1 as a basis of this work. RSVP has been criticized
mainly because of its complexity and poor scalability among others.
We present the first steps towards the definition of a new version of
RSVP. The goal is to provide a more "light" approach that can help
improve handling reservations in the network by means of a simplified
behavior.
This proposal for RSVP Version 2 is not meant as a complete
replacement of RSVP Version 1 but is meant to coexist with Version 1.
For some scenarios such as receiver orientation and multicasting we
assume that RSVP version 1 works fine.
1. Introduction
A key to the success in the provision of QoS over the Internet is the
ability to schedule resources along the communications paths
according to the reservations issued by users. As a result of
reservation signaling, the nodes along the communications paths
Brunner,Greco - Expires March 2003 1
Towards RSVP Version 2 October 2002
should contain sufficient information to detect packets belonging to
specific data flows and be prepared to provide them with an adequate
quality of service.
Not only QoS needs signaling but different other applications should
get enabled such as signaling for MPLA label switched paths or for
firewall traversals [TIST][RSVP-TE].
Currently, the most widely used reservation protocol is RSVP. RSVP
has a large number of implementations in place and it has been
standardized by the IETF in September 1997. For these reasons, we
take RSVP as the basis of this work. However, since its
standardization, RSVP has been criticized mainly because of its
complexity and poor scalability. The protocol has been designed for
large multicast scenarios and for multicast applications such as the
distribution of audio and video contents over IP multicast, as it is
done with the MBONE [RFC 3170]. Although RSVP responds well to the
needs why it has been designed, it is felt to be too complex to be
used in many other scenarios, that are perhaps more restricted but
nevertheless useful for a wide range of applications.
This document presents the first steps towards the definition of a
new version of RSVP, which we call RSVPv2. The goal of RSVPv2 is to
provide a more "light" approach that can help improve handling
reservations in the network by means of a simplified behavior. In
particular, the new protocol should be able to be more efficient in
terms of reservations setup time. We also introduce into the protocol
a series of new mechanisms that extend it to make it able to handle
mobility. It is a first experiment to open up the road for
applications based on mobile IP that need an adequate provision of
quality of service. RSVPv2 is not intended to replace RSVP but, on
the contrary, to coexist with it in a dual stack architecture, so
that both reservation protocols are available to applications with
different needs.
In the rest of this document, we present in details a possible design
of RSVPv2, including the new features for mobility. The message
formats are a quick shot and must be refined in the future anyway.
2. Conventions used in this document
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.
3. Design Principles
3.1. Co-exist with RSVP Version 1
The proposal explicitly changes RSVP Version one such that it co-
exists with the implementation of version 1. It is not meant to re-
design the feature RSVP version 1 does in a nice way.
Brunner, Greco Expires March 2003 2
Towards RSVP Version 2 October 2002
Version 2 should run dual-stack together with version 1.
3.2. Small and efficient core protocol
The core protocol is small, simple and efficient. Only minimal
functionality is used in the core protocol. Everything, which might
not be used in some scenarios or environments is removed and should
get handled in the service specific part.
3.3. Service-specific extensibility
The service-specific part is freely extensible. Any type of service
request can be used. We assume some service types will get
standardized, others are Network provider specific, or vendor
specific.
3.4. Service Toolbox
Since still a set of functionality might be reused for several
service. We provide the mechanism to add common parts into the
service specification. The question then is only is the comman part
present or not. Examples of such common parts include security and
policy data for authentication and authorization.
4. General features
The main features of RSVPv2 have been designed by evaluating pros and
cons and trying to learn as much as possible from RSVP, other
protocols and from the critics moved to them.
4.1. Unicast
RSVPv2 has been thought as a unicast protocol. Even if we consider
multicast as an important feature of a signaling protocol, we
focused, as a first step in the protocol design, on simplicity and
a lightweight approach that can fit very well in many scenarios. We
think that multicast support can be regarded as an extension to be
added to the protocol. The idea is to have an underlying common
structure that can be specialised adding different functionalities
required by particular scenarios.
We even believe the proposed protocol works also for multicast,
however with homogeneous receivers and with only small groups.
4.2. Sender-Oriented
We propose a sender-oriented protocol. This approach has been chosen
considering that, in this way, the complexity of the protocol can be
reduced. In fact, the cost of sending advertisements, processing them
in each aware router along the path is eliminated, together with the
necessity of symmetric routing (from source to destination and vice
versa). Besides, the time to obtain a reservation decreases. This
Brunner, Greco Expires March 2003 3
Towards RSVP Version 2 October 2002
approach does not give the receiver the opportunity to choose or
change service-parameters.
However, from the experience with RSVP version 1, it has been seen
that in most of the cases the receiver will simply request whatever
traffic bandwidth the sender has indicated. The receiver-oriented
approach is helpful in multicast scenario where there is the need to
accommodate a large number of groups membership and heterogeneous
receiver requirements. As previously mentioned, RSVPv2 has been
thought for unicast scenarios and as a minimal protocol where
multicast support can be provided by RSVP version 1 running dual
stack with RSVPv2 or by extension of the protocol itself.
4.3. Soft State
RSVP version 1 is a Soft State protocol, which means that information
about the flows are temporary saved along the path. Soft state gives
adaptivity to route changes during the lifetime of a reservation and
increases the protocol robustness to loss of messages. Besides,
unexpected loss of connectivity from an end-point will simply lead to
timeout states after some time along the path. These characteristics
seem to be very important in every scenario where a signaling
protocol can be used.
Soft state, on the other hand, introduces the issue of refreshing the
information stored along the path. For RSVPv2, we propose to make the
end points of the reservation responsible for sending end-to-end
refresh messages and in particular the source. In this way, the
effort done by intermediate nodes is reduced to the forwarding of the
refresh message as opposite to issuing such messages upon expiration
of the correspondent soft state lifetime.
Besides, even if the soft state approach does not require the
existence of any mechanism for the explicit end (teardown) of a
reservation, this feature can be useful to avoid keeping resources
allocated when they are not needed any longer.
RSVPv2 supports the explicit end of a reservation coming from the
source that requested the reservation.
4.4. Reservation and Error notification
After sending a reservation request, it is desirable to receive an
answer about its result. RSVPv2 has been designed including a
reservation acknowledgement sent from the destination back to the
source in the case of a successful reservation. This acknowledgement
can be used by the source as an indication that the reservation has
been completed along the path. A source may decide whether to wait
for this acknowledgement or not before sending the data (optimistic
versus pessimistic behavior).
In the same way, it is desirable to receive information in case of
failure of a reservation in a node along the network. RSVPv2 sends an
error notification from the node where the reservation failed back to
Brunner, Greco Expires March 2003 4
Towards RSVP Version 2 October 2002
the source. This message may contain information on the state of the
resources at the node where the failure occurred and it can be used
by the source to perform a new reservation request with different
parameters. However, this information is very service specific, there
for the acknowledgment might contain service-specific information.
4.5. Modularity and Extensibility
The proposal is partly modular in the sense that two different layers
are used. The base signaling protocol and a service-specific part are
differentiated. The base signaling protocol is pretty monolithic
because it is optimized for speed. The service-specific part is very
open to any modularity and extensibility.
4.6. Service specification
RSVP version 1 can provide one of the following types of service:
Guaranteed Load and Controlled Load Services and defines the
according service specifications. RSVPv2 wants, on the other hand, to
be as general as possible as far as offering services is concerned.
The idea is that the protocol should be able to carry specifications
for a large number of services in order to be easily used in
different scenarios and not only for QoS.
4.7. Transport mechanism
For RSVPv2, all messages are sent as raw IP packets, following the
same approach used in version 1. The main motivation lies in the
architectural consideration that we want to have a network-level
signaling protocol. This basically excludes to use any transport
protocol.
4.8. Flow Identifier and Reservation Identifier
To keep things separate as much as possible, RSVPv2 uses different
information to identify a flow and a reservation. In other words,
each RSVP message carries a Reservation Identifier to address the
reservation and a Flow Identifier that allows matching data level
mechanisms with the reservation previously set.
Mobile IP scenarios and processing refresh messages profit of this
feature. The first because the source or destination address of the
same reservation might change; the second because searching for a
Reservation Identifier is fast than a N-tuple search.
4.9. Refreshing Reservations
As described before we propose to reuse the soft-state approach.
This implies the use of a refresh mechanism of information stored in
states.
In RSVPv2 refresh messages are generated from the endpoints and
refresh all the state for the reservation saved along the path.
Brunner, Greco Expires March 2003 5
Towards RSVP Version 2 October 2002
Refreshes happen through two different messages a reservation message
as well as through a refresh message. Sending a smaller refresh
message containing only the reservation id and the time value
optimizes for lower badwidth and faster message processing. Using the
refresh message approach, it is necessary to be aware that in case of
route change, there will not be any route adaptation.
A compromise need to be found between reducing the refresh period and
not increasing too much the overhead of the protocol. Reducing the
refresh interval mainly means:
-Quicker adaptability to the routing changes
-Increased robustness to message loss
-Increasing the protocol overhead
For these reasons, RSVPv2 leaves the application requiring the
reservation the freedom to choose the more appropriate time interval
for the refresh. The cost for signaling can be handled in a market
managed way.
4.10. Timers
The states need to be refreshed somehow. In order to keep the
protocol simple, the numbers of timers used is reduced to the
minimum. RSVP version 1 sets a timer for each state saved. This fact
adds complexity and increase scalability problems in the core network
due to the management of thousands of timers. The proposal for
RSVPv2 is to use just one timer for each RSVPv2 daemon. This timer
acts as a garbage collector periodically scanning the list of the
saved states and erasing all the timed out entries.
The time value carried by the reservation messages can be a default
value or the expected time an application needs that particular
service. Both solutions have pros and cons, but what is suggested is
that the first message should carry the default time (i.e. 30s as
suggested in RSVP version 1) because the reservation can fail before
the end point of the reservation is reached and the states already
set should timeout quickly. If the reservation is established, a
longer time should be carried.
With this solution, the synchronization of periodic refresh messages
stated in RSVPv1 is avoided.
5. Outline of the protocol
5.1. Overview
+--------------------------+
| Service-specific |
+--------------------------+
| Base RSVPv2 |
+--------------------------+
| IP |
+--------------------------+
Brunner, Greco Expires March 2003 6
Towards RSVP Version 2 October 2002
Figure: Layering
RSVPv2 as already Version 1 operates directly on top of IP. There is
a limited base signaling protocol, where service-specifics are placed
on top of the base protocol. In the base-protocol not much
extensibility, modularity, or different modes of operations are
included.
The base signaling protocol should be fast and provide very basic
functionality, whereas service specific parts are keeping a lot of
functionality used for the signaling for that particular service.
For instance, any policy data and security relevant data is kept in
the service-specific part, since this heavily depends on the
environment and situation the protocol is used.
However, we could imagine that the service-specific part does have
two layers as well. A common service toolbox containing anything
dealing with security and policy might be defined in order to have
unified mechanisms to be used by several services using RSVPv2.
5.2. Operation
The scenario (and we use a scenario for ease of understanding)
presented here consists of two end-systems placed in different part
of the network that want to request a reservation before transmitting
the data.
The goal of the protocol is to carry a service request from the data
source to the destination. This operation is carried out in two
steps. As a first step, the source sends a reservation (RESV) message
to the destination. If the message reaches the receiver, than an
acknowledgement (ACK) is sent back from the receiver to the source as
a confirmation of the reservation set up. If an error occurs along
the path, then, the RESV message is not further forwarded and an
error message (NACK) is returned back to the source. While processing
a RESV message, each aware router along the path saves state and sets
an appropriate reservation for the flow.
5.3. Basic Message Format
The basic format of a RSVPv2 message is represented in the following
Figure.
+------------------------+
| Common RSVPv2 Header |
+------------------------+
| Message-Type Specific |
+------------------------+
| Service-Specific |
+------------------------+
Figure 1: Basic message format
Brunner, Greco Expires March 2003 7
Towards RSVP Version 2 October 2002
The structure of RSVPv2 messages consists of a common part, a message
specific part, and a service specific part. The common part is
included in all the messages of different types. The message type-
specific part contains information common to all messages of that
particular type, and finally the service-specific part is open to
contain any service-specific information.
5.4. The Common Header
The common header is very similar to the header for RSVPv1.
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+
| Reservation Identifier |
+-------------+-------------+-------------+-------------+
The fields in the common header are as follows:
Vers: 4 bits
Protocol version number. This is version 2.
Flags: 4 bits
0x01 = No message processing until destination reached.
This flag is the equivalent to the usage of the router
alert option for RSVPv2 messages. It means that the
packet must not get handled in the daemon until it
reaches the IP destination address. But it also allows
the daemon to differentiate in-band versus out-of-band
signaling, if both runs on the same daemon.
0x02 = IPv6 addresses used
This means the flow identifier contains IPv6 adresses
0x04 = Trigger bi-directional reservation
It this bit is set a reservation in the reverse
direction is triggered. It doesnot mean the same path
through the network is used.
0x08 = for further study
Msg Type: 8 bits
2 = Resv
6 = ResvTear
8 = Refresh
Brunner, Greco Expires March 2003 8
Towards RSVP Version 2 October 2002
13 = Ack/Nack
RSVP Checksum: 16 bits
The one's complement of the one's complement sum of the
message, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value
means that no checksum was transmitted.
Send_TTL: 8 bits
The IP TTL value with which the message was sent.
RSVP Length: 16 bits
The total length of this RSVP message in bytes, including
the common header and the variable-length objects that
follow.
Reservation Identifier
The Reservation Identifier is a unique number identifying
the reservation independent of any flow or service
specification.
5.5. The Message-type Specific Fields
Reservation Message Specific Fields
+------------------------------------------+
| |
| |
| Flow Identifier |
| |
| |
+------------------------------------------+
| Time Value |
+------------------------------------------+
| Service Type |
+------------------------------------------+
Figure: Message-Type Specific Fields
A so-called Flow Identifier including the IP source and destination
address and the TCP/UDP source and the destination port numbers
represents each flow. We have chosen to keep a basic flow identifier
in the reservation message itself. The other place could have been
the service-specific part. Keeping it general help in certain
situation such as NAT traversal, where a NAT can replace the IP
addresses if they are NSIS aware. However, some services for example
QoS using DiffServ might specify coarser grained flows. So any type
of address masking or ranges of ports need to be carried in the
service-specific part.
Brunner, Greco Expires March 2003 9
Towards RSVP Version 2 October 2002
As previously pointed out, the soft state approach requires to set
and manage a number of timers for the RSVP state saved along the
path. In order to keep the protocol simple, we propose a solution
that reduces the number of timers simplifying its managing even if
the deallocation of timed out resources can be slightly penalized.
RSVP version 1 sets a timer for each state saved. This in fact adds
complexity and increases scalability problems in the core network due
to the management of these of timers. RSVPv2 uses just one timer for
each RSVP list of entries. This timer periodically scans the list of
the saved states and erases all the timed out entries.
In order to reduce the impact of refresh messages in the overhead of
the protocol, the initiating node responsible for the reservation
request, can specify, as a time value, the whole expected duration of
the data transmission without sending any refresh. In case of an
earlier end, an explicit tear down of the reservation can be
performed using an appropriate TearDown message (TEAR) included among
the protocol messages. The time value needs to be chosen according to
the expected route changes the signaling protocol needs to handle.
The Service Type field
+------------------------------------------+
| toolbox | service identifier |
+------------------------------------------+
The service type defines the kind of service requested. It is also
used in other messages referring to that service, such as the ACK and
refreshes. In order to allow for toolbox approach it is divided into
two parts. The service identifier and the tools used.
The values for the toolbox are
0x00: no toolbox functionality used.
0x01: security
0x02: policy
0x04 - 0x0X TBD
The following values for the service identifier are predefined:
0: unknown
1: RSVPv1 Controlled Load and Guaranteed Service. Contains the
FLOWSPEC defined according to [RFC 2210].
2-1023: reserved for standardized services [TBD IANA]
1024-X: IANA
X-Y: provider/domain specific
Refresh Message Specific Field
The refresh message only contains an additional field namely the time
value. The definition is exactly the same as for the reservation
message. It basically prolongs a reservation. The reservation is
identified by the reservation identifier field of the common header.
Brunner, Greco Expires March 2003 10
Towards RSVP Version 2 October 2002
+------------------------------------------+
| Time Value |
+------------------------------------------+
Acknowledge/Not Acknowledge message (ACK/NACK)
This ACK/NACK messages are used for feedback of the reservation
process. The functionality they offer is pretty basic, but it is
coherent with the whole protocol and its scope.
The ACK simply tells the sender of the reservation that complete
reservation process has been handled gracefully, the NACK tells the
opposite, namely an error occurred somewhere in the network. The type
of message is coded into the code field. Also different reasons for
failures can be given in the Reason field.
+------------------------------------------+
| Code | Reason |
+------------------------------------------+
| Service Type |
+------------------------------------------+
Codes:
0x00 : unknown
0x01 : ACK
0x02 : ACK hint
0x03 : Error (see below for error reasons)
...0x04 : Service-specific notification. The reason is then service-
specific and semantic depends on the service type.
Reason (if Code is set to 0x03)
0x00 : unknown, just does not work
0x01 : unavailable resources
0x02 : unknown service-type
0x03 : service not available anymore
.... TBD
In any case service-specific information can follow.
Teardown message
The tear down message does not have any additional parameters.
5.6. Service-Specific Information
Any service-specific information needs to be defined in a different
document and is out of scope of this document.
6. Security Considerations
7. References
Brunner, Greco Expires March 2003 11
Towards RSVP Version 2 October 2002
[NSIS-REQ] M. Brunner et al. "Requirements for Signaling Protocols",
draft-ietf-nsis-req-04.txt, September 2002.
[TIST] M. Shore, "The TIST (Topology-Insensitive Service Traversal)
Protocol", draft-shore-tist-prot-00.txt, May 2002.
[RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
8. Author's Addresses
Marcus Brunner, Rosella Greco
Network Laboratories, NEC Europe Ltd.
Adenauerplatz 6 D-69115 Heidelberg
Germany
Phone: +49 6221 905 110
Email: [brunner|greco]@ccrle.nec.de
9. Appendix: Protocol operations in some scenarios
9.1. Signaling of service between mobile hosts
The mobile scenario has to be analyzed separating two possible cases:
mobile sender and mobile receiver.
Mobile sender
In this case, RSVPv2 tries to increase the re-use of resources and
the probability to obtain a reservation while moving from one place
(IP address A) to another (IP address B).
Brunner, Greco Expires March 2003 12
Towards RSVP Version 2 October 2002
+----+
| MN \ Position B
+----+\\
\\
\ -------
\\ /// \\\
\\ | |
\| |
| | Router C
\\\ ///
-------
-- +-----+
---- | |
---- | | -------
--|- /|/ \\\
| --| | | +-----+
| /| | --| Recv|
|/ | | | +-----+
| \|\ ///
/| | -------
/ +-----+
/
------- /
/// \\\ /
| |/
--| |
-- | |
--- \\\ ///
-- -------
+----+ --
| MN -- Position A
+----+
Figure: Mobile Scenario
Referring to the above Figure, we assume that a mobile user starts a
reservation from its home site (A). The reservation is set through
the entire path till the destination according normal routing. The
Reservation Id identifies the reservation. When the mobile sender
moves to B (which can be everywhere and we are not making any
assumptions on that), it tries to set a new reservation from B. This
new reservation can be sent through a certain numbers of routers,
which are in common with the previous reservation.
The Reservation Id remains unchanged as the source moves. When a new
reservation request comes in a router where a reservation with the
same reservation Id already exists, the flow Id is modified to
reflect the change of the sender IP address and the same resources
allocated for the old reservation are reused. At the merging point
(C), a message is sent back to inform the source that, from there on,
the protocol tries to exploit the old reservation. (note that this is
a hint).
Brunner, Greco Expires March 2003 13
Towards RSVP Version 2 October 2002
Had no Reservation Id field be used by the protocol, as with RSVP
version 1, then the reservation from B would have been seen as
completely new because the sender has a different IP address.
Mobile receiver
If the mobile end-system is the receiver of the data, the following
approach is possible with RSVP version 2. Let us consider the above
Figure again, assuming that a receiver host located in zone A moves
to zone B.
The proposed solution is to use a tunnel between the home agent
located in A to the foreign agent located near location B and to make
a separate and independent reservation across the tunnel. When a
reservation request arrives at the home agent, this agent is
responsible for the creation of a new reservation to the foreign
agent and for forwarding signaling and data messages along the
tunnel.
The creation of the tunnel may introduce additional delay to the
delivery time, which means that mobile users can experience temporary
disruptions of QoS. Since tunnel management is separated from end to
end reservation, it is possible to make tunnel reservation in advance
or in a proprietary way limiting this service disruption.
9.2. Signaling between networks with centralized management of
resources
In a heterogeneous network as Internet is, there can be situations
where signaling should follow a different path from the one followed
by data. In specific, a possible scenario is a DiffServ network where
admission control and all the management of resource inside the
domain is done by a centralized management system often called
Bandwidth Broker (BB) or QoS Server.
In this case, when a RESV message arrives at the BB, it is processed
and resources are reserved in the appropriate routers according to
intra-domain decisions. At this point, a notification is sent back to
the ingress router to notify the result of the reservation inside the
domain. The message contains information necessary to set the routing
tables for the data flow or take the existing route into
consideration for admission control and reservation.
Benefits of this mechanism are that it allows an independent
management of resources inside a domain and it separates the data
from the signaling path.
Brunner, Greco Expires March 2003 14
