Francois le faucheur cisco flefauch@cisco com
This presentation is the property of its rightful owner.
Sponsored Links
1 / 11

Francois Le Faucheur Cisco [email protected] PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on
  • Presentation posted in: General

Use of CCAMP extensions by RSVP Proxy. Francois Le Faucheur Cisco [email protected] 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

Download Presentation

Francois Le Faucheur Cisco [email protected]

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Francois le faucheur cisco flefauch@cisco com

Use of CCAMP extensions by RSVP Proxy

Francois Le [email protected]


Why am i here

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


Path triggered rsvp receiver proxy deployment example cac for video on demand

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


Sender notification about reservation failure the problem

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)


Sender notification about reservation failure the patherr solution mandatory

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)


Sender notification about reservation failure the notify solution optional

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)


Francois le faucheur cisco flefauch cisco

So …

  • Please review draft-ietf-tsvwg-rsvp-proxy-proto when TSVWG Last Call is issued

  • Questions, Comments ?


Fyi back up slides

FYI/Back-up Slides


Rsvp proxy background

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


Taxonomy of rsvp proxy approaches

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


Sender notification about reservation failure the notify solution optional1

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


  • Login