draft-ietf-tsvwg-emergency-rsvp-12.txt   draft-ietf-tsvwg-emergency-rsvp-13.txt 
TSVWG
Internet-Draft Zhao Jihong
Intended status: Standards Track Ren Luyuan
Expires: May 20, 2010 Xi'an Institute of
Posts and Telecommunications
November 16, 2009
TSVWG F. Le Faucheur Addition to Resource ReSerVation Protocol (RSVP) Extension for Emergency Services
Internet-Draft J. Polk draft-ietf-tsvwg-emergency-rsvp-13.txt
Intended status: Standards Track Cisco
Expires: November 29, 2009 K. Carlberg
G11
May 28, 2009
Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority
draft-ietf-tsvwg-emergency-rsvp-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
skipping to change at page 2, line 15 skipping to change at page 2, line ?
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
Some applications require the ability to provide an elevated Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of probability of session establishment to specific sessions in times of
network congestion. When supported over the Internet Protocol suite, network congestion.When supported over the Internet Protocol suite,
this may be facilitated through a network layer admission control this may be facilitated through a network layer admission control
solution that supports prioritized access to resources (e.g., solution that supports prioritized access to resources (e.g.,
bandwidth). These resources may be explicitly set aside for bandwidth). These resources may be explicitly set aside for
prioritized sessions, or may be shared with other sessions. This prioritized sessions, or may be shared with other sessions. This
document specifies extensions to the Resource reSerVation Protocol document specifies extensions to the Resource reSerVation Protocol
(RSVP) that can be used to support such an admission priority (RSVP) that can be used to support such an admission priority
capability at the network layer. capability at the network layer.
Based on current security concerns, these extensions are targeting Based on current security concerns, these extensions are targeting
applicability within a single domain. applicability within a single domain.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Overview of RSVP extensions and Operations . . . . . . . . . . 5 3. Overview of RSVP extensions and Operations . . . . . . . . . . 3
3.1. Operations of Admission Priority . . . . . . . . . . . . . 7 3.1. Operations of Admission Priority . . . . . . . . . . . . . 5
4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 5
4.1. Admission Priority Policy Element . . . . . . . . . . . . 8 4.1. Admission Priority Policy Element . . . . . . . . . . . . 6
4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 8
4.2. Application-Level Resource Priority Policy Element . . . . 11 4.2. Application-Level Resource Priority Policy Element . . . . 8
4.2.1. Application-Level Resource Priority Modifying and 4.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 12 Merging Rules . . . . . . . . . . . . . . . . . . . . 9
4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Use of RSVP Authentication between RSVP neighbors . . . . 13 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 11
5.2. Use of INTEGRITY object within the POLICY_DATA object . . 14 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Examples of Bandwidth Allocation Model for Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 19 Admission Priority . . . . . . . . . . . . . . . . . 16
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 20
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 22
A.4 Admission Priority with Temporary Allocation Model(TAM). . 25
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction Introduction
Some applications require the ability to provide an elevated Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of probability of session establishment to specific sessions in times of
network congestion. network congestion.
Solutions to meet this requirement for elevated session establishment Solutions to meet this requirement for elevated session establishment
probability may involve session layer capabilities prioritizing probability may involve session layer capabilities prioritizing
access to resources controlled by the session control function. As access to resources controlled by the session control function. As
an example, entities involved in session control (such as SIP user an example, entities involved in session control (such as SIP user
agents, when the Session Initiation Protocol (SIP) [RFC3261], is the agents, when the Session Initiation Protocol (SIP) [RFC3261], is the
skipping to change at page 17, line 12 skipping to change at page 14, line 25
A numerical value should be allocated immediately by IANA to all A numerical value should be allocated immediately by IANA to all
existing priority. Then, in the future, IANA should automatically existing priority. Then, in the future, IANA should automatically
allocate a numerical value to any new namespace added to the allocate a numerical value to any new namespace added to the
registry. The numerical value must be unique within each namespace. registry. The numerical value must be unique within each namespace.
For the initial allocation, within each namespace, values should be For the initial allocation, within each namespace, values should be
allocated in decreasing order ending with 0 (so that the greatest allocated in decreasing order ending with 0 (so that the greatest
priority is always allocated value 0). For example, in the drsn priority is always allocated value 0). For example, in the drsn
namespace, "routine" would be allocated numerical value 5 and "flash- namespace, "routine" would be allocated numerical value 5 and "flash-
override-override" would be allocated numerical value 0. override-override" would be allocated numerical value 0.
7. Acknowledgments 7. Acknowledgments
We would like to thank An Nguyen for his encouragement to address This context is as a complement to the previous draft-ietf
this topic and ongoing comments. Also, this document borrows heavily -tsvwg-emergency-rsvp-12.txt.
from some of the work of S. Herzog on Preemption Priority Policy
Element [RFC3181]. Dave Oran and Janet Gunn provided useful input
into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings,
and Ross Callon provided specific guidance for the applicability
statement of the mechanisms defined in this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
skipping to change at page 29, line 22 skipping to change at page 25, line 45
. . |xxoxxxxxxoxxxx| . . . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| . Capacity. . |oxxxooooxxxxoo| .
v . |xxoxxxooxxxxxx| v v . |xxoxxxooxxxxxx| v
. |--------------| --- . |--------------| ---
. |oooooooooooooo| . |oooooooooooooo|
v | | v | |
| | | |
Figure 16: Full non-priority load Figure 16: Full non-priority load
A.4. Admission Priority with Temporary Allocation Model(TAM)
This section illustrates operations of admission priority when a
Temporary Allocation Model(TAM) is used for bandwidth allocation
across non-priority traffic and priority traffic.According to the
characters of emergency services,burstiness and short duration,there
are two periods.One is the emergency period and the other is non-emergency
period.The emergency service can be regarded as priority traffic,while
the normal service is non-priority service.In the non-emergency period,
there is only non-priority traffic.So the bandwidth is available to all
the traffic.
Figure 17 shows all the bandwidth is available for non-priority traffic
in the non-emergency period and some amount of non-priority load being
used at this link.
------------------------
^ | xxxxxxxxxxxxxxx | ^
. | xxxxxxxxxxxxxxx | .
Total . | xxxxxxxxxxxxxxx | .
. | xxxxxxxxxxxxxxx | . Bandwidth
Engi- . | xxxxxxxxxxxxxxx | . Available
neered . | xxxxxxxxxxxxxxx | . for non-priority use
Capacity. | xxxxxxx | .
. | | .
. | | .
. | | .
. | | .
. | | .
. | | .
v | | V
| |
Figure 17: TAM Bandwidth Allocation for non-Emergency
when one or more emergency service requests arrive at PEP or the time
for emergency period arrives (for example,the operator set the time
<9:00~11:00> for emergency period),the operator configure the maximum
bandwidth available for non-priority, no additional non-priority
sessions can be accepted even if the bandwidth reserved for priority
traffic is not currently fully utilized.If the current non-priority
traffic exceeds the maximum bandwidth which is available to non-priority
traffic,then the operator chooses some of the sessions to be teared
down in order to make sure there is a portion of bandwidth available
for priority use.
The same as the other bandwidth allocation models,an operator may map
the TAM model onto the Engineered Capacity limits according to different
policies. As an example,if the engineered capacity limit on a given
link is X,the operator may configure the bandwidth available to
non-priority traffic to 95% of X in the emergency period.when a priority
session(emergency service) arrives,this session is admitted regardless
of the current load.Finally,the operator may decide to strike a balance
in between.The considerations presented for these policies in the MAM,RDM
and PrBM contexts are equally applicable to the Priority Bypass Model.
Figure 18 illustrates the bandwidth allocation with the Temporary Allocation
Model in the emergency periods.
------------------------
^ ^ | | ^
. . | | .
Total . . | | .
. . | | . Bandwidth Limit
Engi- . (2) | | . (on non-priority+priority)
neered (1)or . | | . for admission
Capacity . . | | . of non-priority traffic
. . | | V
. . |------------------| --
. . | |
V . | |
. | |
. | |
v | |
Figure 18: Temporary Allocation Model Bandwidth Allocation for Emergency
Figure 19 shows some of the non-priority capacity and priority capacity of
this link being used.In this situation, both new
non-priority and new priority sessions would be accepted.
--------------------------
^ ^ |xxxxxxxxxxxxxxxxx | ^
. . |xxxxxxxxxxxxxxxxx | .
Total . . |xxxxxxxxxxxxxxxxx | .
. . |xxxxxxxxxxxxxxxxx | . Bandwidth Limit
Engi- . (2) |ooooooooooooooooo | . (on non-priority+priority)
neered (1)or . | | . for admission
Capacity . . | | . of non-priority traffic
. . | | V
. . |------------------| --
. . | |
V . | |
. | |
. | |
v | |
Figure 19: Partial load of non-priority calls & partial load of priority calls
Figure 20 shows the case where aggregate non-priority and priority
load exceeds the bandwidth limit for admission of non-priority
traffic.In the situation,any new non-priority session is rejected
while any new priority session is admitted.
-------------------------
^ ^ |xxxxxxxxxxxxxxxx | ^
. . |xxxxxxxxxxxxxxxx | .
Total . . |xxxxxxxxxxxxxxxx | .
. . |xxxxxxxxxxxxxxxx | . Bandwidth Limit
Engi- . (2) |oooooooooooooooo | . (on non-priority+priority)
neered (1)or . |xxxxxooxxxxooooo | . for admission
Capacity . . |xxxxxxxoooooxxxx | . of non-priority traffic
. . |xxxxxxoooooxxooo | V
. . |-----------------| --
. . |ooooooooooooooooo|
V . | |
. | |
. | |
v | |
Figure 20:Full non-priority load
Figure 21 shows the case when one or more emergency service requests
arrive at PEP or the time for emergency period arrives,
non-priority load exceeds the bandwidth limit for admission of
non-priority traffic .
-------------------------
^ ^ |xxxxxxxxxxxxxxxx | ^
. . |xxxxxxxxxxxxxxxx | .
Total . . |xxxxxxxxxxxxxxxx | .
. . |xxxxxxxxxxxxxxxx | . Bandwidth Limit
Engi- . (2) |xxxxxxxxxxxxxxxx | . (on non-priority+priority)
neered (1)or . |xxxxxxxxxxxxxxxx | . for admission
Capacity . . |xxxxxxxxxxxxxxxx | . of non-priority traffic
. . |xxxxxxxxxxxxxxxx | V
. . |-----------------| --
. . |xxxxxxxxxxxxxxxx |
V . |xxxxxxxx |
. | |
. | |
v | |
Figure 21: non-priority traffic load at the beginning of Emergency
Figure 22 shows the operator chooses some of non-priority sessions to be
teared down and any new non-priority sessionis rejected while any new
priority session is admitted.
-------------------------
^ ^ |xxxxxxxxxxxxxxxx | ^
. . |xxxxxxxxxxxxxxxx | .
Total . . |xxxxxxxxxxxxxxxx | .
. . |xxxxxxxxxxxxxxxx | . Bandwidth Limit
Engi- . (2) |xxxxxxxxxxxxxxxx | . (on non-priority+priority)
neered (1)or . |xxxxxxxxxxxxxxxx | . for admission
Capacity . . |xxxxxxxxxxxxxxxx | . of non-priority traffic
. . |xxxxxxxxxxxxxxxx | V
. . |-----------------| --
. . |oooooooooooooooo |
V . |oooooooooooooooo |
. |oooo |
. | |
v | |
Figure 22: Full non-priority load and partial priority load
Appendix B. Example Usages of RSVP Extensions Appendix B. Example Usages of RSVP Extensions
This section provides examples of how RSVP extensions defined in this This section provides examples of how RSVP extensions defined in this
document can be used (in conjunctions with other RSVP functionality document can be used (in conjunctions with other RSVP functionality
and SIP functionality) to enforce different hypothetical policies for and SIP functionality) to enforce different hypothetical policies for
handling prioritized sessions in a given administrative domain. This handling prioritized sessions in a given administrative domain. This
Appendix does not provide additional specification. It is only Appendix does not provide additional specification. It is only
included in this document for illustration purposes. included in this document for illustration purposes.
We assume an environment where SIP is used for session control and We assume an environment where SIP is used for session control and
skipping to change at page 31, line 35 skipping to change at line 1545
o using Admission-Priority Policy Element in RSVP o using Admission-Priority Policy Element in RSVP
o using Preemption in Policy Element RSVP with: o using Preemption in Policy Element RSVP with:
* setup (Prioritized) > defending (Non-Prioritized) * setup (Prioritized) > defending (Non-Prioritized)
* setup (Non-Prioritized) <= defending (Prioritized) * setup (Non-Prioritized) <= defending (Prioritized)
o activate RFC4495 RSVP Bandwidth Reduction mechanisms o activate RFC4495 RSVP Bandwidth Reduction mechanisms
Authors' Addresses Authors'Addresses
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
James Polk
Cisco Systems
2200 East President George Bush Highway
Richardson, TX 75082-3550
United States
Phone: +1 972 813 5208
Email: jmpolk@cisco.com
Ken Carlberg
G11
123a Versailles Circle
Towson, MD 21204
United States
Email: carlberg@g11.org.uk Zhao Jihong, Ren Luyuan
Xi'an Institute of Posts and Telecommunications
y.y0910@163.com
 End of changes. 13 change blocks. 
68 lines changed or deleted 205 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/