One document matched: draft-bader-nsis-rmd-diffserv-qsm-00.txt
NSIS Working Group Attila Bader
INTERNET-DRAFT Lars Westberg
Ericsson
Expires: January 2005 Georgios Karagiannis
University of Twente
Cornelia Kappler
Siemens
Tom Phelan
Sonus
July 10, 2004
Resource Management In Diffserv: An NSIS QoS Signaling Model for
Diffserv Networks
<draft-bader-nsis-rmd-diffserv-qsm-00.txt>
Status of this memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Abstract
Resource Management in Diffserv (RMD) is a technique for adding
admission control to Differentiated Services (Diffserv) networks.
RMD complements the Diffserv architecture by pushing complex
classification, conditioning and admission control functions to
the edges of a Diffserv domain and simplifying the operation of
internal nodes. It allows feedback to systems outside of the
Diffserv domain on the availability of resources for individual
flows within the domain while aggregating end-to-end resource
reservations at the edge of the domain to reduce the burden on
internal nodes.
Bader, et al. [Page 1]
INTERNET-DRAFT RMD QoS signaling model
This document describes the RMD concept and an NSIS QoS Signaling
Model for Diffserv. The RMD QoS Signaling Model allows devices to
use the NSIS QoS-NSLP protocol to signal reservation requests from
devices outside the Diffserv domain to edge nodes in the domain,
edge nodes to aggregate the requests and signal the aggregated
requests through internal nodes along the data path to the egress
edge nodes, and for egress edge nodes to signal the original,
disaggregated, requests to outside devices.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4
3. Overview of RMD QoS Model and QoS Signaling Model . . . . . .4
3.1 RMD QoS Model . . . . . . . . . . . . . . . . . . . . . .4
3.2 RMD QoS Signaling Model Overview . . . . . . . . . . . . 5
4. RMD QoS Signaling Model detailed description . . . . . . . . 6
4.1 Role of QoS NSLP Entities (QNEs) . . . . . . . . . . . . 6
4.2 QSpec Definition . . . . . . . . . . . . . . . . . . . . 6
4.2.1 RMD QoS descriptors . . . . . . . . . . . . . . . .7
4.2.2 RMD control information . . . . . . . . . . . . . .7
4.2.3 Mapping of QSpec parameters onto generic
QSpec Parameters . . . . . . . . . . . . . . . . . 8
4.3 Message format . . . . . . . . . . . . . . . . . . . . . 8
4.4 State management . . . . . . . . . . . . . . . . . . . . 8
4.5 Operation and sequence of events . . . . . . . . . . . . 8
4.5.1 Edge discovery and addressing of messages . . . . .9
4.5.2 Basic unidirectional operation . . . . . . . . . . 9
4.5.2.1 Successful reservation. . . . . . . . . . . . 9
4.5.2.2 Unsuccessful reservation . . . . . . . . . . .9
4.5.2.3 Severe congestion. . . . . . . . . . . . . . .9
4.5.3 Basic bidirectional operation . . . . . . . . . . 10
5. Security Consideration. . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .10
7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .10
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .11
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Appendix: QoS models, QoS Signaling Models and Qspecs . . .12
Bader, et al. [Page 2]
INTERNET-DRAFT RMD QoS signaling model
1. Introduction
The Differentiated Services (Diffserv) architecture ([RFC2475],
[RFC2638]) was introduced as a result of efforts to avoid the
scalability and complexity problems of Intserv [RFC1633].
Scalability is achieved by offering services on an aggregate basis
rather than per-flow and by forcing as much of the per-flow state
as possible to the edges of the network. The service
differentiation is achieved using the Differentiated Services (DS)
field in the IP header and the Per-Hop Behavior (PHB) as main
building blocks. Packets are handled at each node according to the
PHB indicated by the DS field in the message header.
The Diffserv architecture does not specify any way for devices
outside the domain to dynamically reserve resources or receive
indications of network resource availability. In practice,
service providers rely on subscription-time Service Level
Agreements (SLAs) that statically define the parameters of the
traffic that will be accepted from a customer.
In [RMD], RMD was introduced as a possible method for dynamic
reservation of resources within a Diffserv domain. It describes a
method for aggregating individual reservation request at the
ingress edge of the domain, two possible modes of operation for
internal nodes to admit aggregated requests (a stateless,
measurement-based mode, and a reduced-state reservation mode), and
a method to forward the original requests across the domain to the
egress edge and on.
This document describes the RMD concept and specifies a data-path-
coupled NSIS QoS Signaling Model that defines how the path-coupled
signaling provided by the NSIS QoS-NSLP (Next Steps In Signaling
Quality of Service ¡ NSIS Signaling Layer Protocol) can be used to
support RMD. The RMD QoS Signaling Model uses the QoS-NSLP [QoS-
NSLP] and the NTLP (NSIS Transport Layer Protocol) [NTLP] that are
being standardized by the NSIS working group.
The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP)
establishes and maintains states at nodes along the path of a data
flow for the purpose of providing or querying forwarding resources
for that flow [QoS-NSLP]. In QoS-NSLP the signaling is
independent of the underlying QoS model; it can signal for any QoS
provisioning method or QoS architecture, such as Diffserv
[RFC2475] or IntServ [RFC1633]. The method by which the protocol
signals for a specific QoS Model is called QoS Signaling Model. A
QoS Signaling Model defines specific QSpec objects, which are
carried in QoS-NSLP messages. QSpec objects include QoS
descriptors and control information. A QoS Signaling Model also
describes how QSpecs are processed. More information on QoS
Models, QoS signaling models and QSpec is provided in the
Appendix.
Bader, et al. [Page 3]
INTERNET-DRAFT RMD QoS signaling model
In the RMD QoS signaling model, the edges of the Diffserv domain
support both the NSIS stateful and stateless/reduced state
operations, while the interior routers in the Diffserv domain
support only the NSIS stateless/reduced state operation. Only
routers at the edges of a Diffserv domain support the QoS-NSLP
stateful operation. Internal routers support either the QoS-NSLP
stateless operation, or a reduced-state operation with coarser
granularity than the edge nodes (e.g., per PHB).
2. Terminology
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.
3. Overview of RMD QoS Model and QoS Signaling Model
3.1. RMD QoS Model
The dynamic Diffserv QoS signaling model can be realized by using
the original concept of Resource Management in Diffserv (RMD)
framework [RMD]. In RMD, scalability is achieved by separating a
complex reservation mechanism used in edge nodes of a Diffserv
domain from a much simpler reservation mechanism needed in the
interior nodes. In particular, it is assumed that edge nodes of a
Diffserv domain support per-flow QoS states in order to provide
QoS guarantees for each flow. Interior nodes use only one
aggregated reservation state per traffic class or no states at
all. This solution allows fast processing of signaling messages
and makes possible to handle large number of flows in the interior
nodes. In this way, the RMD concept optimizes the NSLP/NTLP
functionality and processing.
In RMD two basic operation modes are described: a measurement
based admission control and a reservation based admission control.
The measurement-based algorithm uses the requested and available
resources as input to query the aggregated reservation state per
traffic class in the interior nodes. The advantage of measurement
based resource management protocols is that they do not require
explicit reservation or release. Moreover, when the user traffic
is variable, measurement based admission control could provide
higher network utilization than, e.g., peak-rate reservation.
However, this requires more complex implementation in interior
nodes and introduces an uncertainty of the availability of the
resources. In case of the reservation-based method, each node in
the domain maintains one reservation state per traffic class. The
reservation is done in resource units. These resources are
requested dynamically per PHB and reserved on demand in all nodes
in the communication path from an ingress node to an egress node.
Bader, et al. [Page 4]
INTERNET-DRAFT RMD QoS signaling model
3.2. RMD QoS Signaling Model Overview
We denote the dynamic Diffserv QoS signaling model, which is based
on the RMD concept, the RMD QoS signaling model. The RMD QoS
signaling model supports both measurement- and reservation-based
admission control. In the first case QoS-NSLP states do not need
to be refreshed, therefore it is a stateless operation mode, while
the reservation based methods is a reduced state operation mode.
The RMD QoS Signaling Model uses a simple, hop-by-hop signaling
mechanism. When a new flow arrives with some requested resources
(typically bandwidth), a message indicating the required resources
is sent along the data path. Every node, one after the other,
checks the available resources on the data path of the flow with
either the reservation-based or the measurement-based method. If
an intermediate node cannot accommodate the new request, it
indicates it by marking a single bit in the message.
In the simplest case the domain wherein the RMD QoS signaling
model is applied is identical to a Diffserv administrative
domain. However, the protocol can be extended for multiple domain
as well. The boundary nodes of the domain are NSIS aware edge
nodes (QNF ingress and QNF egress edges) and the interior nodes
are NSIS aware interior nodes (QNF interior). The RMD QoS
Signaling Model uses the stateless/reduced state operation mode
defined in QoS-NSLP.
|------| |-------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QoS | | QoS | | QoS | | QoS |
| | |-------| |------| |------|
| | |-------| |-------| |-------| |------| | |
| | | local |<->| local |<->| local |<->| local| | |
| | | QoS | | QoS | | QoS | | QoS | | |
| | | | | | | | | | | |
| NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP |
|st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful|
| | | | |red.st.| |red.st.| | | | |
| | |-------| |-------| |-------| |------| | |
|------| |-------| |-------| |-------| |------| |------|
------------------------------------------------------------------
|------| |-------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful|
|------| |-------| |-------| |-------| |------| |------|
QNI QNF QNF QNF QNF QNR
(end) (ingress edge)(interior) (interior) (egress edge) (end)
st.ful: statefull, st.less: stateless
st.less red.st.: stateless or reduced state
Figure 1 Protocol model of stateless/reduced state operation
Bader, et al. [Page 5]
INTERNET-DRAFT RMD QoS signaling model
The protocol model of the RMD QoS Signaling Model is shown in
Figure 1. Consider an end-to-end QoS signaling model, i.e.,
Intserv, in which NF nodes between End and Edge nodes install and
maintain per-flow QoS-NSLP states. In the Edge node of the
Diffserv domain, the end-to-end QoS-NSLP messages trigger the
generation of local dynamic Diffserv QoS-NSLP messages. The QSpec
of the end-to-end QoS-NSLP message is translated into RMD QSpec.
The original QoS-NSLP messages are sent directly to the next NTLP
stateful node, e.g. to the egress edge node. The local QoS-NSLP
messages are processed and interpreted in all interior NSLP
routers along the path, hop-by-hop, up to the egress edge node.
4. RMD QoS Signaling Model detailed description
This section describes the RMD QoS signaling model in details.
Particularly, we explain the role of stateless and reduced-state
QNEs, define the QSpec Object, the format of QoS NSLP messages,
how QSpecs are processed and used, and the protocol operation.
4.1. Role of QoS NSLP Entities (QNEs)
Edge nodes of an RMD domain can support both NSIS operation modes,
i.e., stateful and stateless/reduced state operation modes. As
NSIS stateful nodes the edge nodes can store and administrate QoS-
NSLP and NTLP states. The interior nodes are either completely
stateless, i.e., they are not supporting any QoS-NSLP or NTLP
states as for measurement-based operation, or they are reduced
state nodes, i.e., they do not store NTLP states but they store
per PHB aggregated QoS-NSLP states as in reservation-based
operation.
Note that the RMD domain may contain interior nodes that are not
NSIS aware nodes. Furthermore, some of these NSIS unaware nodes
may be used for measuring the traffic congestion level on the data
path. These measurements, however, can be used by the RMD QoS
signaling model in the severe congestion operation (see Section
4.5.2.3).
4.2. Qspec Definition
This section describes the Qspec that is used by the RMD QoS
signaling model. There are two types of QSpec parameters: QoS
Descriptors, and Control Information. RMD QSpec parameters are
defined in [RMD], and will be updated in line with QSpec Template
draft [QSM-T].
Bader, et al. [Page 6]
INTERNET-DRAFT RMD QoS signaling model
4.2.1. RMD QoS descriptors
<bandwidth>:
This parameter specifies the resources to be reserved in the nodes
along the data path. It can be number of resource units or
bandwidth. Bandwidth can be peak bandwidth, average bandwidth or
even effective bandwidth, depending on the implementation. The
default interpretation of this field is peak bandwidth.
<PHB>:
This parameter specifies the traffic class for which resources
should be reserved
Both these QoS descriptors are immutable and of the type "QoS
desired".
4.2.2. RMD control information
<M Bit>:
In case of unsuccessful reservation in an interior QNF, this QNF
sets the M bit in order to notify the egress QNF.
<Hop Count>:
The Hop Count is set to zero when a RESERVE message enters a
domain and increased by one at each interior QNF. However when a
QNF is reached that does not have sufficient resources to admit
the reservation, the M Bit is set, and the Hop Count value is
frozen. Hence the Hop Count counts the number of hops where the
reservation was successful. In case of an unsuccessful
reservation the M Bit is set, and the egress QNF reacts by sending
a RESPONSE message containing the Hop Count to the ingress QNF.
The ingress QNF uses the Hop Count value to remove the unnecessary
reservations by an explicit tearing RESERVE message to the nodes
along the path where the reservation has already been made.
<S Bit>:
In case of a route change refreshing RESERVE messages follow the
new data path, and hence resources are requested there. However,
on the new path resources may not be sufficient to accommodate the
new traffic. Congested interior nodes should notify edge QNFs
about the congestion, in order to terminate some of the flows.
The notification of the egress QNF is carried out by marking
either the data packets with dedicated DSCPs or by setting the S
Bit indicating severe congestion in the refresh message. The
egress QNF decides which flows should be terminated and sends a
Response message to the Ingress edge with the flow ID and
indicating the severe congestion. Since refresh messages are
usually sent less frequently than the data packets a more
efficient method for the notification is marking the data packets
by changing the DSCP field.
Bader, et al. [Page 7]
INTERNET-DRAFT RMD QoS signaling model
More details on the required control information for the RMD QoS
signaling model will be provided in a future version of this
draft.
4.2.3. Mapping of QSpec parameters onto generic QSpec Parameters
To be provided in a future version of this draft.
4.3. Message format
The format of the messages used by the RMD QoS signaling model
complies with the QoS-NSLP specification. As specified in [QoS-
NSLP], for each QoS-NSLP message type, there is a set of rules for
the permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation
should create messages with the objects in the order shown here,
but accept the objects in any permissible order. More details on
the message formats will be provided in the future versions of this
draft.
4.4. State management
The way of how the QoS-NSLP states are created and managed is
specified in [QoS-NSLP]. This section will describe how the
reservation states Resource Management Function of the reduced
states nodes are created and maintained. More details on the state
management in the reduced state will be provided in the future.
4.5. Operation and sequence of events
This section describes the operation and the sequence of events in
the RMD QoS signaling model. More details on the operation and the
sequence of events will be provided in future versions of this
draft. This operation is similar to the protocol operation
described in [RMD].
The transport characteristics for the 'local' reservation model
can be different from that of the end-to-end reservation model.
GIMPS can be used in a different way for the edge-to-edge and
hop-by-hop sessions, (i.e. sending of messages in datagram mode,
and not retaining optional path state, i.e., NTLP stateless mode).
The reduced state reservation can be updated independently of the
per-flow end-to-end reservations.
Bader, et al. [Page 8]
INTERNET-DRAFT RMD QoS signaling model
4.5.1. Edge discovery and addressing of messages
This section describes the egress edge discovery and the
addressing of the signaling messages.
Mainly, the egress edge discovery can be performed either by using
the NTLP discovery mechanism or by configuration. The addressing
of signaling messages depends on the used NTLP transport mode.
The RMD QoS signaling messages that are processed only by the edge
nodes use the peer-peer addressing of the NTLP connection mode
(C). While the RMD QoS signaling messages that are processed by
all nodes of the Diffserv domain, i.e., edges and interior nodes,
use the end-end addressing of the NTLP datagram (D) mode. More
details on the egress edge discovery and the addressing of the
signaling messages will be provided in a future version of this
draft.
4.5.2. Basic unidirectional operation
This section describes the basic unidirectional operation and
sequence of events of the RMD QoS signaling model. The following
basic operation cases are distinguished, more details can be
found in [RMD].
4.5.2.1. Successful reservation
This section describes the operation of the RMD QoS signaling
model where a reservation is successfully accomplished.
4.5.2.2. Unsuccessful reservation
This section describes the operation where a request for
reservation cannot be satisfied by the RMD QoS signaling model.
4.5.2.3. Severe congestion
This section describes the operation of the RMD QoS signaling
model where a severe congestion occurs within the Diffserv domain.
Severe congestion is an undesirable event, e.g after re-routing,
where the resources are not enough to meet the required QoS for
all the flows along the new path, therefore one or more flows
should be terminated. Interior nodes notify edge nodes by data
marking or marking the refresh messages. In order to eliminate
severe congestion the degree of overload can also be indicated,
e.g. by using proportional marking.
Bader, et al. [Page 9]
INTERNET-DRAFT RMD QoS signaling model
Congestion can also occur in an interior node due to the
underestimation of the data traffic, inappropriate policer
settings, or due to the uncertainty introduced by the measurement
method.
Severe congestion function of RMD can be used for implementiong
a lightweight measurement based admission control within a
Diffserv domain. It is possible that not all the nodes along the
path implement and run admission control, only a few interior
nodes are responsible for admission control. In these nodes there
may be predefined thresholds that can be set for the different
PHBs. If the threshold is exceeded refresh messages or the data
packets can be marked to indicate the high load of different
PHBs.
4.5.3. Basic bidirectional operation
This section describes the basic bidirectional operation and
sequence of events in the RMD QoS signaling model. Combined
sender-receiver initiated reservation cannot be done in the domain
because upstream NTLP states are not stored in interior routers.
Therefore bi-directional operation can be performed by two sender-
initiated reservations. However, if the edge nodes are common for
both upstream and downstream direcrions, RMD offers significant
optimization. More details will be provided in the next version
of this draft.
5. Security Consideration
Future versions of this draft will describe the security
considerations associated with the RMD QoS signaling model.
6. IANA Considerations
If the document creates a new IANA registry, or reserves new
values for an existing IANA registry, an IANA considerations
section should be included, see RFC 2434.
7. Open issues
This section describes the open issues related to the RMD QoS
signaling model. More details on open issues will be provided in a
future version of this draft.
Bader, et al. [Page 10]
INTERNET-DRAFT RMD QoS signaling model
8. Acknowledgments
The authors express their acknowledgement to people worked earlier on
the RMD concept: Z. Turanyi, R. Szabo, A. Csaszar, A. Takacs, G.
Pongracz, O. Pop, V. Rexhepi, D. Partain, M. Jacobsson, S. Oosthoek,
P. Wallentin.
9. Authors' Addresses
Attila Bader
Traffic Lab
Ericsson Research
Ericsson Hungary Ltd.
Laborc u. 1 H-1037
Budapest Hungary
EMail: Attila.Bader@ericsson.com
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@ericsson.com
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Email: cornelia.kappler@siemens.com
Tom Phelan
Sonus Networks
EMail: tphelan@sonusnet.com
Bader, et al. [Page 11]
INTERNET-DRAFT RMD QoS signaling model
10. References
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998
[RFC2638] Nichols K., Jacobson V., Zhang L. "A Two-bit
Differentiated Services Architecture for the Internet", RFC 2638,
July 1999
[RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in
the Internet Architecture: an Overview" RFC 1633
[QoS-NSLP] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 (work
in progress), May 2004.
[QSM-T] Ash, J., Bader, A., Kappler C., "QoS-NSLP QSpec Template"
draft-ash-nsis-nslp-QSpec-00 (work in progress), February 2004.
[RMD] Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP
model", draft-bader-rmd-qos-model-00 (work in progress),
February 2004.
[QSM-CL] Kappler, C. "A QoS Model for signaling IntServ Controlled-
Load Service with NSIS", draft-kappler-nsis-qosmodel-
controlledload-00 (work in progress), February 2004.
11. Appendix: QoS models, QoS Signaling Models and QSpecs
This section gives a description of QoS models, QSMs and QSpecs
and explains what is the relation between them. Once these
descriptions are contained in a stable form in the appropriate IDs
(mainly QoS NSLP [2] and QSpec Template[3]) this Appendix will be
removed.
QoS NSLP is a generic QoS Signaling Protocol that can signal for
many QoS Models. A QoS Model is a particular QoS provisioning
method or QoS architecture such a IntServ Controlled Load,
Guaranteed Service, DiffServ or RMD.
The definition of the QoS Model is independent from the definition
of QoS-NSLP. Existing QoS Models do not specify how to use QoS
NSLP to signal for them. Therefore, we need to define the QoS
Signaling Models (QSMs), specific to each QoS Model, which
describes the QoS Model specific signaling functions. In this
draft we defined the RMD QoS Signaling Model to signal for RMD.
Another QoS Signaling Model was defined for IntServ Controlled
Load in [7].
Bader, et al. [Page 12]
INTERNET-DRAFT RMD QoS signaling model
A QSM should include the following information (for an
illustration see this draft):
- Role of QNEs in the QoS Model:
E.g. location, frequency, statefulness...
- QSpec Definition:
QoS NSLP carries QSM-specific information in the QSpec object. The
QSpec is opaque to QoS NSLP. It contains the QoS Signaling Model
specific control information and QoS description parameters. QoS
description parameters can have sub-objects e.g. corresponding to
the TSpec, RSpec and AdSpec objects specified in RSVP. QSM should
specify QSpec.
- Message Format
Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY
messgages
- State Management
It describes how QSpec info is treated and interpreted in the
Resource Management Function and QSM specific processing, e.g.
admission control, scheduling, policy control, QoS parameter
accumulation (e.g. delay)à
- Operation and Sequence of Events
Usage of QoS-NSLP messages to signal the QoS model.
Intellectual Property Statement
Ericsson will issue an IPR statement about RMD.
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 IETF's procedures with respect to
rights in IETF Documents can be found in RFC 3667 (BCP 78) and RFC
3668 (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.
Bader, et al. [Page 13]
INTERNET-DRAFT RMD QoS signaling model
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
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.
Bader, et al. [Page 14] | PAFTECH AB 2003-2026 | 2026-04-22 17:05:23 |