Y.1541-QOSM -- Y.1541 QoS Model for Networks
Using Y.1541 QoS ClassesAT&T Labs200 Laurel Avenue SouthMiddletown,NJ07748USAgash5107@yahoo.comAT&T Labs200 Laurel Avenue SouthMiddletown,NJ07748USA+1 732 420 1571+1 732 368 1192acmorton@att.comhttp://home.comcast.net/~acmacm/AT&T Labs200 Laurel Avenue SouthMiddletown,NJ07748USAmdolly@att.comAT&T Labs200 Laurel Avenue SouthMiddletown,NJ07748USAtarapore@att.comAT&T Labs180 Park Ave Bldg 2Florham Park,NJ07932USA+ 1 973-236-6700cdvorak@att.comhttp:Alcatel-LucentRoute de NozayMarcoussis cedex91460France+33 1 69 63 41 87yacine.el_mghazli@alcatel.frThis draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T
Recommendation Y.1541 Network QoS Classes and related signaling
requirements. Y.1541 specifies 8 classes of Network Performance
objectives, and the Y.1541-QOSM extensions include additional QSPEC
parameters and QOSM processing guidelines.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.This draft describes a QoS model (QOSM) for NSIS QoS signaling layer
protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541
Network QoS Classes and related signaling requirements. currently specifies 8 classes of Network
Performance objectives, and the Y.1541-QOSM extensions include
additional QSPEC parameters and QOSM processing guidelines. The
extensions are based on standardization work in the ITU-T on QoS
signaling requirements .[QoS-SIG] 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 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 . The QSPEC
object contains the QoS parameters defined by the QOSM. A QOSM provides
a specific set of parameters to be carried in the QSPEC. At each QoS
NSIS element (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.As stated above, is a specification of
standardized QoS classes for IP networks (a summary of these classes is
given below). specifies the
requirements for achieving end-to-end QoS in IP networks, with Y.1541
QoS classes as a basis. 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. 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 . Classes 0 and 1 might be
implemented using the DiffServ EF PHB, and support interactive
real-time applications. Classes 2, 3, and 4 might be implemented using
the DiffServ AFxy PHB Group, and support data transfer applications
with various degrees of interactivity. Class 5 generally corresponds
to the DiffServ Default PHB, has all the QoS parameters unspecified
consistent with a best-effort service. Classes 6 and 7 provide support
for extremely loss-sensitive user applications, such as high quality
digital television, 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 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.1451 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
streamingClass 5: Unspecified applications with unspecified mean delay,
delay variation, and loss ratio. Application examples include
traditional applications of Default IP NetworksClass 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 , , and . provides the requirements for
signaling information regarding 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
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.It MUST be possible to derive the following service level
parameters as part of the process of requesting service:a. Y.1541 QoS classb. rate (r)c. peak rate (p)d. bucket size (b)e. peak bucket size (Bp)*, octetsf. maximum packet size (M)*, octetsg. DiffServ PHB class h. admission priorityi. restoration priority*All parameters except Bp, M, and restoration priority have already
been specified in . These
additional parameters are 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 domainsb. 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 already supported by and the functions are
illustrated in Section 4.The traffic model (TMOD) extension parameter is represented by one
floating point number in single-precision IEEE floating point format
and one 32-bit unsigned integer.When the Bp term is represented as an IEEE floating point
value, 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 maximum
packet size (M) is an unsigned integer.The QSPEC parameter behavior for (Bp) and (M) is similar to that
defined in , section 6.2.1
and 6.2.2. The new parameters (and all traffic-related parameters) are
specified independently from the Y.1541 class 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:Restoration Priority: 3 priority values are listed here in the
order of lowest priority to highest priority:0 - best effort1 - normal2 - highThese priority values are described in , 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.Reserved: These 3 octets are reserved for future use. There are
several ways to elaborate on restoration priority, and two
possibilities are described below:a. Time-to-Restore: 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, candidate restoration objectives are:Best Time-to-Restore: <= 200 msNormal Time-to-Restore <= 2 sUnspecified Time-to-Restore = 0 (Unspecified)b. Extent of Restoration: 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.The Reserved octets MAY be designated for these or other uses in
the future.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 or parameters (except those described in section
3) are required to enable the Y.1541 QOSM. 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.QNEs may be Stateful in some limited aspects, but obviously it is
preferable to deploy stateless QNEs.All procedures defined in section 5.3 of are applicable to this QOSM. describes the information
processing in Y.1541 QNEs. section 8 defines the accumulation
rules for individual performance parameters (e.g., delay, jitter).When a 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.As described in the example given in (Section 4.4) 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
parameters Bp and M; restoration priority is also an optional,
Y.1541-QOSM-specific parameter.As illustrated in Figure 3, 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 and , 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 , 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 [QoS-SIG] . 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 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 achieve
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.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".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.This section defines the registries and initial codepoint assignments
for the QSPEC template, in accordance with BCP 26 . It also defines the procedural requirements to
be followed by IANA in allocating new codepoints.This document specifies the following QSPEC parameters to be assigned
within the QSPEC Parameter ID registry created in :<TMOD Extension> parameter (Section 3.1, suggested ID=15)<Restoration Priority> parameter (Section 3.2, suggested
ID=16)This specification creates the following registry with the structure
as defined below:Restoration Priority Parameter (8 bits):The following values are allocated by this specification:0-2: assigned as specified in Section 3.2:0: best-effort priority1: normal priority2: high priorityThe allocation policies for further values are as follows:3-63: Standards Action64-255: ReservedThe security considerations of and apply to this Document. There are
no new security considerations based on this document.The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch,
and Hannes Tschofenig for helpful comments and discussion.Signaling Requirements for IP-QoSInternet protocol data communication service - IP packet
transfer and availability performance parametersNetwork Performance Objectives for IP-Based ServicesService restoration priority levels in Next Generation
NetworksQoS Routing Support for Interworking of QoS Service Classes
Across Routing Technologies