INTERNET-DRAFT Werner Almesberger
Jean-Yves Le Boudec
EPFL ICA, Switzerland
Tiziana Ferrari
DEIS, Uni Bologna, INFN/CNAF, Italy
March 1998
Encoding of SRP packet types in the DS byte
<draft-watfjyl-srp-ds-00.txt>
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
We propose an encoding of the packet types used by SRP (Scalable
Reservation Protocol) in the DS byte under study by the
Differentiated Services working group.
1. Introduction
SRP [1] is a light-weight reservation protocol designed to provide
dependable reservations for the Internet. SRP aggregates flows in
routers to achieve good scalability to very large numbers of
individual flows.
The semantics of the actual reservation protocol can be expressed on
a per-packet and per-hop basis. We describe the desired behaviour of
routers and define a possible encoding of the SRP packet types in the
"TOS octet" or "DS byte" as defined in the context of the IETF
Differentiated Services (diffserv) working group [2].
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 1]
INTERNET-DRAFT draft-watfjyl-srp-ds-00.txt March 1998
Although diffserv targets slightly different semantics when using the
TOS octet, we believe this octet to be a highly appropriate location
for indicating the use of other, packet-based mechanisms to control
QoS. With this draft, we intend to advocate that the specification
produced by the diffserv working group should allow for such uses,
and that it should provide room for the corresponding code points.
We base our description on the initial draft proposal for using the
TOS octet [3] and we acknowledge that the exact layout of the TOS
octet is still subject to ongoing discussion and may change in the
future. We plan to update this document accordingly.
Note that our description of possible uses of the DS byte only
reflects our own design ideas and shall not be interpreted as
implying any endorsement by the diffserv working group or by related
groups.
2. Reservations
SRP sets up reservations for aggregated flows. The exact definition
of what constitutes an aggregated flow is a local issue of each
router. Simple definitions may be obtained by considering all flows
as aggregates, which:
- leave the router at the same port, or
- traverse the router through the same pair of ports.
A reservation means that a router has set aside sufficient resources
to process and forward conforming packets using the reservation, and
to do so in timely way. A packet conforms to a reservation if
- it traverses the router through the same pair of ports as the
packet(s) that have set up the reservation,
- the source has shaped it according to the shaping requirements
for sources (TBD) and all routers have forwarded it according to
rules specified in this document, and
- it does not request any other service(s) from the router (by
whatever means the router supports) than the one(s) used for the
packet(s) that have set up the reservation.
3. Packet types
We distinguish three types of packets:
- RESERVED packets use a previously agreed-upon reservation.
Sources may emit RESERVED packets only if a reservation was
granted and only according to the shaping requirements. After
optionally performing policing, routers must include such packets
in their estimate of current resource use, and forward them with
priority over best-effort.
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 2]
INTERNET-DRAFT draft-watfjyl-srp-ds-00.txt March 1998
- flows of REQUEST packets have the effect of setting up a new
reservation or increasing an existing one. This specification
does not impose any restrictions on when or how often a source
may send REQUEST packets. When receiving a REQUEST packet, a
router must decide if it has sufficient resources to increase the
present reservation. If yes, it updates its estimate accordingly
and forwards REQUEST the packet like it forwards RESERVED
packets. Otherwise, it degrades the packet to DENIED and
processes it accordingly.
- DENIED packets are treated similar to best-effort, but a router
may discard DENIED packets even with higher probability than
normal best-effort, because DENIED packets will typically not be
congestion-controlled by the source. SRP does not allow a source
to emit packets of type DENIED (but, if the encoding of the
DENIED packet type coincides with a packet type defined
elsewhere, a source may of course emit such packets according to
that other specification)
As a local option, routers may entrust other routers to make
acceptance decisions for them. Doing so does not remove their
obligation to forward RESERVED and REQUEST packets according to this
specification.
Estimator algorithms are not specified in this document. We study
examples for such algorithms in [4].
Destinations identify the types of incoming packets and generate
feedback for the source. Further details of this are TBD.
4. Encoding of packet types
We propose two possible ways for encoding SRP packet types in the DS
byte. Criteria for deciding which of the proposals is appropriate are
discussed below.
4.1 Proposal 1
Assuming a PHB (per-hop behaviour) code point is assigned to SRP,
we define the encoding of SRP packet types in values of the DS
byte as follows:
SRP packet | IN PHB CU
type | (in/out of (per-hop (currently
| profile) behaviour) unused)
---------------------------------------------
RESERVED | in(1) SRP -
REQUEST | out(0) SRP -
DENIED | out(0) DE -
Where DE is the default best-effort forwarding described in [3].
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 3]
INTERNET-DRAFT draft-watfjyl-srp-ds-00.txt March 1998
4.2 Proposal 2
Recent discussion in the diffserv group has indicated that perhaps
only selected routers may be allowed to change the DS byte. Not
allowing every router to change the DS byte would conflict with
SRP's potential need to perform acceptance control at every
router, and consequently to degrade some REQUEST packets to
DENIED. If such restrictions should be put on the use of the DS
byte, we propose using the ECN bit (Explicit Congestion
Notification, [5]), which - much like SRP packet types - may be
set at any router, and which carries similar information. Then,
the encoding would be as follows:
SRP packet | IN PHB ECN ECN
type | Capable
-----------------------------------
RESERVED | in(1) SRP TBD TBD
REQUEST | out(0) SRP TBD 0
DENIED | out(0) SRP TBD 1
Note that the use of the ECN bits as described in this second
proposal does not interfere with employing them for implementing
congestion control on top of reservations (like it is done in
Frame Relay [6]), if a need for this should arise.
Because the exact use of ECN and the relation between DS and ECN
are still the subject of vivid discussion, this latter encoding
proposal should be considered as even more volatile than the
previous one.
5. References
[1] Almesberger, Werner; Ferrari, Tiziana; Le Boudec, Jean-Yves.
SRP essentials (work in progress), Internet Draft
draft-watfjyl-srp-00.txt, March 1998.
[2] IETF, Differentiated Services (diffserv) working group.
http://www.ietf.org/html.charters/diffserv-charter.html
[3] Nichols, Kathleen (Ed.); Blake, Steven (Ed.). Differentiated
Services Operational Model and Definitions (work in progress),
Internet Draft draft-nichols-dsopdef-00.txt, February 1998.
[4] Almesberger, Werner; Ferrari, Tiziana; Le Boudec, Jean-Yves.
SRP: a Scalable Resource Reservation Protocol for the Internet,
ftp://lrcftp.epfl.ch/pub/people/almesber/srp/srpMar98.ps.gz,
Technical Report SSC/1998/009, EPFL, March 1998.
[5] Ramakrishnan, Kadangode K.; Floyd, Sally. A Proposal to add
Explicit Congestion Notification (ECN) to IPv6 and to TCP (work
in progress), Internet Draft draft-kksjf-ecn-00.txt, November
1997.
[6] ITU-T Recommendation X.36. Interface between data terminal
equipment (DTE) and data circuit-terminating equipment (DCE) for
public data networks providing frame relay data transmission
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 4]
INTERNET-DRAFT draft-watfjyl-srp-ds-00.txt March 1998
service by dedicated circuit, ITU, April 1995.
6. Author's address
Werner Almesberger
Jean-Yves Le Boudec
Institute for computer Communications and Applications
Swiss Federal Institute of Technology (EPFL)
CH-1015 Lausanne
Switzerland
email: Werner.Almesberger,Leboudec@epfl.ch
Tiziana Ferrari
DEIS, University of Bologna
viale Risorgimento, 2
I-40136 Bologna
Italy
and
Italian National Inst. for Nuclear Physics/CNAF
viale Berti Pichat, 6/2
I-40127 Bologna
Italy
email: Tiziana.Ferrari@cnaf.infn.it
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 5]