doc: Add RFC documents

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]
+