[Banana] Removal of "solutions"

[Margaret Cullen <[e-mail]>]

Hi All,

I have made another pass at the charter, removing the word “solution(s)” as that word seems to mean distinctly different things to different people.  The updated text is included below.  

Does this make the purpose of the group clearer?  Or less clear?  Does this address the concerns of people who think that this group should only be chartered to develop protocols and mechanisms, not solutions?

From my standpoint, this change does not actually modify the proposed scope, work items, or goals of the group, but hopefully it makes the proposed goals/scope clearer to people who use the term “solutions” to include system-level descriptions of the network architecture, etc?

Margaret

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. these will be Over-The-Top (OTT) solutions).

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 solution 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