70 likes | 87 Views
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.
E N D
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
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
Next Steps • Proposal : • Issue new rev fixing editorial nits • Then go to WG Last Call
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
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
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...