[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

    INTERNET-DRAFT                           D. Ahlard, Telia Research
    Expires: August 1999                  J. Bergkvist, Telia Research
                                           I. Cselenyi, Telia Research
                                            T. Engborg, Telia Research

    February, 1999


           Boomerang - A Simple Resource Reservation Framework for IP
                      <draft-ahlard-boomerang-framework-00.txt>

    Status of this Memo

    This document is an Internet-Draft and is NOT offered in
    accordance with Section 10 of RFC2026, and the author does not
    provide the IETF with any rights other than to publish as 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 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 describes a framework for providing quantitative IP
    services with guaranteed QoS. Although the proposed reservation
    approach is based on a new, lightweight signaling protocol, it can
    be used with interoperability with other IP QoS techniques such as
    Diff-Serv, Int-Serv.

        Distinguishing features of the Boomerang protocol are:
           * signaling messages are generated only by the initiating
             node, therefore complexity and intelligence is
             concentrated in one point enabling simple implementation
           * flow state aggregation can be suggested to subsequent
             nodes by appending the Boomerang message, thus good
             scalability can be achieved
           * bi-directional reservation can be made independently of
             the path, which yields a fast and effective reservation
             process
           * the only requirement on the far-end node is that it
             should be able to bounce the Boomerang message back,
             ensuring quick penetration into the current Internet.

Bergkvist, et.al.       Expires: August 1999                  [Page 1]


INTERNET-DRAFT Boomerang framework                       February 1999


        There is a lab prototype in which the Boomerang protocol is
    wrapped in ICMP ECHO / ECHO-REPLY (PING) messages.




            Table of contents

1 Terminology                                                   3
2 Introduction                                                  3
3 Properties                                                    4
 3.1Simple Implementation                                       4
 3.2Good Scalability                                            4
 3.3Simple But Effective Signaling Process                      5
  3.3.1Bi-directional Reservation                               5
  3.3.2Concentrated Intelligence                                5
  3.3.3Low protocol overhead                                    5
  3.3.4Soft-state                                               5
  3.3.5Resource Query                                           5
  3.3.6Fast Reservation Process                                 5
 3.4Penetration                                                 6
  3.4.1Transparency                                             6
  3.4.2QoS Interoperability                                     6
  3.4.3Multiple Scope                                           6
  3.4.4No requirements on the Far-end Node                      6
4 Reservation Concept                                           6
 4.1Boomerang Reservation Message                               6
  4.1.1Signaling Header                                         7
  4.1.2Flow Specification                                       7
  4.1.3QoS Specification                                        7
  4.1.4Transport Mechanism                                      7
 4.2Operation                                                   8
  4.2.1Lost Boomerang                                           9
5 Issues                                                        9
 5.1Flow-state Aggregation                                      9
  5.1.1Aggregation Suggested by Earlier Node                    9
  5.1.2Measurement Based Admission Control                     10
  5.1.3Refresh Message based Admission Control                 10
 5.2Route Changes                                              10
 5.3Multicasting                                               11
 5.4Denial of Service                                          11
 5.5Selective Hunting                                          11
 5.6Security                                                   11
 5.7Decreasing network signaling                               11
  5.7.1Network flooding by refresh messages                    12
  5.7.2Network loading by end to end transmission of NACKED
  connections                                                  12
6 Illustrative scenarios                                       13
 6.1Single-domain with a bottleneck                            13
 6.2End-to-end reservation with aggregation                    14
7 References                                                   15
8 Author Information                                           16


Bergkvist, et.al.       Expires: August 1999                  [Page 2]


INTERNET-DRAFT Boomerang framework                       February 1999


1   Terminology

    The terminology given in [E2E] is used in this document extended
    with the following notions:

    Boomerang Protocol (BOOMP)
    The simple, hop-by-hop resource reservation protocol used in this
    framework.

    Initiating Node (IN)
    This is the node initiating the resource reservation. Can be the
    sender or receiver host or any BOOMP-aware network node.

    Far-End Node (FEN)
    This is the node to which reservations are being made.

    Micro-Flow
    A data flow from one end-point to another, defined uniquely by MF
    classification [MF].

    Boomerang Node (BN)
    A BOOMP-aware node which performs admission control and
    reservation for single or aggregated micro-flows.

    Aggregating Node (AN)
    A Boomerang Node that associates several micro-flows with a
    common, aggregated QoS specification and appends an aggregation
    field to the Boomerang messages of associated micro-flows, in
    order to suggest an aggregated reservation state for subsequent
    BNs.


2   Introduction

    Besides Differentiated Services [DSARCH] network operators may
    also be interested in offering guaranteed services to ambitious
    customers, and quantitative QoS applications [E2E] in an end-to-
    end manner. However, best effort network domains or bottleneck
    segments within a DS domain may compromise the end-to-end QoS
    during peak hours in the network. Therefore a simple signaling
    protocol is needed to signal per micro-flow QoS requirements to
    the network and to reserve resources end-to-end in guaranteed
    manner.

    RSVP is the only accepted signaling protocol for resource
    reservation setup in IP networks [RSVP], although it has several
    limitations:

    1. it relies on per micro-flow state, which results in a
    scalability problem in terms of memory, capacity and processing
    time
    2. it is complex to implement both in nodes and hosts due to
    separation of reservation and path finding messages, receiver

Bergkvist, et.al.       Expires: August 1999                  [Page 3]


INTERNET-DRAFT Boomerang framework                       February 1999

    diversity
    3. it requires modification in the far end host
    4. The intelligence of signaling processing is spread over
    the network. Each node along a reserved path contains a flow state
    and a signaling state. Therefore, each reservation session
    increases the load on network nodes.
    5. it requires multiple interaction between sender and
    receiver for a successful reservation setup

    We propose a new reservation protocol for IP networks, called
    Boomerang, which meets the following challenges:

    1. Simple way for aggregating micro-flow reservation states
    2. Simple processing of signaling messages at network nodes
    resulting in simple implementation
    3. No special requirements on the far end
    4. Concentrating the intelligence in the Initiating Node (IN). The
    IN is responsible for signaling- and handling flow state for the
    setup reservation. Network nodes along reserved path keep only
    flow states, resulting in low load and processing time on network
    nodes.
    5. Quick reservation setup thanks to a single signaling loop

    The Boomerang protocol has been designed to be quick and simple,
    yet powerful. It aims for extending the QoS mechanisms offered by
    DS, RSVP, Int-Serv [IntServ] rather than replacing them.


3   Properties

    The properties of the Boomerang protocol are grouped according to
    the main benefits they yield.


3.1 Simple Implementation

    In BOOMP, signaling states (meaning intelligence) are needed only
    in the initiating node. Other BNs are 'passive' and the only
    requirement is that they are able to interpret the Boomerang
    message. Therefore the most complex BOOMP implementation is made
    locally in IN and it is a reasonable belief that BOOMP can be
    simply implemented in other nodes. Another feature that
    contributes to simplicity is that BOOMP is focused on unicast and
    sender oriented multicast services.


3.2 Good Scalability

    In order to decrease the context made for keeping track of the
    reservation state of micro-flows, ANs can propose an aggregation
    of these flow states. Consistency of micro-flow aggregation is
    maintained by appending an aggregation field in the repeatedly
    circulated BOOMP refresh messages. All control logic related to an
    aggregation is concentrated in one AN, while other nodes can

Bergkvist, et.al.       Expires: August 1999                  [Page 4]


INTERNET-DRAFT Boomerang framework                       February 1999

    simply rely on the information steadily coming in Boomerang
    messages or handle micro-flow states.


3.3 Simple But Effective Signaling Process

3.3.1 Bi-directional Reservation

    This implies that both the sender and the receiver node can send a
    Boomerang, i.e. can act as IN. Many applications can not benefit
    from receiver orientated reservations. Moreover, policy and
    billing may suit better to sender initiated reservation in case of
    certain applications (like broadcast video). For unicast
    applications BOOMP can be used in a receiver oriented manner.

    Different QoS parameters might be set up along the forward and
    reverse path of the traffic flow. The forward and reverse path for
    a bi-directional flow may differ.


3.3.2 Concentrated Intelligence

    The signaling control logic is concentrated in the initiating node
    in BOOMP. Other nodes are not generating signaling messages.


3.3.3 Low protocol overhead

    There is typically one or maximum two signaling loop required per
    reservation session. Only the IN generates signaling messages,
    other BNs do not. A simple calculation is given in Section 6.
    about the amount of signaling overhead for BOOMP.


3.3.4 Soft-state

    BNs maintain reservation states as soft states, i.e. reservations
    time out if they are not refreshed periodically. In this way
    orphan reservations disappear automatically and routing changes
    have just a temporary effect.


3.3.5 Resource Query

    When the Boomerang flies through the network, each BN decreases
    the resource request field if it has less resources available for
    the corresponding reservation. In this way the IN gets information
    about the current network state and has a good chance to make a
    successful reservation trial.


3.3.6 Fast Reservation Process

    BOOMP requires only one 'signaling loop' between the IN and FEN

Bergkvist, et.al.       Expires: August 1999                  [Page 5]


INTERNET-DRAFT Boomerang framework                       February 1999

    for a successful reservation.


3.4 Penetration

    The following features results in an incremental deployment of
    BOOMP in current IP networks.


3.4.1 Transparency

    The only requirement for BOOMP-unaware nodes is to forward the
    BOOMP messages. QoS in this node has to be ensured by another
    (loose or tight) QoS mechanism, otherwise the end-to-end QoS can
    be compromised. There is a prototype in which PING is used as the
    transport mechanism of BOOMP enabling the proper behavior in the
    vast majority of current IP-capable network devices.


3.4.2 QoS Interoperability

    On the top of guaranteed resource reservation in Boomerang Nodes,
    BOOMP can be used for asking for both tight QoS (such as the EF
    DSCP) and loose QoS (such as AF DSCP) [EF, AF]. It is not limited
    to any specific QoS specification, for instance it can transport
    Intserv parameters as well.


3.4.3 Multiple Scope

    There are many different way of using the Boomerang protocol for
    resource reservation. It can be used between two hosts running
    unicast services, either in a sender in or receiver oriented
    manner. It can also be used for sender oriented multicast
    services.

    Moreover, the scope of BOOMP can be limited to a single
    network domain, which is connected to domains utilizing other QoS
    techniques.


3.4.4 No requirements on the Far-end Node

    The other end-user can be quite unaware of all BOOMP
    implementation in initiating node and network nodes and still
    profit from its functionality.


4   Reservation Concept

4.1 Boomerang Reservation Message

    The BOOMP reservation message contains the following fields for
    IPv4 traffic [BOOMP]:

Bergkvist, et.al.       Expires: August 1999                  [Page 6]


INTERNET-DRAFT Boomerang framework                       February 1999


        * a signaling header
        * a flow specification
        * QoS specification


4.1.1 Signaling Header

    This field contains the refresh interval and several flags in
    which BNs can indicate the result of processing the Boomerang
    message.

    The refresh interval in the Boomerang message is a measure of how
    often the reservation has to be refreshed in order to keep it from
    timing out in the network nodes. The Initiating Node chooses a
    refresh interval. But it can be decreased by any router that needs
    a lower refresh interval; thus enforcing a higher refresh rate by
    the IN.

    If the IN stops sending refresh messages the resource allocation
    will eventually time out. The network administrator should choose
    the actual timeout in the network, and the IN should make no
    assumptions about it.


4.1.2 Flow Specification

    A BN identifies a micro-flow uniquely by five fields, found in the
    BOOMP reservation message that sets up the flow. These fields in
    the reservation message are: source IP address, source port
    number, destination IP address, destination port number and the IP
    protocol field.


4.1.3 QoS Specification

    The IN indicates the type of QoS it requires with the BOOMP
    reservation message - for the forward as well as for the reverse
    direction. The QoS parameter in current BOOMP implementation is
    bit rate, but other formats are also possible [DGVECTOR].
    Requested handling of the flow is specified in the reservation
    message. Different types of data flow require different queue
    handling rules in the nodes. The Boomerang protocol categorizes
    different service classes, each with different types of queue
    handling rules. Queue handling rules differ regarding priority,
    loss sensitivity and delay sensitivity.


4.1.4 Transport Mechanism

    There are several ways for transporting the Boomerang protocol.

    ICMP ECHO / ECHO REPLY
    In the current prototype implementation BOOMP is wrapped in an

Bergkvist, et.al.       Expires: August 1999                  [Page 7]


INTERNET-DRAFT Boomerang framework                       February 1999

    ICMP
    ECHO / ECHO REPLY messages, i.e. a normal PING message. This
    conveniently ensures the correct node behavior from most existing
    nodes both passive routers and hosts.

    New protocol or new ICMP message
    A cleaner implementation would be to define a new ICMP message for
    the BOOMP primitives, or to assign an entirely new protocol for
    BOOMP signaling.

    In both these later cases however, we would not have the correct
    end-node behavior for free. We would probably have to configure
    each unaware network node to accept these messages.

    The router alert option should be set for each Boomerang message
    in order to indicate that the routers should investigate this
    message [RALERT].

    Inbound signaling
    A slightly different approach is to transport the reservation
    messages as an integral part of the transport protocol. In this
    case a transport mechanism must be defined for each transport
    protocol where we desire to do resource reservation. This is the
    approach taken in YESSIR [YESSIR], which is an inbound signaling
    protocol for RTP connections.



4.2 Operation

    Resource reservation with the Boomerang protocol is simple. The
    Initiating Node (IN) sends a Boomerang message to the Far-End Node
    (FEN) containing the desired forward and reverse QoS descriptors
    (e.g. bit rate). When this message reaches the FEN, it is echoed
    back to the IN. The Boomerang message follows standard routing
    protocols, and allocates resources hop-by-hop in all Boomerang-
    aware nodes (BNs) en route. This ensures that the reservation will
    be made along the correct path for both upstream and downstream
    traffic. When IN gets back the Boomerang message, it verifies the
    completion of the reservation by examining the appropriate message
    flags that have been set in the BOOMP message by the BNs along the
    way. Reservation messages are then sent periodically from the IN
    to the FEN (the rate is specified by the IN itself) to keep the
    reservation alive in all of the nodes along the upstream and
    downstream paths.

    If a reservation request is denied by a BN, the following actions
    are taken before the reservation message is forwarded using
    standard routing rules:
        a) The NACK flag in the message is set
        b) If the requested resources are greater than the available
    resources at the current node, the QoS Specification fields of the
    Boomerang message are updated to reflect the current lowest
    available resources.

Bergkvist, et.al.       Expires: August 1999                  [Page 8]


INTERNET-DRAFT Boomerang framework                       February 1999

        c) If the Refresh Interval in the Boomerang exceeds the
    network node's current maximum refresh interval, it is updated to
    reflect the current minimum refresh interval.

    If a message arrives at the network node with the NACK flag
    already set, only actions (b) and (c) are taken.

    When the reservation arrives back at the IN, it checks the message
    to see if the reservation was successful.
    If the NACK flag is NOT set, the reservation was successful, but
    the Refresh Interval field might still have changed. If this is
    the case, the IN continues to send Boomerang messages with the
    interval stated in the refresh interval field.
    If the NACK flag is set, the request was denied somewhere along
    the message path. This is where the IN has to take some action. A
    new maximum QoS Specification might have been specified, so the IN
    may choose to retry the old request, revoke it with the attained
    new QoS specification, or release the request.



4.2.1 Lost Boomerang

    If the Boomerang message does not return to the IN within a
    certain time, it is considered to be lost. The IN can wait and
    repeat the original request again, or downgrade the demanded
    resource amount and request less.


5   Issues

5.1 Flow-state Aggregation

    The Boomerang protocol requires no signaling states in the network
    nodes. However, other kind of states may be needed for several
    other reasons such as policing of flows and to keep track of the
    amount of resources used in a robust way. To take full benefit of
    the Boomerang protocol in network nodes with a high aggregation of
    traffic we require ways of doing admission control that does not
    require us to keep information per micro-flow.

    There are different ways for making flow state aggregation in
    BOOMP.


5.1.1 Aggregation Suggested by Earlier Node

    This is an extension to the Boomerang protocol, which allows a
    microflow node to suggest a destination subnet-based aggregation
    to a later network node. When the microflow node discovers that it
    has a large number of reservations between two subnets it can
    decide to append aggregation information for these subnets to each
    signaling message within this aggregated flow. This is done by
    appending a special message field to Boomerang containing the

Bergkvist, et.al.       Expires: August 1999                  [Page 9]


INTERNET-DRAFT Boomerang framework                       February 1999

    class, IP protocol, source / destination subnetmask for this
    aggregation, an aggregation key (e.g. the aggregating node's own
    IP number) and the total resource demand of this aggregated flow.
    Nodes inside the network may now use this information to create
    states for these aggregates of micro-flows and can perform
    policing on these. The later node can then in turn suggest further
    aggregation for following nodes.


5.1.2 Measurement Based Admission Control

    This covers any method where no hard control is kept of the
    allocated resources. On contrary, admission control is performed
    by measuring the current amount of traffic in the given class.
    Experiments indicate [MEASURE] that measurement based techniques
    can be made to work even with long range dependant flows for a
    reasonably large aggregation.


5.1.3 Refresh Message based Admission Control

    Instead of storing hard states for keeping track of the used
    resources, the refresh request messages can be used. By summing
    the requested rates weighted by the refresh interval over a
    sliding window, the node can estimate the amount of resources
    already reserved and use this knowledge to do admission control. A
    similar approach is proposed in [TICKET]. The accuracy of the
    estimate will depend on the number of refresh messages within the
    sliding window, and the node should therefore refresh a rather
    frequent refresh interval. As with the measurement-based scheme,
    dynamic policeing of individual flows is not possible.


5.2 Route Changes

    While the issues of routing and route changes are not strictly a
    part of the signaling problem, the questions inevitably arise. If
    we are granted resources along a specific path, our data must stay
    along this path or our reservation will be useless. Furthermore,
    if we reserve resources along a path and allow these packets
    through policing as e.g. EF PHB, a path change may ruin the
    performance of other EF users in violation of the PHB
    specifications. To avoid this we must either keep states at each
    potential bottleneck where we might expect sudden route changes,
    or pin the route. This can be done either dynamically by
    "freezing" the router cache entry, or by using static route
    policies over narrow links. Our own experiences shows that in a
    network with best effort routing, route changes are very rare and
    are almost always triggered by a change in topology (such as a
    link failure). The case of non topology driven route changes
    almost always occur in the access network where the number of
    flows is reasonably low. Refreshed reservations and soft
    reservation states can help in most of the cases.


Bergkvist, et.al.       Expires: August 1999                  [Page 10]


INTERNET-DRAFT Boomerang framework                       February 1999


5.3 Multicasting

    The Boomerang protocol does not distinguish individual leafs
    within a multicast group, so the most natural way to use it in
    conjunction with multicast would be a sender oriented scheme. The
    sender would send the reservation request to the entire multicast
    group and it would be up to the leafs to detect the success or
    failure for that particular branch. A typical application could be
    a broadcast video server similar to the pay-TV found in hotel
    rooms. The server would send reservation messages to the multicast
    group with a short refresh interval (e.g. 3 seconds) and the
    NO_ECHO flag set. When a new client is added to the multicast
    group resource reservation is attempted within one refresh
    interval and the client will start receiving data along with
    either ACKed or NACKed reservations. If it receives NACKs then
    obviously the reservation failed and it is up to the client to ask
    to be removed from the multicast list.

    From the perspective of the BOOMP, it is possible to ask for
    resources for a multicast group along a specific branch. However,
    we think that solving the complexity of multiple users depending
    on the same reservation (accounting and such) is out of the scope
    of the network layer.


5.4 Denial of Service

    The Boomerang protocol provides a special ?key? field for
    preventing misuse of partially failed reservations. The access
    router could easily have a rate limit mechanism per source
    address. This is mainly an implementation issue.


5.5 Selective Hunting

    The main idea is that even if the node is "Boomerang aware" we
    only need to actually process the Boomerang messages if the node
    is judged to be a bottleneck. The Boomerang protocol could be
    deactivated by something like a bandwidth broker, if the node is
    not a bottleneck. However, computers as opposed to humans do not
    benefit significantly from resting so the main gain from
    deactivating the Boomerang protocol would be a decrease in
    signaling delay.


5.6 Security

    TBD.


5.7 Decreasing network signaling

    There are a few issues concerning the efficiency of the protocol

Bergkvist, et.al.       Expires: August 1999                  [Page 11]


INTERNET-DRAFT Boomerang framework                       February 1999

    and their possible solutions.


5.7.1 Network flooding by refresh messages

    Since the Boomerang protocol suggests refreshing of reservations
    with intervals down to a few seconds, using it with no aggregation
    might create a significant network load. If the refresh interval
    is the same for a large number of sources these will not quickly
    decorrelate if they happen to be correlated, which may result in
    unpleasant bursts of network traffic. A small numerical example:
    with the very short refresh interval of 3 sec and packets
    consisting of 56 byte IPv4 Boomerang message + ICMP + IP+ Ethernet
    = 92 bytes we will have a bitrate of 245bps. For a 12kbps IP
    telephony call this is about 2% overhead. In practical use with
    longer refresh interval, the overhead should be significantly
    less. As for the correlation, the reservations are obviously
    initiated in an uncorrelated fashion and it would therefore be
    quite rare that more than a few sources at a time would drive into
    correllation. The impact of these occurrences could be further
    reduced by letting hosts and nodes that sets the refresh value
    randomize it in a neighborhood of the desired value.


5.7.2 Network loading by end to end transmission of NACKED connections

    In the Boomerang protocol we state that all signaling is end to
    end. This means that network nodes does not generate signaling
    they only modify and update incoming signaling messages. The
    reason for this is that it makes the protocol extremely simple to
    implement. This also means that a reservation which is NACKed
    early in the network still has to travel the entire way to the end
    node and back, which both loads the network and increases the
    probability of the reservation getting lost. A solution to this
    would be to return the NACK immediately by the NACKing node. We
    have chosen not to do this since the NACK messages are an
    extremely small part of the network traffic and we value the
    simplicity of passive nodes more. Instead we treat the NACKed
    message as a query, and update it along the path with the minimum
    available resources. This way the returning NACK can serve as
    decision support for the initiating node.














Bergkvist, et.al.       Expires: August 1999                  [Page 12]


INTERNET-DRAFT Boomerang framework                       February 1999

6   Illustrative scenarios

    The multiple scopes of Boomerang based reservation process is
    illustrated by two simple examples.


6.1 Single-domain with a bottleneck

    Let us consider a scenario where we have two hosts (A, F) attached
    to a DS domain (B-C-D-E). The DS network is non blocking for high
    priority traffic, but there is a highly utilized link in the
    middle (C-D) where over-provisioning is difficult or very
    expensive (e.g. the Atlantic cable). This is a potential
    bottleneck link for the guaranteed service.

            A       B        C       D        E       F
                    /-------------------------\
                   |                           |
          +---+  +----+    +---+   +---+    +----+  +---+
          |IN |  |    |    |BN |   |BN |    |    |  |FEN|
          +---+--|    |----|   |===|   |----|    |--+---+
          +---+  +----+    +---+   +---+    +----+  +---+
                   |                           |
                    \-------DS domain---------/


    The traffic between hosts (A) and (F) has to pass through the DS
    compliant network including the bottleneck link. Therefore one of
    the hosts should send a BOOMP reservation request, in order to get
    resources on the bottleneck link in a guaranteed manner.

    Let us assume that host (A) sends a BOOMP message, which is
    forwarded hop-by-hop through the network and echoed back by host
    (F). Since (B) and (E) are BOOMP-unaware nodes, they just simply
    forward the Boomerang message to the next hop. Node (C) as the
    ingress node of the bottleneck link performs admission control for
    the requested resources and indicate the result in the Boomerang
    message. Similarly, node (D) performs admission control for the
    backward traffic. It is possible to specify different amount of
    resources for the traffic going in the forward and reverse
    directions, and forward and reverse paths can differ.

    Host A can then see the result of the reservation from the
    returned BOOMP message.

    In case of a successful reservation, host A can start to send (or
    receive) traffic with guaranteed QoS on the bottleneck links and
    DS-based QoS in the rest of the DS network. For the latter, data
    packets shall be marked with proper DSCP [DSHEAD]. The initiating
    host should refresh the reservation by sending BOOMP messages
    periodically to prevent the soft states in the nodes from timing
    out.



Bergkvist, et.al.       Expires: August 1999                  [Page 13]


INTERNET-DRAFT Boomerang framework                       February 1999


6.2  End-to-end reservation with aggregation

     SUBNET_1                                         SUBNET_2

     +---+                                             +---+
     | X |\        A       B       C       D          /| Z |
     +---+ \     +---+  +----+-+  +----+  +----+     / +---+
     +---+  \    |   |  | AN | |  |BN  |  |BN  |    /  +---+
             *---+   +--|    | |--|    |--|    |---*
     +---+  /    +---+  +----+-+  +----+  +----+    \  +---+
     | Y | /                                         \ | U |
     +---+/                                           \+---+
     +---+          B -- aggregating node              +---+


    Aggregation of flow states can be made, if one or more resource
    reservations share the same QoS specifications. It can be made on
    a subnet-to-subnet basis, and requires no special de-aggregation
    functionality.

    In this example, (X) and (Y) are two nodes that want to allocate
    resources to (Z). They do this in the usual way by sending
    Boomerang messages that will pass through (A), (B), (C) and (D),
    bounce at (Z) and then go back, reserving bandwidth in the
    opposite direction. (X) and (Y) send their reservations
    periodically, each with its own refresh interval.

    The (B) node might aggregate these reservations, since it is aware
    of the fact that both reservations are made with source=SUBNET_1
    and destination=SUBNET_2. To aggregate these reservations, (B)
    appends an aggregation field to each refresh Boomerang message
    that arrives from (X) and (Y). This aggregation field contains the
    sum of resources reserved for the aggregate, information that
    helps to identify the corresponding subnets (SUBNET_1 and
    SUBNET_2), and a special aggregation key to differentiate this
    aggregation from other ones made between the same subnets.

    (B) still keeps track of each reservation, it does not remove any
    context. When the Boomerang messages leaves (B), heading for (Z),
    it will contain this appended aggregation field and subsequent
    nodes may use it to create contexts.

    If (C) gets a Boomerang message from (X), with an aggregation
    field appended, it may ignore the information about the individual
    flow, and only create a context for the aggregation. Whenever
    another reservation message arrives, (C) looks for aggregation
    fields, and uses this part of the Boomerang message as a refresh
    message for the aggregated reservation state.

    Node (D) may, on the other hand, simply ignore these aggregation
    fields, and treat each message as a unique reservation. If (X)
    then stops sending refresh messages, the corresponding reservation
    state times out in (B), and (B) updates the aggregated state to be

Bergkvist, et.al.       Expires: August 1999                  [Page 14]


INTERNET-DRAFT Boomerang framework                       February 1999

    consistent with the currently reserved bandwidth. Moreover, (B)
    indicates this change in the corresponding Boomerang messages by
    removing the aggregation field. When the aggregation is removed
    completely, the aggregated reservation will eventually time out in
    (C), but by that time a new context should have been created in
    (C) for each individual flow.


7   References

    [E2E]     Bernet, Y., Yavatka,r R., Ford, P., Baker, F., Nichols,
              K., Speer, M., "A Framework for End-to-End QoS Combining
              RSVP/Intserv and Differentiated Services", IETF
              <draft-ietf-DiffServ-rsvp-00.txt>, March 1998.

    [DSARCH]  D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang,
              and W. Weiss, "An Architecture for Differentiated Services",
              Internet Draft, May 1998.

    [DSHEAD]  K. Nichols and S. Blake, "Definition of the Differentiated
              Services Field (DS Byte) in the IPv4 and IPv6 Headers",
              Internet Draft, May 1998.

    [EF]      V. Jacobson, Kathleen Nichols, Kedernath Poduri,
              "An Expedited Forwarding PHB", Internet Draft, February 1999
              <draft-ietf-diffserv-phb-ef-02.txt>

    [AF]      F. Baker, J. Heinanen, J. Wroclawski, W. Weiss, "Assured
              Forwarding PHB Group", Internet Draft, February 1999.
              <draft-ietf-diffserv-af-06.txt>

    [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated
              Services in the Internet Architecture: An Overview", Internet
              RFC 1633, July 1994.

    [RSVP]    Braden, R., Zhang, L., Berson, S., Herzog, S., and
              Jamin, S., "Resource Reservation Protocol (RSVP) Version 1
              Functional Specification", IETF RFC 2205, Proposed
              Standard, September 1997.

    [YESSIR]  P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation
              Mechnism for the Internet",
              http://www.ctr.columbia.edu/~pan/work/yessir/yessir.ps



Bergkvist, et.al.       Expires: August 1999                  [Page 15]


INTERNET-DRAFT Boomerang framework                       February 1999


    [DGVECTOR]Cselényi, I., Szabó, R., Szabó, I., Björkman, N., Latour-
              Henner, A., "Experimental Platform for Telecommunication
              Resource Management" Computer Communications (21)17 (1998)
              pp.1624-1640

    [MEASURE] J.T. Lewis, R. Russell, F. Toomey, B. McGurk, S. Crosby,
              I. Leslie, "Practical connection admission control
              for ATM networks based on on-line measurements",
              Computer Communications (21)17 (1998) pp. 1585-1596

    [TICKET]  A. Eriksson, C. Gehrmann, "Robust and Secure Light-
              weight Resource Reservation for Unicast IP Traffic",
              International WS on QoS'98, IWQoS'98, May 18-20, 1998

    [BOOMP]   _The Boomerang Resource Reservation Protocol_

    [RALERT]  D. Katz, "IP router alert option", RFC 2113, IETF,
              February 1997


8   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

              Engborg, Tomas
              Telia Research
              Vitsandsgatan 9B
              S-123 86 Farsta, Sweden
              Phone: +46 8 713 81 76
              Email: toeng@trab.se

Bergkvist, et.al.       Expires: August 1999                  [Page 16]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/