Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
RFC 5976
| Document | Type | RFC - Experimental (October 2010) | |
|---|---|---|---|
| Authors | Al Morton , Yacine El Mghazli , Martin Dolly , Percy Tarapore , Gerald Ash , Chuck Dvorak | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Magnus Westerlund | |
| Send notices to | (None) |
RFC 5976
<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 Ash, et al. Experimental [Page 11] RFC 5976 Y.1541 QOSM October 2010 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 4.5. Bit-Level QSPEC Example 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. Ash, et al. Experimental [Page 12] RFC 5976 Y.1541 QOSM October 2010 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 | Ash, et al. Experimental [Page 13] RFC 5976 Y.1541 QOSM October 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Y.1541 QoS Cls.| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: An Example QSPEC (Initiator) where 32-bit floating point numbers are as specified in [IEEE754]. 4.6. Preemption Behavior 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. 5. IANA Considerations 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 BCP 26 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints for the new registry. 5.1. Assignment of QSPEC Parameter IDs This document specifies the following QSPEC parameters, which have been assigned in the QSPEC Parameter ID registry created in [RFC5975]: <TMOD Extension> parameter (Section 3.1, ID=15) <Restoration Priority> parameter (Section 3.2, ID=16) 5.2. Restoration Priority Parameter Registry 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. 5.2.1. Restoration Priority Field The Restoration Priority Field is 8 bits in length. The following values are allocated by this specification: Ash, et al. Experimental [Page 14] RFC 5976 Y.1541 QOSM October 2010 0-2: assigned as specified in Section 3.2: 0: best-effort priority 1: normal priority 2: high priority Further values are as follows: 3-255: Unassigned The registration procedure is Specification Required. 5.2.2. Time to Restore Field The Time to Restore Field is 4 bits in length. The following values are allocated by this specification: 0-2: assigned as specified in Section 3.2: 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. 5.2.3. Extent of Restoration Field 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 Section 3.2: 0 - unspecified EOR 1 - high priority restored at 100%; medium priority restored at 100% Ash, et al. Experimental [Page 15] RFC 5976 Y.1541 QOSM October 2010 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. 6. Security Considerations The security considerations of [RFC5974] and [RFC5975] 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. 7. Acknowledgements The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, and Hannes Tschofenig for helpful comments and discussion. Ash, et al. Experimental [Page 16] RFC 5976 Y.1541 QOSM October 2010 8. References 8.1. Normative References [IEEE754] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic", 1985. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010. [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010. [Y.1221] ITU-T Recommendation Y.1221, "Traffic control and congestion control in IP based networks", March 2002. [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2007. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006. [Y.2172] ITU-T Recommendation Y.2172, "Service restoration priority levels in Next Generation Networks", June 2007. 8.2. Informative References [COMPOSITION] Morton, A. and E. Stephan, "Spatial Composition of Metrics", Work in Progress, July 2010. [E.361] ITU-T Recommendation E.361, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies", May 2003. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. Ash, et al. Experimental [Page 17] RFC 5976 Y.1541 QOSM October 2010 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3246] 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)", RFC 3246, March 2002. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010. [TRQ-QoS-SIG] 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: http://home.comcast.net/~acmacm/ Ash, et al. Experimental [Page 18] RFC 5976 Y.1541 QOSM October 2010 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]