1IETF66/TSVWG: RSVP Extensions for Emergency

draft-lefaucheur-emergency-rsvp-02.txt

RSVP Extensions for Emergency Services

Francois Le Faucheur - flefauch@cisco.com

Francois Le Faucheur, James Polk,Cisco Systems

Ken CarlbergG11

222IETF66/TSVWG: RSVP Extensions for Emergency

Changes from Previous version:Addressing Known Open Issues

• modified the Introduction to add additional clarity and to place related work in a better context wrt the extensions proposed in this draft

• Moved bandwidth allocation models to an Appendix

• Allowed multiple Application-Level Resource Priority inside ALRP Policy Element

• Added merging rule for ALRP Policy Element

• Added a 2nd appendix providing examples of RSVP extensions usage

333IETF66/TSVWG: RSVP Extensions for Emergency

Dealing with various flavors of Emergency services (eg without/with/with-limited preemption)

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

444IETF66/TSVWG: RSVP Extensions for Emergency

Dealing with various flavors of Emergency services (eg without/with/with-limited preemption)

Added Appendix : examples of RSVP extensions usage to implement different Emergency Services:

• If one wants to implement an emergency service purely based on 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 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

555IETF66/TSVWG: RSVP Extensions for Emergency

Dealing with various flavors of Emergency services (eg without/with/with-limited preemption)

• If one wants to implement an emergency service based on 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...

666IETF66/TSVWG: RSVP Extensions for Emergency

Next Steps

• Accept as Working Group document