draft-ietf-tsvwg-rsvp-emergency-00.txt
RSVP Extensions for Emergency Services
Francois Le Faucheur - flefauch@cisco.com
Francois Le Faucheur, Ken Carlberg
James Polk, G11
Cisco Systems
IETF67/TSVWG: RSVP Extensions for Emergency
1
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
IETF67/TSVWG: RSVP Extensions for Emergency
2
Next Steps
• Proposal :
Issue new rev fixing editorial nits
Then go to WG Last Call
IETF67/TSVWG: RSVP Extensions for Emergency
3
Backup Slides
IETF67/TSVWG: RSVP Extensions for Emergency
4
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
IETF67/TSVWG: RSVP Extensions for Emergency
5
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
IETF67/TSVWG: RSVP Extensions for Emergency
6
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...
IETF67/TSVWG: RSVP Extensions for Emergency
7