J. Bergkvist I. Cselenyi Telia Research AB June, 1999 Boomerang Protocol Specification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. To learn the current status of any Internet-Draft, please check the "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This draft specifies the Boomerang resource reservation protocol which provides Diff-Serv compliant quantitative IP QoS service at application time-scale [BOOMER]. Boomerang can be used for specifying and reserving network resources for a bi-directional traffic stream between two Internet nodes, independently from the path. Traffic stream can be specified as a single microflow or flow aggregate (e.g. DS behavior aggregate or flows between subnets). Moreover, Boomerang nodes can merge the resource demand of several traffic streams enabling subsequent Boomerang nodes to reserve only for the aggregate. Reservation setup is made by a single message loop (PING) and established soft reservation- states are refreshed by periodically repeated Boomerangs. Data packets of the specified traffic stream shall be conditioned in Boomerang nodes according to the QoS Specification of the reservation message. Table of Contents 1. Motivation ................................................ 2 2. Required Node Behavior .................................... 2 3. Message Structure ......................................... 3 4. Appendix - Example of Boomerang Reservation Messages ...... 12 5. References ................................................ 12 6. Author Information ........................................ 13 Bergkvist, et.al. Expires: December 1999 [Page 1] INTERNET-DRAFT Boomerang Protocol Specification June 1999 1 Motivation This draft specifies the Boomerang Resource Reservation Protocol referenced in [BOOMER] using the terminology defined in [BOOMER], [DSARCH] and [DSFIELD]. In Diff-Serv networks, the DS field signals the resource and forwarding demands of DS Behavior Aggregates. Traffic Conditioner nodes - placed on the edge or inside of the DS region - are responsible for enforcing the TCA referred by the particular DSCP. Signaling protocol based interaction between traffic conditioners and traffic sources and per microflow QoS control are currently discouraged, although these could be essential components of new, dynamic quantitative QoS services. The Boomeanrg resource reservation protocol enables traffic sources to quantify their resource demand and get a feed-back from Boomerang nodes (i.e. traffic conditioners) if there are available resources in the network. Traffic streams can be specified in a flexible way allowing QoS control per microflow or per group of microflows. Boomerang can be considered as an operational control protocol among traffic conditioners and traffic sources related to the same traffic stream. The main concern against signaling based resource reservation is scalability, therefore reservation-states can be aggregated and any Boomerang node can insert an aggregation option at the end of the Boomerang reservation message. Using this optional message, subsequent nodes can reserve resources for the traffic aggregate. Typical example of such an aggregation is if we consider reservations over a DS region where DS Ingress routers aggregate the resource demand of microflows per behavior aggregate and output interface. Thus Interior DS nodes may perform reservation and traffic conditioning of data packets for the aggregate. This results in faster classification and forwarding on the expence of giving up individual QoS control of a subset of flows in the aggregate. Simulation based performance evaluation of the Boomerang reservation protocol can be found in [QOSWS]. 2 Required Node Behavior Based on the functions which are required in different nodes for processing the Boomerang signaling messages, three types of nodes can be differentiated: Bergkvist, et.al. Expires: December 1999 [Page 2] INTERNET-DRAFT Boomerang Protocol Specification June 1999 2.1 Initiating Node * repeatedly sends Boomerang reservation messages with a chosen refresh interval * handles the state of reservation setup session * recognizes loss of Boomerang message and revokes reservation * interprets the Boomerang message * pre-marks data packets with the DSCP matching the QoS Specification format of the Boomerang reservation message (optional) 2.2 Far-End Node * echoes back the Boomerang message to the Initiating Node * interprets the Boomerang message (optional) * pre-marks data packets (optional) 2.3 Boomerang Node * interprets the Boomerang message * performs admission control and creates reservation-state for the traffic stream specified in the reservation message * if a Resource Aggregate Option is also available in the Boomerang message it may perform admission control and reservation only for that aggregate * initiates its DS marker (optional) * indicates the progress of the request by setting interactive fields in the Boomerang message (e.g. flags) * inserts an Resource Aggregate Option in the body of the Boomerang container (optional) * forwards the Boomerang message to next hop 3 Message Structure The Boomerang Container is a versatile, simple and modular format, which is suitable for lightweight signaling between two IP nodes. Each component of a Boomerang message is 32-bit aligned and small. This picture describes the bit and byte numbering: |01234567|01234567|01234567|01234567| <-- Bit numbering +-----------------------------------+ | one | two | three | four | <-- 32 bits, 4 bytes +-----------------------------------+ | five | six | seven | eight | <-- 32 bits, 4 bytes +-----------------------------------+ The Boomerang Reservation message is carried in a Boomerang Container which is encapsulated in an ICMP packet: Boomerang_Message :== [] 3.1 Container Header The Container Header contains information about the content and structure of the signaling message, as well as a place for signaling Bergkvist, et.al. Expires: December 1999 [Page 3] INTERNET-DRAFT Boomerang Protocol Specification June 1999 information and flags to be computed without the need for going into the message body. Container Header |01234567|01234567|01234567|01234567| +-----------------------------------+ | MAGIC = 0x47114711 | +-----------------------------------+ | transaction_id | +-----------------------------------+ | type | format | flags | +-----------------------------------+ MAGIC [32 bit] The magic number is 0x47114711. It is used for differentiating the Boomerang message from other ICMP messages. transaction_id [32 bit] used by the initiator of signaling to identify to which transaction a reply belongs, if using multiple simultaneous transactions. type [8 bit] contains the type of message. Currently two message types are defined. BOOMERANG_RESERVATION is used for resource reservation. Message types +==============================+ | BOOMERANG_RESERVATION | 0x10 | +==============================+ | DS MARKER_SETUP | 0x20 | +------------------------------+ format [8 bit] specifies the parameter format or version of the enbedded message and could be seen as the LSB of the type field. The interpretation of the "format" and "flags" fields are specific to each "type". Currently two general formats are defined. These codes are supposed to be ORÆed with the type-specific formats. :== OR The format of internet protocol is a general format: INTERNET_PROTOCOL formats +===========================+ | FORMAT | CODE | +===========================+ | PF_IPv4 | 0x02 | +---------------------------+ | PF_IPv6 | 0x0A | +---------------------------+ In case of BOOMERANG_RESERVATION message type the following type specific format is defined: Bergkvist, et.al. Expires: December 1999 [Page 4] INTERNET-DRAFT Boomerang Protocol Specification June 1999 QOS_SPECIFICATION formats +===========================+ | FORMAT | CODE | +===========================+ | QOSFMT_BITRATE | 0x10 | +---------------------------+ | QOSFMT_INTSERV | 0x20 | +---------------------------+ | QOSFMT_DOWNGRADE| 0x30 | +---------------------------+ For example, if the format is QOSFMT_BITRATE & PF_IPV4, the Reservation Message consists of an IPv4 Flow Specification and a Bitrate QoS specification. flags [16 bit] Signaling flags such as the NACK flag, which is the least significnt bit of this field and signals the success (0) or failure (1) of the reservation request if the message type is BOOMERANG_RESERVATION. 3.2 Reservation Message The Reservation Message consists of three parts. ::= The first part is the Reservation Header, which contains general information about the reservation. The second part is the Flow Specification, which describes which flow or group of flows this particular reservation is valid for. The Flow Specification also contains a bit mask, where valid parts of the flow spec are masked out. The third part is the QoS Specification, which describes the resources that are to be bound for the specified flow(s). All parts are 32-bit aligned, and there may only exist one instance of each part in a Boomerang message. 3.2.1 Reservation Header Reservation Header |01234567|01234567|01234567|01234567| +-----------------------------------+ |refresh | version| PADDING | +-----------------------------------+ | KEY | | | +-----------------------------------+ refresh_int [8 bits] The refresh interval for the particular reservation session, in seconds. To be certain that the session is not torn down anywhere along the Bergkvist, et.al. Expires: December 1999 [Page 5] INTERNET-DRAFT Boomerang Protocol Specification June 1999 route, refresh messages have to be sent with at least this interval. The initating node suggests a refresh interval, which might be shortened by any Boomerang node en route. version [8 bits] Field for indicating the version of the Reservation message. Currently value is 0x01. padding [16 bits] Reserved for future use. key [64 bits] Boomerang nodes do not see if a reservation fails in a subsequent node, since they do not correlate Boomerangs flying in the forward and reverse directions (and nothing ensures that the two pathes are the same). Therefore a confirmation mechanism is required which is based on the KEY field. At the beginning of a reservation session, the KEY field is initiated to 1 by the initiating terminal. Any suspicious node (such as an access node in a public network) on the way of the reservation may generate a key and lock the reservation context. The key is a 64 bit prime number, which is multiplied to the KEY field of the message. If a Boomerang Node can not reserve the specified resources, it shall set the key field to zero. If the request is returned to the initiating terminal with a value greater than 1 it means that resources are reserved but one or more nodes are locked. In this case the terminal must repeat the request with the obtained KEY value. Each node with locked reservation contexts can now check, whether their key is a factor of the reservation key value and activate the context if it is. 3.2.2 Flow Specification Two Flow Specifications are currently defined, one for Ipv4 and one for Ipv6. Both consist of two parts: ::= The Classifier field contains the actual specification of the flow and the Mask shall contain the mask for the classifier. Both Classifier and Mask fields have the same format. In this way, it is possible to mask out parts of the Classifier Field and request resources for a group of microflows. One good example is that the mask makes it possible to specify microflows between two hosts, where the port numbers, protocol and tos fields are not important. Bergkvist, et.al. Expires: December 1999 [Page 6] INTERNET-DRAFT Boomerang Protocol Specification June 1999 IPv4 classifier |01234567|01234567|01234567|01234567| +-----------------------------------+ | src Ipv4 address | +-----------------------------------+ | dst Ipv4 address | +-----------------------------------+ | sport | dport | +-----------------------------------+ | tproto | tos | flags | +-----------------------------------+ IPv6 classifier |01234567|01234567|01234567|01234567| +-----------------------------------+ | src Ipv6 address | +- -+ | | +- -+ | | +- -+ | | +-----------------------------------+ | dst Ipv6 address | +- -+ | | +- -+ | | +- -+ | | +-----------------------------------+ | sport | dport | +-----------------------------------+ | tproto | tos | flags | +-----------------------------------+ src [32(IPv4) or 128(IPv6) bits] This is the source address of the flow(s). dst [32(IPv4) or 128(IPv6) bits] This is the destination address of the flow(s). sport [16 bits] This is the source address port of the flow(s). dport [16 bits] This is the destination address port of the flow(s). tproto [8 bits] This is the protocol of the flow(s). Bergkvist, et.al. Expires: December 1999 [Page 7] INTERNET-DRAFT Boomerang Protocol Specification June 1999 tos [8 bits] This field specifies the PHB (or precedence forwarding behavior) for the flow(s). The initiating node may pre-mark data packets itself. In case of Bitrate QoS Specification format, the following DSCPs shall be used depending on the capability of Boomerang nodes: Targeted DSCP +===================================+ | Node capability | DSCP | +===================================+ | DS compliant | EF = 101110xx | +-----------------------------------+ | Legacy node | CS5 = 101000xx | +-----------------------------------+ | non-DS-compliant | CS0 = 000000xx | +-----------------------------------+ In DS-compliant networks, other PHB group relying on at least one prioritized queue with assured departure rate may also be used. 3.2.3 QOS Specification The format of this field is determined by the QoS Specification Format stored in the Container Header. Bitrate QoS Format The QOSFMT_BITRATE format is for quantitative QoS, and consists of two 32-bit numbers, specifying the bitrate that shall be reserved for a particular flow. This is an interactive field, where Boomerang nodes can write the maximum bitrate they can provide for the specified flow(s), if the requested bitrate is too much (i.e. the reservation failed). Bitrate Specification |01234567|01234567|01234567|01234567| +-----------------------------------+ | forward bit-rate [bps] | +-----------------------------------+ | reverse bit-rate [bps] | +-----------------------------------+ forward bit-rate [32 bits] The forward bitrate that should be reserved for the specified flow. The amount will be reserved in the upstream direction (from the Initiating nodeÆs point of view). If the rate is set to zero, no resources are reserved in this direction. reverse bit-rate [32 bits] The reverse bitrate that should be reserved for the specified flow. The amount will be reserved in the downstream direction (from the Initiating nodeÆs point of view). Bergkvist, et.al. Expires: December 1999 [Page 8] INTERNET-DRAFT Boomerang Protocol Specification June 1999 Downgrade-able Bitrate QoS Format The QOSFMT_DOWNGRADE format is an extended version of the previous, where a list of decreasing bitrate values are specified in order to avoid multiple reservation trials, if the specified flow(s) can not get the largest bitrate [DGVECTOR]. Downgrade-able Bitrate QoS Specification |01234567|01234567|01234567|01234567| +-----------------------------------+ |vec_size| policy |padding | +-----------------------------------+ | | + bitrate specifications + | | +-----------------------------------+ | | vector_size [8 bits] gives the number of elements in the downgrade list policy [16 bits] downgrade policy padding [8 bits] reserved for future usage bitrate specifications [vector_size * 64 bits] List of forward and reverse bitrates in a decreasing order. 3.3 Options Each Boomerang Container may carry one or more optional messages, which are appended to the main message and contain supplementary information. Each optional message consists of an option header and an option body. ::= [ ]... Several options can be inserted into the same container. It is not defined what should happen if two conflicting options are present. No assumptions should be made about the order in which options are parsed, nor that any conflicting options should cancel each other. The result of a duplicated option is not specified. Option header |01234567|01234567|01234567|01234567| +-----------------------------------+ | type | flags | +-----------------------------------+ Bergkvist, et.al. Expires: December 1999 [Page 9] INTERNET-DRAFT Boomerang Protocol Specification June 1999 Option Types +=====================================+ | Option type | Value | +=====================================+ | Boomerang_UID | 0x01 | +-------------------------------------+ | RESV_AGGREGATION | 0x02 | +-------------------------------------+ 3.3.1 Boomerang User ID option |01234567|01234567|01234567|01234567| +-----------------------------------+ | User ID | | | +-----------------------------------+ | Credential | | | +-----------------------------------+ User ID [64 bit] A 64-bit (8 char) identifier of the user associated with the signaling message carried in the container. Credential [64 bit] User credential may be based upon a shared secret or a public/private key pair. 3.3.2 Resource Aggregation Option An aggregate option has been specified, to enable nodes to aggregate resource demand of flows or flow groups that have some common denominators, e.g. belong to the same DS behavior aggregate or travel between the same subnets. Bergkvist, et.al. Expires: December 1999 [Page 10] INTERNET-DRAFT Boomerang Protocol Specification June 1999 IPV4 BITRATE AGGREGATE OPTION |01234567|01234567|01234567|01234567| +-----------------------------------+ | Address | +-----------------------------------+ | Transaction Id | +-----------------------------------+ | src Ipv4 address |<-IPv4 Classifier +- - - - - - - - - - - - - - - - - -+ | | dst Ipv4 address | | +- - - - - - - - - - - - - - - - - -+ | | sport | dport | | +- - - - - - - - - - - - - - - - - -+ | | tproto | tos | flags |<-| +-----------------------------------+ | src Ipv4 address |<-IPv4 Mask +- - - - - - - - - - - - - - - - - -+ | | dst Ipv4 address | | +- - - - - - - - - - - - - - - - - -+ | | sport | dport | | +- - - - - - - - - - - - - - - - - -+ | | tproto | tos | flags |<-| +-----------------------------------+ | Rate [bps] | +-----------------------------------+ address [32 bit] The node that proposes aggregation must insert itÆs own IP number in this field. id [32 bit] This is used by the aggregating node to keep track of which Boomerang is which. IPv4 Classifier [128 bit] For aggregate flows, the only parts of this FlowSpec that need to be filled in are the parts that are common. All other parts will be masked out using the FlowSpec Mask. IPv4 Mask [128 bit] Mask is used to describe which parts of the Classifier field is used as a basis of aggregation. Example: If aggregation is based upon class C subnet information and tos, all bits except the 24 first and those corresponding to the tos parts should be set. Rate [32] An aggregate rate, the sum of demanded bitrates for the aggregated flow. Bergkvist, et.al. Expires: December 1999 [Page 11] INTERNET-DRAFT Boomerang Protocol Specification June 1999 4 Appendix û Example of Boomerang Reservation Messages Example of a Boomerang Reservation Message which has IPv4 Bitrate QoS Specifier format and which is tagged with an User ID option. |0 |8 |16 |24 |32 +--------------------------------+ | ICMP HEADER | +--------------------------------+ | MAGIC = 0x47114711 | +--------------------------------+ | transaction id | +--------------------------------+ | type | format| flags | +--------------------------------+ |refresh |version| PADDING | +--------------------------------+ | KEY | | | +--------------------------------+ | src Ipv4 address | +--------------------------------+ | dst Ipv4 address | +--------------------------------+ | sport | dport | +--------------------------------+ |tproto | tos | flags | +--------------------------------+ | forward bit-rate [bps] | +--------------------------------+ | reverse bit-rate [bps] | +--------------------------------+ | type | flags | +--------------------------------+ | User ID | | | +--------------------------------+ | Credential | | | +--------------------------------+ 5 References [BOOMER] Ahlard, D., Bergkvist, J., Cselenyi, I., Engborg, T., "Boomerang - A Simple Resource Reservation Framework for IP", Internet Draft, February 1999 [DSARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Bergkvist, et.al. Expires: December 1999 [Page 12] INTERNET-DRAFT Boomerang Protocol Specification June 1999 [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [EF] V. Jacobson, Kathleen Nichols, Kedernath Poduri, "An Expedited Forwarding PHB", Internet Draft, February 1999 [QOSWS] Feher, G., Nemeth, K., Maliosz, M., Ahlard, D., Bergkvist, J., Cselenyi, I., Engborg, T., "Boomerang - A Simple Protocol for Resource Reservation in IP Networks", IEEE Workshop on QoS Support for Real-Time Internet Applications, Vancouver, Canada, June 1-4, 1999 [DGVECTOR]Cselenyi, I., Szabo, R., Szabo, I., Bjorkman, N., Latour- Henner, A., "Experimental Platform for Telecommunication Resource Management" Computer Communications (21)17 (1998) pp.1624-1640 6 Author Information Ahlard, David Telia Research Vitsandsgatan 9B S-123 86 Farsta, Sweden Phone: +46 8 713 81 90 Email: davahl@trab.se Bergkvist, Joakim Telia Research Vitsandsgatan 9B S-123 86 Farsta, Sweden Phone: +46 8 713 81 71 Email: jobe@trab.se Cselenyi, Istvan Telia Research Vitsandsgatan 9B S-123 86 Farsta, Sweden Phone: +46 8 713 81 73 Email: cse@trab.se Bergkvist, et.al. Expires: December 1999 [Page 13]