Document Action: 'RSVP Proxy Approaches' to Informational RFC
The IESG <iesg-secretary@ietf.org> Mon, 26 April 2010 16:35 UTC
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 4FD0E3A6A2B; Mon, 26 Apr 2010 09:35:49 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'RSVP Proxy Approaches' to Informational RFC
Message-Id: <20100426163549.4FD0E3A6A2B@core3.amsl.com>
Date: Mon, 26 Apr 2010 09:35:49 -0700
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 16:35:49 -0000
The IESG has approved the following document: - 'RSVP Proxy Approaches ' <draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt> as an Informational RFC This document is the product of the Transport Area Working Group. The IESG contact person is Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt Technical Summary 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 flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. The Proto document defines the RSVP extensions that are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. Working Group Summary The consensus for the publication was strong but from a small group within the WG. Document Quality The shepherd doesn't know of any implementations. The documents could have benefited from wider review. Personnel WG Shepherd and responsible AD is Magnus Westerlund.