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