One document matched: draft-ietf-nsis-y1541-qosm-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-nsis-y1541-qosm-06" ipr="full3978">
<front>
<title abbrev="Y.1541 QOSM">Y.1541-QOSM -- Y.1541 QoS Model for Networks
Using Y.1541 QoS Classes</title>
<author fullname="Jerry Ash" initials="G." surname="Ash">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>200 Laurel Avenue South</street>
<city>Middletown,</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>gash5107@yahoo.com</email>
<uri></uri>
</address>
</author>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>200 Laurel Avenue South</street>
<city>Middletown,</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<phone>+1 732 420 1571</phone>
<facsimile>+1 732 368 1192</facsimile>
<email>acmorton@att.com</email>
<uri>http://home.comcast.net/~acmacm/</uri>
</address>
</author>
<author fullname="Martin Dolly" initials="M." surname="Dolly">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>200 Laurel Avenue South</street>
<city>Middletown,</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>mdolly@att.com</email>
<uri></uri>
</address>
</author>
<author fullname="Percy Tarapore" initials="P." surname="Tarapore">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>200 Laurel Avenue South</street>
<city>Middletown,</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>tarapore@att.com</email>
<uri></uri>
</address>
</author>
<author fullname="Chuck Dvorak" initials="C." surname="Dvorak">
<organization>AT&T Labs</organization>
<address>
<postal>
<street>180 Park Ave Bldg 2</street>
<city>Florham Park,</city>
<region>NJ</region>
<code>07932</code>
<country>USA</country>
</postal>
<phone>+ 1 973-236-6700</phone>
<facsimile></facsimile>
<email>cdvorak@att.com</email>
<uri>http:</uri>
</address>
</author>
<author fullname="Yacine El Mghazli" initials="Y." surname="El Mghazli">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Route de Nozay</street>
<city>Marcoussis cedex</city>
<region></region>
<code>91460</code>
<country>France</country>
</postal>
<phone>+33 1 69 63 41 87</phone>
<facsimile></facsimile>
<email>yacine.el_mghazli@alcatel.fr</email>
<uri></uri>
</address>
</author>
<date day="24" month="February" year="2008" />
<abstract>
<t>This 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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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. Y.1541 <xref
target="Y.1541"></xref> 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 <xref target="Y.1541"></xref> <xref
target="TRQ-QoS-SIG"></xref> <xref target="E.361"></xref>.</t>
<t>[QoS-SIG] <xref target="I-D.ietf-nsis-qos-nslp"></xref> 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 [QSPEC] <xref
target="I-D.ietf-nsis-qspec"></xref> 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, RFC2210] <xref target="RFC2205"></xref> <xref
target="RFC2210"></xref> . 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.</t>
</section>
<section title="Summary of ITU-T Recommendations Y.1541 & Signaling Requirements ">
<t>As stated above, [Y.1541] <xref target="Y.1541"></xref> is a
specification of standardized QoS classes for IP networks (a summary of
these classes is given below). [TRQ-QoS-SIG] <xref
target="TRQ-QoS-SIG"></xref> specifies the requirements for achieving
end-to-end QoS in IP networks, with Y.1541 QoS classes as a basis.
[Y.1541] <xref target="Y.1541"></xref> 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.</t>
<section title="Y.1541 Classes">
<t>[Y.1541] <xref target="Y.1541"></xref> 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 <xref
target="Y.1540"></xref>. 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.</t>
<t>The QoS classes apply to a packet flow, where [Y.1541] <xref
target="Y.1541"></xref> 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:</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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</t>
<t>Class 5: Unspecified applications with unspecified mean delay,
delay variation, and loss ratio. Application examples include
traditional applications of Default IP Networks</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="Y.1541"></xref>, <xref
target="I-D.ietf-ippm-framework-compagg"></xref>, and <xref
target="I-D.ietf-ippm-spatial-composition"></xref>.</t>
</section>
<section title="Y.1541-QOSM Processing Requirements">
<t>[TRQ-QoS-SIG] <xref target="TRQ-QoS-SIG"></xref> 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 <xref
target="Y.1541"></xref> , 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.</t>
<t>It MUST be possible to derive the following service level
parameters as part of the process of requesting service:</t>
<t>a. Y.1541 QoS class</t>
<t>b. rate (r)</t>
<t>c. peak rate (p)</t>
<t>d. bucket size (b)</t>
<t>e. peak bucket size (Bp)*</t>
<t>f. maximum packet size (M)*</t>
<t>g. DiffServ PHB class [RFC2475] <xref target="RFC2475"></xref></t>
<t>h. admission priority</t>
<t>i. restoration priority*</t>
<t>All parameters except Bp, M, and restoration priority have already
been specified in [QSPEC] <xref target="I-D.ietf-nsis-qspec"></xref>.
These additional parameters are specified in Section 3.</t>
<t>It MUST be possible to perform the following QoS-NSLP signaling
functions to meet Y.1541-QOSM requirements:</t>
<t>a. accumulate delay, delay variation and loss ratio across the
end-to-end connection, which may span multiple domains</t>
<t>b. enable negotiation of Y.1541 QoS class across domains.</t>
<t>c. enable negotiation of delay, delay variation, and loss ratio
across domains.</t>
<t>These signaling requirements are already supported by [QoS-SIG]
<xref target="I-D.ietf-nsis-qos-nslp"></xref> and the functions are
illustrated in Section 4.</t>
</section>
</section>
<section title="Additional QSPEC Parameters for Y.1541 QOSM">
<t></t>
<section title="Traffic Model (TMOD) Extension Parameter">
<t>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.</t>
<t><figure anchor="Fig1" title="TMOD Extension">
<preamble></preamble>
<artwork align="center"><![CDATA[ 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| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [M] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>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.</t>
<t>The QSPEC parameter behavior for (Bp) and (M) is similar to that
defined in <xref target="I-D.ietf-nsis-qspec">[QSPEC]</xref>, 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.</t>
</section>
<section title="Restoration Priority Parameter">
<t>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:</t>
<t><figure anchor="Fig2" title="Restoration Priority">
<preamble></preamble>
<artwork align="center"><![CDATA[ 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| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>Restoration Priority: 3 priority values are listed here in the
order of lowest priority to highest priority:</t>
<t>0 - best effort</t>
<t>1 - normal</t>
<t>2 - high</t>
<t>Each restoration priority class has two parameters:</t>
<t>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:</t>
<t>High Restoration Priority: Time-to-Restore <= 200 ms</t>
<t>Normal Restoration Priority: Time-to-Restore <= 2 s</t>
<t>Best Effort Restoration Priority: Time-to-Restore = Unspecified</t>
<t>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.</t>
</section>
</section>
<section title="Y.1541-QOSM Considerations and Processing Example">
<t>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.</t>
<section title="Deployment Considerations">
<t><xref target="TRQ-QoS-SIG"></xref> 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.</t>
<t>QNEs may be Stateful in some limited aspects, but obviously it is
preferable to deploy stateless QNEs.</t>
</section>
<section title="Applicable QSPEC Procedures">
<t>All procedures defined in section 5.3 of <xref
target="I-D.ietf-nsis-qspec">[QSPEC]</xref> are applicable to this
QOSM.</t>
</section>
<section title="QNE Processing Rules">
<t><xref target="TRQ-QoS-SIG"></xref> describes the information
processing in Y.1541 QNEs.</t>
<t><xref target="Y.1541"></xref> section 8 defines the accumulation
rules for individual performance parameters (e.g., delay, jitter).</t>
<t>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.</t>
</section>
<section title="Processing Example">
<t>As described in the example given in [QSPEC] <xref
target="I-D.ietf-nsis-qspec"></xref> (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.</t>
<t>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 [QoS-SIG] <xref
target="I-D.ietf-nsis-qos-nslp"></xref> and [QSPEC] <xref
target="I-D.ietf-nsis-qspec"></xref>, 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 [QSPEC] <xref
target="I-D.ietf-nsis-qspec"></xref>, 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.</t>
<t>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] <xref
target="I-D.ietf-nsis-qos-nslp"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
<t><figure anchor="Fig3" title="Example of Y.1541-QOSM Operation">
<preamble></preamble>
<artwork align="center"><![CDATA[|------| |------| |------| |------|
| 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)
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
<section title="Bit-Level QSPEC Example">
<t>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.</t>
<t>This example assumes that all the parameters MUST be supported by
the QNEs, so all M flags have been set to "1".</t>
<t><figure anchor="Figr4" title="An Example QSPEC (Initiator)">
<preamble></preamble>
<artwork align="center"><![CDATA[ 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 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 15 |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [M] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
<section title="Preemption Behaviour">
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section defines the registries and initial codepoint assignments
for the QSPEC template, in accordance with BCP 26 RFC 2434 <xref
target="RFC2434"></xref>. It also defines the procedural requirements to
be followed by IANA in allocating new codepoints.</t>
<t>This document specifies the following QSPEC parameters to be assigned
within the QSPEC Parameter ID registry created in [QSPEC] <xref
target="I-D.ietf-nsis-qspec"></xref>:</t>
<t><TMOD Extension> parameter (Section 3.1, suggested ID=15)</t>
<t><Restoration Priority> parameter (Section 3.2, suggested
ID=16)</t>
<t>This specification creates the following registry with the structure
as defined below:</t>
<t>Restoration Priority Parameter (8 bits):</t>
<t>The following values are allocated by this specification:</t>
<t>0-2: assigned as specified in Section 3.2:</t>
<t>0: best-effort priority</t>
<t>1: normal priority</t>
<t>2: high priority</t>
<t>The allocation policies for further values are as follows:</t>
<t>3-63: Standards Action</t>
<t>64-255: Reserved</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations of <xref
target="I-D.ietf-nsis-qos-nslp"></xref> and <xref
target="I-D.ietf-nsis-qspec"></xref> apply to this Document. There are
no new security considerations based on this document.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch,
and Hannes Tschofenig for helpful comments and discussion.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.I-D.ietf-nsis-qos-nslp'?>
<?rfc include='reference.I-D.ietf-nsis-qspec'?>
<reference anchor="TRQ-QoS-SIG">
<front>
<title>Signaling Requirements for IP-QoS</title>
<author fullname="" surname="ITU-T Supplement">
<organization></organization>
</author>
<date month="January " year="2004" />
</front>
</reference>
<reference anchor="Y.1540">
<front>
<title>Internet protocol data communication service - IP packet
transfer and availability performance parameters</title>
<author fullname="" surname="ITU-T Recommendation Y.1540">
<organization></organization>
</author>
<date month="December " year="2002" />
</front>
</reference>
<reference anchor="Y.1541">
<front>
<title>Network Performance Objectives for IP-Based Services</title>
<author fullname="" surname="ITU-T Recommendation Y.1540">
<organization></organization>
</author>
<date month="February " year="2006" />
</front>
</reference>
<?rfc ?>
</references>
<references title="Informative References">
<reference anchor="E.361">
<front>
<title>QoS Routing Support for Interworking of QoS Service Classes
Across Routing Technologies</title>
<author fullname="" surname="ITU-T Recommendation E.361">
<organization></organization>
</author>
<date month="May" year="2003" />
</front>
</reference>
<?rfc include='reference.I-D.ietf-ippm-framework-compagg'?>
<?rfc include='reference.I-D.ietf-ippm-spatial-composition'?>
<?rfc include='reference.RFC.2205'?>
<?rfc include='reference.RFC.2210'?>
<?rfc include='reference.RFC.2434'?>
<?rfc include='reference.RFC.2475'?>
<?rfc ?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 23:16:27 |