1 / 11

Francois Le Faucheur, James Polk, C isco Systems

draft-lefaucheur-emergency-rsvp-00.txt RSVP Extensions for Emergency Services Francois Le Faucheur - flefauch@cisco.com. Francois Le Faucheur, James Polk, C isco Systems. Ken Carlberg G11. Background.

jteresa
Download Presentation

Francois Le Faucheur, James Polk, C isco Systems

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. draft-lefaucheur-emergency-rsvp-00.txtRSVP Extensions for Emergency ServicesFrancois Le Faucheur - flefauch@cisco.com Francois Le Faucheur, James Polk, Cisco Systems Ken Carlberg G11

  2. Background • RFC3689 & RFC3690 define the requirements for support of Emergency telecommunications services, including: • Elevated probability of session establishment from an authorized user in times of network congestion (e.g. crisis condition) • “mlpp-that-works” defines how network-based CAC (e.g. RSVP) can be used to achieve: • MLPP Services (e.g. DoD/NATO’s MLPP) • All necessary RSVP extension already standardised • CAC may also be used for Emergency (Jury is still out) • Small RSVP extensions needed : Objective of this document • RFC 3689 “General Requirements for Emergency Telecommunication Service (ETS)” • RFC 3690 “IP Telephony Requirements for Emergency Telecommunication Service (ETS)” • draft-ietf-tsvwg-mlpp-that-works-04, “Implementing an Emergency Telecommunications Service for Real Time Services in the Internet Protocol Suite"

  3. Changes from Previous version • added a second RSVP Policy Element • contains the application-level resource priority requirements (for example as communicated in the SIP Resource-Priority Header) • for scenarios where priority calls transits through multiple administrative domains • added description of a third (simpler) bandwidth allocation model example: the Priority Bypass Model • added discussion on policies for mapping the various bandwidth allocation model over the engineered capacity limits

  4. Proposed Extension: New Policy Elements(inside Policy Data object) Admission Priority Policy Element +-------------+-------------+-------------+-------------+ | Length | P-Type = ADMISSION_PRI | +-------------+-------------+-------------+-------------+ | Flags | M. Strategy | Error Code | Reserved | +-------------+-------------+-------------+-------------+ | Rvd | Pri| Reserved | +---------------------------+---------------------------+ Reduced to 3 bits Application-Level Resource Priority Policy Element +-------------+-------------+-------------+-------------+ | Length | P-Type = APP_RESOURCE_PRI | +-------------+-------------+-------------+-------------+ | Flags | M. Strategy | Error Code | Reserved | +-------------+-------------+-------------+-------------+ | ARP Namespace | ARP Priority| Reserved | +---------------------------+---------------------------+ e.g. "dsn", "drsn", "q735", "ets" and "wps"

  5. ets.0 Give ets.0 highest Admission Priority Give ets.0 Medium Admission Priority ets.0 ets.0 ets.0 2 0 0 Use of Application-Level Resource Priority Policy Element in Multi-Domain P1 Domain 1 Domain 2 R3 SIP Message SIP Resource-Priority Header xx RSVP Message yy RSVP “Application-Level Resource Priority” Policy Element RSVP “Admission Priority” Policy Element yy

  6. New non-priority call REJECTED New priority call ACCEPTED Admission Priority Operations Example:Priority Bypass Model Total Link Bw Admission Control Limit (for non-priority sessions) Non-priority call Priority call

  7. Engineering Trade-Off Example: Total Link Bw Admission Control Limit (for non-priority sessions) Engineered Capacity for Voice Option 1: Admission Control Limit set BELOW Engineered Capacity: * Some capacity set aside for Emergency ( accept less non-priority calls in normal time) * QoS absolutely guaranteed (Emergency sessions fit within Engineered Capacity) Non-priority call Priority call

  8. Engineering Trade-Off Example: Total Link Bw Admission Control Limit (for non-priority sessions) Engineered Capacity for Voice Option 2: Admission Control Limit set EQUAL TO Engineered Capacity: * No capacity blocked for Emergency (ie no waste) * Emergency sessions eat into QoS safety marging Non-priority call Priority call

  9. Open Issues (1) • Support ETS emergency type sessions which need: • - to benefit from elevated admission priority • - to be able to preempt other ETS emergency type sessions • - to not be able to preempt non-emergency sessions. • One approach: Add a new Flag in the “Preemption Priority” Policy Element: • which reduces the scope of RSVP preemption to emergency sessions.

  10. Open Issues (2) • In case of Multicast Sessions, Merging Rules for “Application-Level Resource Priority” Policy Element: • One approach is reunion of all the namespaces

  11. Next Steps • Accept as Working Group document • Address open items when issuing as WG doc

More Related