Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
draft-ietf-nsis-y1541-qosm-10

Network Working Group                                             G. Ash
Internet-Draft                                                 A. Morton
Intended status: Experimental                                   M. Dolly
Expires: August 8, 2010                                      P. Tarapore
                                                               C. Dvorak
                                                               AT&T Labs
                                                           Y. El Mghazli
                                                          Alcatel-Lucent
                                                        February 4, 2010

       Y.1541-QOSM -- Model for Networks Using Y.1541 QoS Classes
                     draft-ietf-nsis-y1541-qosm-10

Abstract

   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.

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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Ash, et al.              Expires August 8, 2010                 [Page 1]
Internet-Draft                 Y.1541 QOSM                 February 2010

   This Internet-Draft will expire on August 8, 2010.

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
   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 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.

Ash, et al.              Expires August 8, 2010                 [Page 2]
Internet-Draft                 Y.1541 QOSM                 February 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Summary of ITU-T Recommendations Y.1541 & Signaling
       Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Description of Y.1541 Classes  . . . . . . . . . . . . . .  3
     2.2.  Y.1541-QOSM Processing Requirements  . . . . . . . . . . .  5
   3.  Additional QSPEC Parameters for Y.1541 QOSM  . . . . . . . . .  7
     3.1.  Traffic Model (TMOD) Extension Parameter . . . . . . . . .  7
     3.2.  Restoration Priority Parameter . . . . . . . . . . . . . .  7
   4.  Y.1541-QOSM Considerations and Processing Example  . . . . . .  9
     4.1.  Deployment Considerations  . . . . . . . . . . . . . . . .  9
     4.2.  Applicable QSPEC Procedures  . . . . . . . . . . . . . . .  9
     4.3.  QNE Processing Rules . . . . . . . . . . . . . . . . . . . 10
     4.4.  Processing Example . . . . . . . . . . . . . . . . . . . . 10
     4.5.  Bit-Level QSPEC Example  . . . . . . . . . . . . . . . . . 12
     4.6.  Preemption Behaviour . . . . . . . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     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  . . . . . . . . . . . . . . . . 14
       5.2.3.  Extent of Restoration Field  . . . . . . . . . . . . . 15
       5.2.4.  Reserved Bits  . . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Ash, et al.              Expires August 8, 2010                 [Page 3]
Internet-Draft                 Y.1541 QOSM                 February 2010

1.  Introduction

   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.  [Y.1541] currently specifies 8 classes of Network
   Performance objectives, and the Y.1541-QOSM extensions include
   additional QSPEC [I-D.ietf-nsis-qspec] 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].

   [I-D.ietf-nsis-qos-nslp] 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 [I-D.ietf-nsis-qspec] contains a set of
   parameters and values describing the requested resources.  It is
   opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and
   AdSpec specified in [RFC2205] [RFC2210].  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.

2.  Summary of ITU-T Recommendations Y.1541 & 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.

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

Ash, et al.              Expires August 8, 2010                 [Page 4]
Internet-Draft                 Y.1541 QOSM                 February 2010

   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 precidence.

   Classes 0 and 1 might be implemented using the DiffServ Expedited
   Forwarding (EF) Per-Hop Behavior (PHB), and support interactive real-
   time applications[RFC3246].  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[RFC2597].  Class 5 generally corresponds to the
   DiffServ Default PHB, 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 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.

   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 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.

   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.

   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.

   Class 3: Interactive transaction data.  Mean delay upper bound is 400

Ash, et al.              Expires August 8, 2010                 [Page 5]
Internet-Draft                 Y.1541 QOSM                 February 2010

   ms, delay variation is unspecified, and loss ratio is less than
   10^-3.  Application examples include signaling.

   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

   Class 5: Unspecified applications with unspecified mean delay, delay
   variation, and loss ratio.  Application examples include traditional
   applications of Default IP Networks

   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.

   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.

   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.

   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], [I-D.ietf-ippm-framework-compagg], and
   [I-D.ietf-ippm-spatial-composition].

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 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.

   For implementations to claim compliance with this memo, it MUST be
   possible to derive the following service level parameters as part of

Ash, et al.              Expires August 8, 2010                 [Page 6]
Internet-Draft                 Y.1541 QOSM                 February 2010

   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 (M), 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 [I-D.ietf-nsis-qspec].  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]

   o  restoration priority, as defined in Section 3 of this memo

   and 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.

Ash, et al.              Expires August 8, 2010                 [Page 7]
Internet-Draft                 Y.1541 QOSM                 February 2010

   These signaling requirements are supported in
   [I-D.ietf-nsis-qos-nslp] 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
   [I-D.ietf-nsis-qspec].

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.

   The QSPEC parameter behavior for the TMOD extended parameter follows
   that defined in Section 3.3.1 of[I-D.ietf-nsis-qspec].  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:

Ash, et al.              Expires August 8, 2010                 [Page 8]
Internet-Draft                 Y.1541 QOSM                 February 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |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 the same as 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 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 priority traffic, for

Ash, et al.              Expires August 8, 2010                 [Page 9]
Internet-Draft                 Y.1541 QOSM                 February 2010

   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.

   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.

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 [I-D.ietf-nsis-qspec] are
   applicable to this QOSM.

Ash, et al.              Expires August 8, 2010                [Page 10]
Internet-Draft                 Y.1541 QOSM                 February 2010

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 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.

4.4.  Processing Example

   As described in the example given in Section 3.4 of
   [I-D.ietf-nsis-qspec] 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.

   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
   [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec], 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 [I-D.ietf-nsis-qspec], 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.

Ash, et al.              Expires August 8, 2010                [Page 11]
Internet-Draft                 Y.1541 QOSM                 February 2010

   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 [I-D.ietf-nsis-qos-nslp].  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.

   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.

   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.

Ash, et al.              Expires August 8, 2010                [Page 12]
Internet-Draft                 Y.1541 QOSM                 February 2010

     |------|   |------|                           |------|   |------|
     | 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 fir 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".

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

Ash, et al.              Expires August 8, 2010                [Page 13]
Internet-Draft                 Y.1541 QOSM                 February 2010

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

                  Figure 4: An Example QSPEC (Initiator)

   where 32-bit floating point numbers are as specified in [IEEE754].

4.6.  Preemption Behaviour

   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.

5.  IANA Considerations

   This section defines additional codepoint assignments in the QSPEC

Ash, et al.              Expires August 8, 2010                [Page 14]
Internet-Draft                 Y.1541 QOSM                 February 2010

   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 [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 to be assigned
   within the QSPEC Parameter ID registry created in
   [I-D.ietf-nsis-qspec]:

   <TMOD Extension> parameter (Section 3.1 above, suggested ID=15)

   <Restoration Priority> parameter (Section 3.2 above, suggested ID=16)

5.2.  Restoration Priority Parameter Registry

   The Registry for Restoration Priority contains assignments for three
   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:

   0-2: assigned as specified in Section 3.2:

   0: best-effort priority

   1: normal priority

   2: high priority

   The allocation policies for further values are as follows:

   3-255: 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:

Ash, et al.              Expires August 8, 2010                [Page 15]
Internet-Draft                 Y.1541 QOSM                 February 2010

   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

   The allocation policies for further values are as follows:

   3-15: 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:

   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%

   The allocation policies for further values are as follows:

   6-15: Specification Required

5.2.4.  Reserved Bits

   The remaining bits in the Restoration Priority Parameter are
   Reserved.  The Reserved bits MAY be designated for other uses in the
   future.

Ash, et al.              Expires August 8, 2010                [Page 16]
Internet-Draft                 Y.1541 QOSM                 February 2010

6.  Security Considerations

   The security considerations of [I-D.ietf-nsis-qos-nslp] and
   [I-D.ietf-nsis-qspec] 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 to get 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.

8.  References

8.1.  Normative References

   [I-D.ietf-nsis-qos-nslp]
              Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
              Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
              (work in progress), January 2010.

   [I-D.ietf-nsis-qspec]
              Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
              Template", draft-ietf-nsis-qspec-24 (work in progress),
              January 2010.

   [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.

   [Y.1221]   ITU-T Recommendation Y.1221, "Traffic control and

Ash, et al.              Expires August 8, 2010                [Page 17]
Internet-Draft                 Y.1541 QOSM                 February 2010

              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

   [E.361]    ITU-T Recommendation E.361, "QoS Routing Support for
              Interworking of QoS Service Classes Across Routing
              Technologies", May 2003.

   [I-D.ietf-ippm-framework-compagg]
              Morton, A., "Framework for Metric Composition",
              draft-ietf-ippm-framework-compagg-09 (work in progress),
              December 2009.

   [I-D.ietf-ippm-spatial-composition]
              Morton, A. and E. Stephan, "Spatial Composition of
              Metrics", draft-ietf-ippm-spatial-composition-10 (work in
              progress), October 2009.

   [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.

   [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,

Ash, et al.              Expires August 8, 2010                [Page 18]
Internet-Draft                 Y.1541 QOSM                 February 2010

              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.

   [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

   Phone:
   Fax:
   Email: gash5107@yahoo.com
   URI:

   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.              Expires August 8, 2010                [Page 19]
Internet-Draft                 Y.1541 QOSM                 February 2010

   Martin Dolly
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748
   USA

   Phone:
   Fax:
   Email: mdolly@att.com
   URI:

   Percy Tarapore
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748
   USA

   Phone:
   Fax:
   Email: tarapore@att.com
   URI:

   Chuck Dvorak
   AT&T Labs
   180 Park Ave Bldg 2
   Florham Park,, NJ  07932
   USA

   Phone: + 1 973-236-6700
   Fax:
   Email: cdvorak@att.com
   URI:   http:

   Yacine El Mghazli
   Alcatel-Lucent
   Route de Nozay
   Marcoussis cedex,   91460
   France

   Phone: +33 1 69 63 41 87
   Fax:
   Email: yacine.el_mghazli@alcatel.fr
   URI:

Ash, et al.              Expires August 8, 2010                [Page 20]