Presentation is loading. Please wait.

Presentation is loading. Please wait.

Francois Le Faucheur Cisco

Similar presentations


Presentation on theme: "Francois Le Faucheur Cisco"— Presentation transcript:

1 Francois Le Faucheur Cisco flefauch@cisco.com
Use of CCAMP extensions by RSVP Proxy Francois Le Faucheur Cisco

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 (*) including over R3->R4 link
Path-Triggered RSVP Receiver Proxy Deployment Example: CAC for Video on Demand RSVP Receiver Proxy Non RSVP capable RSVP capable R1 R3 R4 R2 VoD Path Resv Video Stream RSVP Reservation/CAC for VoD session over R1-->R3(*) even if receiver R4 is not RSVP capable (*) including over R3->R4 link

4 Sender Notification about Reservation Failure: The Problem
RSVP Receiver Proxy Non RSVP capable RSVP capable R1 R3 R4 R2 VoD Path Resv CAC reject CAC rejec ResvErr (CAC reject) 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

5 Sender Notification about Reservation Failure: The “PathErr” Solution (Mandatory)
RSVP Receiver Proxy Non RSVP capable RSVP capable R1 R3 R4 R2 VoD Path Resv CAC reject ResvErr (CAC reject) PathErr (CAC reject, PSR) 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

6 Sender Notification about Reservation Failure: The “Notify” Solution (Optional)
RSVP Receiver Proxy Non RSVP capable RSVP capable R1 R3 R4 R2 VoD Path (Notify Request=sender) Resv (Notify Request=sender) CAC reject ResvErr (CAC reject) Notify (CAC reject) 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

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


Download ppt "Francois Le Faucheur Cisco"

Similar presentations


Ads by Google