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 . 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). Section 7 of specifies
signaling features needed to achieve 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.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-7b. rate (r), octets per secondc. peak rate (p), octets per secondd. bucket size (b), octetse. maximum packet size (M), octets, IP header + IP payloadf. DiffServ PHB class g. admission priority, 32 bit integer, range : 0-2Compliant 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 i. restoration priority*, multiple integer values defined in
Section 3 belowAll parameters except Bp and restoration priority have already been
specified in . These
additional parameters are defined asBp, 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 restoration priority, as defined in Section 3 of this memoand 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 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 supported in and the functions are
illustrated in Section 4 of this memo.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.The Peak Bucket Size term, Bp, is represented as an IEEE floating
point value 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.Reserved: These 4 octets are reserved. The Reserved octets MAY be
designated for other uses in the future. Senders conforming to this
version of the Y.1541 QOSM SHALL set the Reserved octets to zero.
Receivers conforming to this version of the Y.1541 QOSM SHALL ignore
the Reserved octets.The QSPEC parameter behavior for the TMOD extended parameter is
similar to that defined in Section 3.3.1 of. The new parameter (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: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 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. 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-Restore1 - Best Time-to-Restore: <= 200 ms2 - Normal Time-to-Restore <= 2 sExtent 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 EOR1 - 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.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). 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.Section 7 of describes the
information processing in Y.1541 QNEs.Section 8 of 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 of 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 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 . 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 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.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".where 32-bit floating point numbers are as specified in
.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 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 . It also defines
the procedural requirements to be followed by IANA in allocating new
codepoints for the new Registry.This document specifies the following QSPEC parameters to be
assigned within the QSPEC Parameter ID registry created in :<TMOD Extension> parameter (Section 3.1 above, suggested
ID=15)<Restoration Priority> parameter (Section 3.2 above,
suggested ID=16)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: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 priority1: normal priority2: high priorityThe allocation policies for further values are as follows:3-63: Specification RequiredThe 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-Restore1 - Best Time-to-Restore: <= 200 ms2 - Normal Time-to-Restore <= 2 sThe allocation policies for further values are as follows:3-15: Specification RequiredThe 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 EOR1 - 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 RequiredThe remaining bits in the Restoration Priority Parameter are
Reserved. The Reserved bits MAY be designated for other uses in the
future.The security considerations of and 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.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 ServicesTraffic control and congestion control in IP based
networksService restoration priority levels in Next Generation
NetworksANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point
ArithmeticQoS Routing Support for Interworking of QoS Service Classes
Across Routing Technologies