1IETF67/TSVWG: RSVP Proxy

draft-lefaucheur-tsvwg-rsvp-proxy-00.txt

RSVP Proxy Approaches

Francois Le Faucheur - flefauch@cisco.comFrancois Le Faucheur,Dan Wing Cisco Systems

Jukka MannerUniversity of Helsinki

222IETF67/TSVWG: RSVP Proxy

RSVP Proxy Background

• RSVP deployments 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 this in base specs

333IETF67/TSVWG: RSVP Proxy

L3 IP/MPLS Core

VoD

802.1Q

Ethernet/IP/MPLS Aggregation

Business

Corporate

Use Case: VoD CAC on Aggregation in Triple Play

Residential

RSVP Path

RSVP Resv

RSVPReceiver Proxy

RSVPUnaware

RSVP aware

RSVP aware

VideoStream

444IETF67/TSVWG: RSVP Proxy

Location BLocation A

Use Case: Voice/Video CAC on WAN in Enterprise

HQ

RSVP

SIP

SIP

SIP Server

RSVPUnaware

RSVP aware

RSVP Proxy

WAN

RSVP Proxy

555IETF67/TSVWG: RSVP Proxy

Example of required RSVP Extension

• Regular RSVP sends CAC reject notification towards Receiver

• RSVP Receiver Proxy can not do much with it

• Extension to notify Sender of CAC reject

VoD

RSVPReceiver Proxy

RSVPUnaware RSVP aware

Path

Resv

ResvErr (CAC reject)

CAC reject

??? PathErr (CAC reject)

666IETF67/TSVWG: RSVP Proxy

I-Ds Roadmap

• As announced on mailing list after Montreal

• draft-lefaucheur-tsvwg-rsvp-proxy:

•Provides Framework for RSVP Proxy concept

•Taxonomy of (useful) Proxy Approaches

•Minor RSVP extensions for simple Proxy approaches

•Use Cases (in Appendix)

• draft-manner-tsvwg-rsvp-proxy-sig ("Localized RSVP for Controlling RSVP Proxies”) :

•Specifies RSVP signaling extensions for more complex Proxy approaches (RSVP-Signaling-Triggered Proxy)

777IETF67/TSVWG: RSVP Proxy

Taxonomy of Proxy Approaches:

• Path-Triggered Receiver Proxy

• Path-Triggered Sender Proxy for Reverse Direction

• Inspection-Triggered Proxy

• STUN-Triggered Proxy

• Application-Signaling-Triggered On-Path Proxy

• Application-Signaling-Triggered Off-Path Source Proxy

• RSVP-Signaling-Triggered Proxy

888IETF67/TSVWG: RSVP Proxy

Next Steps

• Progress RSVP Proxy under TSVWG

• Address comments received

• Should rsvp-proxy target Informational Track or Standards Track?

If Informational, need to move minor “extensions” out of rsvp-proxy I-D.

Should all extensions go to rsvp-proxy-sig or to separate I-Ds for different Proxy approaches?