--- 1/draft-ietf-tsvwg-emergency-rsvp-12.txt 2009-11-17 09:12:12.000000000 +0100 +++ 2/draft-ietf-tsvwg-emergency-rsvp-13.txt 2009-11-17 09:12:13.000000000 +0100 @@ -1,21 +1,19 @@ +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 -Internet-Draft J. Polk -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 - +Addition to Resource ReSerVation Protocol (RSVP) Extension for Emergency Services + draft-ietf-tsvwg-emergency-rsvp-13.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this @@ -64,49 +62,49 @@ prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Based on current security concerns, these extensions are targeting applicability within a single domain. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 - 3. Overview of RSVP extensions and Operations . . . . . . . . . . 5 - 3.1. Operations of Admission Priority . . . . . . . . . . . . . 7 - 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Admission Priority Policy Element . . . . . . . . . . . . 8 - 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10 - 4.2. Application-Level Resource Priority Policy Element . . . . 11 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview of RSVP extensions and Operations . . . . . . . . . . 3 + 3.1. Operations of Admission Priority . . . . . . . . . . . . . 5 + 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Admission Priority Policy Element . . . . . . . . . . . . 6 + 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 8 + 4.2. Application-Level Resource Priority Policy Element . . . . 8 4.2.1. Application-Level Resource Priority Modifying and - Merging Rules . . . . . . . . . . . . . . . . . . . . 12 - 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 13 - 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Merging Rules . . . . . . . . . . . . . . . . . . . . 9 + 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 11 + 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Examples of Bandwidth Allocation Model for - Admission Priority . . . . . . . . . . . . . . . . . 19 - A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19 - A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23 - A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26 + Admission Priority . . . . . . . . . . . . . . . . . 16 + A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18 + A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 20 + 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 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 -1. Introduction +Introduction Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. Solutions to meet this requirement for elevated session establishment probability may involve session layer capabilities prioritizing access to resources controlled by the session control function. As an example, entities involved in session control (such as SIP user agents, when the Session Initiation Protocol (SIP) [RFC3261], is the @@ -716,27 +711,22 @@ allocate a numerical value to any new namespace added to the registry. The numerical value must be unique within each namespace. For the initial allocation, within each namespace, values should be allocated in decreasing order ending with 0 (so that the greatest priority is always allocated value 0). For example, in the drsn namespace, "routine" would be allocated numerical value 5 and "flash- override-override" would be allocated numerical value 0. 7. Acknowledgments - We would like to thank An Nguyen for his encouragement to address - this topic and ongoing comments. Also, this document borrows heavily - 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. + This context is as a complement to the previous draft-ietf + -tsvwg-emergency-rsvp-12.txt. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 @@ -1271,20 +1261,187 @@ . . |xxoxxxxxxoxxxx| . Capacity. . |oxxxooooxxxxoo| . v . |xxoxxxooxxxxxx| v . |--------------| --- . |oooooooooooooo| v | | | | 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 This section provides examples of how RSVP extensions defined in this document can be used (in conjunctions with other RSVP functionality and SIP functionality) to enforce different hypothetical policies for handling prioritized sessions in a given administrative domain. This Appendix does not provide additional specification. It is only included in this document for illustration purposes. We assume an environment where SIP is used for session control and @@ -1382,34 +1537,13 @@ o using Preemption in Policy Element RSVP with: * setup (Prioritized) > defending (Non-Prioritized) * setup (Non-Prioritized) <= defending (Prioritized) o activate RFC4495 RSVP Bandwidth Reduction mechanisms 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