One document matched: draft-ietf-nsis-y1541-qosm-07.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-07" 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="27" month="October" 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. <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 <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 <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, <xref target="Y.1541"></xref> is a specification of
standardized QoS classes for IP networks (a summary of these classes is
given below). <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. <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><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 <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> <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)*, octets</t>
<t>f. maximum packet size (M)*, octets</t>
<t>g. DiffServ PHB class <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 <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 <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"></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>These priority values are described in <xref
target="Y.2172"></xref>, 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.</t>
<t>Reserved: These 3 octets are reserved for future use. There are
several ways to elaborate on restoration priority, and two
possibilities are described below:</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>Best Time-to-Restore: <= 200 ms</t>
<t>Normal Time-to-Restore <= 2 s</t>
<t>Unspecified Time-to-Restore = 0 (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>
<t>The Reserved octets MAY be designated for these or other uses in
the future.</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"></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 <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 <xref
target="I-D.ietf-nsis-qos-nslp"></xref> and <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 <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 <xref
target="RFC5226"></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 <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="2007" />
</front>
</reference>
<reference anchor="Y.1541">
<front>
<title>Network Performance Objectives for IP-Based Services</title>
<author fullname="" surname="ITU-T Recommendation Y.1541">
<organization></organization>
</author>
<date month="February " year="2006" />
</front>
</reference>
<reference anchor="Y.2172">
<front>
<title>Service restoration priority levels in Next Generation
Networks</title>
<author fullname="" surname="ITU-T Recommendation Y.1540">
<organization></organization>
</author>
<date month="June" year="2007" />
</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.5226'?>
<?rfc include='reference.RFC.2475'?>
<?rfc ?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 23:16:18 |