1 / 7

RSVP Extensions for Emergency Services

This document outlines the technical capabilities required from the network layer control plane, specifically focusing on the RSVP signaling protocol, to support various flavors of emergency services. It covers the required capabilities for different types of emergency services without recommending or mandating specific deployment scenarios. Examples of implementing emergency services using RSVP extensions are provided, detailing protocols for app layer call queueing and prioritized access to network resources.

bonilla
Download Presentation

RSVP Extensions for Emergency Services

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

  2. Changes from Previous version: • Renamed draft-ietf-tsvwg-… in accordance with WG decision in Montreal to accept as WG Doc • Addressed comments on List (ie Janet’s): • Extended the Admission Priority field from 3 to 8 bits and inverted the encoding order • Added DRSN example in ARLP Priority field description • Clarifications on “Engineered Capacity Limits” used for enforcement of admission priority

  3. Next Steps • Proposal : • Issue new rev fixing editorial nits • Then go to WG Last Call

  4. Backup Slides

  5. Dealing with various flavors of Emergency services (eg without/with/with-limited preemption, with/without call queueing, with/without call displacement) Working assumptions behind emergency-rsvp I-D: • 1) the document focuses on technical capabilities required from 
"network layer" control plane (when the signaling/reservation protocol 
in use is RSVP) for support of emergency services • 2) the document should cover all the capabilities that are 
required by the various known/desired "flavors" of emergency services • 3) recommending (let alone mandating) which "flavor" of 
emergency services should be deployed where/when/why is completely out 
of the scope of this document • 4) discussing which flavor is legal/illegal where/when/why is 
completely out of the scope of the document

  6. Dealing with various flavors of Emergency services (eg without/with/with-limited preemption, with/without call queueing, with/without call displacement) Added Appendix : examples of RSVP extensions usage to implement different Emergency Services: • If one wants to implement an emergency service purely based on App Layer Call Queueing, one can achieve this by signaling emergency calls: * using "Resource-Priority" Header in SIP * not using Admission-Priority Policy Elt in RSVP * not using Preemption Policy Elt in RSVP • If one wants to implement an emergency service based on App Layer Call Queueing AND on "prioritized access to network layer resources", one can achieve this by signaling emergency calls: * using "Resource-Priority" Header in SIP * using Admission-Priority Policy Elt in RSVP * not using Preemption Policy Elt in RSVP

  7. Dealing with various flavors of Emergency services (eg without/with/with-limited preemption, with/without call queueing, with/without call displacement) • If one wants to implement an emergency service based on App Layer Call Queueing, on "prioritized access to network layer resources", and ensures that "Emergency-1" sessions can preempt "Emergency-2" sessions, but non-emergency sessions are not affected by preemption, one can do that by signaling emergency calls: * using "Resource-Priority" Header in SIP * using Admission-Priority Policy Element in RSVP * using Preemption Policy Element in RSVP with: o setup(Emergency-1) > defending(Emergency-2) o setup(Emergency-2) <= defending(Emergency-1) o setup(Emergency-1) <= defending(Non-Emergency) o setup(Emergency-2) <= defending(Non-Emergency) • Etc...

More Related