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

[Amreesh Phokeer <[e-mail]>]

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.

--
Amreesh


---------- Forwarded message ----------
From: Margaret Cullen <[e-mail]>
Date: Mon, Oct 2, 2017 at 10:16 PM
Subject: [Banana] Proposed Charter for BANANA WG
To: Suresh Krishnan <[e-mail]>
Cc: [e-mail]


[snip]

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
disruption.

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
congestion)
        • Information needed by the Bandwidth Aggregation mechanism(s) in
use
        • Determining which flows are/are not eligible for Bandwidth
Aggregation
        • 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.

Milestones
        • Apr 2018 Adopt WG draft on provisioning/configuration protocol(s)
        • Apr 2018 Adopt WG draft  on protocol(s) to send control
information
        • 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
[e-mail]
https://www.ietf.org/mailman/listinfo/banana



-- 
Amreesh Phokeer