110 likes | 126 Views
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.
E N D
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
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"
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
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"
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
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
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
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
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.
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
Next Steps • Accept as Working Group document • Address open items when issuing as WG doc