One document matched: draft-ietf-nsis-y1541-qosm-03.txt
Differences from draft-ietf-nsis-y1541-qosm-02.txt
NSIS Working Group Jerry Ash
Internet Draft Martin Dolly
<draft-ietf-nsis-y1541-qosm-03.txt> Chuck Dvorak
Expiration Date: May 2007 Al Morton
Percy Tarapore
AT&T
Yacine El Mghazli
Alcatel
November 2006
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-
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 May 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 1]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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 . . . . . . . . . . . . . 7
4. Control Processing for Y.1541 QOSM . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 10
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
11. Intellectual Property Statement . . . . . . . . . . . . . . . 11
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . 12
Copyright Statement . . .. . . . . . . . . . . . . . . . . . . . 12
Conventions Used in This Document
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].
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
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 2]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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
QOSM.
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
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.
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 3]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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
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.
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
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 4]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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
networks.
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
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
format.
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 5]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
0 - best effort
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
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 6]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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
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.
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 7]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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
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. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 8]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
|------| |------| |------| |------|
| 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
The security considerations of [QoS-SIG] and [QSPEC] apply to this
Document. There are no new security considerations based on this
document.
6. 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
allocating new codepoints. Guidelines on the technical criteria to
be followed in evaluating requests for new codepoint assignments are
given for the overall NSIS protocol suite in a separate NSIS
extensibility document [NSIS-EXTENSIBILITY].
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
The allocation policies for further values are as follows:
3-63: Standards Action
64-255: Reserved
7. Acknowledgements
The authors thank Attila Bader, Cornelia Kappler, and Sven Van
den Bosch for helpful comments and discussion.
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 9]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
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
progress.
[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," 2006.
9. Informative References
[E.361] ITU-T Recommendation, "QoS Routing Support for Interworking
of QoS Service Classes Across Routing Technologies," May 2003.
[NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work
in progress.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs," RFC 2434, October 1998.
[RFC2475] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RMD] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling Policy
Model for Networks
10. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Email: gash@att.com
Martin Dolly
AT&T
Room E3-3A14
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-4574
E-mail: mdolly@att.com
Chuck Dvorak
AT&T
Room 2A37
180 Park Avenue, Building 2
Florham Park, NJ 07932
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 10]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
Phone: + 1 973-236-6700
E-mail: cdvorak@att.com
Yacine El Mghazli
Alcatel
Route de Nozay
91460 Marcoussis cedex - FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
Al Morton
AT&T
Room D3-3C06
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-1571
E-mail: acmorton@att.com
Percy Tarapore
AT&T
Room D1-33
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
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.
Ash, et. al. <draft-ietf-nsis-y1541-qosm-03.txt> [Page 11]
Internet Draft Y.1541-QOSM for Y.1541 QoS Classes November 2006
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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-ietf-nsis-y1541-qosm-03.txt> [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 06:23:02 |