1 / 11

Francois Le Faucheur Cisco flefauch@cisco

Use of CCAMP extensions by RSVP Proxy. Francois Le Faucheur Cisco flefauch@cisco.com. Why am I here?. TSVWG is documenting operations of RSVP Proxys for IPv4/IPv6 Sessions (not RSVP-TE sessions) Allows per-flow reservation where the sender or receiver is not RSVP-capable

walt
Download Presentation

Francois Le Faucheur Cisco flefauch@cisco

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Use of CCAMP extensions by RSVP Proxy Francois Le FaucheurCiscoflefauch@cisco.com

  2. Why am I here? • TSVWG is documenting operations of RSVP Proxys for IPv4/IPv6 Sessions (not RSVP-TE sessions) • Allows per-flow reservation where the sender or receiver is not RSVP-capable • draft-ietf-tsvwg-rsvp-proxy-approaches: • Informational Track • Taxonomy of approaches for deploying RSVP Proxys • draft-ietf-tsvwg-rsvp-proto: • Standards Track • RSVP operations for “Path-triggered RSVP Receiver Proxy” approach • Reuses CCAMP mechanisms • Reuse of CCAMP mechanisms has been reviewed/suggested by a few CCAMP experts, but we’d like broader CCAMP review

  3. VoD R4 R3 R2 R1 Path-Triggered RSVP Receiver ProxyDeployment Example: CAC for Video on Demand RSVP Receiver Proxy • RSVP Reservation/CAC for VoD session over R1-->R3(*) even if receiver R4 is not RSVP capable Non RSVP capable RSVP capable Path Resv Video Stream (*) including over R3->R4 link

  4. VoD R4 R3 R2 R1 Sender Notification about Reservation Failure: The Problem RSVP Receiver Proxy • Regular RSVP sends “CAC reject” notification towards Receiver: • RSVP Receiver Proxy knows of “CAC reject” but can not do much about it • RSVP sender does not know • ==> need RSVP extensions for sender notification of CAC reject Non RSVP capable RSVP capable Path Resv CAC reject CAC rejec ResvErr (CAC reject)

  5. VoD R4 R3 R2 R1 Sender Notification about Reservation Failure: The “PathErr” Solution (Mandatory) RSVP Receiver Proxy • Receiver Proxy sends PathErr with “CAC reject” error code • approach borrowed from RFC3209 for MPLS-TE Head-end Notification • Receiver Proxy MAY include PSR flag to expedite release of resources reuse PSR (Path_State_Removed) flag from RFC3473 as specified there Non RSVP capable RSVP capable Path Resv CAC reject ResvErr (CAC reject) PathErr (CAC reject, PSR)

  6. VoD R4 R3 R2 R1 Sender Notification about Reservation Failure: The “Notify” Solution (Optional) RSVP Receiver Proxy • RSVP Router responsible for “CAC reject” sends Notify to sender • Reuse Notify mechanism of RFC3473 as specified there • Receiver Proxy puts sender address in Notify Request inside Resv • --> ensures Notify containing “CAC reject” is sent to sender Non RSVP capable RSVP capable Path (Notify Request=sender) Resv (Notify Request=sender) CAC reject ResvErr (CAC reject) Notify (CAC reject)

  7. So … • Please review draft-ietf-tsvwg-rsvp-proxy-proto when TSVWG Last Call is issued • Questions, Comments ?

  8. FYI/Back-up Slides

  9. RSVP Proxy Background • RSVP deployments are happening: • eg for Voice/Video CAC on WAN in Enterprise • eg for VoD CAC on Aggregation in Triple-Play SP • RSVP also considered: • eg for Mobile Voice CAC on Radio • Many deployment scenarios involve RSVP only on a subset of end-to-end path • non-RSVP-capable Sender, or non-RSVP-capable Receiver • RSVP CAC only needed on (radio) access • Current RSVP spec assumes end-to-end signaling • Need to : • document (resurrect) non end-to-end deployment approaches • standardize corresponding extensions (where needed) • NSIS included Proxys in base specs

  10. Taxonomy of RSVP Proxy Approaches: • Path-Triggered Receiver Proxy • Path-Triggered Sender Proxy for Reverse Direction • Inspection-Triggered Proxy • STUN-Triggered Proxy • Application_Entity-Controlled Proxy • Policy_Server-Controlled Proxy • RSVP-Signaling-Triggered Proxy • Endsystem-Controlled Proxy

  11. Sender Notification about Reservation Failure: The “Notify” Solution (Optional) • PROs: • Allows failure notification to be sent directly upstream to the sender by the router where the failure occurs • Allows the failure notification to travel directly to the sender without hop-by-hop RSVP processing • Ensures notification is only sent to senders which are interested • Ensures notification is only sent in presence of a Receiver Proxy • CONs: • More sophistication • Requirement for RSVP routers and senders to support the Notify messages and procedures defined in RFC3473 ==> “PathErr Solution” is Mandatory, “Notify Solution” is Optional

More Related