Internet DRAFT - draft-bergkvist-boomerang-spec
draft-bergkvist-boomerang-spec
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:48:40 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 30 Jun 1999 16:47:21 GMT
ETag: "2e6b6f-70eb-377a4a19"
Accept-Ranges: bytes
Content-Length: 28907
Connection: close
Content-Type: text/plain
J. Bergkvist
I. Cselenyi
Telia Research AB
June, 1999
Boomerang Protocol Specification
<draft-bergkvist-boomerang-spec-00.txt>
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 :== <ICMP Header> <CONTAINER_HEADER>
<RESERVATION_MESSAGE> [<OPTIONAL_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.
<format> :== <general format> OR <type specific format>
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.
<Res_MSG> ::= <Res_Header> <Flow_Spec> <QoS_Spec>
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:
<Flow_Spec> ::= <Classifier> <Mask>
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.
<Optional_Message> ::= <Option_Header> <Option_Body>
[<Option_Header> <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
<draft-ahlard-boomerang-framework-00.txt>
[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
<draft-ietf-diffserv-phb-ef-02.txt>
[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]
