draft-ietf-tsvwg-rsvp-proxy-proto-05.txt   draft-ietf-tsvwg-rsvp-proxy-proto-06.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Manner Intended status: Standards Track J. Manner
Expires: October 27, 2008 University of Helsinki Expires: December 1, 2008 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf
H. Malik H. Malik
Bharti Neuf
April 25, 2008 May 30, 2008
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-05.txt draft-ietf-tsvwg-rsvp-proxy-proto-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 27, 2008. This Internet-Draft will expire on December 1, 2008.
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of flows. With conventional RSVP, both the data sender and receiver of
a given flow take part in RSVP signaling. Yet, there are many use a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
skipping to change at page 16, line 25 skipping to change at page 16, line 25
o allow the failure notification to be sent directly upstream to the o allow the failure notification to be sent directly upstream to the
sender by the router where the failure occurs (as opposed to first sender by the router where the failure occurs (as opposed to first
travelling downstream towards the Receiver Proxy and then travelling downstream towards the Receiver Proxy and then
travelling upstream from the Receiver Proxy to the sender, as travelling upstream from the Receiver Proxy to the sender, as
effectively happens with the method defined in Section 3.1) effectively happens with the method defined in Section 3.1)
o allow the failure notification to travel directly to the sender o allow the failure notification to travel directly to the sender
without hop-by-hop RSVP processing without hop-by-hop RSVP processing
o ensure that such a notification is only sent to senders which are o ensure that such a notification is sent to senders which are
capable and willing to process it (i.e. to synchronize reservation capable and willing to process it (i.e. to synchronize reservation
status with application) status with application)
o ensure that such a notification is only sent in case the receiver o ensure that such a notification is only sent in case the receiver
is not itself capable and willing to do the synchronisation with is not itself capable and willing to do the synchronisation with
the application (i.e. because we are in the presence of a receiver the application (i.e. because we are in the presence of a receiver
proxy so that RSVP signaling is not visible to the receiver). proxy so that RSVP signaling is not visible to the receiver).
Note, however, that such benefits come at the cost of : Note, however, that such benefits come at the cost of :
skipping to change at page 20, line 5 skipping to change at page 19, line 13
is RECOMMENDED that the RSVP Receiver Proxy also issues sender is RECOMMENDED that the RSVP Receiver Proxy also issues sender
notification via a PathErr message. This maximizes the chances that notification via a PathErr message. This maximizes the chances that
the notification reaches the sender in all situations (e.g. even if the notification reaches the sender in all situations (e.g. even if
some RSVP routers do not support the Notify procedure, or if a Notify some RSVP routers do not support the Notify procedure, or if a Notify
message gets dropped). However, for controlled environments (e.g. message gets dropped). However, for controlled environments (e.g.
where all RSVP routers are known to support Notify procedures) and where all RSVP routers are known to support Notify procedures) and
where it is desirable to minimize the volume of signaling, the RSVP where it is desirable to minimize the volume of signaling, the RSVP
Receiver Proxy MAY rely exclusively on sender notification via Notify Receiver Proxy MAY rely exclusively on sender notification via Notify
message and thus not issue sender notification via PathErr message. message and thus not issue sender notification via PathErr message.
In environments where there are both RSVP-capable receivers and RSVP
Receiver Proxies acting on behalf of non RSVP-capable receivers, a
sender does not know whether a given reservation is established with
an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a
sender that supports the procedures defined in this section may very
well include a Notify Request object in Path messages for a
reservation that happens to be controlled by an RSVP-capable
receiver. This document does not define, nor expect, any change in
existing receiver behavior. As a result, in this case, the sender
will actually not receive Notify messages conveying downstream
notifications. However, this is perfectly fine because the
synchronisation between the RSVP reservation state and the
application requirement can be performed by the actual receiver in
this case as per the regular end-to-end RSVP model, so that in this
case, the sender need not care about downstream notifications.
A sender that does not support the procedures defined in this section
could happen to include a Notify Request object in Path messages for
a reservation simply because it is interested in getting upstream
notifications faster. If the reservation happens to be controlled by
an RSVP Receiver Proxy supporting the procedures defined in this
section, the sender will then also receive unexpected Notify messages
containing downstream notifications. It is expected that such a
sender will simply naturally drop such downstream notifications as
invalid. Because it is RECOMMENDED above that the RSVP Receiver
Proxy also issues sender notification via a PathErr message even when
sender notification via Notify message is used, the sender will still
be notified of reservation failure in accordance with the "sender
notification via PathErr" method. In summary, activating the
OPTIONAL "sender notification via Notify" method on a Receiver Proxy,
does not prevent a sender that does not support this method, to rely
on the MANDATORY "sender notification via PathErr" method. It would,
however, allow a sender supporting the "sender notification via
Notify" method to take advantage of this OPTIONAL method.
4. Security Considerations 4. Security Considerations
To ensure the integrity of the associated reservation and admission To ensure the integrity of the associated reservation and admission
control mechanisms, the RSVP Authentication mechanisms defined in control mechanisms, the RSVP Authentication mechanisms defined in
[RFC2747] and [RFC3097] may be used. Those protect RSVP message [RFC2747] and [RFC3097] may be used. Those protect RSVP message
integrity hop-by-hop and provide node authentication as well as integrity hop-by-hop and provide node authentication as well as
replay protection, thereby protecting against corruption and spoofing replay protection, thereby protecting against corruption and spoofing
of RSVP messages. These hop-by-hop integrity mechanisms can be used of RSVP messages. These hop-by-hop integrity mechanisms can be used
to protect the RSVP reservations established using an RSVP receiver to protect the RSVP reservations established using an RSVP receiver
proxy in accordance with the present document. proxy in accordance with the present document.
 End of changes. 7 change blocks. 
7 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/