70 likes | 208 Views
draft-ietf-tsvwg-rsvp-emergency-00.txt RSVP Extensions for Emergency Services Francois Le Faucheur - flefauch@cisco.com. Francois Le Faucheur, James Polk, C isco Systems. Ken Carlberg G11. Changes from Previous version:.
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...