[gaia] Fwd: [Banana] Proposed Charter for BANANA WG

Amreesh Phokeer <amreesh.phokeer@gmail.com> Mon, 02 October 2017 20:30 UTC

Return-Path: <amreesh.phokeer@gmail.com>
X-Original-To: gaia@ietfa.amsl.com
Delivered-To: gaia@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 355F1134877 for <gaia@ietfa.amsl.com>; Mon, 2 Oct 2017 13:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CZ_-yHszZpfC for <gaia@ietfa.amsl.com>; Mon, 2 Oct 2017 13:30:19 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470E6134865 for <gaia@irtf.org>; Mon, 2 Oct 2017 13:30:19 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id i197so5817823ioe.9 for <gaia@irtf.org>; Mon, 02 Oct 2017 13:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cqKb1v8mv2Gg2U8cRV7Pfu6pmqbOROqCNx9RR8U7nE4=; b=uZmcnZFVrZlEmsNpfpzp976Ga523+iktpwIyUwUa6w9Zgw99gUjROoVDT8dzu72hKD P0NKourBn+1JOQzYGZdJLRd3jqPsHfOVitDoG9albakm5dAitFcX7vzV2vCBxlwgRRYz IIqq4sYuPEuFDiKRIuFV25RPmk+b/ifrt0tFlcJWV3bBrzQOZh8vM/glKvQZZ+gOVXl6 MhJQsIsLVJusuB+psZSMyHs3Q4KoDRBb53nrRXP58npFQxvU6gRMJh/w3iD43hQ231S1 NfmHwKOBjKk2plUWZtmUcZDJztdp0wjgSIHHTN8lus4joVEucRD2impJtD5BuLjSpxcC G46A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cqKb1v8mv2Gg2U8cRV7Pfu6pmqbOROqCNx9RR8U7nE4=; b=uEVth6o1gd9GgOsbJ/0BByUk5HrUNv3E2ICxJAiob38ZWdqzOhl0OHgc7f3D+218Yn v0+OMwOLfBhVe5vOwTh7uw9InVFVl9THnz2gj8QeEfIEUZmzeq3W3s74pcB51nlzU3kL lSvxVES4NDXbcPRTMNSR7b77hGw8QSCdzp8p4DCx1ATqCDixNjbZOYv1KlI973h3WF/S 1SGsj0R4FEgx0eT7C5AcbjFOcOlowArkKzdPTRDNX44JvCXdpbxl7BbKfe8fpXcmfRJL Uf2F89LXnJ7+ZB+NwFDZZ/CZK4+ePfj2GWwwmjWMcdFsXVZlKlz9lvB5rYV25LoXFFAm 9bAw==
X-Gm-Message-State: AMCzsaVXUDP0tE+cQuCl12aplKOQQBPM3p3LsWYjfV4eNSrmmjjkRDfk 3xn3dVF6k6k5fYMzLYNOrgXEMLhVQ6BOxsSDn9gs9w==
X-Google-Smtp-Source: AOwi7QC+/UBZSpZmom/d1MQnVF/ajRMLb15z/OHdh4szKzPNHeB3JV6x76xXl/z8o7z6qNODthpEsn+HV/nfWk8usHA=
X-Received: by with SMTP id b4mr25509875iog.6.1506976218141; Mon, 02 Oct 2017 13:30:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Oct 2017 13:29:37 -0700 (PDT)
In-Reply-To: <6F4F266A-7E26-4E0B-82B1-6D65FD926338@gmail.com>
References: <6F4F266A-7E26-4E0B-82B1-6D65FD926338@gmail.com>
From: Amreesh Phokeer <amreesh.phokeer@gmail.com>
Date: Mon, 02 Oct 2017 22:29:37 +0200
Message-ID: <CACRw5zkW67SqqWm1V_UkK=UnKQqcUk+VOTVpK7VujKZkH9aKdQ@mail.gmail.com>
To: gaia <gaia@irtf.org>
Content-Type: multipart/alternative; boundary="94eb2c1c5e0a2ae460055a963e28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gaia/5AdIswoLfKhnr2ap7gu1SqG8hn0>
Subject: [gaia] Fwd: [Banana] Proposed Charter for BANANA WG
X-BeenThere: gaia@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Global Access to the Internet for All <gaia.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/gaia>, <mailto:gaia-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gaia/>
List-Post: <mailto:gaia@irtf.org>
List-Help: <mailto:gaia-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/gaia>, <mailto:gaia-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2017 20:30:22 -0000

Those who attended IETF-99 have heard about the new BANANA WG (BANdwidth
Aggregation for Network Access).
Though the chartering process has been (is still) full of controversy, the
problem space they are trying to address might be relevant to GAIA.


---------- Forwarded message ----------
From: Margaret Cullen <margaretw42@gmail.com>
Date: Mon, Oct 2, 2017 at 10:16 PM
Subject: [Banana] Proposed Charter for BANANA WG
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Cc: banana@ietf.org


Proposed Charter:  BANdwidth Aggregation for Network Access WG

The BANdwidth Aggregation for Network Access (BANANA) Working Group is
chartered to specify protocols and mechanisms to support dynamic path
selection on a per-packet basis in networks that have more than one point
of attachment to the Internet.  The protocols and mechanisms produced by
this WG will be designed to work in situations where Internet access is
provided by more than one Internet Service Provider, and without
cooperation between a set of Internet Service Providers (i.e. they will be
Over-The-Top (OTT) mechanisms).

Bandwidth Aggregation consists of splitting local traffic across multiple
Internet access links on a per-packet basis, including the ability to split
a single flow across multiple links when necessary.

It is the goal of this WG to produce Bandwidth Aggregation mechanisms with
the following benefits:

        • Higher Per-Flow Bandwidth: Many Internet links available to homes
and small offices (DSL, Cable, LTE, Satellite, VPNs, etc.) have relatively
low bandwidth. Users may wish to run applications (such as streaming video,
or content up/downloads) that require (or could benefit from) more
bandwidth for a single traffic flow than is available on any of the local
links. A Bandwidth Aggregation mechanism could supply the needed bandwidth
by splitting a single traffic flow across multiple Internet links.
        • Reduced Cost: Traffic sharing on a per-packet basis allows the
full bandwidth of the lowest-cost link to be used first, only using a
higher-cost link when the lowest-cost link is full.
        • Increased Reliability: When one Internet link goes down, ongoing
application flows can be moved to another link, preventing service

Proposed Bandwidth Aggregation mechanisms use different techniques (e.g.
tunnels, proxies, etc.) to split and recombine traffic, but at an abstract
level, they involve a local (hardware or software) component on the
multiple-access network, a remote component within the Internet or at the
remote end, and ways for those components to find each other, exchange
control information, and direct packets to each other.   We refer to the
functional components at each end as the Local and Remote “BANANA Boxes”,
and we refer to the ways they direct traffic to each other as “Bandwidth
Aggregation mechanisms”.

[Note:  Despite our use of the term “Boxes”, it should be understood that a
“BANANA Box” might be a software component running on a piece of hardware
with another primary purpose (e.g. a CPE router).]

The Bandwidth Aggregation mechanism(s) developed in the BANANA working
group will be designed to work in scenarios where Internet access links
from multiple, independent Internet access providers are being aggregated
(i.e. where the aggregated Internet access links are not provided by a
single Internet access provider, nor by a set of cooperating providers).
Any protocols defined by this working group will be IP-based,
link-layer-independent solutions, and they will be designed to work across
NATs and other middle boxes, as needed.

The BANANA WG is chartered to complete the following  work items:
        • Informally document/discuss a BANANA problem statement and usage
scenarios in a non-archival document (e.g. Wiki, etc.)
        • Determine how Local and Remote BANANA Boxes find each other (i.e.
describe how BANANA boxes will be provisioned/configured).
        • Select or specify protocol(s) that can be used to send control
information between BANANA Boxes, including:
        • IP Prefixes of access  links
        • Information about link status and properties (including
        • Information needed by the Bandwidth Aggregation mechanism(s) in
        • Determining which flows are/are not eligible for Bandwidth
        • Select (and extend, if necessary) a tunnel-based method for
sending traffic between BANANA Boxes (i.e. specify a tunnel-based Bandwidth
Aggregation mechanism).

When applicable, the BANANA WG will use existing IETF protocols, or
extensions to existing IETF protocols, as the basis for the work items
listed above.  When an existing protocol is used, the WG deliverable will
be a document describing the use of that protocol for Bandwidth Aggregation
and/or a set of options or extensions to an existing IETF protocol to make
it useful for Bandwidth Aggregation.

The BANANA WG will work with other IETF WGs that define "Bandwidth
Aggregation mechanisms" (as defined above), to ensure that protocols
selected or specified by the BANANA WG for provisioning and the exchange of
control information will work for those Bandwidth Aggregation mechanisms.
The BANANA WG will also work with other SDO(s) that are defining Bandwidth
Aggregation solutions (e.g. Broadband Forum TR-378) to ensure that there
are no conflicts between our work, and to ensure that there are no negative
consequences for users when multiple Bandwidth Aggregation technologies are
available in a single environment.

        • Apr 2018 Adopt WG draft on provisioning/configuration protocol(s)
        • Apr 2018 Adopt WG draft  on protocol(s) to send control
        • Apr 2018 Adopt WG draft on tunnel-based BA mechanism(s)
        • Feb 2019 WGLC on provisioning/configuration protocol(s)
        • Feb 2019 WGLC on protocol(s) to send control information
        • Feb 2019 WGLC on tunnel-based BA mechanism(s)
        • Aug 2019 Send provisioning/configuration mechanism to the IESG
        • Aug 2019 Send signalling protocol to the IESG
        • Aug 2019 Send tunnel encapsulation(s) to the IESG

Banana mailing list

Amreesh Phokeer