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 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]