summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5976.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5976.txt')
-rw-r--r--doc/rfc/rfc5976.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5976.txt b/doc/rfc/rfc5976.txt
new file mode 100644
index 0000000..8760f31
--- /dev/null
+++ b/doc/rfc/rfc5976.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) G. Ash
+Request for Comments: 5976 A. Morton
+Category: Experimental M. Dolly
+ISSN: 2070-1721 P. Tarapore
+ C. Dvorak
+ AT&T Labs
+ Y. El Mghazli
+ Alcatel-Lucent
+ October 2010
+
+
+Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
+
+Abstract
+
+ This document describes a QoS-NSLP Quality-of-Service 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.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5976.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+
+
+
+Ash, et al. Experimental [Page 1]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
+ 2. Summary of ITU-T Recommendations Y.1541 and Signaling
+ Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Description of Y.1541 Classes . . . . . . . . . . . . . . 4
+ 2.2. Y.1541-QOSM Processing Requirements . . . . . . . . . . . 6
+ 3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 7
+ 3.1. Traffic Model (TMOD) Extension Parameter . . . . . . . . . 7
+ 3.2. Restoration Priority Parameter . . . . . . . . . . . . . . 8
+ 4. Y.1541-QOSM Considerations and Processing Example . . . . . . 10
+ 4.1. Deployment Considerations . . . . . . . . . . . . . . . . 10
+ 4.2. Applicable QSPEC Procedures . . . . . . . . . . . . . . . 10
+ 4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 10
+ 4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 10
+ 4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 12
+ 4.6. Preemption Behavior . . . . . . . . . . . . . . . . . . . 14
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1. Assignment of QSPEC Parameter IDs . . . . . . . . . . . . 14
+ 5.2. Restoration Priority Parameter Registry . . . . . . . . . 14
+ 5.2.1. Restoration Priority Field . . . . . . . . . . . . . . 14
+ 5.2.2. Time to Restore Field . . . . . . . . . . . . . . . . 15
+ 5.2.3. Extent of Restoration Field . . . . . . . . . . . . . 15
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+Ash, et al. Experimental [Page 2]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+1. Introduction
+
+ This document 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. [Y.1541] currently specifies 8 classes of
+ Network Performance objectives, and the Y.1541-QOSM extensions
+ include additional QSPEC [RFC5975] parameters and QOSM processing
+ guidelines. The extensions are based on standardization work in the
+ ITU-T on QoS signaling requirements ([Y.1541] and [E.361]), and
+ guidance in [TRQ-QoS-SIG].
+
+ [RFC5974] defines message types and control information for the QoS-
+ NSLP that are 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 [RFC5975] 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] and
+ [RFC2210]. 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.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Summary of ITU-T Recommendations Y.1541 and Signaling Requirements
+
+ As stated above, [Y.1541] is a specification of standardized QoS
+ classes for IP networks (a summary of these classes is given below).
+ Section 7 of [TRQ-QoS-SIG] describes the signaling features needed to
+ achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a
+ basis. [Y.1541] 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.
+
+
+
+
+
+
+
+Ash, et al. Experimental [Page 3]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+2.1. Description of Y.1541 Classes
+
+ [Y.1541] 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 [Y.1540].
+
+ Note that [Y.1541] 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
+ [Y.1541] take precedence.
+
+ Classes 0 and 1 might be implemented using the Diffserv Expedited
+ Forwarding (EF) Per-Hop Behavior (PHB), and they support interactive
+ real-time applications [RFC3246]. Classes 2, 3, and 4 might be
+ implemented using the Diffserv Assured Forwarding (AFxy) PHB Group,
+ and they support data transfer applications with various degrees of
+ interactivity [RFC2597]. Class 5 generally corresponds to the
+ Diffserv Default PHB, and it has all the QoS parameters unspecified
+ consistent with a best-effort service[RFC2474]. Classes 6 and 7
+ provide support for extremely loss-sensitive user applications, such
+ as high-quality digital television, Time Division Multiplexing (TDM)
+ circuit emulation, and high-capacity file transfers using TCP. These
+ classes are intended to serve as a basis for agreements between end-
+ users and service providers, and between service providers. They
+ support a wide range of user applications including point-to-point
+ telephony, data transfer, multimedia conferencing, and others. The
+ limited number of classes supports the requirement for feasible
+ implementation, particularly with respect to scale in global
+ networks.
+
+ The QoS classes apply to a packet flow, where [Y.1541] 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:
+
+ Class 0:
+ Real-time, highly interactive applications, sensitive to jitter.
+ Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <=
+ 10^-3. Application examples include VoIP and video teleconference.
+
+
+
+
+
+
+
+Ash, et al. Experimental [Page 4]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ Class 1:
+ Real-time, interactive applications, sensitive to jitter. Mean delay
+ <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3.
+ Application examples include VoIP and video teleconference.
+
+ Class 2:
+ Highly interactive transaction data. Mean delay <= 100 ms, delay
+ variation is unspecified, loss ratio <= 10^-3. Application examples
+ include signaling.
+
+ Class 3:
+ Interactive transaction data. Mean delay <= 400 ms, delay variation
+ is unspecified, loss ratio <= 10^-3. Application examples include
+ signaling.
+
+ Class 4:
+ Low Loss Only applications. Mean delay <= 1 s, delay variation is
+ unspecified, loss ratio <= 10^-3. Application examples include short
+ transactions, bulk data, and video streaming.
+
+ Class 5:
+ Unspecified applications with unspecified mean delay, delay
+ variation, and loss ratio. Application examples include traditional
+ applications of default IP networks.
+
+ Class 6:
+ Applications that are highly sensitive to loss. Mean delay <= 100
+ ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application
+ examples include television transport, high-capacity TCP transfers,
+ and Time-Division Multiplexing (TDM) circuit emulation.
+
+ Class 7:
+ Applications that are highly sensitive to loss. Mean delay <= 400
+ ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application
+ examples include television transport, high-capacity TCP transfers,
+ and TDM circuit emulation.
+
+ These classes enable service level agreements (SLAs) to be defined
+ between customers and network service providers with respect to QoS
+ requirements. The service provider then needs to ensure that the
+ requirements are recognized and receive appropriate treatment across
+ network layers.
+
+ Work is in progress to specify methods for combining local values of
+ performance metrics to estimate the performance of the complete path.
+ See Section 8 of [Y.1541], [RFC5835], and [COMPOSITION].
+
+
+
+
+
+Ash, et al. Experimental [Page 5]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+2.2. Y.1541-QOSM Processing Requirements
+
+ [TRQ-QoS-SIG] 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 [Y.1541] , a network needs to provide specific user-plane
+ functionality at the UNI and NNI. Dynamic network provisioning at a
+ UNI and/or NNI node allows a traffic contract for an IP flow to be
+ dynamically requested from a specific source node to one or more
+ destination nodes. In response to the request, the network
+ determines if resources are available to satisfy the request and
+ provision the network.
+
+ For implementations to claim compliance with this memo, it MUST be
+ possible to derive the following service-level parameters as part of
+ the process of requesting service:
+
+ a. Y.1541 QoS class, 32-bit integer, range: 0-7
+
+ b. rate (r), octets per second
+
+ c. peak rate (p), octets per second
+
+ d. bucket size (b), octets
+
+ e. maximum packet size (MPS), octets, IP header + IP payload
+
+ f. Diffserv PHB class [RFC2475]
+
+ g. admission priority, 32-bit integer, range: 0-2
+
+ Compliant implementations MAY derive the following service-level
+ parameters as part of the service request process:
+
+ h. peak bucket size (Bp), octets, 32-bit floating point number in
+ single-precision IEEE floating point format [IEEE754]
+
+ i. restoration priority, multiple integer values defined in
+ Section 3 below
+
+ All parameters except Bp and restoration priority have already been
+ specified in [RFC5975]. These additional parameters are defined as
+
+ o 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 [Y.1221]
+
+
+
+
+Ash, et al. Experimental [Page 6]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ o restoration priority, as defined in Section 3 of this memo
+
+ Their QSPEC Parameter format is specified in Section 3.
+
+ It MUST be possible to perform the following QoS-NSLP signaling
+ functions to meet Y.1541-QOSM requirements:
+
+ a. accumulate delay, delay variation, and loss ratio across the end-
+ to-end connection, which may span multiple domains.
+
+ b. enable negotiation of Y.1541 QoS class across domains.
+
+ c. enable negotiation of delay, delay variation, and loss ratio
+ across domains.
+
+ These signaling requirements are supported in [RFC5974], and the
+ functions are illustrated in Section 4 of this memo.
+
+3. Additional QSPEC Parameters for Y.1541 QOSM
+
+ The specifications in this section extend the QSPEC [RFC5975].
+
+3.1. Traffic Model (TMOD) Extension Parameter
+
+ 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.
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: TMOD Extension
+
+ The Peak Bucket Size term, Bp, is represented as an IEEE floating
+ point value [IEEE754] 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.
+
+
+
+
+
+
+Ash, et al. Experimental [Page 7]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ The QSPEC parameter behavior for the TMOD extended parameter follows
+ that defined in Section 3.3.1 of [RFC5975]. The new parameter (and
+ all traffic-related parameters) are specified independently from the
+ Y.1541 class parameter.
+
+3.2. Restoration Priority Parameter
+
+ Restoration priority is the urgency with which a service requires
+ successful restoration under failure conditions. Restoration
+ priority is achieved by provisioning sufficient backup capacity, as
+ necessary, and allowing relative priority for access to available
+ bandwidth when there is contention for restoration bandwidth.
+ Restoration priority is defined as follows:
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Restoration Priority Parameter
+
+ This parameter has three fields and a reserved area, as defined
+ below.
+
+ Restoration Priority Field (8-bit unsigned integer): 3 priority
+ values are listed here in the order of lowest priority to highest
+ priority:
+
+ 0 - best effort
+
+ 1 - normal
+
+ 2 - high
+
+ These priority values are described in [Y.2172], where best-effort
+ priority is the same as Priority level 3, normal priority is
+ Priority level 2, and high priority is Priority level 1. There
+ are several ways to elaborate on restoration priority, and the two
+ current parameters are described below.
+
+ Time-to-Restore (TTR) Field (4-bit unsigned integer): Total amount
+ of time to restore traffic streams belonging to a given
+ restoration class impacted by the failure. This time period
+ depends on the technology deployed for restoration. A fast
+ recovery period of < 200 ms is based on current experience with
+
+
+
+Ash, et al. Experimental [Page 8]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ Synchronous Optical Network (SONET) rings and a slower recovery
+ period of 2 seconds is suggested in order to enable a voice call
+ to recover without being dropped. Accordingly, TTR restoration
+ suggested ranges are:
+
+ 0 - Unspecified Time-to-Restore
+
+ 1 - Best Time-to-Restore: <= 200 ms
+
+ 2 - Normal Time-to-Restore <= 2 s
+
+ 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 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
+ SLAs developed between the service provider and the customer.
+
+ EOR values are assigned as follows:
+
+ 0 - unspecified EOR
+
+ 1 - high priority restored at 100%;
+ medium priority restored at 100%
+
+ 2 - high priority restored at 100%;
+ medium priority restored at 80%
+
+ 3 - high priority restored >= 80%;
+ medium priority restored >= 80%
+
+ 4 - high priority restored >= 80%;
+ medium priority restored >= 60%
+
+ 5 - high priority restored >= 60%;
+ medium priority restored >= 60%
+
+ Reserved: These 2 octets are reserved. The Reserved bits MAY be
+ designated for other uses in the future. Senders conforming to
+ this version of the Y.1541 QOSM SHALL set the Reserved bits to
+ zero. Receivers conforming to this version of the Y.1541 QOSM
+ SHALL ignore the Reserved bits.
+
+
+
+
+
+
+
+Ash, et al. Experimental [Page 9]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+4. Y.1541-QOSM Considerations and Processing Example
+
+ 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).
+
+4.1. Deployment Considerations
+
+ [TRQ-QoS-SIG] 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.
+
+4.2. Applicable QSPEC Procedures
+
+ All procedures defined in Section 5.3 of [RFC5975] are applicable to
+ this QOSM.
+
+4.3. QNE Processing Rules
+
+ Section 7 of [TRQ-QoS-SIG] describes the information processing in
+ Y.1541 QNEs.
+
+ Section 8 of [Y.1541] defines the accumulation rules for individual
+ performance parameters (e.g., delay, jitter).
+
+ 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 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.
+
+4.4. Processing Example
+
+ As described in the example given in Section 3.4 of [RFC5975] and as
+ illustrated in Figure 3, the QoS NSIS initiator (QNI) initiates an
+ end-to-end, interdomain 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
+
+
+
+
+
+Ash, et al. Experimental [Page 10]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ extension parameter contains the OPTIONAL Y.1541-QOSM-specific terms;
+ restoration priority is also an OPTIONAL Y.1541-QOSM-specific
+ parameter.
+
+ As Figure 3 below shows, the RESERVE message may cross multiple
+ domains supporting different QOSMs. In this illustration, the
+ Initiator QSPEC arrives in a QoS NSLP RESERVE message at the ingress
+ node of the local-QOSM domain. As described in [RFC5974] and
+ [RFC5975], at the ingress edge node of the local-QOSM domain, the
+ end-to-end, interdomain QoS-NSLP message may trigger the generation
+ of a Local QSPEC, and the Initiator QSPEC is 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
+ [RFC5975], if any QNE cannot meet the requirements designated by the
+ Initiator QSPEC to support an optional QSPEC parameter (i.e., with
+ the M bit set to zero for the parameter), the QNE sets the N flag
+ (not supported flag) for the parameter to one. For example, if the
+ QNE cannot support the accumulation of end-to-end delay with the
+ <Path Latency> parameter, where the M flag for the <Path Latency>
+ parameter is set to zero denoting <Path Latency> as an optional
+ parameter, the QNE sets the N flag (not supported flag) for the <Path
+ Latency> parameter to one.
+
+ Also, the Y.1541-QOSM requires negotiation of the <Y.1541 QoS Class>
+ across domains. This negotiation can be done with the use of the
+ existing procedures already defined in [RFC5974]. For example, the
+ QNI sets <Desired QoS>, <Minimum QoS>, and <Available QoS> objects to
+ include <Y.1541 QoS Class>, which specifies objectives for the <Path
+ Latency>, <Path Jitter>, and <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.
+
+ 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
+
+
+
+Ash, et al. Experimental [Page 11]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ would be that Class 0 cannot be achieved, and Class 1 is available
+ (with its 400 ms objective). In addition, this QOSM allows the
+ response to include an available <Path Latency> = 150 ms, making
+ acceptance of the available <Y.1541 QoS Class> more likely. There
+ are many long paths where the propagation delay alone exceeds the
+ Y.1541 Class 0 objective, so this feature adds flexibility to commit
+ to exceed the Class 1 objective when possible.
+
+ This example illustrates Y.1541-QOSM negotiation of <Y.1541 QoS
+ Class> and cumulative parameter values that can be achieved end-to-
+ end. The example illustrates how the QNI can use the cumulative
+ values collected in <QoS Available> to decide if a lower <Y.1541 QoS
+ Class> than specified in <QoS Desired> is acceptable.
+
+ |------| |------| |------| |------|
+ | 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)
+
+ Figure 3: Example of Y.1541-QOSM Operation
+
+4.5. Bit-Level QSPEC Example
+
+ 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 for the Y.1541 Class.
+
+ This example assumes that all the parameters MUST be supported by the
+ QNEs, so all M-flags have been set to 1.
+
+
+
+
+
+
+
+
+
+Ash, et al. Experimental [Page 12]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ 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 [MPS] (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 |
+
+
+
+Ash, et al. Experimental [Page 13]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Y.1541 QoS Cls.| (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: An Example QSPEC (Initiator)
+
+ where 32-bit floating point numbers are as specified in [IEEE754].
+
+4.6. Preemption Behavior
+
+ The default QNI behavior of tearing down a preempted reservation is
+ followed in the Y.1541 QOSM. The restoration priority parameter
+ described above does not rely on preemption.
+
+5. IANA Considerations
+
+ This section defines additional codepoint assignments in the QSPEC
+ Parameter ID registry and establishes one new registry for the
+ Restoration Priority Parameter (and assigns initial values), in
+ accordance with BCP 26 [RFC5226]. It also defines the procedural
+ requirements to be followed by IANA in allocating new codepoints for
+ the new registry.
+
+5.1. Assignment of QSPEC Parameter IDs
+
+ This document specifies the following QSPEC parameters, which have
+ been assigned in the QSPEC Parameter ID registry created in
+ [RFC5975]:
+
+ <TMOD Extension> parameter (Section 3.1, ID=15)
+
+ <Restoration Priority> parameter (Section 3.2, ID=16)
+
+5.2. Restoration Priority Parameter Registry
+
+ The Registry for Restoration Priority contains assignments for 3
+ fields in the 4-octet word and a Reserved section of the word.
+
+ This specification creates the following registry with the structure
+ as defined below.
+
+5.2.1. Restoration Priority Field
+
+ The Restoration Priority Field is 8 bits in length.
+
+ The following values are allocated by this specification:
+
+
+
+
+
+Ash, et al. Experimental [Page 14]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ 0-2: assigned as specified in Section 3.2:
+
+ 0: best-effort priority
+
+ 1: normal priority
+
+ 2: high priority
+
+ Further values are as follows:
+
+ 3-255: Unassigned
+
+ The registration procedure is Specification Required.
+
+5.2.2. Time to Restore Field
+
+ The Time to Restore Field is 4 bits in length.
+
+ The following values are allocated by this specification:
+
+ 0-2: assigned as specified in Section 3.2:
+
+ 0 - Unspecified Time-to-Restore
+
+ 1 - Best Time-to-Restore: <= 200 ms
+
+ 2 - Normal Time-to-Restore <= 2 s
+
+ Further values are as follows:
+
+ 3-15: Unassigned
+
+ The registration procedure is Specification Required.
+
+5.2.3. Extent of Restoration Field
+
+ The Extent of Restoration (EOR) Field is 4 bits in length.
+
+ The following values are allocated by this specification:
+
+ 0-5: assigned as specified in Section 3.2:
+
+ 0 - unspecified EOR
+
+ 1 - high priority restored at 100%;
+ medium priority restored at 100%
+
+
+
+
+
+Ash, et al. Experimental [Page 15]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ 2 - high priority restored at 100%;
+ medium priority restored at 80%
+
+ 3 - high priority restored >= 80%;
+ medium priority restored >= 80%
+
+ 4 - high priority restored >= 80%;
+ medium priority restored >= 60%
+
+ 5 - high priority restored >= 60%;
+ medium priority restored >= 60%
+
+ Further values are as follows:
+
+ 6-15: Unassigned
+
+ The registration procedure is Specification Required.
+
+6. Security Considerations
+
+ The security considerations of [RFC5974] and [RFC5975] apply to this
+ document.
+
+ The restoration priority parameter raises possibilities for theft-of-
+ service attacks because users could claim an emergency priority for
+ their flows without real need, thereby effectively preventing serious
+ emergency calls from getting through. Several options exist for
+ countering such attacks, for example:
+
+ - only some user groups (e.g., the police) are authorized to set the
+ emergency priority bit
+
+ - any user is authorized to employ the emergency priority bit for
+ particular destination addresses (e.g., police or fire
+ departments)
+
+ There are no other known security considerations based on this
+ document.
+
+7. Acknowledgements
+
+ The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch,
+ and Hannes Tschofenig for helpful comments and discussion.
+
+
+
+
+
+
+
+
+Ash, et al. Experimental [Page 16]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+8. References
+
+8.1. Normative References
+
+ [IEEE754] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for
+ Binary Floating-Point Arithmetic", 1985.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
+ Signaling Layer Protocol (NSLP) for Quality-of-Service
+ Signaling", RFC 5974, October 2010.
+
+ [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC
+ Template for the Quality-of-Service NSIS Signaling
+ Layer Protocol (NSLP)", RFC 5975, October 2010.
+
+ [Y.1221] ITU-T Recommendation Y.1221, "Traffic control and
+ congestion control in IP based networks", March 2002.
+
+ [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data
+ communication service - IP packet transfer and
+ availability performance parameters", December 2007.
+
+ [Y.1541] ITU-T Recommendation Y.1541, "Network Performance
+ Objectives for IP-Based Services", February 2006.
+
+ [Y.2172] ITU-T Recommendation Y.2172, "Service restoration
+ priority levels in Next Generation Networks", June
+ 2007.
+
+8.2. Informative References
+
+ [COMPOSITION] Morton, A. and E. Stephan, "Spatial Composition of
+ Metrics", Work in Progress, July 2010.
+
+ [E.361] ITU-T Recommendation E.361, "QoS Routing Support for
+ Interworking of QoS Service Classes Across Routing
+ Technologies", May 2003.
+
+ [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+ Jamin, "Resource ReSerVation Protocol (RSVP) --
+ Version 1 Functional Specification", RFC 2205,
+ September 1997.
+
+ [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
+ Services", RFC 2210, September 1997.
+
+
+
+Ash, et al. Experimental [Page 17]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+ "Definition of the Differentiated Services Field (DS
+ Field) in the IPv4 and IPv6 Headers", RFC 2474,
+ December 1998.
+
+ [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+ Z., and W. Weiss, "An Architecture for Differentiated
+ Services", RFC 2475, December 1998.
+
+ [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+ "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+ [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
+ Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
+ D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+ Behavior)", RFC 3246, March 2002.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26, RFC
+ 5226, May 2008.
+
+ [RFC5835] Morton, A. and S. Van den Berghe, "Framework for
+ Metric Composition", RFC 5835, April 2010.
+
+ [TRQ-QoS-SIG] ITU-T Supplement 51 to the Q-Series, "Signaling
+ Requirements for IP-QoS", January 2004.
+
+Authors' Addresses
+
+ Gerald Ash
+ AT&T Labs
+ 200 Laurel Avenue South
+ Middletown, NJ 07748
+ USA
+
+ EMail: gash5107@yahoo.com
+
+
+ Al Morton
+ AT&T Labs
+ 200 Laurel Avenue South
+ Middletown, NJ 07748
+ USA
+
+ Phone: +1 732 420 1571
+ Fax: +1 732 368 1192
+ EMail: acmorton@att.com
+ URI: http://home.comcast.net/~acmacm/
+
+
+
+Ash, et al. Experimental [Page 18]
+
+RFC 5976 Y.1541 QOSM October 2010
+
+
+ Martin Dolly
+ AT&T Labs
+ 200 Laurel Avenue South
+ Middletown, NJ 07748
+ USA
+
+ EMail: mdolly@att.com
+
+
+ Percy Tarapore
+ AT&T Labs
+ 200 Laurel Avenue South
+ Middletown, NJ 07748
+ USA
+
+ EMail: tarapore@att.com
+
+
+ Chuck Dvorak
+ AT&T Labs
+ 180 Park Ave Bldg 2
+ Florham Park, NJ 07932
+ USA
+
+ Phone: + 1 973-236-6700
+ EMail: cdvorak@att.com
+
+
+ Yacine El Mghazli
+ Alcatel-Lucent
+ Route de Nozay
+ Marcoussis cedex 91460
+ France
+
+ Phone: +33 1 69 63 41 87
+ EMail: yacine.el_mghazli@alcatel.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al. Experimental [Page 19]
+