Format of the RSVP DCLASS Object
RFC 2996
|
Document |
Type |
|
RFC - Proposed Standard
(November 2000; No errata)
|
|
Author |
|
Yoram Bernet
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Internet Engineering Task Force (IETF)
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2996 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group Y. Bernet
Request for Comments: 2996 Microsoft
Category: Standards Track November 2000
Format of the RSVP DCLASS Object
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Resource Reservation Protocol (RSVP) signaling may be used to request
Quality of Service (QoS) services and enhance the manageability of
application traffic's QoS in a differentiated service (diff-serv or
DS) network. When using RSVP with DS networks it is useful to be
able to carry carry Differentiated Services Code Points (DSCPs) in
RSVP message objects. One example of this is the use of RSVP to
arrange for the marking of packets with a particular DSCP upstream
from the DS network's ingress point, at the sender or at a previous
network's egress router.
The DCLASS object is used to represent and carry DSCPs within RSVP
messages. This document specifies the format of the DCLASS object
and briefly discusses its use.
1. Introduction
This section describes the mechanics of using RSVP [RSVP] signaling
and the DCLASS object for effecting admission control and applying
QoS policy within a Differentiated Service network [DS]. It assumes
standard RSVP senders and receivers, and a diff-serv network
somewhere in the path between sender and receiver. At least one RSVP
aware network element resides in the diff-serv network. This network
element may be a policy enforcement point (PEP) [RAP] or may simply
act as an admission control agent for the network, admitting or
denying resource requests based on the availability of resources. In
either case, this network element interacts with RSVP messages
arriving from outside the DS network, accepting resource requests
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's
admission control and resource allocation decisions to the higher-
level RSVP. The network element is typically a router and will be
considered to be so for the purpose of this document. This model is
described fully in [INTDIFF].
1.1 Use of the DCLASS Object to Carry Upstream Packet Marking
Information
A principal usage of the DCLASS object is to carry DSCP information
between a DS network and upstream nodes that may wish to mark packets
with DSCP values. Briefly, the sender composes a standard RSVP PATH
message and sends it towards the receiver. At some point the PATH
message reaches the DS network. The PATH message traverses one or
more network elements that are PEPs and/or admission control agents
for the diff-serv network. These elements install appropriate state
and forward the PATH message towards the receiver. If admission
control is successful downstream of the diff-serv network, then a
RESV message will arrive from the direction of the receiver. As this
message arrives at the PEPs and/or admission control agents that are
RSVP enabled, each of these network elements must make a decision
regarding the admissibility of the signaled flow to the diff-serv
network.
If the network element determines that the request represented by the
PATH and RESV messages is admissible to the diff-serv network, the
appropriate diff-serv service level (or behavior aggregate) for the
traffic represented in the RSVP request is determined. Next, a
decision is made to mark arriving data packets for this traffic
locally using MF classification, or to request upstream marking of
the packets with the appropriate DSCP(s). This upstream marking
could occur anywhere before the DS network's ingress point. Two
likely candidates are the originating sender and the egress boundary
router of some upstream (DS or non-DS) network. The decision about
where the RSVP request's packets should be marked can be made by
agreement or through a negotiation protocol; the details are outside
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. This
information is conveyed with the DCLASS object. To do this, the
network element adds a DCLASS object containing one or more DSCPs
corresponding to the behavior aggregate, to the RESV message. The
Show full document text