NSIS Working Group                                           Jerry Ash
Internet Draft                                            Martin Dolly
<draft-ash-nsis-y1541-qosm-00.txt>                        Chuck Dvorak
Expiration Date: November 2005                               Al Morton
                                                        Percy Tarapore
                                                     Yacine El Mghazli

                                                              May 2005

Y.1541-QOSM -- Y.1541 QoS Model
for Networks Using Y.1541 QoS Classes

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 26, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T
   Recommendation Y.1541 QoS signaling requirements.  Y.1541 specifies 6
   standard QoS classes, and the Y.1541-QOSM extensions include
   additional QSPEC parameters and QOSM control processing guidelines.

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 1]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Summary of ITU-T Recommendations Y.1541 & Signaling
      Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
      2.1 Y.1541 QoS Classes . . . . . . . . . . . . . . . . . . . . 3
      2.2. Y.1541 Signaling Requirements . . . . . . . . . . . . . . 5
   3. Additional QSPEC Parameters for Y.1541 QOSM  . . . . . . . . . 6
      3.1 <Token Bucket Extensions> Parameters . . . . . . . . . . . 6
      3.2 <Restoration Priority> Parameter . . . . . . . . . . . . . 6
   4. Control Processing for Y.1541 QOSM . . . . . . . . . . . . . . 7
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . 9
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 9
   7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
   9. Informative References . . . . . . . . . . . . . . . . . . . . 10
   10. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 10
   11. Intellectual Property Statement . . . . . . . . . . . . . . . 11
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . . 12
   Disclaimer of Validity  . . . . . . . . . . . . . . . . . . . . . 12

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 2]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

1. Introduction

   This draft describes a QoS model (QOSM) for QoS-NSIS signaling
   layer protocol (QoS-NSLP) application based on ITU-T Recommendation
   Y.1541 QoS signaling requirements.  Y.1541 currently specifies 6
   standard QoS classes, and the Y.1541-QOSM extensions include
   additional QSPEC parameters and QOSM control 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] 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] 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].  The QSPEC object contains control information and the QoS
   parameters defined by the QOSM.  A QOSM provides a specific set of
   parameters to be carried in the QSPEC - IntServ [RFC2210], DiffServ
   [RFC2475], and [Y.1541] are examples of QOSMs.  At each QoS NSIS
   element (QNE), its contents are interpreted by the resource
   management function (RMF) for the purposes of policy control and
   traffic control (including admission control and configuration of the
   packet classifier and scheduler).

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

   As stated above, Recommendation [Y.1541] is a specification of
   standardized QoS classes for IP networks (a summary of these classes
   is given below).  Recommendation [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 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 control information needed to support the Y.1541

2.1 Y.1541 QoS 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

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 3]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   objectives for one-way IP packet delay, IP packet delay variation, IP
   packet loss ratio, etc.  Classes 0 and 1, which generally correspond
   to the DiffServ EF PHB, support interactive real-time applications.
   Classes 2, 3, and 4, which generally correspond to the DiffServ AFxy
   PHB Group, support non-interactive applications.  Class 5, which
   generally corresponds to the DiffServ best-effort PHB, has all the
   QoS parameters unspecified.  These classes serve as a basis for
   agreements between end-users and service providers, and between
   service providers. They support a wide range of traffic 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.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

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

   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.

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 4]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   Recommendation Y.1541 is currently being enhanced to provide support
   for extremely loss-sensitive user applications, such as high quality
   digital television, TDM circuit emulation, and high capacity
   transfers using TCP. The plan is to add a minimal number of classes
   to meet these needs.

2.2 Y.1541 Signaling Requirements

   [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, a network needs to provide specific user plane
   functionality at UNI, NNI, and INI 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.

   The call/session control signaling includes an indication of the QoS
   requirements for each session.  Obtaining user-to-user QoS will
   require standard signaling protocols for communicating the
   requirements among the major entities.  These entities include users
   and their end terminal equipment, and network service providers and
   their equipment, especially equipment implementing the inter-working
   and signaling function between networks, and between users and

   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. peak data rate (p)
   c. peak bucket size (Bp)
   d. sustainable rate (Rs)
   e. sustainable bucket size (b)
   f. token bucket rate (r)
   g. maximum allowed packet size (M)
   h. DiffServ field [RFC2475]
   i. reservation priority class (urgency of establishing service
      connection) can be requested
   j. restoration priority class (urgency of restoring service
      connection under failure) can be requested

   All parameters except <Bp>, <Rs>, and <Restoration Priority> have
   already been specified in [QSPEC].  These additional parameters are
   specified in Section 3.

   It MUST be possible to perform the following QoS-NSLP signaling

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 5]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   functions to enable 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.

   Additional signaling functions beyond those already specified in
   [QSPEC] are discussed in Section 4.

3. Additional QSPEC Parameters for Y.1541 QOSM

3.1 <Token Bucket Extensions> Parameters

   The <Token Bucket Extensions> parameters are represented by two
   floating point numbers in single-precision IEEE floating point

   |  Peak Bucket Size [Bb] (32-bit IEEE floating point number)    |
   |  Sustainable Rate [Rs] (32-bit IEEE floating point number)    |

   When the Bp and Rs terms are represented as IEEE floating point
   values, 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 zeroes.

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 4 5 6 7
   |  Restoration  |
   |   Priority    |

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

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 6]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   2 - best effort
   1 - normal
   0 - 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. Control Processing for Y.1541 QOSM

   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
   control processing capabilities or parameters are required to enable
   the Y.1541 QOSM.

   As described in the example given in [QSPEC], Section 4.3, and as
   illustrated in Figure 1, 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>, <Token Bucket>, <Token Bucket
   Extensions>, <Reservation Priority>, <Restoration Priority>, and
   perhaps other generic QSPEC parameters for the flow.  As described in
   Section 3, the <Token Bucket Extensions> object contains the
   optional, Y.1541-QOSM-Specific parameters <Bp> and <Rs>; <Restoration
   Priority> is also an optional, Y.1541-QOSM-Specific parameter.

   As illustrated in Figure 1, 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] and
   [QSPEC], at the ingress edge node of the Local-QOSM domain, the
   end-to-end, inter-domain QoS-NSLP messages trigger the generation of

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 7]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   a Local QSPEC, which is pushed on top of the Initiator QSPEC.  That
   is, the Initiator QSPEC is translated into a Local-QOSM QSPEC.  For
   example, if the Local-QOSM is the RMD-QOSM [RMD], then the <Y.1541
   QOS Class> parameter would be translated to the <PHB Class>
   parameter.  The Local QSPEC is used for QoS processing in the
   Local-QOSM domain, and then popped at the egress edge node of the
   Local-QOSM domain.  The Initiator QSPEC is then used for QoS
   processing at the QoS NSIS receiver (QNR).

   Each node on the data path checks the availability of resources and
   accumulating the delay, delay variation, and loss ratio parameters,
   as described below.  If an intermediate node cannot accommodate the
   new request, it indicates it by marking a single bit, the <NON QOSM
   Hop> bit specified in [QSPEC], in the message, and continues
   forwarding the message.  When the message reaches the egress edge
   node of the Local-QOSM domain, if no intermediate node has denied the
   reservation, the Initiator QSPEC is forwarded to the next domain, as
   described above.  If an intermediate node has denied the reservation,
   by setting the <NON QOSM Hop> bit, the reservation is denied.

   As specified in [QSPEC], if any QNE does not support the Y.1541 QOSM,
   it sets the <NON QOSM Hop> flag to one to indicate that it does not
   support the Y.1541 QOSM.  The <NON QOSM Hop> flag is normally set to
   zero.  As specified in [QSPEC], if any QNE cannot meet the
   requirements designated by the Initiator QSPEC to support an optional
   QSPEC parameter, for example, it cannot support the accumulation of
   end-to-end delay with the <Path Latency> parameter, the QNE sets the
   <Path Latency Flag> to one.  The <Path Latency Flag> is normally set
   to zero.

   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].  For example, the
   QNI sets <Desired QoS>, <Minimum QoS>, <Available QoS> objects to
   include <Y.1541 QoS Class>, <Path Latency>, <Path Jitter>, <Path BER>
   parameters.  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

   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

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 8]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   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.

     |------|   |------|                           |------|   |------|
     | e2e  |<->| e2e  |<------------------------->| e2e  |<->| e2e  |
     | QoS  |   | QoS  |                           | QoS  |   | QoS  |
     |      |   |------|   |-------|   |-------|   |------|   |      |
     |      |   | local|<->| local |<->| local |<->| local|   |      |
     |      |   | QoS  |   |  QoS  |   |  QoS  |   |  QoS |   |      |
     |      |   |      |   |       |   |       |   |      |   |      |
     | 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 1   Protocol Model of Y.1541-QOSM Operation

5. Security Considerations

   There are no new security considerations based on this draft.

6. IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434].

   [QoS-SIG] requires IANA to create a new registry for QoS Model
   Identifiers.  The QoS Model Identifier (QOSM ID) is a 32-bit value
   carried in a QSPEC object.  The allocation policy for new QOSM IDs is

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>        [Page 9]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   This document also defines 3 new objects for the QSPEC Template, as
   detailed in Section 3.  Values are to be assigned for them from the
   NTLP Object Type registry.

7. Acknowledgements

   The authors thank Attila Bader, Cornelia Kappler, and Sven Van
   den Bosch for helpful comments and discussion.

8. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.
   [QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service
   Signaling," work in progress.
   [QSPEC], Ash, J., et. al., "QoS-NSLP QSPEC Template," work in
   [TRQ-QoS-SIG] ITU-T Recommendation, "Signaling Requirements for
   IP-QoS," January 2004.
   [Y.1541] ITU-T Recommendation Y.1541, "Network Performance
   Objectives for IP-Based Services," May 2002.

9. Informative References

   [E.361] ITU-T Recommendation, "QoS Routing Support for Interworking
   of QoS Service Classes Across Routing Technologies," May 2003.
   [RFC2205] Braden, B., et. al., "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.
   [RFC2475] Blake, S., et. al., "An Architecture for Differentiated
   Services", RFC 2475, December 1998.

10. Authors' Addresses

   Jerry Ash
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   Email: gash@att.com

   Martin Dolly
   Room E3-3A14
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-4574
   E-mail: mdolly@att.com

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>       [Page 10]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   Chuck Dvorak
   Room 2A37
   180 Park Avenue, Building 2
   Florham Park, NJ 07932
   Phone: + 1 973-236-6700
   E-mail: cdvorak@att.com

   Yacine El Mghazli
   Route de Nozay
   91460 Marcoussis cedex - FRANCE
   Phone: +33 1 69 63 41 87
   Email: yacine.el_mghazli@alcatel.fr

   Al Morton
   Room D3-3C06
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-1571
   E-mail: acmorton@att.com

   Percy Tarapore
   Room D1-3D33
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-4172
   E-mail: tarapore@.att.com

11. Intellectual Property Statement

   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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>       [Page 11]

Internet Draft       Y.1541-QOSM for Y.1541 QoS Classes        May 2005

   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.

Ash, et. al.         <draft-ash-nsis-y1541-qosm-00.txt>       [Page 12]