As per Relevance of the word upstream, we have this rfc below:
Network Working Group Y.
Request for Comments: 2996
Category: Standards Track November 2000
Format of the RSVP DCLASS
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
Resource Reservation Protocol (RSVP) signaling may be used to
Quality of Service (QoS) services and enhance the manageability
application traffic's QoS in a differentiated service (diff-serv
DS) network. When using RSVP with DS networks it is useful to
able to carry carry Differentiated Services Code Points (DSCPs)
RSVP message objects. One example of this is the use of RSVP
arrange for the marking of packets with a particular DSCP
from the DS network's ingress point, at the sender or at a
network's egress router
The DCLASS object is used to represent and carry DSCPs within
messages. This document specifies the format of the DCLASS
and briefly discusses its use
1.
This section describes the mechanics of using RSVP [RSVP]
and the DCLASS object for effecting admission control and
QoS policy within a Differentiated Service network [DS]. It
standard RSVP senders and receivers, and a diff-serv
somewhere in the path between sender and receiver. At least one
aware network element resides in the diff-serv network. This
element may be a policy enforcement point (PEP) [RAP] or may
act as an admission control agent for the network, admitting
denying resource requests based on the availability of resources.
either case, this network element interacts with RSVP
arriving from outside the DS network, accepting resource
Bernet Standards Track [Page 1]
RFC 2996 Format of the RSVP DCLASS Object November 2000
from RSVP-aware senders and receivers, and conveying the DS network'
admission control and resource allocation decisions to the higher
level RSVP. The network element is typically a router and will
considered to be so for the purpose of this document. This model
described fully in [INTDIFF].
1.1 Use of the DCLASS Object to Carry Upstream Packet
A principal usage of the DCLASS object is to carry DSCP
between a DS network and upstream nodes that may wish to mark
with DSCP values. Briefly, the sender composes a standard RSVP
message and sends it towards the receiver. At some point the
message reaches the DS network. The PATH message traverses one
more network elements that are PEPs and/or admission control
for the diff-serv network. These elements install appropriate
and forward the PATH message towards the receiver. If
control is successful downstream of the diff-serv network, then
RESV message will arrive from the direction of the receiver. As
message arrives at the PEPs and/or admission control agents that
RSVP enabled, each of these network elements must make a
regarding the admissibility of the signaled flow to the diff-
network
If the network element determines that the request represented by
PATH and RESV messages is admissible to the diff-serv network,
appropriate diff-serv service level (or behavior aggregate) for
traffic represented in the RSVP request is determined. Next,
decision is made to mark arriving data packets for this
locally using MF classification, or to request upstream marking
the packets with the appropriate DSCP(s). This upstream
could occur anywhere before the DS network's ingress point.
likely candidates are the originating sender and the egress
router of some upstream (DS or non-DS) network. The decision
where the RSVP request's packets should be marked can be made
agreement or through a negotiation protocol; the details are
the scope of this document
If the packets for this RSVP request are to be marked upstream
information about the DSCP(s) to use must be conveyed from the RSVP
aware network element to the upstream marking point.
information is conveyed with the DCLASS object. To do this,
network element adds a DCLASS object containing one or more
corresponding to the behavior aggregate, to the RESV message.
RESV message is then sent upstream towards the RSVP sender
If the network element determines that the RSVP request is
admissible to the diff-serv network, it sends a RESV error
Bernet Standards Track [Page 2]
RFC 2996 Format of the RSVP DCLASS Object November 2000
towards the receiver. No DCLASS is required
1.1 Additional Uses of the DCLASS
The DCLASS object is intended to be a general tool for conveying
information in RSVP messages. This may be useful in a number
situations. We give one further example here as motivation
In this example, we assume that the decision about the
behavior aggregate for a RSVP-mediated traffic flow is made at the
network egress router (or a related Policy Decision Point)
observing RSVP PATH and RESV messages and other
information. However, the actual packet marking must be done at
ingress of the network. The DCLASS object can be used to carry
needed marking information between egress and ingress routers
2. Format of the DCLASS
The DCLASS object has the following format
0 | 1 | 2 | 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (>= 8) | C-Num (225) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 1st DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 2nd DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | . . . . | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first word contains the standard RSVP object header (the
Num for the DCLASS object is 225). The length field indicates
total object length in bytes. The object header is followed by
or more 32-bit words, each containing a DSCP in the six high-
bits of the least significant byte. The length field in the
header indicates the number of DSCPs included in the object
Specifically, the number of DCLASS objects present is equal
(Length - 4) / 4.
The network may return multiple DSCPs in the DCLASS object in
to enable the host to discriminate sub-flows within a
aggregate. For example, in the case of the AF PHB group [AF],
network may return the DSCPs 001010, 001100, and 001110
to increasing levels of drop precedence within Class 1 of the AF
group. Note that this document makes no statements regarding
significance of the order of the returned DSCPs.
interpretation of DSCP sets is dependent on the specific
Bernet Standards Track [Page 3]
RFC 2996 Format of the RSVP DCLASS Object November 2000
requested by the host and is beyond the scope of this document
Note that the Class-Num for the DCLASS object is chosen from
space of unknown class objects that should be ignored and
by nodes that do not recognize it. This is to assure
backward compatibility
3. Admission Control
From a black-box perspective, admission control and
functionality amounts to the decision whether to accept or reject
request and the determination of the DSCPs that should be used
the corresponding traffic. The specific details of admission
are beyond the scope of this document. In general the
control decision is based both on resource availability and
policies regarding the use of resources in the diff-serv network
The admission control decision made by RSVP aware network
represents both considerations
In order to decide whether the RSVP request is admissible in terms
resource availability, one or more network elements within or at
boundary of the diff-serv network must understand the impact
admission would have on specific diff-serv resources, as well as
availability of these resources along the relevant data path in
diff-serv network
In order to decide whether the RSVP request is admissible in terms
policy, the network element may use identity objects describing
and/or applications that may be included in the request. The
may act as a PEP/PDP and use data from a policy database or
to aid in this decision
See Appendix A for a simple mechanism for configurable resource
admission control
4. Security
The DCLASS object conveys information that can be used to
enhanced QoS from a DS network, so inappropriate modification of
object could allow traffic flows to obtain a higher or lower level
QoS than appropriate. Particularly, modification of a DCLASS
by a third party inserted between the DS network ingress node and
upstream marker constitutes a possible denial of service attack
This attack is subtle because it is possible to reduce the
QoS to an unacceptably low level without completely cutting off
flow, making the attack harder to detect
The possibility of raising the received level of QoS by
Bernet Standards Track [Page 4]
RFC 2996 Format of the RSVP DCLASS Object November 2000
modification of the DCLASS object is less significant because it
subclass of a larger class of attacks that must already be
by the system. Protection must already be in place to prevent a
raising its received level of QoS by simply guessing "good" DSCP'
and marking packets accordingly. If this protection is at
boundary of the DS network, it will detect inappropriate marking
arriving packets caused by modified DCLASS objects as well. If
however, the protection function as well as the marking function
been pushed upstream (perhaps to a trusted third party
intermediate node), correct transmission of the DCLASS object must
ensured to prevent a possible theft of service attack
Simple observation of the DCLASS object in a RSVP message
several issues which may be seen as security concerns.
of observed DCLASS object values with RSVP requests or
classification parameters allows the observer to determine
different flows are receiving different levels of QoS, which may
knowledge that should be protected in some environments. Similarly
observation of the DCLASS object can allow the observer to
that a single flow's QoS has been promoted or demoted, which
signal significant events in the life of that flow's application
user. Finally, observation of the DCLASS object may
information about the internal operations of a DS network that
be useful to observers interested in theft-of-services attacks
5.
[INTDIFF] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B. and J. Wroclawski, "
Framework for Integrated Services Operation over
Networks", RFC 2998, November 2000.
[DS] Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss
"An Architecture for Differentiated Services", RFC 2475,
December 1998.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
for Policy Based Admission Control", RFC 2753,
2000.
[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski
"Assured Forwarding PHB Group", RFC 2597, June 1999.
Bernet Standards Track [Page 5]
RFC 2996 Format of the RSVP DCLASS Object November 2000
6.
Thanks to Fred Baker and Carol Iturralde for reviewing this document
Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee
input
7. Author's
Yoram
One Microsoft Way
Redmond, WA 98052
Phone: (425) 936-9568
EMail: yoramb@microsoft.
Bernet Standards Track [Page 6]
RFC 2996 Format of the RSVP DCLASS Object November 2000
Appendix A - Simple Configurable Resource Based Admission
Routers may use quite sophisticated mechanisms in making
admission control decision, including policy considerations,
intra-domain signaling protocols, results of traffic monitoring
so on. It is recommended that the following basic functionality
provided to enable simple resource based admission control in
absence of more sophisticated mechanisms. This functionality can
used with configurable, standalone routers. It applies to
RSVP/Intserv requests. This minimal functionality assumes only
single DSCP is included in the DCLASS object, but may readily
extended to support multiple DSCPs
It must be possible to configure two tables in the router. These
described below
A.1 Service Type to DSCP
One table provides a mapping from the intserv service-type
in the RSVP request to a DSCP that can be used to obtain
corresponding service in the diff-serv network. This table
a row for each intserv service type for which a mapping is available
Each row has the following format
Intserv service type :
The table would typically contain at least three rows; one
Guaranteed service, one for Controlled Load service and one for Best
Effort service. (The best-effort service will typically map to
000000, but may be overridden). It should be possible to add
for as-yet-undefined service types
This table allows the network administrator to statically configure
DSCP that the router will return in the DCLASS object for an
RSVP request. In general, more sophisticated and likely more
mechanisms may be used to determine the DSCP to be returned in
DCLASS object. Also, it is likely that a real mapping for
services would use more than one DSCP, with the DSCP depending on
invocation parameters of a specific service request. In this case
these mechanisms may override or replace the static table
mapping described here
A.2 Quantitative Resource
Standard intserv requests are quantitative in nature. They
token bucket parameters describing the resources required by
traffic for which admission is requested. The second table
the network administrator to statically configure
Bernet Standards Track [Page 7]
RFC 2996 Format of the RSVP DCLASS Object November 2000
parameters to be used by the router when making an admission
decision for quantitative service requests. Each row in this
has the following form
DSCP : Token bucket
The first column specifies those DSCPs for which
admission control is applied. The second column specifies the
bucket parameters which represent the total resources available
the diff-serv network to accommodate traffic in the service
specified by the DSCP
Bernet Standards Track [Page 8]
RFC 2996 Format of the RSVP DCLASS Object November 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Bernet Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
