File: rfc3181.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (675 lines) | stat: -rw-r--r-- 21,990 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675






Network Working Group                                          S. Herzog
Request for Comments: 3181                          PolicyConsulting.Com
Obsoletes: 2751                                             October 2001
Category: Standards Track


              Signaled Preemption Priority Policy Element

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes a preemption priority policy element for use
   by signaled policy based admission protocols (such as the Resource
   ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS).

   Preemption priority defines a relative importance (rank) within the
   set of flows competing to be admitted into the network. Rather than
   admitting flows by order of arrival (First Come First Admitted)
   network nodes may consider priorities to preempt some previously
   admitted low priority flows in order to make room for a newer, high-
   priority flow.

   This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
   error in RFC 2751.
















Herzog                      Standards Track                     [Page 1]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


Table of Contents

   1 Introduction .....................................................2
   2 Scope and Applicability ..........................................3
   3 Stateless Policy .................................................3
   4 Policy Element Format ............................................4
   5 Priority Merging Issues ..........................................5
   5.1  Priority Merging Strategies ...................................6
   5.1.1 Take priority of highest QoS .................................6
   5.1.2 Take highest priority ........................................7
   5.1.3 Force error on heterogeneous merge ...........................7
   5.2  Modifying Priority Elements ...................................7
   6 Error Processing .................................................8
   7 IANA Considerations ..............................................8
   8 Security Considerations ..........................................8
   9 References .......................................................9
   10  Author's Address ...............................................9
   Appendix A: Example ...............................................10
   A.1  Computing Merged Priority ....................................10
   A.2  Translation (Compression) of Priority Elements ...............11
   Full Copyright Statement ..........................................12

1  Introduction

   This document describes a preemption priority policy element for use
   by signaled policy based admission protocols (such as [RSVP] and
   [COPS]).

   Traditional Capacity based Admission Control (CAC) indiscriminately
   admits new flows until capacity is exhausted (First Come First
   Admitted).  Policy based Admission Control (PAC) on the other hand
   attempts to minimize the significance of order of arrival and use
   policy based admission criteria instead.

   One of the more popular policy criteria is the rank of importance of
   a flow relative to the others competing for admission into a network
   node.  Preemption Priority takes effect only when a set of flows
   attempting admission through a node represents overbooking of
   resources such that based on CAC some would have to be rejected.
   Preemption priority criteria help the node select the most important
   flows (highest priority) for admission, while rejecting the low
   priority ones.

   Network nodes which support preemption should consider priorities to
   preempt some previously admitted low-priority flows in order to make
   room for a newer, high-priority flow.





Herzog                      Standards Track                     [Page 2]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


   This document describes the format and applicability of the
   preemption priority represented as a policy element in [RSVP-EXT].

2  Scope and Applicability

   The Framework document for policy-based admission control [RAP]
   describes the various components that participate in policy decision
   making (i.e., PDP, PEP and LDP).  The emphasis of PREEMPTION_PRI
   elements is to be simple, stateless, and light-weight such that they
   could be implemented internally within a node's LDP (Local Decision
   Point).

   Certain base assumptions are made in the usage model for
   PREEMPTION_PRI elements:

   -  They are created by PDPs

      In a model where PDPs control PEPs at the periphery of the policy
      domain (e.g., in border routers), PDPs reduce sets of relevant
      policy rules into a single priority criterion.  This priority as
      expressed in the PREEMPTION_PRI element can then be communicated
      to downstream PEPs of the same policy domain, which have LDPs but
      no controlling PDP.

   -  They can be processed by LDPs

      PREEMPTION_PRI elements are processed by LDPs of nodes that do not
      have a controlling PDP.  LDPs may interpret these objects, forward
      them as is, or perform local merging to forward an equivalent
      merged PREEMPTION_PRI policy element.  LDPs must follow the
      merging strategy that was encoded by PDPs in the PREEMPTION_PRI
      objects.  (Clearly, a PDP, being a superset of LDP, may act as an
      LDP as well).

   -  They are enforced by PEPs

      PREEMPTION_PRI elements interact with a node's traffic control
      module (and capacity admission control) to enforce priorities, and
      preempt previously admitted flows when the need arises.

3  Stateless Policy

   Signaled Preemption Priority is stateless (does not require past
   history or external information to be interpreted).  Therefore, when
   carried in COPS messages for the outsourcing of policy decisions,
   these objects are included as COPS Stateless Policy Data Decision
   objects (see [COPS, COPS-RSVP]).




Herzog                      Standards Track                     [Page 3]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


4  Policy Element Format

   The format of Policy Data objects is defined in [RSVP-EXT].  A single
   Policy Data object may contain one or more policy elements, each
   representing a different (and perhaps orthogonal) policy.

   The format of preemption priority policy element is as follows:

      +-------------+-------------+-------------+-------------+
      | Length (12)               | P-Type = PREEMPTION_PRI   |
      +------+------+-------------+-------------+-------------+
      | Flags       | M. Strategy | Error Code  | Reserved(0) |
      +------+------+-------------+-------------+-------------+
      | Preemption Priority       | Defending Priority        |
      +------+------+-------------+-------------+-------------+

   Length: 16 bits
      Always 12.  The overall length of the policy element, in bytes.

   P-Type: 16 bits
      PREEMPTION_PRI  = 1

      This value is registered with IANA, see Section 7.

   Flags: 8 bits
      Reserved (always 0).

   Merge Strategy: 8 bit
      1    Take priority of highest QoS: recommended
      2    Take highest priority: aggressive
      3    Force Error on heterogeneous merge

   Reserved: 8 bits
   Error code: 8 bits
      0  NO_ERROR        Value used for regular PREEMPTION_PRI elements
      1  PREEMPTION      This previously admitted flow was preempted
      2  HETEROGENEOUS   This element encountered heterogeneous merge

   Reserved: 8 bits
      Always 0.

   Preemption Priority: 16 bit (unsigned)
      The priority of the new flow compared with the defending priority
      of previously admitted flows.  Higher values represent higher
      Priority.






Herzog                      Standards Track                     [Page 4]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


   Defending Priority: 16 bits (unsigned)
      Once a flow was admitted, the preemption priority becomes
      irrelevant.  Instead, its defending priority is used to compare
      with the preemption priority of new flows.

   For any specific flow, its preemption priority must always be less
   than or equal to the defending priority.  A wide gap between
   preemption and defending priority provides added stability: moderate
   preemption priority makes it harder for a flow to preempt others, but
   once it succeeded, the higher defending priority makes it easier for
   the flow to avoid preemption itself.  This provides a mechanism for
   balancing between order dependency and priority.

5  Priority Merging Issues

   Consider the case where two RSVP reservations merge:

            F1: QoS=High,  Priority=Low
            F2: QoS=Low,   Priority=High

   F1+F2= F3: QoS=High,  Priority=???

   The merged reservation F3 should have QoS=Hi, but what Priority
   should it assume? Several negative side-effects have been identified
   that may affect such a merger:

   Free-Riders:

   If F3 assumes Priority=High, then F1 got a free ride, assuming high
   priority that was only intended to the low QoS F2.  If one associates
   costs as a function of QoS and priority, F1 receives an "expensive"
   priority without having to "pay" for it.

   Denial of Service:

   If F3 assumes Priority=Low, the merged flow could be preempted or
   fail even though F2 presented high priority.

   Denial of service is virtually the inverse of the free-rider problem.
   When flows compete for resources, if one flow receives undeserving
   high priority it may be able to preempt another deserving flow (hence
   one free-rider turns out to be another's denial of service).









Herzog                      Standards Track                     [Page 5]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


   Instability:

   The combination of preemption priority, killer reservation and
   blockade state [RSVP] may increase the instability of admitted flows
   where a reservation may be preempted, reinstated, and preempted again
   periodically.

5.1  Priority Merging Strategies

   In merging situations LDPs may receive multiple preemption elements
   and must compute the priority of the merged flow according to the
   following rules:

   a. Preemption priority and defending priority are merged and computed
      separately, irrespective of each other.

   b. Participating priority elements are selected.

      All priority elements are examined according to their merging
      strategy to decide whether they should participate in the merged
      result (as specified bellow).

   c. The highest priority of all participating priority elements is
      computed.

   The remainder of this section describes the different merging
   strategies the can be specified in the PREEMPTION_PRI element.

5.1.1  Take priority of highest QoS

   The PREEMPTION_PRI element would participate in the merged
   reservation only if it belongs to a flow that contributed to the
   merged QoS level (i.e., that its QoS requirement does not constitute
   a subset another reservation.)  A simple way to determine whether a
   flow contributed to the merged QoS result is to compute the merged
   QoS with and without it and to compare the results (although this is
   clearly not the most efficient method).

   The reasoning for this approach is that the highest QoS flow is the
   one dominating the merged reservation and as such its priority should
   dominate it as well.  This approach is the most amiable to the
   prevention of priority distortions such as free-riders and denial of
   service.

   This is a recommended merging strategy.






Herzog                      Standards Track                     [Page 6]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


5.1.2  Take highest priority

   All PREEMPTION_PRI elements participate in the merged reservation.

   This strategy disassociates priority and QoS level, and therefore is
   highly subject to free-riders and its inverse image, denial of
   service.

   This is not a recommended method, but may be simpler to implement.

5.1.3  Force error on heterogeneous merge

   A PREEMPTION_PRI element may participate in a merged reservation only
   if all other flows in the merged reservation have the same QoS level
   (homogeneous flows).

   The reasoning for this approach assumes that the heterogeneous case
   is relatively rare and too complicated to deal with, thus it better
   be prohibited.

   This strategy lends itself to denial of service, when a single
   receiver specifying a non-compatible QoS level may cause denial of
   service for all other receivers of the merged reservation.

   Note: The determination of heterogeneous flows applies to QoS level
   only (FLOWSPEC values), and is a matter for local (LDP) definition.
   Other types of heterogeneous reservations (e.g., conflicting
   reservation styles) are handled by RSVP and are unrelated to this
   PREEMPTION_PRI element.

   This is a recommended merging strategy when reservation homogeneity
   is coordinated and enforced for the entire multicast tree.  It is
   more restrictive than Section 5.1.1, but is easier to implement.

5.2  Modifying Priority Elements

   When POLICY_DATA objects are protected by integrity, LDPs should not
   attempt to modify them.  They must be forwarded as-is or else their
   security envelope would be invalidated.  In other cases, LDPs may
   modify and merge incoming PREEMPTION_PRI elements to reduce their
   size and number according to the following rule:

   Merging is performed for each merging strategy separately.

   There is no known algorithm to merge PREEMPTION_PRI element of
   different merging strategies without loosing valuable information
   that may affect OTHER nodes.




Herzog                      Standards Track                     [Page 7]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


   -  For each merging strategy, the highest QoS of all participating
      PREEMPTION_PRI elements is taken and is placed in an outgoing
      PREEMPTION_PRI element of this merging strategy.

   -  This approach effectively compresses the number of forwarded
      PREEMPTION_PRI elements to at most to the number of different
      merging strategies, regardless of the number of receivers (See the
      example in Appendix A.2).

6  Error Processing

   A PREEMPTION_PRI error object is sent back toward the appropriate
   receivers when an error involving PREEMPTION_PRI elements occur.

   PREEMPTION

   When a previously admitted flow is preempted, a copy of the
   preempting flow's PREEMPTION_PRI element is sent back toward the PDP
   that originated the preempted PREEMPTION_PRI object.  This PDP,
   having information on both the preempting and the preempted
   priorities may construct a higher priority PREEMPTION_PRI element in
   an effort to re-instate the preempted flow.

   Heterogeneity

   When a flow F1 with Heterogeneous Error merging strategy set in its
   PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI
   element is sent back toward receivers with the Heterogeneity error
   code set.

7  IANA Considerations

   Following the policies outlined in [IANA-CONSIDERATIONS], Standard
   RSVP Policy Elements (P-type values) are assigned by IETF Consensus
   action as described in [RSVP-EXT].

   P-Type PREEMPTION_PRI is assigned the value 1.

8  Security Considerations

   The integrity of PREEMPTION_PRI is guaranteed, as any other policy
   element, by the encapsulation into a Policy Data object [RSVP-EXT].

   Further security mechanisms are not warranted, especially considering
   that preemption priority aims to provide simple and quick guidance to
   routers within a trusted zone or at least a single zone (no zone
   boundaries are crossed).




Herzog                      Standards Track                     [Page 8]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


9  References

   [RFC2751]             Herzog, S., "Signaled Preemption Priority
                         Policy Element", RFC 2751, January 2000.

   [RSVP-EXT]            Herzog, S., "RSVP Extensions for Policy
                         Control", RFC 2750, January 2000.

   [COPS-RSVP]           Boyle, J., Cohen, R., Durham, D., Herzog, S.,
                         Raja, R. and A. Sastry, "COPS usage for RSVP",
                         RFC 2749, January 2000.

   [RAP]                 Yavatkar, R., Pendarakis, D. and R. Guerin, "A
                         Framework for Policy Based Admission Control",
                         RFC 2753, January 2000.

   [COPS]                Boyle, J., Cohen, R., Durham, D., Herzog, S.,
                         Raja, R. and A. Sastry, "The COPS (Common Open
                         Policy Service) Protocol", RFC 2748, January
                         2000.

   [RSVP]                Braden, R., Zhang, L., Berson, S., Herzog, S.
                         and S. Jamin, "Resource ReSerVation Protocol
                         (RSVP) - Functional Specification", RFC 2205,
                         September 1997.

   [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
                         Writing an IANA Considerations Section in
                         RFCs", BCP 26, RFC 2434, October 1998.

10 Author's Address

   Shai Herzog
   PolicyConsulting.Com
   200 Clove Rd.
   New Rochelle, NY 10801

   EMail: herzog@policyconsulting.com













Herzog                      Standards Track                     [Page 9]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


Appendix A:    Example

   The following examples describe the computation of merged priority
   elements as well as the translation (compression) of PREEMPTION_PRI
   elements.

A.1 Computing Merged Priority

                             r1
                            /   QoS=Hi (Pr=3, St=Highest QoS)
                           /
         s1-----A---------B--------r2  QoS=Low (Pr=4, St=Highest PP)
                 \        \
                  \        \   QoS=Low  (Pr=7, St=Highest QoS)
                   r4        r3

           QoS=Low (Pr=9, St=Error)

         Example 1: Merging preemption priority elements

   Example one describes a multicast scenario with one sender and four
   receivers each with each own PREEMPTION_PRI element definition.

   r1, r2 and r3 merge in B.  The resulting priority is 4.

   Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not
   contributing to the merged QoS) and the priority is the highest of
   the PREEMPTION_PRI from r1 and r2.

   r1, r2, r3 and r4 merge in A.  The resulting priority is again 4: r4
   doesn't participate because its own QoS=Low is incompatible with the
   other (r1) QoS=High.  An error PREEMPTION_PRI should be sent back to
   r4 telling it that its PREEMPTION_PRI element encountered
   heterogeneity.

















Herzog                      Standards Track                    [Page 10]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


A.2 Translation (Compression) of Priority Elements

   Given this set of participating PREEMPTION_PRI elements, the
   following compression can take place at the merging node:

   From:
             (Pr=3, St=Highest QoS)
             (Pr=7, St=Highest QoS)
             (Pr=4, St=Highest PP)
             (Pr=9, St=Highest PP)
             (Pr=6, St=Highest PP)
   To:
             (Pr=7, St=Highest QoS)
             (Pr=9, St=Highest PP)





































Herzog                      Standards Track                    [Page 11]

RFC 3181      Signaled Preemption Priority Policy Element   October 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Herzog                      Standards Track                    [Page 12]