One document matched: draft-ietf-nsis-y1541-qosm-10.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="exp" docName="draft-ietf-nsis-y1541-qosm-10"
ipr="pre5378Trust200902">
<front>
<title abbrev="Y.1541 QOSM">Y.1541-QOSM -- Model for Networks Using Y.1541
QoS Classes</title>
<author fullname="Gerald 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="4" month="February" year="2010" />
<abstract>
<t>This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T
Recommendation Y.1541 Network QoS Classes and related guidance on
signaling. Y.1541 specifies 8 classes of Network Performance objectives,
and the Y.1541-QOSM extensions include additional QSPEC parameters and
QOSM processing guidelines.</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 Next Steps in Signaling
(NSIS) QoS signaling layer protocol (QoS-NSLP) application based on
ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on
signaling. <xref target="Y.1541"></xref> currently specifies 8 classes
of Network Performance objectives, and the Y.1541-QOSM extensions
include additional QSPEC <xref target="I-D.ietf-nsis-qspec"></xref>
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> and <xref target="E.361"></xref>, and guidance
in <xref target="TRQ-QoS-SIG"></xref>.</t>
<t><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>. A QOSM provides a specific set of parameters
to be carried in the QSPEC object. At each QoS NSIS Entity (QNE), the
QSPEC contents are interpreted by the resource management function (RMF)
for purposes of policy control and traffic control, including admission
control and configuration of the scheduler.</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). Section 7 of <xref target="TRQ-QoS-SIG"></xref> describes
the signaling features needed to achieve 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="Description of 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>.</t>
<t>Note that <xref target="Y.1541"></xref> is maintained by the ITU-T
and subject to occasional updates and revisions. The material in this
section is provided for information and to make this document easier
to read. In the event of any discrepancies, the normative definitions
found in <xref target="Y.1541"></xref> take precidence.</t>
<t>Classes 0 and 1 might be implemented using the DiffServ Expedited
Forwarding (EF) Per-Hop Behavior (PHB), and support interactive
real-time applications<xref target="RFC3246"></xref>. Classes 2, 3,
and 4 might be implemented using the DiffServ Assured Forwarding
(AFxy) PHB Group, and support data transfer applications with various
degrees of interactivity<xref target="RFC2597"></xref>. Class 5
generally corresponds to the DiffServ Default PHB, has all the QoS
parameters unspecified consistent with a best-effort service<xref
target="RFC2474"></xref>. Classes 6 and 7 provide support for
extremely loss-sensitive user applications, such as high quality
digital television, Time Division Multiplex (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.1541 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> guides the specification of
signaling information for IP-based QoS at the interface between the
user and the network (UNI) and across interfaces between different
networks (NNI). To meet specific network performance requirements
specified for the Y.1541 QoS classes <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>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:</t>
<t>a. Y.1541 QoS class, 32 bit integer, range : 0-7</t>
<t>b. rate (r), octets per second</t>
<t>c. peak rate (p), octets per second</t>
<t>d. bucket size (b), octets</t>
<t>e. maximum packet size (M), octets, IP header + IP payload</t>
<t>f. DiffServ PHB class <xref target="RFC2475"></xref></t>
<t>g. admission priority, 32 bit integer, range : 0-2</t>
<t>Compliant implementations MAY derive the following service level
parameters as part of the service request process:</t>
<t>h. peak bucket size (Bp)*, octets, 32 bit floating point number in
single-precision IEEE floating point format <xref
target="IEEE754"></xref></t>
<t>i. restoration priority*, multiple integer values defined in
Section 3 below</t>
<t>All parameters except Bp and restoration priority have already been
specified in <xref target="I-D.ietf-nsis-qspec"></xref>. These
additional parameters are defined as</t>
<t><list style="symbols">
<t>Bp, The size of the peak-rate bucket in a dual token bucket
arrangement, essentially setting the maximum length of bursts in
the peak-rate stream. For example, see Annex B of <xref
target="Y.1221"></xref></t>
<t>restoration priority, as defined in Section 3 of this memo</t>
</list>and their QSPEC Parameter format is 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 supported in <xref
target="I-D.ietf-nsis-qos-nslp"></xref> and the functions are
illustrated in Section 4 of this memo.</t>
</section>
</section>
<section title="Additional QSPEC Parameters for Y.1541 QOSM">
<t>The specifications in this section extend the QSPEC <xref
target="I-D.ietf-nsis-qspec"></xref>.</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 reserved field.</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| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>The Peak Bucket Size term, Bp, is represented as an IEEE floating
point value <xref target="IEEE754"></xref> 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.</t>
<t>The QSPEC parameter behavior for the TMOD extended parameter
follows that defined in Section 3.3.1 of<xref
target="I-D.ietf-nsis-qspec"></xref>. The new parameter (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 Parameter">
<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| TTR | EOR | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>This parameter has three fields and a reserved area, as defined
below.</t>
<t>Restoration Priority Field (8-bit unsigned integer): 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. There are several ways to
elaborate on restoration priority, and the two current parameters are
described below.</t>
<t>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:</t>
<t>0 - Unspecified Time-to-Restore</t>
<t>1 - Best Time-to-Restore: <= 200 ms</t>
<t>2 - Normal Time-to-Restore <= 2 s</t>
<t>Extent of Restoration (EOR) Field (4-bit unsigned integer):
Percentage of traffic belonging to the restoration class that can be
restored. This percentage depends on the amount of spare capacity
engineered. All high priority restoration 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>EOR values are assigned as follows:</t>
<t>0 - unspecified EOR</t>
<t>1 - high priority restored at 100%; medium priority restored at
100%</t>
<t>2 - high priority restored at 100%; medium priority restored at
80%</t>
<t>3 - high priority restored >= 80%; medium priority restored
>= 80%</t>
<t>4 - high priority restored >= 80%; medium priority restored
>= 60%</t>
<t>5 - high priority restored >= 60%; medium priority restored
>= 60%</t>
<t>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.</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 are required to enable the Y.1541 QOSM
(excluding the two OPTIONAL new parameters specified in Section 3).</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>
</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>Section 7 of <xref target="TRQ-QoS-SIG"></xref> describes the
information processing in Y.1541 QNEs.</t>
<t>Section 8 of <xref target="Y.1541"></xref> defines the accumulation
rules for individual performance parameters (e.g., delay, jitter).</t>
<t>When a QoS NSIS initiator (QNI) specifies the Y.1541 QoS Class
number, <Y.1541 QoS Class>, it is a sufficient specification of
objectives for the <Path Latency>, <Path Jitter>, and
<Path BER> parameters. As described 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 Section 3.4 of <xref
target="I-D.ietf-nsis-qspec"></xref> 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.</t>
<t>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 <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 <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 QoS NSIS Receiver (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 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.</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 = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [M] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|r| 15 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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>where 32-bit floating point numbers are as specified in
<xref target="IEEE754"></xref>.</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 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 <xref target="RFC5226"></xref>. It also defines
the procedural requirements to be followed by IANA in allocating new
codepoints for the new Registry.</t>
<section title="Assignment of QSPEC Parameter IDs">
<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 above, suggested
ID=15)</t>
<t><Restoration Priority> parameter (Section 3.2 above,
suggested ID=16)</t>
</section>
<t></t>
<section title="Restoration Priority Parameter Registry">
<t>The Registry for Restoration Priority contains assignments for
three fields in the 4 octet word, and a Reserved section of the
word.</t>
<t>This specification creates the following registry with the
structure as defined below:</t>
<section title="Restoration Priority Field">
<t>The Restoration Priority Field is 8 bits in length.</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-255: Specification Required</t>
</section>
<section title="Time to Restore Field">
<t>The Time to Restore Field is 4 bits in length.</t>
<t>The following values are allocated by this specification:</t>
<t>0-2: assigned as specified in Section 3.2:</t>
<t>0 - Unspecified Time-to-Restore</t>
<t>1 - Best Time-to-Restore: <= 200 ms</t>
<t>2 - Normal Time-to-Restore <= 2 s</t>
<t>The allocation policies for further values are as follows:</t>
<t>3-15: Specification Required</t>
</section>
<section title="Extent of Restoration Field">
<t>The Extent of Restoration (EOR) Field is 4 bits in length.</t>
<t>The following values are allocated by this specification:</t>
<t>0-5: assigned as specified in Section 3.2:</t>
<t>EOR values are assigned as follows:</t>
<t>0 - unspecified EOR</t>
<t>1 - high priority restored at 100%; medium priority restored at
100%</t>
<t>2 - high priority restored at 100%; medium priority restored at
80%</t>
<t>3 - high priority restored >= 80%; medium priority restored
>= 80%</t>
<t>4 - high priority restored >= 80%; medium priority restored
>= 60%</t>
<t>5 - high priority restored >= 60%; medium priority restored
>= 60%</t>
<t>The allocation policies for further values are as follows:</t>
<t>6-15: Specification Required</t>
</section>
<section title="Reserved Bits">
<t>The remaining bits in the Restoration Priority Parameter are
Reserved. The Reserved bits MAY be designated for other uses in the
future.</t>
</section>
</section>
<t></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.</t>
<t>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</t>
<t>- only some user groups (e.g. the police) are authorized to set the
emergency priority bit</t>
<t>- any user is authorized to employ the emergency priority bit for
particular destination addresses (e.g. police or fire departments)</t>
<t>There are no other known 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="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.1221">
<front>
<title>Traffic control and congestion control in IP based
networks</title>
<author fullname="" surname="ITU-T Recommendation Y.1221">
<organization></organization>
</author>
<date month="March " year="2002" />
</front>
</reference>
<reference anchor="Y.2172">
<front>
<title>Service restoration priority levels in Next Generation
Networks</title>
<author fullname="" surname="ITU-T Recommendation Y.2172">
<organization></organization>
</author>
<date month="June" year="2007" />
</front>
</reference>
<reference anchor="IEEE754">
<front>
<title>ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point
Arithmetic</title>
<author fullname="Institute of Electrical and Electronics Engineers"
surname="ANSI/IEEE">
<organization></organization>
</author>
<date year="1985" />
</front>
</reference>
<?rfc ?>
</references>
<references title="Informative References">
<reference anchor="TRQ-QoS-SIG">
<front>
<title>Signaling Requirements for IP-QoS</title>
<author fullname="" surname="ITU-T Supplement 51 to the Q-Series">
<organization></organization>
</author>
<date month="January " year="2004" />
</front>
</reference>
<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 include="reference.RFC.2474"?>
<?rfc include='reference.RFC.2597'?>
<?rfc include='reference.RFC.3246'?>
<?rfc ?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 23:17:56 |