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
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
|
<pre>Internet Engineering Task Force (IETF) G. Ash
Request for Comments: 5976 A. Morton
Category: Experimental M. Dolly
ISSN: 2070-1721 P. Tarapore
C. Dvorak
AT&T Labs
Y. El Mghazli
Alcatel-Lucent
October 2010
Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
Abstract
This document describes a QoS-NSLP Quality-of-Service model (QOSM)
based on ITU-T Recommendation Y.1541 Network QoS Classes and related
guidance on signaling. Y.1541 specifies 8 classes of Network
Performance objectives, and the Y.1541-QOSM extensions include
additional QSPEC parameters and QOSM processing guidelines.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5976">http://www.rfc-editor.org/info/rfc5976</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
<span class="grey">Ash, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
2. Summary of ITU-T Recommendations Y.1541 and Signaling
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Description of Y.1541 Classes . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Y.1541-QOSM Processing Requirements . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.1">3.1</a>. Traffic Model (TMOD) Extension Parameter . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Restoration Priority Parameter . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Y.1541-QOSM Considerations and Processing Example . . . . . . <a href="#page-10">10</a>
<a href="#section-4.1">4.1</a>. Deployment Considerations . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.2">4.2</a>. Applicable QSPEC Procedures . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. QNE Processing Rules . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Processing Example . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.5">4.5</a>. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.6">4.6</a>. Preemption Behavior . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5">5</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.1">5.1</a>. Assignment of QSPEC Parameter IDs . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.2">5.2</a>. Restoration Priority Parameter Registry . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.2.1">5.2.1</a>. Restoration Priority Field . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.2.2">5.2.2</a>. Time to Restore Field . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.2.3">5.2.3</a>. Extent of Restoration Field . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Ash, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes a QoS model (QOSM) for Next Steps in
Signaling (NSIS) QoS signaling layer protocol (QoS-NSLP) application
based on ITU-T Recommendation Y.1541 Network QoS Classes and related
guidance on signaling. [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] currently specifies 8 classes of
Network Performance objectives, and the Y.1541-QOSM extensions
include additional QSPEC [<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>] parameters and QOSM processing
guidelines. The extensions are based on standardization work in the
ITU-T on QoS signaling requirements ([<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] and [<a href="#ref-E.361" title=""QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies"">E.361</a>]), and
guidance in [<a href="#ref-TRQ-QoS-SIG" title=""Signaling Requirements for IP-QoS"">TRQ-QoS-SIG</a>].
[<a id="ref-RFC5974">RFC5974</a>] defines message types and control information for the QoS-
NSLP that are generic to all QOSMs. A QOSM is a defined mechanism
for achieving QoS as a whole. The specification of a QOSM includes a
description of its QSPEC parameter information, as well as how that
information should be treated or interpreted in the network. The
QSPEC [<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>] contains a set of parameters and values describing
the requested resources. It is opaque to the QoS-NSLP and similar in
purpose to the TSpec, RSpec, and AdSpec specified in [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] and
[<a href="./rfc2210" title=""The Use of RSVP with IETF Integrated Services"">RFC2210</a>]. A QOSM provides a specific set of parameters to be
carried in the QSPEC object. At each QoS NSIS Entity (QNE), the
QSPEC contents are interpreted by the resource management function
(RMF) for purposes of policy control and traffic control, including
admission control and configuration of the scheduler.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Summary of ITU-T Recommendations Y.1541 and Signaling Requirements</span>
As stated above, [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] is a specification of standardized QoS
classes for IP networks (a summary of these classes is given below).
Section 7 of [<a href="#ref-TRQ-QoS-SIG" title=""Signaling Requirements for IP-QoS"">TRQ-QoS-SIG</a>] describes the signaling features needed to
achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a
basis. [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] recommends a flexible allocation of the end-to-end
performance objectives (e.g., delay) across networks, rather than a
fixed per-network allocation. NSIS protocols already address most of
the requirements; this document identifies additional QSPEC
parameters and processing requirements needed to support the Y.1541
QOSM.
<span class="grey">Ash, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Description of Y.1541 Classes</span>
[<a id="ref-Y.1541">Y.1541</a>] proposes grouping services into QoS classes defined
according to the desired QoS performance objectives. These QoS
classes support a wide range of user applications. The classes group
objectives for one-way IP packet delay, IP packet delay variation, IP
packet loss ratio, etc., where the parameters themselves are defined
in [<a href="#ref-Y.1540" title=""Internet protocol data communication service - IP packet transfer and availability performance parameters"">Y.1540</a>].
Note that [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] is maintained by the ITU-T and subject to
occasional updates and revisions. The material in this section is
provided for information and to make this document easier to read.
In the event of any discrepancies, the normative definitions found in
[<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] take precedence.
Classes 0 and 1 might be implemented using the Diffserv Expedited
Forwarding (EF) Per-Hop Behavior (PHB), and they support interactive
real-time applications [<a href="./rfc3246" title=""An Expedited Forwarding PHB (Per-Hop Behavior)"">RFC3246</a>]. Classes 2, 3, and 4 might be
implemented using the Diffserv Assured Forwarding (AFxy) PHB Group,
and they support data transfer applications with various degrees of
interactivity [<a href="./rfc2597" title=""Assured Forwarding PHB Group"">RFC2597</a>]. Class 5 generally corresponds to the
Diffserv Default PHB, and it has all the QoS parameters unspecified
consistent with a best-effort service[RFC2474]. Classes 6 and 7
provide support for extremely loss-sensitive user applications, such
as high-quality digital television, Time Division Multiplexing (TDM)
circuit emulation, and high-capacity file transfers using TCP. These
classes are intended to serve as a basis for agreements between end-
users and service providers, and between service providers. They
support a wide range of user applications including point-to-point
telephony, data transfer, multimedia conferencing, and others. The
limited number of classes supports the requirement for feasible
implementation, particularly with respect to scale in global
networks.
The QoS classes apply to a packet flow, where [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] defines a
packet flow as the traffic associated with a given connection or
connectionless stream having the same source host, destination host,
class of service, and session identification. The characteristics of
each Y.1541 QoS class are summarized here:
Class 0:
Real-time, highly interactive applications, sensitive to jitter.
Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <=
10^-3. Application examples include VoIP and video teleconference.
<span class="grey">Ash, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
Class 1:
Real-time, interactive applications, sensitive to jitter. Mean delay
<= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3.
Application examples include VoIP and video teleconference.
Class 2:
Highly interactive transaction data. Mean delay <= 100 ms, delay
variation is unspecified, loss ratio <= 10^-3. Application examples
include signaling.
Class 3:
Interactive transaction data. Mean delay <= 400 ms, delay variation
is unspecified, loss ratio <= 10^-3. Application examples include
signaling.
Class 4:
Low Loss Only applications. Mean delay <= 1 s, delay variation is
unspecified, loss ratio <= 10^-3. Application examples include short
transactions, bulk data, and video streaming.
Class 5:
Unspecified applications with unspecified mean delay, delay
variation, and loss ratio. Application examples include traditional
applications of default IP networks.
Class 6:
Applications that are highly sensitive to loss. Mean delay <= 100
ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application
examples include television transport, high-capacity TCP transfers,
and Time-Division Multiplexing (TDM) circuit emulation.
Class 7:
Applications that are highly sensitive to loss. Mean delay <= 400
ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application
examples include television transport, high-capacity TCP transfers,
and TDM circuit emulation.
These classes enable service level agreements (SLAs) to be defined
between customers and network service providers with respect to QoS
requirements. The service provider then needs to ensure that the
requirements are recognized and receive appropriate treatment across
network layers.
Work is in progress to specify methods for combining local values of
performance metrics to estimate the performance of the complete path.
See Section 8 of [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>], [<a href="./rfc5835" title=""Framework for Metric Composition"">RFC5835</a>], and [<a href="#ref-COMPOSITION" title=""Spatial Composition of Metrics"">COMPOSITION</a>].
<span class="grey">Ash, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Y.1541-QOSM Processing Requirements</span>
[<a id="ref-TRQ-QoS-SIG">TRQ-QoS-SIG</a>] guides the specification of signaling information for
IP-based QoS at the interface between the user and the network (UNI)
and across interfaces between different networks (NNI). To meet
specific network performance requirements specified for the Y.1541
QoS classes [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] , a network needs to provide specific user-plane
functionality at the UNI and NNI. Dynamic network provisioning at a
UNI and/or NNI node allows a traffic contract for an IP flow to be
dynamically requested from a specific source node to one or more
destination nodes. In response to the request, the network
determines if resources are available to satisfy the request and
provision the network.
For implementations to claim compliance with this memo, it MUST be
possible to derive the following service-level parameters as part of
the process of requesting service:
a. Y.1541 QoS class, 32-bit integer, range: 0-7
b. rate (r), octets per second
c. peak rate (p), octets per second
d. bucket size (b), octets
e. maximum packet size (MPS), octets, IP header + IP payload
f. Diffserv PHB class [<a href="./rfc2475" title=""An Architecture for Differentiated Services"">RFC2475</a>]
g. admission priority, 32-bit integer, range: 0-2
Compliant implementations MAY derive the following service-level
parameters as part of the service request process:
h. peak bucket size (Bp), octets, 32-bit floating point number in
single-precision IEEE floating point format [<a href="#ref-IEEE754" title=""ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic"">IEEE754</a>]
i. restoration priority, multiple integer values defined in
<a href="#section-3">Section 3</a> below
All parameters except Bp and restoration priority have already been
specified in [<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>]. These additional parameters are defined as
o Bp, the size of the peak-rate bucket in a dual-token bucket
arrangement, essentially setting the maximum length of bursts in
the peak-rate stream. For example, see Annex B of [<a href="#ref-Y.1221" title=""Traffic control and congestion control in IP based networks"">Y.1221</a>]
<span class="grey">Ash, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
o restoration priority, as defined in <a href="#section-3">Section 3</a> of this memo
Their QSPEC Parameter format is specified in <a href="#section-3">Section 3</a>.
It MUST be possible to perform the following QoS-NSLP signaling
functions to meet Y.1541-QOSM requirements:
a. accumulate delay, delay variation, and loss ratio across the end-
to-end connection, which may span multiple domains.
b. enable negotiation of Y.1541 QoS class across domains.
c. enable negotiation of delay, delay variation, and loss ratio
across domains.
These signaling requirements are supported in [<a href="./rfc5974" title=""NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling"">RFC5974</a>], and the
functions are illustrated in <a href="#section-4">Section 4</a> of this memo.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Additional QSPEC Parameters for Y.1541 QOSM</span>
The specifications in this section extend the QSPEC [<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Traffic Model (TMOD) Extension Parameter</span>
The traffic model (TMOD) extension parameter is represented by one
floating point number in single-precision IEEE floating point format
and one 32-bit reserved field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 15 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TMOD Extension
The Peak Bucket Size term, Bp, is represented as an IEEE floating
point value [<a href="#ref-IEEE754" title=""ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic"">IEEE754</a>] in units of octets. The sign bit MUST be zero
(all values MUST be non-negative). Exponents less than 127 (i.e., 0)
are prohibited. Exponents greater than 162 (i.e., positive 35) are
discouraged, except for specifying a peak rate of infinity. Infinity
is represented with an exponent of all ones (255), and a sign bit and
mantissa of all zeros.
<span class="grey">Ash, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
The QSPEC parameter behavior for the TMOD extended parameter follows
that defined in <a href="./rfc5975#section-3.3.1">Section 3.3.1 of [RFC5975]</a>. The new parameter (and
all traffic-related parameters) are specified independently from the
Y.1541 class parameter.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Restoration Priority Parameter</span>
Restoration priority is the urgency with which a service requires
successful restoration under failure conditions. Restoration
priority is achieved by provisioning sufficient backup capacity, as
necessary, and allowing relative priority for access to available
bandwidth when there is contention for restoration bandwidth.
Restoration priority is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| 16 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest. Priority| TTR | EOR | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Restoration Priority Parameter
This parameter has three fields and a reserved area, as defined
below.
Restoration Priority Field (8-bit unsigned integer): 3 priority
values are listed here in the order of lowest priority to highest
priority:
0 - best effort
1 - normal
2 - high
These priority values are described in [<a href="#ref-Y.2172" title=""Service restoration priority levels in Next Generation Networks"">Y.2172</a>], where best-effort
priority is the same as Priority level 3, normal priority is
Priority level 2, and high priority is Priority level 1. There
are several ways to elaborate on restoration priority, and the two
current parameters are described below.
Time-to-Restore (TTR) Field (4-bit unsigned integer): Total amount
of time to restore traffic streams belonging to a given
restoration class impacted by the failure. This time period
depends on the technology deployed for restoration. A fast
recovery period of < 200 ms is based on current experience with
<span class="grey">Ash, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
Synchronous Optical Network (SONET) rings and a slower recovery
period of 2 seconds is suggested in order to enable a voice call
to recover without being dropped. Accordingly, TTR restoration
suggested ranges are:
0 - Unspecified Time-to-Restore
1 - Best Time-to-Restore: <= 200 ms
2 - Normal Time-to-Restore <= 2 s
Extent of Restoration (EOR) Field (4-bit unsigned integer):
Percentage of traffic belonging to the restoration class that can
be restored. This percentage depends on the amount of spare
capacity engineered. All high-priority restoration traffic, for
example, may be "guaranteed" at 100% by the service provider.
Other classes may offer lesser chances for successful restoration.
The restoration extent for these lower priority classes depend on
SLAs developed between the service provider and the customer.
EOR values are assigned as follows:
0 - unspecified EOR
1 - high priority restored at 100%;
medium priority restored at 100%
2 - high priority restored at 100%;
medium priority restored at 80%
3 - high priority restored >= 80%;
medium priority restored >= 80%
4 - high priority restored >= 80%;
medium priority restored >= 60%
5 - high priority restored >= 60%;
medium priority restored >= 60%
Reserved: These 2 octets are reserved. The Reserved bits MAY be
designated for other uses in the future. Senders conforming to
this version of the Y.1541 QOSM SHALL set the Reserved bits to
zero. Receivers conforming to this version of the Y.1541 QOSM
SHALL ignore the Reserved bits.
<span class="grey">Ash, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Y.1541-QOSM Considerations and Processing Example</span>
In this section, we illustrate the operation of the Y.1541 QOSM, and
show how current QoS-NSLP and QSPEC functionality is used. No new
processing capabilities are required to enable the Y.1541 QOSM
(excluding the two OPTIONAL new parameters specified in <a href="#section-3">Section 3</a>).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Deployment Considerations</span>
[<a id="ref-TRQ-QoS-SIG">TRQ-QoS-SIG</a>] emphasizes the deployment of Y.1541 QNEs at the borders
of supporting domains. There may be domain configurations where
interior QNEs are desirable, and the example below addresses this
possibility.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Applicable QSPEC Procedures</span>
All procedures defined in <a href="./rfc5975#section-5.3">Section 5.3 of [RFC5975]</a> are applicable to
this QOSM.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. QNE Processing Rules</span>
Section 7 of [<a href="#ref-TRQ-QoS-SIG" title=""Signaling Requirements for IP-QoS"">TRQ-QoS-SIG</a>] describes the information processing in
Y.1541 QNEs.
Section 8 of [<a href="#ref-Y.1541" title=""Network Performance Objectives for IP-Based Services"">Y.1541</a>] defines the accumulation rules for individual
performance parameters (e.g., delay, jitter).
When a QoS NSIS initiator (QNI) specifies the Y.1541 QoS Class
number, <Y.1541 QoS Class>, it is a sufficient specification of
objectives for the <Path Latency>, <Path Jitter>, and <Path BER>
parameters. As described in <a href="#section-2">Section 2</a>, some Y.1541 Classes do not
set objectives for all the performance parameters above. For
example, Classes 2, 3, and 4 do not specify an objective for <Path
Jitter> (referred to as IP Packet Delay Variation). In the case that
the QoS Class leaves a parameter unspecified, then that parameter
need not be included in the accumulation processing.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Processing Example</span>
As described in the example given in <a href="./rfc5975#section-3.4">Section 3.4 of [RFC5975]</a> and as
illustrated in Figure 3, the QoS NSIS initiator (QNI) initiates an
end-to-end, interdomain QoS NSLP RESERVE message containing the
Initiator QSPEC. In the case of the Y.1541 QOSM, the Initiator QSPEC
specifies the <Y.1541 QOS Class>, <TMOD>, <TMOD Extension>,
<Admission Priority>, <Restoration Priority>, and perhaps other QSPEC
parameters for the flow. As described in <a href="#section-3">Section 3</a>, the TMOD
<span class="grey">Ash, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
extension parameter contains the OPTIONAL Y.1541-QOSM-specific terms;
restoration priority is also an OPTIONAL Y.1541-QOSM-specific
parameter.
As Figure 3 below shows, the RESERVE message may cross multiple
domains supporting different QOSMs. In this illustration, the
Initiator QSPEC arrives in a QoS NSLP RESERVE message at the ingress
node of the local-QOSM domain. As described in [<a href="./rfc5974" title=""NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling"">RFC5974</a>] and
[<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>], at the ingress edge node of the local-QOSM domain, the
end-to-end, interdomain QoS-NSLP message may trigger the generation
of a Local QSPEC, and the Initiator QSPEC is encapsulated within the
messages signaled through the local domain. The Local QSPEC is used
for QoS processing in the local-QOSM domain, and the Initiator QSPEC
is used for QoS processing outside the local domain. As specified in
[<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>], if any QNE cannot meet the requirements designated by the
Initiator QSPEC to support an optional QSPEC parameter (i.e., with
the M bit set to zero for the parameter), the QNE sets the N flag
(not supported flag) for the parameter to one. For example, if the
QNE cannot support the accumulation of end-to-end delay with the
<Path Latency> parameter, where the M flag for the <Path Latency>
parameter is set to zero denoting <Path Latency> as an optional
parameter, the QNE sets the N flag (not supported flag) for the <Path
Latency> parameter to one.
Also, the Y.1541-QOSM requires negotiation of the <Y.1541 QoS Class>
across domains. This negotiation can be done with the use of the
existing procedures already defined in [<a href="./rfc5974" title=""NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling"">RFC5974</a>]. For example, the
QNI sets <Desired QoS>, <Minimum QoS>, and <Available QoS> objects to
include <Y.1541 QoS Class>, which specifies objectives for the <Path
Latency>, <Path Jitter>, and <Path BER> parameters. In the case that
the QoS Class leaves a parameter unspecified, then that parameter
need not be included in the accumulation processing. The QNE/domain
SHOULD set the Y.1541 class and cumulative parameters, e.g., <Path
Latency>, that can be achieved in the <QoS Available> object (but not
less than specified in <Minimum QoS>). This could include, for
example, setting the <Y.1541 QoS Class> to a lower class than
specified in <QoS Desired> (but not lower than specified in <Minimum
QoS>). If the <Available QoS> fails to satisfy one or more of the
<Minimum QoS> objectives, the QNE/domain notifies the QNI and the
reservation is aborted. Otherwise, the QoS NSIS Receiver (QNR)
notifies the QNI of the <QoS Available> for the reservation.
When the available <Y.1541 QoS Class> must be reduced from the
desired <Y.1541 QoS Class> (say, because the delay objective has been
exceeded), then there is an incentive to respond with an available
value for delay in the <Path Latency> parameter. If the available
<Path Latency> is 150 ms (still useful for many applications) and the
desired QoS is Class 0 (with its 100 ms objective), then the response
<span class="grey">Ash, et al. Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
would be that Class 0 cannot be achieved, and Class 1 is available
(with its 400 ms objective). In addition, this QOSM allows the
response to include an available <Path Latency> = 150 ms, making
acceptance of the available <Y.1541 QoS Class> more likely. There
are many long paths where the propagation delay alone exceeds the
Y.1541 Class 0 objective, so this feature adds flexibility to commit
to exceed the Class 1 objective when possible.
This example illustrates Y.1541-QOSM negotiation of <Y.1541 QoS
Class> and cumulative parameter values that can be achieved end-to-
end. The example illustrates how the QNI can use the cumulative
values collected in <QoS Available> to decide if a lower <Y.1541 QoS
Class> than specified in <QoS Desired> is acceptable.
|------| |------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Y.1541| |local | |local | |local | |local | |Y.1541|
| QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM |
|------| |------| |-------| |-------| |------| |------|
-----------------------------------------------------------------
|------| |------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |
|------| |------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End)
Figure 3: Example of Y.1541-QOSM Operation
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Bit-Level QSPEC Example</span>
This is an example where the QOS Desired specification contains the
TMOD-1 parameters and TMOD extended parameters defined in this
specification, as well as the Y.1541 Class parameter. The QOS
Available specification utilizes the Latency, Jitter, and Loss
parameters to enable accumulation of these parameters for easy
comparison with the objectives desired for the Y.1541 Class.
This example assumes that all the parameters MUST be supported by the
QNEs, so all M-flags have been set to 1.
<span class="grey">Ash, et al. Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R| Length = 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 [m] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MPS] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 15 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail) |r|r|r|r| Length = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 14 |r|r|r|r| 1 |
<span class="grey">Ash, et al. Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: An Example QSPEC (Initiator)
where 32-bit floating point numbers are as specified in [<a href="#ref-IEEE754" title=""ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic"">IEEE754</a>].
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Preemption Behavior</span>
The default QNI behavior of tearing down a preempted reservation is
followed in the Y.1541 QOSM. The restoration priority parameter
described above does not rely on preemption.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This section defines additional codepoint assignments in the QSPEC
Parameter ID registry and establishes one new registry for the
Restoration Priority Parameter (and assigns initial values), in
accordance with <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a> [<a href="./rfc5226" title="">RFC5226</a>]. It also defines the procedural
requirements to be followed by IANA in allocating new codepoints for
the new registry.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Assignment of QSPEC Parameter IDs</span>
This document specifies the following QSPEC parameters, which have
been assigned in the QSPEC Parameter ID registry created in
[<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>]:
<TMOD Extension> parameter (<a href="#section-3.1">Section 3.1</a>, ID=15)
<Restoration Priority> parameter (<a href="#section-3.2">Section 3.2</a>, ID=16)
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Restoration Priority Parameter Registry</span>
The Registry for Restoration Priority contains assignments for 3
fields in the 4-octet word and a Reserved section of the word.
This specification creates the following registry with the structure
as defined below.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Restoration Priority Field</span>
The Restoration Priority Field is 8 bits in length.
The following values are allocated by this specification:
<span class="grey">Ash, et al. Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
0-2: assigned as specified in <a href="#section-3.2">Section 3.2</a>:
0: best-effort priority
1: normal priority
2: high priority
Further values are as follows:
3-255: Unassigned
The registration procedure is Specification Required.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Time to Restore Field</span>
The Time to Restore Field is 4 bits in length.
The following values are allocated by this specification:
0-2: assigned as specified in <a href="#section-3.2">Section 3.2</a>:
0 - Unspecified Time-to-Restore
1 - Best Time-to-Restore: <= 200 ms
2 - Normal Time-to-Restore <= 2 s
Further values are as follows:
3-15: Unassigned
The registration procedure is Specification Required.
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. Extent of Restoration Field</span>
The Extent of Restoration (EOR) Field is 4 bits in length.
The following values are allocated by this specification:
0-5: assigned as specified in <a href="#section-3.2">Section 3.2</a>:
0 - unspecified EOR
1 - high priority restored at 100%;
medium priority restored at 100%
<span class="grey">Ash, et al. Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
2 - high priority restored at 100%;
medium priority restored at 80%
3 - high priority restored >= 80%;
medium priority restored >= 80%
4 - high priority restored >= 80%;
medium priority restored >= 60%
5 - high priority restored >= 60%;
medium priority restored >= 60%
Further values are as follows:
6-15: Unassigned
The registration procedure is Specification Required.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The security considerations of [<a href="./rfc5974" title=""NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling"">RFC5974</a>] and [<a href="./rfc5975" title=""QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)"">RFC5975</a>] apply to this
document.
The restoration priority parameter raises possibilities for theft-of-
service attacks because users could claim an emergency priority for
their flows without real need, thereby effectively preventing serious
emergency calls from getting through. Several options exist for
countering such attacks, for example:
- only some user groups (e.g., the police) are authorized to set the
emergency priority bit
- any user is authorized to employ the emergency priority bit for
particular destination addresses (e.g., police or fire
departments)
There are no other known security considerations based on this
document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch,
and Hannes Tschofenig for helpful comments and discussion.
<span class="grey">Ash, et al. Experimental [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-IEEE754">IEEE754</a>] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for
Binary Floating-Point Arithmetic", 1985.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5974">RFC5974</a>] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", <a href="./rfc5974">RFC 5974</a>, October 2010.
[<a id="ref-RFC5975">RFC5975</a>] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC
Template for the Quality-of-Service NSIS Signaling
Layer Protocol (NSLP)", <a href="./rfc5975">RFC 5975</a>, October 2010.
[<a id="ref-Y.1221">Y.1221</a>] ITU-T Recommendation Y.1221, "Traffic control and
congestion control in IP based networks", March 2002.
[<a id="ref-Y.1540">Y.1540</a>] ITU-T Recommendation Y.1540, "Internet protocol data
communication service - IP packet transfer and
availability performance parameters", December 2007.
[<a id="ref-Y.1541">Y.1541</a>] ITU-T Recommendation Y.1541, "Network Performance
Objectives for IP-Based Services", February 2006.
[<a id="ref-Y.2172">Y.2172</a>] ITU-T Recommendation Y.2172, "Service restoration
priority levels in Next Generation Networks", June
2007.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-COMPOSITION">COMPOSITION</a>] Morton, A. and E. Stephan, "Spatial Composition of
Metrics", Work in Progress, July 2010.
[<a id="ref-E.361">E.361</a>] ITU-T Recommendation E.361, "QoS Routing Support for
Interworking of QoS Service Classes Across Routing
Technologies", May 2003.
[<a id="ref-RFC2205">RFC2205</a>] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", <a href="./rfc2205">RFC 2205</a>,
September 1997.
[<a id="ref-RFC2210">RFC2210</a>] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", <a href="./rfc2210">RFC 2210</a>, September 1997.
<span class="grey">Ash, et al. Experimental [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
[<a id="ref-RFC2474">RFC2474</a>] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>,
December 1998.
[<a id="ref-RFC2475">RFC2475</a>] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Services", <a href="./rfc2475">RFC 2475</a>, December 1998.
[<a id="ref-RFC2597">RFC2597</a>] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", <a href="./rfc2597">RFC 2597</a>, June 1999.
[<a id="ref-RFC3246">RFC3246</a>] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", <a href="./rfc3246">RFC 3246</a>, March 2002.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC</a>
<a href="./rfc5226">5226</a>, May 2008.
[<a id="ref-RFC5835">RFC5835</a>] Morton, A. and S. Van den Berghe, "Framework for
Metric Composition", <a href="./rfc5835">RFC 5835</a>, April 2010.
[<a id="ref-TRQ-QoS-SIG">TRQ-QoS-SIG</a>] ITU-T Supplement 51 to the Q-Series, "Signaling
Requirements for IP-QoS", January 2004.
Authors' Addresses
Gerald Ash
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
EMail: gash5107@yahoo.com
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: <a href="http://home.comcast.net/~acmacm/">http://home.comcast.net/~acmacm/</a>
<span class="grey">Ash, et al. Experimental [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5976">RFC 5976</a> Y.1541 QOSM October 2010</span>
Martin Dolly
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
EMail: mdolly@att.com
Percy Tarapore
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
EMail: tarapore@att.com
Chuck Dvorak
AT&T Labs
180 Park Ave Bldg 2
Florham Park, NJ 07932
USA
Phone: + 1 973-236-6700
EMail: cdvorak@att.com
Yacine El Mghazli
Alcatel-Lucent
Route de Nozay
Marcoussis cedex 91460
France
Phone: +33 1 69 63 41 87
EMail: yacine.el_mghazli@alcatel.fr
Ash, et al. Experimental [Page 19]
</pre>
|
