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


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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.

   This Internet-Draft will expire on August 27, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T
   Recommendation Y.1541 Network QoS Classes and related signaling
   requirements.  Y.1541 specifies 8 classes of Network Performance



Ash, et al.              Expires August 27, 2008                [Page 1]


Internet-Draft                 Y.1541 QOSM                 February 2008


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Summary of ITU-T Recommendations Y.1541 & Signaling
       Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Y.1541 Classes . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Y.1541-QOSM Processing Requirements  . . . . . . . . . . .  5
   3.  Additional QSPEC Parameters for Y.1541 QOSM  . . . . . . . . .  6
     3.1.  Traffic Model (TMOD) Extension Parameter . . . . . . . . .  6
     3.2.  Restoration Priority Parameter . . . . . . . . . . . . . .  7
   4.  Y.1541-QOSM Considerations and Processing Example  . . . . . .  8
     4.1.  Deployment Considerations  . . . . . . . . . . . . . . . .  8
     4.2.  Applicable QSPEC Procedures  . . . . . . . . . . . . . . .  9
     4.3.  QNE Processing Rules . . . . . . . . . . . . . . . . . . .  9
     4.4.  Processing Example . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Bit-Level QSPEC Example  . . . . . . . . . . . . . . . . . 11
     4.6.  Preemption Behaviour . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17
















Ash, et al.              Expires August 27, 2008                [Page 2]


Internet-Draft                 Y.1541 QOSM                 February 2008


1.  Introduction

   This draft describes a QoS model (QOSM) for NSIS QoS signaling layer
   protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541
   Network QoS Classes and related signaling requirements.  Y.1541
   [Y.1541] currently specifies 8 classes of Network Performance
   objectives, and the Y.1541-QOSM extensions include additional QSPEC
   parameters and QOSM processing guidelines.  The extensions are based
   on standardization work in the ITU-T on QoS signaling requirements
   [Y.1541] [TRQ-QoS-SIG] [E.361].

   [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 [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] [RFC2205] [RFC2210] .  The
   QSPEC object contains the QoS parameters defined by the QOSM.  A QOSM
   provides a specific set of parameters to be carried in the QSPEC.  At
   each QoS NSIS element (QNE), the QSPEC contents are interpreted by
   the resource management function (RMF) for purposes of policy control
   and traffic control, including admission control and configuration of
   the scheduler.


2.  Summary of ITU-T Recommendations Y.1541 & Signaling Requirements

   As stated above, [Y.1541] [Y.1541] is a specification of standardized
   QoS classes for IP networks (a summary of these classes is given
   below).  [TRQ-QoS-SIG] [TRQ-QoS-SIG] specifies the requirements for
   achieving end-to-end QoS in IP networks, with Y.1541 QoS classes as a
   basis.  [Y.1541] [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.  Y.1541 Classes

   [Y.1541] [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 27, 2008                [Page 3]


Internet-Draft                 Y.1541 QOSM                 February 2008


   in [Y.1540].  Classes 0 and 1 might be implemented using the DiffServ
   EF PHB, and support interactive real-time applications.  Classes 2,
   3, and 4 might be implemented using the DiffServ AFxy PHB Group, and
   support data transfer applications with various degrees of
   interactivity.  Class 5 generally corresponds to the DiffServ Default
   PHB, has all the QoS parameters unspecified consistent with a best-
   effort service.  Classes 6 and 7 provide support for extremely loss-
   sensitive user applications, such as high quality digital television,
   TDM circuit emulation, and high capacity file transfers using TCP.
   These classes are intended to serve as a basis for agreements between
   end-users and service providers, and between service providers.  They
   support a wide range of user applications including point-to-point
   telephony, data transfer, multimedia conferencing, and others.  The
   limited number of classes supports the requirement for feasible
   implementation, particularly with respect to scale in global
   networks.

   The QoS classes apply to a packet flow, where [Y.1541] [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.1451 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
   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



Ash, et al.              Expires August 27, 2008                [Page 4]


Internet-Draft                 Y.1541 QOSM                 February 2008


   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] [TRQ-QoS-SIG] provides the requirements for signaling
   information regarding IP-based QoS at the interface between the user
   and the network (UNI) and across interfaces between different
   networks (NNI).  To meet specific network performance requirements
   specified for the Y.1541 QoS classes [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.

   It MUST be possible to derive the following service level parameters
   as part of the process of requesting service:

   a.  Y.1541 QoS class

   b. rate (r)

   c. peak rate (p)

   d. bucket size (b)

   e. peak bucket size (Bp)*



Ash, et al.              Expires August 27, 2008                [Page 5]


Internet-Draft                 Y.1541 QOSM                 February 2008


   f. maximum packet size (M)*

   g.  DiffServ PHB class [RFC2475] [RFC2475]

   h. admission priority

   i. restoration priority*

   All parameters except Bp, M, and restoration priority have already
   been specified in [QSPEC] [I-D.ietf-nsis-qspec].  These additional
   parameters are 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 already supported by [QoS-SIG]
   [I-D.ietf-nsis-qos-nslp] and the functions are illustrated in Section
   4.


3.  Additional QSPEC Parameters for Y.1541 QOSM

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
















Ash, et al.              Expires August 27, 2008                [Page 6]


Internet-Draft                 Y.1541 QOSM                 February 2008


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M|E|N|r|           15          |r|r|r|r|          2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Peak Bucket Size [Bp] (32-bit IEEE floating point number)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Maximum Packet Size [M] (32-bit unsigned integer)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1: TMOD Extension

   When the Bp term is represented as an IEEE floating point value, the
   sign bit MUST be zero (all values MUST be non-negative).  Exponents
   less than 127 (i.e., 0) are prohibited.  Exponents greater than 162
   (i.e., positive 35) are discouraged, except for specifying a peak
   rate of infinity.  Infinity is represented with an exponent of all
   ones (255) and a sign bit and mantissa of all zeros.  The maximum
   packet size (M) is an unsigned integer.

   The QSPEC parameter behavior for (Bp) and (M) is similar to that
   defined in [QSPEC] [I-D.ietf-nsis-qspec], section 6.2.1 and 6.2.2.
   The new parameters (and all traffic-related parameters) are specified
   independently from the Y.1541 class parameter.

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

                      Figure 2: Restoration Priority

   Restoration Priority: 3 priority values are listed here in the order
   of lowest priority to highest priority:

   0 - best effort



Ash, et al.              Expires August 27, 2008                [Page 7]


Internet-Draft                 Y.1541 QOSM                 February 2008


   1 - normal

   2 - high

   Each restoration priority class has two parameters:

   a.  Time-to-Restore: Total amount of time to restore traffic streams
   belonging to a given restoration class impacted by the failure.  This
   time period depends on the technology deployed for restoration.  A
   fast recovery period of < 200 ms is based on current experience with
   SONET rings and a slower recovery period of 2 seconds is suggested in
   order to enable a voice call to recover without being dropped.
   Accordingly, candidate restoration objectives are:

   High Restoration Priority: Time-to-Restore <= 200 ms

   Normal Restoration Priority: Time-to-Restore <= 2 s

   Best Effort Restoration Priority: Time-to-Restore = Unspecified

   b.  Extent of Restoration: Percentage of traffic belonging to the
   restoration class that can be restored.  This percentage depends on
   the amount of spare capacity engineered.  All high priority
   restoration priority traffic, for example, may be "guaranteed" at
   100% by the service provider.  Other classes may offer lesser chances
   for successful restoration.  The restoration extent for these lower
   priority classes depend on SLA agreements developed between the
   service provider and the customer.


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 or parameters (except those described in
   section 3) are required to enable the Y.1541 QOSM.

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.

   QNEs may be Stateful in some limited aspects, but obviously it is
   preferable to deploy stateless QNEs.





Ash, et al.              Expires August 27, 2008                [Page 8]


Internet-Draft                 Y.1541 QOSM                 February 2008


4.2.  Applicable QSPEC Procedures

   All procedures defined in section 5.3 of [QSPEC]
   [I-D.ietf-nsis-qspec] are applicable to this QOSM.

4.3.  QNE Processing Rules

   [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs.

   [Y.1541] section 8 defines the accumulation rules for individual
   performance parameters (e.g., delay, jitter).

   When a QNI specifies the Y.1541 QoS Class number, <Y.1541 QoS Class>,
   it is a sufficient specification of objectives for the <Path
   Latency>, <Path Jitter>, and <Path BER> parameters.  As described
   above in section 2, some Y.1541 Classes do not set objectives for all
   the performance parameters above.  For example, Classes 2, 3, and 4,
   do not specify an objective for <Path Jitter> (referred to as IP
   Packet Delay Variation).  In the case that the QoS Class leaves a
   parameter Unspecified, then that parameter need not be included in
   the accumulation processing.

4.4.  Processing Example

   As described in the example given in [QSPEC] [I-D.ietf-nsis-qspec]
   (Section 4.4) and as illustrated in Figure 3, the QoS NSIS initiator
   (QNI) initiates an end-to-end, inter-domain QoS NSLP RESERVE message
   containing the Initiator QSPEC.  In the case of the Y.1541 QOSM, the
   Initiator QSPEC specifies the <Y.1541 QOS Class>, <TMOD>, <TMOD
   Extension>, <Admission Priority>, <Restoration Priority>, and perhaps
   other QSPEC parameters for the flow.  As described in Section 3, the
   TMOD extension parameter contains the optional, Y.1541-QOSM-specific
   parameters Bp and M; restoration priority is also an optional,
   Y.1541-QOSM-specific parameter.

   As illustrated in Figure 3, the RESERVE message may cross multiple
   domains supporting different QOSMs.  In this illustration, the
   initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress
   node of the local-QOSM domain.  As described in [QoS-SIG]
   [I-D.ietf-nsis-qos-nslp] and [QSPEC] [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 [QSPEC]
   [I-D.ietf-nsis-qspec], if any QNE cannot meet the requirements
   designated by the initiator QSPEC to support an optional QSPEC



Ash, et al.              Expires August 27, 2008                [Page 9]


Internet-Draft                 Y.1541 QOSM                 February 2008


   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.

   Also, the Y.1541-QOSM requires negotiation of the <Y.1541 QoS Class>
   across domains.  This negotiation can be done with the use of the
   existing procedures already defined in [QoS-SIG]
   [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 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 achieve end-to-
   end.  The example illustrates how the QNI can use the cumulative
   values collected in <QoS Available> to decide if a lower <Y.1541 QoS
   Class> than specified in <QoS Desired> is acceptable.








Ash, et al.              Expires August 27, 2008               [Page 10]


Internet-Draft                 Y.1541 QOSM                 February 2008


     |------|   |------|                           |------|   |------|
     | 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 = 4       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TMOD Rate-1 [r] (32-bit IEEE floating point number)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TMOD Size-1 [b] (32-bit IEEE floating point number)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Peak Data Rate-1 [p] (32-bit IEEE floating point number)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Minimum Policed Unit-1 [m] (32-bit unsigned integer)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           15          |r|r|r|r|          2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Ash, et al.              Expires August 27, 2008               [Page 11]


Internet-Draft                 Y.1541 QOSM                 February 2008


     |  Peak Bucket Size [Bp] (32-bit IEEE floating point number)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Maximum Packet Size [M] (32-bit unsigned integer)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           14          |r|r|r|r|          1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Y.1541 QoS Cls.|                (Reserved)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|r|r|r|  Type = 1 (QoS Avail) |r|r|r|r|      Length = 11      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           3           |r|r|r|r|          1            |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                Path Latency (32-bit integer)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           4           |r|r|r|r|          4            |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |          Path Jitter STAT1(variance) (32-bit integer)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Path Jitter STAT2(99.9%-ile) (32-bit integer)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Path Jitter STAT3(minimum Latency) (32-bit integer)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Path Jitter STAT4(Reserved)        (32-bit integer)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           5           |r|r|r|r|          1            |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |             Path Packet Loss Ratio (32-bit floating point)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           14          |r|r|r|r|          1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Y.1541 QoS Cls.|                (Reserved)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 4: An Example QSPEC (Initiator)

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 the registries and initial codepoint assignments
   for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434].
   It also defines the procedural requirements to be followed by IANA in



Ash, et al.              Expires August 27, 2008               [Page 12]


Internet-Draft                 Y.1541 QOSM                 February 2008


   allocating new codepoints.

   This document specifies the following QSPEC parameters to be assigned
   within the QSPEC Parameter ID registry created in [QSPEC]
   [I-D.ietf-nsis-qspec]:

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

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

   This specification creates the following registry with the structure
   as defined below:

   Restoration Priority Parameter (8 bits):

   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-63: Standards Action

   64-255: Reserved


6.  Security Considerations

   The security considerations of [I-D.ietf-nsis-qos-nslp] and
   [I-D.ietf-nsis-qspec] apply to this Document.  There are no new
   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





Ash, et al.              Expires August 27, 2008               [Page 13]


Internet-Draft                 Y.1541 QOSM                 February 2008


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-16
              (work in progress), February 2008.

   [I-D.ietf-nsis-qspec]
              Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
              QSPEC Template", draft-ietf-nsis-qspec-18 (work in
              progress), October 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TRQ-QoS-SIG]
              ITU-T Supplement, "Signaling Requirements for IP-QoS",
              January  2004.

   [Y.1540]   ITU-T Recommendation Y.1540, "Internet protocol data
              communication service - IP packet transfer and
              availability performance parameters", December  2002.

   [Y.1541]   ITU-T Recommendation Y.1540, "Network Performance
              Objectives for IP-Based Services", February  2006.

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-06 (work in progress),
              February 2008.

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

   [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.              Expires August 27, 2008               [Page 14]


Internet-Draft                 Y.1541 QOSM                 February 2008


   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.


Authors' Addresses

   Jerry 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/


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

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






Ash, et al.              Expires August 27, 2008               [Page 15]


Internet-Draft                 Y.1541 QOSM                 February 2008


   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 27, 2008               [Page 16]


Internet-Draft                 Y.1541 QOSM                 February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ash, et al.              Expires August 27, 2008               [Page 17]