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 Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5976.
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
Ash, et al. Experimental [Page 1]

RFC 5976 Y.1541 QOSM October 20101. Introduction
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. [Y.1541] currently specifies 8 classes of
Network Performance objectives, and the Y.1541-QOSM extensions
include additional QSPEC [RFC5975] parameters and QOSM processing
guidelines. The extensions are based on standardization work in the
ITU-T on QoS signaling requirements ([Y.1541] and [E.361]), and
guidance in [TRQ-QoS-SIG].
[RFC5974] 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 [RFC5975] 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] and
[RFC2210]. 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.
1.1. 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 [RFC2119].
2. Summary of ITU-T Recommendations Y.1541 and Signaling Requirements
As stated above, [Y.1541] is a specification of standardized QoS
classes for IP networks (a summary of these classes is given below).
Section 7 of [TRQ-QoS-SIG] describes the signaling features needed to
achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a
basis. [Y.1541] 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.
Ash, et al. Experimental [Page 3]

RFC 5976 Y.1541 QOSM October 20102.1. Description of Y.1541 Classes
[Y.1541] 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].
Note that [Y.1541] 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] 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 [RFC3246]. 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 [RFC2597]. 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 [Y.1541] 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.
Ash, et al. Experimental [Page 4]

RFC 5976 Y.1541 QOSM October 20102.2. Y.1541-QOSM Processing Requirements
[TRQ-QoS-SIG] 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] , 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 [RFC2475]
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]
i. restoration priority, multiple integer values defined in
Section 3 below
All parameters except Bp and restoration priority have already been
specified in [RFC5975]. 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 [Y.1221]
Ash, et al. Experimental [Page 6]

RFC 5976 Y.1541 QOSM October 2010
The QSPEC parameter behavior for the TMOD extended parameter follows
that defined in Section 3.3.1 of [RFC5975]. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [Y.2172], 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
Ash, et al. Experimental [Page 8]

RFC 5976 Y.1541 QOSM October 2010
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.
Ash, et al. Experimental [Page 9]

RFC 5976 Y.1541 QOSM October 20104. 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] 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 [RFC5975] are applicable to
this QOSM.
4.3. QNE Processing Rules
Section 7 of [TRQ-QoS-SIG] describes the information processing in
Y.1541 QNEs.
Section 8 of [Y.1541] 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 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 [RFC5975] 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 Section 3, the TMOD
Ash, et al. Experimental [Page 10]

RFC 5976 Y.1541 QOSM October 2010
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 [RFC5974] and
[RFC5975], 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
[RFC5975], 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 [RFC5974]. 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
Ash, et al. Experimental [Page 11]

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]