Network Working Group J. Manner
Internet-Draft University of Helsinki
Intended status: Standards Track October 16, 2006
Expires: April 19, 2007
Localized RSVP for Controlling RSVP Proxies
draft-manner-tsvwg-rsvp-proxy-sig-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Manner Expires April 19, 2007 [Page 1]
Internet-Draft LRSVP October 2006
Abstract
This draft specifies a mechanism for explicit control of RSVP
proxies. The scheme is based on one bit and two new RSVP messages,
and allows triggering both RSVP Sender and Receiver proxies.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RSVP Proxy Signaling . . . . . . . . . . . . . . . . . . . . . 4
2.1. RSVP Receiver Proxy Operation . . . . . . . . . . . . . . 4
2.2. RSVP Sender Proxy Operation . . . . . . . . . . . . . . . 5
2.3. Additional functionality . . . . . . . . . . . . . . . . . 7
2.4. Addressing Issues . . . . . . . . . . . . . . . . . . . . 7
3. Interworking Issues . . . . . . . . . . . . . . . . . . . . . 8
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Manner Expires April 19, 2007 [Page 2]
Internet-Draft LRSVP October 2006
1. Introduction
The usual signaling model of RSVP [RFC2205] includes the data sender
and receiver, and a network of RSVP routers. The data sender
initiates the RSVP signaling by sending the Path message. This
message is routed through the network, setting states in RSVP
routers, and finally arriving at the data receiver. The receiver
then responds to the signaling by sending the Resv message, which
applies the reservation for the data stream.
If the data receiver is not RSVP-aware, it can not respond to the
signaling and make the resource reservation happen. Similarly, if
the receiver is RSVP-aware, but the sender is not, the sender can not
initiate the signaling for the resource reservation.
RSVP proxies for data senders and receivers have been shown to be a
good idea [I-D.lefaucheur-tsvwg-rsvp-proxy]. These proxies can be
triggered to run a sender or receiver proxy operation either through
implicit mechanisms, such as, traffic filters, or by an explicit
signaling protocol. This draft presents an extension to RSVP that
provides explicit requests to RSVP proxies to operate proxy
functionality for given flows. Essentially, the mechanism in this
draft enables the Path-Triggered Receiver Proxy and the Path-
Triggered Sender Proxy for Reverse Direction
[I-D.lefaucheur-tsvwg-rsvp-proxy]. The mechanism is flexible and can
be used along standard end-to-end signaling sessions.
Manner Expires April 19, 2007 [Page 3]
Internet-Draft LRSVP October 2006
2. RSVP Proxy Signaling
In this specification, we assume a model where an end host triggers
the RSVP proxy to operate either a sender or receiver proxy. Yet, it
is possible to trigger the RSVP proxies from an off-path node. An
RSVP proxy can be located anywhere on the path between data sender
and receiver. In order to distinguish reservations targeted to the
proxy from end-to-end reservations, we use one bit in the unused
Flags field in the RSVP Session Object. The Proxy bit (P-bit)
(currently we use bit 0x8) is used to differentiate reservations that
are proxied. When the bit is set the RSVP message is part of a
proxied resource signaling and the RSVP router running the proxy will
operate as the end point of the signaling session. A default value
of zero indicates standard end-to-end signaling, where the RSVP proxy
is not concerned. In this case, the RSVP proxy only operates as a
standard RSVP router.
The RSVP Proxy node discussed in this draft is an enhanced RSVP
router. Fully standard RSVP messages are processed as the RSVP
standards describe. Only when the Proxy bit is set in RSVP messages,
the RSVP router includes the proxy functions. One implementation
option is to run the proxy application as a local client on top of
the RSVP stack; all RSVP messages that have the Proxy bit set are
provide through an upcall to the local proxy application. Thus, all
proxy functions are handled in a separate application process.
Note that this specification does not support a concept of nested
proxies, where the data path between sender and receiver includes
several proxies. The proxy RSVP signaling session discussed in this
draft terminates at the first proxy encountered on the data path.
Still, it is possible for two communicating nodes to run their own
RSVP proxies, thus, both end points would be communicating with their
own domain RSVP proxies.
In addition, we present two new messages, a Path Request and a Path
Request Tear. Due to the new bit and message types, all RSVP routers
within the proxied region must be upgraded to understand the RSVP
proxy signaling. The operation of our scheme is presented below.
2.1. RSVP Receiver Proxy Operation
When an end host wants to trigger an RSVP receiver proxy, it sends a
Path message as usuall, but sets the Proxy bit (Figure 1). The
Session Object of the message defines the destination of the flow
that will eventually be transmitted from the local end host, and the
Sender Template provides information about the local end host itself.
When the RSVP proxy eventually gets the Path message, it notes the
Proxy bit is set, and replies back to the end host with a Resv. A
Manner Expires April 19, 2007 [Page 4]
Internet-Draft LRSVP October 2006
Path is not sent further towards the data receiver. When a Resv
message arrives at the end host, the resources for the session
defined in the Path message have been allocated.
[Data]
[END HOST] [RSVP ROUTER] [RSVP ROUTER] [PROXY] ... [receiver]
| | | | |
|----- Path -> data receiver (P-bit = 1) ----->| |
| | | | |
| | | (proxy |
| | | intercepts) |
| | | | |
| | |<- Resv (P=1)--| |
| |<- Resv (P=1)--| | |
|<- Resv (P=1)-| | | |
| | | | |
Figure 1: RSVP Receiver Proxy operation
2.2. RSVP Sender Proxy Operation
Before triggering an RSVP sender proxy, the end host needs to be
aware of the data senders for which proxy operation will be
requested. For multimedia communications, a session is usually
initiated with application layer protocols like SIP [RFC3261] or RTSP
[RFC2326]. Based on this correspondence, the end host knows the
necessary information about the sender. Another, more coarse
reservation could be set, for example, for browsing different audio
servers; the end host would indicate in the RSVP messages that the
sender will use UDP. It is, therefore, possible to make resource
reservations for any sender that wants to communicate with the end
host. However, in order to allow for more accurate QoS support, more
information should be given. The way to find this information is out
of scope of this document, this is discussed in more detail in
[I-D.lefaucheur-tsvwg-rsvp-proxy].
When an end host wants to make a resource reservation for an incoming
flow, i.e., trigger RSVP sender proxy operation, it needs a mechanism
to trigger the proxy to send a Path message towards the end host.
This signaling mechanism can be implemented with a number of
different mechanisms. In our scheme, the end host sends a new
message called Path Request towards the data source, or to an
indicated RSVP proxy (addressing issues are discussed later in this
document). This message instructs the RSVP proxy to send a Path
message towards the end host (Figure 2). The end host can then reply
with a Resv, and set up a reservation on behalf of a data sender.
All these messages carry the Proxy bit in order to distinguish the
Manner Expires April 19, 2007 [Page 5]
Internet-Draft LRSVP October 2006
messages from standard end-to-end sessions.
[Data]
[END HOST] [RSVP Router] [X-OVER ROUTER] [PROXY] ... [sender]
| | | | |
|--- Path Request -> Data sender (P-bit=1) --->| |
| | | | |
| | | (proxy |
| | | intercepts ) |
| | | | |
| | |<- Path (P=1)--| |
| |<- Path (P=1) -| | |
|<- Path (P=1)-| | | |
| | | | |
|- Resv (P=1)->| | | |
| |-- Resv (P=1)->| | |
| | |-- Resv (P=1)->| |
| | | | |
Figure 2: RSVP Sender Proxy operation
The Path Request message is essentially identical to a standard Path
message apart from the message type field. The Session Object must
include information about the recipient, the local end host in this
case, and the Sender Template must define the expected sender(s).
The Traffic specification (Tspec) can either be based on the end
user's wishes, a best estimate of the incoming traffic
characteristics, or on application level session signaling prior to
the transfer.
The Path Request message can also be used end-to-end, to request the
correspondent node to initiate a resource reservation. In this case,
the Proxy bit must not be set, since it would stop the message at the
edge of a proxied domain.
There is one concern related to the Sender Proxy signaling, namely
the case of asymmetric routing, and reverse routing. When the end
host sends the Path Request towards a data sender, a RSVP Sender
Proxy will reply to the signaling. Yet, due to the nature of IP
routing, the data coming from the data sender may not arrive through
the RSVP Sender Proxy, and through the path where the reservation is
set up. This case is more probable the further away the data sender
is from the RSVP Sender Proxy. Ultimately, the data receiver sending
the Path Request should be able to run a reverse-routing scheme to
find out the routing path of the incoming data stream, or some other
scheme to find out the proper RSVP Sender Proxy to trigger.
Manner Expires April 19, 2007 [Page 6]
Internet-Draft LRSVP October 2006
2.3. Additional functionality
All the other features of RSVP are used in the standard way including
the local repair mechanism and reservation tear down. Reservations
from a RSVP Sender Proxy are torn down with the Path Request Tear
message. The operation follows that of the Path Request: the message
does not change states within the network, but only triggers the
proxy to send a Path Tear message towards the end host for the
specified session.
All messages used for the proxied reservation session must have the
Proxy bit set in order to distinguish the session from standard end-
to-end sessions. Intermediate RSVP routers between the end host and
the RSVP proxy should not process the Path Request message and they
should forward it as an ordinary IP packet.
2.4. Addressing Issues
When an end host sends Path or Path Request messages, it needs to use
some IP address as the destination in the IP header. There are
various options which address the local end host can or can not use.
The end host must use in priority order (if known):
1. The address of the correspondent host,
2. The address of a designated RSVP proxy,
3. The address of the next-hop RSVP router, or
4. The address of the default router.
The first option may not be possible, if the end host wants to
allocate resources only for certain services regardless of the
sender, HTTP, for example. The second possible address could be
given through auto-configuration. The third option would be to send
the IP packet to the next-hop RSVP router, if the end host has
knowledge of it - ideally, this would be the default router. The
final option would be to send the RSVP packet to the default router,
and see if the router is also running an RSVP daemon and could handle
the reservation attempt. If the default router is not running an
RSVP daemon, it will return an ICMP error message.
Manner Expires April 19, 2007 [Page 7]
Internet-Draft LRSVP October 2006
3. Interworking Issues
The proposed scheme makes use of one bit in the Session Object and
adds two new message types. There can be situations where such a
currently non-standard message arrives at a standard RSVP router.
According to the message processing rules in RFC2209 [RFC2209], the
Path Request and Path Request Tear messages would be forwarded intact
by standard RSVP routers. However, for standard RSVP message, the
Proxy bit may or may not be kept between RSVP hops, and, thus, the
indication of proxy signaling may be lost. Therefore, all RSVP
routers between the end host the RSVP proxy must be set to keep the
bits intact.
The network of the end host may not understand the proxy extension or
even standard RSVP. Thus, Path messages with the Proxy bit and Path
Request message can be routed out of the local network. If the
domain of the correspondent node has support for the proxy mode, that
network RSVP proxy gets the Path or Path Request message with the
Proxy bit set from possibly a wrong network interface. The proxy
must drop the message and respond with a PathErr message and a new
error code called "LRSVP not supported". This would inform the host
that RSVP proxy mode is not supported and it still can try end-to-end
signaling.
If the recipients network does not either support the RSVP proxies,
an end host will receive the proxy mode RSVP message. If the end
host supports the RSVP proxy operation, it can operate as follows:
o If an end host receives a Path message with the Proxy bit set, it
should respond with a Resv message and not set the Proxy bit. The
reason is that that if the RSVP proxies drop Path messages with
the Proxy bit set coming from seemingly erroneous networks, end
hosts can trust that if they receive such a message, it must have
(if the network is properly configured) arrived from the
corresponding and RSVP-capable end host. Now, if our end host
that sent the Path message receives the Resv without the Proxy
bit, it can use this as an indication that the correspondent node
is RSVP-aware and may remove the Proxy bit in subsequent messages
belonging to the same session.
o Similarly, if the correspondent node receives a Path Request
message, it should respond with a Path message that does not have
the Proxy bit set. Again, if our end host receives a Path message
without the Proxy bit set in response to the proxy mode Path
Request sent earlier, it can use this as an indication that the
correspondent node is RSVP-aware and it should remove the Proxy
bit in subsequent messages belonging to the same session.
Manner Expires April 19, 2007 [Page 8]
Internet-Draft LRSVP October 2006
4. Summary
In summary, the Localized RSVP requires the following changes in the
standard RSVP protocol:
1. A new message type and number, named Path Request (initially
number 8).
2. A new message type and number, named Path Request Tear (initially
number 9).
3. A bit from the Session Object for the use as the Proxy bit
(P-bit) (initially bit 0x8).
4. An RSVP router must keep the Proxy bit set in all messages
belonging to that session, if it encounters packets with the bit
set.
5. An RSVP router that is not also a proxy, must forward an RSVP
packet with a message type "Path Request" without storing state.
6. An RSVP router that is not also a proxy, must forward an RSVP
packet with a message type "Path Request Tear" without affecting
the stored state.
7. A new error code to indicate that the access network does not
support local reservations. If local resources cannot be
requested, the end-host can always try to do end-to-end
signaling.
Manner Expires April 19, 2007 [Page 9]
Internet-Draft LRSVP October 2006
5. Security Considerations
The Path Request message triggers most processing at the RSVP Sender
proxy. This could potentially be used for Denial of Service attacks.
A typical security check in RSVP is for a RSVP router connected to
end hosts verify that the session is truly for the end host in
question. This has the benefit that the RSVP proxy may trust that
the previous RSVP routers have validated the message; this can be
seen as distributed processing of the authentication and
authorization data. The same considerations apply for the Path
message.
The RSVP daemon at the end hosts and the proxy must also modify their
security/sanity checks to allow the end host to send the Path Request
with apparently suspicious session information (identifying the
correspondent node(s)). Also, the RSVP Sender proxy must be able to
send RSVP messages on-behalf of external network nodes.
The RSVP proxy must be configured to identify the interfaces from
where proxy mode messages are supported. If the proxy receives a
Path or a Path Request message with the Proxy bit set from an
erroneous interface, it must drop the message.
The two new messages can make use of the standard RSVP INTEGRITY and
POLICY objects. For the remaining functionality, the security
considerations with standard RSVP apply [RFC4230].
Manner Expires April 19, 2007 [Page 10]
Internet-Draft LRSVP October 2006
6. IANA Considerations
IANA needs to allocate one flag bit in the RSVP Session Object, the
Proxy bit. In addition, IANA needs to give two RSVP message type
numbers to the Path Request and Path Request Tear messages and one
Error Type indicating that a proxy resource reservation is not
allowed.
Manner Expires April 19, 2007 [Page 11]
Internet-Draft LRSVP October 2006
7. References
7.1. Normative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC 2209,
September 1997.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005.
7.2. Informative References
[I-D.lefaucheur-tsvwg-rsvp-proxy]
Le Faucheur, F., Manner, J., and D. Wing, "RSVP Proxy
Approaches", October 2006.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Manner Expires April 19, 2007 [Page 12]
Internet-Draft LRSVP October 2006
Author's Address
Jukka Manner
University of Helsinki
P.O. Box 68
University of Helsinki FIN-00014 University of Helsinki
Finland
Phone: +358 9 191 51298
Email: jmanner@cs.helsinki.fi
URI: http://www.cs.helsinki.fi/u/jmanner/
Manner Expires April 19, 2007 [Page 13]
Internet-Draft LRSVP October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Manner Expires April 19, 2007 [Page 14]