draft-ietf-tsvwg-rsvp-proxy-approaches-05.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational J. Manner Intended status: Informational J. Manner
Expires: May 4, 2009 University of Helsinki Expires: May 4, 2009 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
October 31, 2008 October 31, 2008
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-05.txt draft-ietf-tsvwg-rsvp-proxy-approaches-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 3, line 28 skipping to change at page 3, line 28
Since the data sender or receiver may be unaware of RSVP, there are Since the data sender or receiver may be unaware of RSVP, there are
two types of RSVP Proxies. When the sender is not using RSVP, an two types of RSVP Proxies. When the sender is not using RSVP, an
entity in the network must operate on behalf of the data sender, and entity in the network must operate on behalf of the data sender, and
in particular, generate RSVP Path messages, and eventually receive, in particular, generate RSVP Path messages, and eventually receive,
process and sink Resv messages. We refer to this entity as the RSVP process and sink Resv messages. We refer to this entity as the RSVP
Sender Proxy. When the receiver is not using RSVP, an entity in the Sender Proxy. When the receiver is not using RSVP, an entity in the
network must receive Path messages sent by a data sender (or by an network must receive Path messages sent by a data sender (or by an
RSVP Sender Proxy), sink those, and return Resv messages on behalf of RSVP Sender Proxy), sink those, and return Resv messages on behalf of
the data receiver(s). We refer to this entity as the RSVP Receiver the data receiver(s). We refer to this entity as the RSVP Receiver
Proxy. Proxy. The RSVP Proxies need to be on the data path in order to
establish the RSVP reservation; Note, however, that some of the
approaches described in this document allow the RSVP Proxies to be
controlled/triggered by an off-path entity.
The flow sender and receiver generally have at least some (if not The flow sender and receiver generally have at least some (if not
full) awareness of the application producing or consuming that flow. full) awareness of the application producing or consuming that flow.
Hence, the sender and receiver are in a natural position to Hence, the sender and receiver are in a natural position to
synchronize the establishment, maintenance and tear down of the RSVP synchronize the establishment, maintenance and tear down of the RSVP
reservation with the application requirements. Similarly they are in reservation with the application requirements. Similarly they are in
a natural position to determine the characteristics of the a natural position to determine the characteristics of the
reservation (bandwidth, QoS service,...) which best match the reservation (bandwidth, QoS service,...) which best match the
application requirements. For example, before completing the application requirements. For example, before completing the
establishment of a multimedia session, the endpoints may decide to establishment of a multimedia session, the endpoints may decide to
skipping to change at page 29, line 20 skipping to change at page 29, line 20
towards the triggering node. The node then replies back with a Resv. towards the triggering node. The node then replies back with a Resv.
More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig].
Such an RSVP-Signaling-Triggered Proxy approach would require RSVP Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
signaling extensions (that are outside the scope of the present signaling extensions (that are outside the scope of the present
document). However it could provide more flexibility in the control document). However it could provide more flexibility in the control
of the Proxy behavior (e.g. control of reverse reservation of the Proxy behavior (e.g. control of reverse reservation
parameters) than provided by the Path-Triggered approaches defined in parameters) than provided by the Path-Triggered approaches defined in
Section 4.1 and Section 4.2. Section 4.1 and Section 4.2.
Through potential corresponding protocol extensions, an RSVP-
Signaling-Triggered Proxy approach could facilitate operation (e.g.
reduce or avoid the need for associated configuration) in hybrid
environments involving both reservations established end-to-end and
reservations established via RSVP Proxies. For
example,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism
allowing an end-system to control whether a reservation can be
handled by an RSVP Proxy on the path or is to be established end-to-
end.
4.8. Reachability Considerations 4.8. Reachability Considerations
There may be situations where the RSVP Receiver Proxy is reachable by There may be situations where the RSVP Receiver Proxy is reachable by
the sender, while the receiver itself is not. In such situations, it the sender, while the receiver itself is not. In such situations, it
is possible that the RSVP Receiver Proxy is not always aware that the is possible that the RSVP Receiver Proxy is not always aware that the
receiver is unreachable, and consequently may accept to establish an receiver is unreachable, and consequently may accept to establish an
RSVP reservation on behalf of that receiver. This would result in RSVP reservation on behalf of that receiver. This would result in
unnecessary reservation establishment and unnecessary network unnecessary reservation establishment and unnecessary network
resource consumption. resource consumption.
skipping to change at page 30, line 14 skipping to change at page 30, line 24
RSVP Proxys. RSVP Proxys.
The mirror considerations apply for situations involving an RSVP The mirror considerations apply for situations involving an RSVP
Sender Proxy and where the sender cannot reach the destination while Sender Proxy and where the sender cannot reach the destination while
the RSVP Sender Proxy can. the RSVP Sender Proxy can.
5. Security Considerations 5. Security Considerations
In the environments of concern for this document, RSVP messages are In the environments of concern for this document, RSVP messages are
used to control resource reservations on a segment of the end-to-end used to control resource reservations on a segment of the end-to-end
path of flows. To ensure the integrity of the associated reservation path of flows. The general security considerations associated with
and admission control mechanisms, the cryptographic authentication [RFC2205] apply. To ensure the integrity of the associated
mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those reservation and admission control mechanisms, the cryptographic
protect RSVP messages integrity hop-by-hop and provide node authentication mechanisms defined in [RFC2747]] and [RFC3097] can be
authentication, thereby protecting against corruption, spoofing of used. Those protect RSVP messages integrity hop-by-hop and provide
RSVP messages and replay. [I-D.ietf-tsvwg-rsvp-security-groupkeying] node authentication, thereby protecting against corruption, spoofing
discusses key types and key provisioning methods as well as their of RSVP messages and replay.
respective applicability to RSVP authentication mechanisms and to [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and
IPsec protection (e.g. [RFC4303]) of RSVP. key provisioning methods as well as their respective applicability to
RSVP authentication and RSVP encryption (e.g. [RFC4303]).
A number of additional security considerations apply to the use of A number of additional security considerations apply to the use of
RSVP proxies and are discussed below. RSVP proxies and are discussed below.
With some RSVP Proxy approaches, the RSVP proxy operates autonomously With some RSVP Proxy approaches, the RSVP proxy operates autonomously
inside an RSVP router. This is the case for the Path-Triggered Proxy inside an RSVP router. This is the case for the Path-Triggered Proxy
approaches defined in Section 4.1 and in Section 4.2, for the approaches defined in Section 4.1 and in Section 4.2, for the
Inspection-Triggered Proxy approach defined in Section 4.3, for the Inspection-Triggered Proxy approach defined in Section 4.3, for the
STUN-Triggered Proxy approach defined in Section 4.4 and for the STUN-Triggered Proxy approach defined in Section 4.4 and for the
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
 End of changes. 4 change blocks. 
11 lines changed or deleted 25 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/