Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes
draft-ietf-nsis-y1541-qosm-10

Abstract

This draft describes a QoS-NSLP QoS 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.

Requirements Language

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 9, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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 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

1.  Introduction
2.  Summary of ITU-T Recommendations Y.1541 & Signaling Requirements
    2.1.  Description of Y.1541 Classes
    2.2.  Y.1541-QOSM Processing Requirements
3.  Additional QSPEC Parameters for Y.1541 QOSM
    3.1.  Traffic Model (TMOD) Extension Parameter
    3.2.  Restoration Priority Parameter
4.  Y.1541-QOSM Considerations and Processing Example
    4.1.  Deployment Considerations
    4.2.  Applicable QSPEC Procedures
    4.3.  QNE Processing Rules
    4.4.  Processing Example
    4.5.  Bit-Level QSPEC Example
    4.6.  Preemption Behaviour
5.  IANA Considerations
    5.1.  Assignment of QSPEC Parameter IDs
    5.2.  Restoration Priority Parameter Registry
        5.2.1.  Restoration Priority Field
        5.2.2.  Time to Restore Field
        5.2.3.  Extent of Restoration Field
        5.2.4.  Reserved Bits
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

This draft 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. [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) currently specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) parameters and QOSM processing guidelines. The extensions are based on standardization work in the ITU-T on QoS signaling requirements [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) and [E.361] (ITU-T Recommendation E.361, “QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies,” May 2003.), and guidance in [TRQ‑QoS‑SIG] (ITU-T Supplement 51 to the Q-Series, “Signaling Requirements for IP-QoS,” January  2004.).

[I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.) defines message types and control information for the QoS-NSLP 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 [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) 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 [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) [RFC2210] (Wroclawski, J., “The Use of RSVP with IETF Integrated Services,” September 1997.). 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.

2.  Summary of ITU-T Recommendations Y.1541 & Signaling Requirements

As stated above, [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) is a specification of standardized QoS classes for IP networks (a summary of these classes is given below). Section 7 of [TRQ‑QoS‑SIG] (ITU-T Supplement 51 to the Q-Series, “Signaling Requirements for IP-QoS,” January  2004.) describes the signaling features needed to achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a basis. [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) 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.

2.1.  Description of Y.1541 Classes

[Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) 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 [Y.1540] (ITU-T Recommendation Y.1540, “Internet protocol data communication service - IP packet transfer and availability performance parameters,” December  2007.).

Note that [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) 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 [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) take precidence.

Classes 0 and 1 might be implemented using the DiffServ Expedited Forwarding (EF) Per-Hop Behavior (PHB), and support interactive real-time applications[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),” March 2002.). Classes 2, 3, and 4 might be implemented using the DiffServ Assured Forwarding (AFxy) PHB Group, and support data transfer applications with various degrees of interactivity[RFC2597] (Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” June 1999.). Class 5 generally corresponds to the DiffServ Default PHB, has all the QoS parameters unspecified consistent with a best-effort service[RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.). Classes 6 and 7 provide support for extremely loss-sensitive user applications, such as high quality digital television, Time Division Multiplex (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 [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) 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 upper bound is 100 ms, delay variation is less than 50 ms, and loss ratio is less than 10^-3. Application examples include VoIP, Video Teleconference.

Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay upper bound is 400 ms, delay variation is less than 50 ms, and loss ratio is less than 10^-3. Application examples include VoIP, video teleconference.

Class 2: Highly interactive transaction data. Mean delay upper bound is 100 ms, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include signaling.

Class 3: Interactive transaction data. Mean delay upper bound is 400 ms, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include signaling.

Class 4: Low Loss Only applications. Mean delay upper bound is 1s, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include short transactions, bulk data, 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: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation.

Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation.

These classes enable 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 [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.), [I‑D.ietf‑ippm‑framework‑compagg] (Morton, A., “Framework for Metric Composition,” December 2009.), and [I‑D.ietf‑ippm‑spatial‑composition] (Morton, A. and E. Stephan, “Spatial Composition of Metrics,” April 2010.).

2.2.  Y.1541-QOSM Processing Requirements

[TRQ‑QoS‑SIG] (ITU-T Supplement 51 to the Q-Series, “Signaling Requirements for IP-QoS,” January  2004.) 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 [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) , a network needs to provide specific user plane functionality at UNI and NNI interfaces. Dynamic network provisioning at a UNI and/or NNI node allows the ability to dynamically request a traffic contract for an IP flow 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 (M), octets, IP header + IP payload

f. DiffServ PHB class [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.)

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 [IEEE754] (ANSI/IEEE, “ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic,” 1985.)

i. restoration priority*, multiple integer values defined in Section 3 below

All parameters except Bp and restoration priority have already been specified in [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.). These additional parameters are defined as

• 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 [Y.1221] (ITU-T Recommendation Y.1221, “Traffic control and congestion control in IP based networks,” March  2002.)
• restoration priority, as defined in Section 3 of this memo

and their QSPEC Parameter format is specified in Section 3.

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 [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.) and the functions are illustrated in Section 4 of this memo.

3.  Additional QSPEC Parameters for Y.1541 QOSM

The specifications in this section extend the QSPEC [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.).

3.1.  Traffic Model (TMOD) Extension Parameter

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)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Peak Bucket Size term, Bp, is represented as an IEEE floating point value [IEEE754] (ANSI/IEEE, “ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic,” 1985.) 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.

The QSPEC parameter behavior for the TMOD extended parameter follows that defined in Section 3.3.1 of[I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.). The new parameter (and all traffic-related parameters) are specified independently from the Y.1541 class parameter.

3.2.  Restoration Priority Parameter

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)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 [Y.2172] (ITU-T Recommendation Y.2172, “Service restoration priority levels in Next Generation Networks,” June 2007.), where best effort priority is the same as Priority level 3, normal priority is Priority level 2, and high priority is the same as 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 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 priority 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 SLA agreements 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.

4.  Y.1541-QOSM Considerations and Processing Example

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 Section 3).

4.1.  Deployment Considerations

[TRQ‑QoS‑SIG] (ITU-T Supplement 51 to the Q-Series, “Signaling Requirements for IP-QoS,” January  2004.) 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.

4.2.  Applicable QSPEC Procedures

All procedures defined in section 5.3 of [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) are applicable to this QOSM.

4.3.  QNE Processing Rules

Section 7 of [TRQ‑QoS‑SIG] (ITU-T Supplement 51 to the Q-Series, “Signaling Requirements for IP-QoS,” January  2004.) describes the information processing in Y.1541 QNEs.

Section 8 of [Y.1541] (ITU-T Recommendation Y.1541, “Network Performance Objectives for IP-Based Services,” February  2006.) 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 above in section 2, 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.

4.4.  Processing Example

As described in the example given in Section 3.4 of [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) and as illustrated in Figure 3, the QoS NSIS initiator (QNI) initiates an end-to-end, inter-domain 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 Section 3, the TMOD 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 an QoS NSLP RESERVE message at the ingress node of the local-QOSM domain. As described in [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.) and [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.), at the ingress edge node of the local-QOSM domain, the end-to-end, inter-domain QoS-NSLP message may trigger the generation of a local QSPEC, and the initiator QSPEC 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 [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.), if any QNE cannot meet the requirements designated by the initiator QSPEC to support an optional QSPEC parameter, with the M bit set to zero for the parameter, for example, it cannot support the accumulation of end-to-end delay with the <Path Latency> 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 [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.). For example, the QNI sets <Desired QoS>, <Minimum QoS>, <Available QoS> objects to include <Y.1541 QoS Class>, which specifies objectives for the <Path Latency>, <Path Jitter>, <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 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)

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 fir 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".

 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 [M] (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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.|                (Reserved)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.6.  Preemption Behaviour

The default QNI behaviour 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 requests the establishment of one new registry for the Restoration Priority Parameter (and assigns initial values), in accordance with BCP 26 [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.). 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 to be assigned within the QSPEC Parameter ID registry created in [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.):

<TMOD Extension> parameter (Section 3.1 above, suggested ID=15)

<Restoration Priority> parameter (Section 3.2 above, suggested ID=16)

5.2.  Restoration Priority Parameter Registry

The Registry for Restoration Priority contains assignments for three 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:

0-2: assigned as specified in Section 3.2:

0: best-effort priority

1: normal priority

2: high priority

The allocation policies for further values are as follows:

3-255: 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

The allocation policies for further values are as follows:

3-15: 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:

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%

The allocation policies for further values are as follows:

6-15: Specification Required

5.2.4.  Reserved Bits

The remaining bits in the Restoration Priority Parameter are Reserved. The Reserved bits MAY be designated for other uses in the future.

6.  Security Considerations

The security considerations of [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.) and [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) 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 to get 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.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses