The motivations for developing OFI evolved from 
experience by many different classes of users of the
existing OpenFabrics Software (OFS), which is produced and distributed by
the OpenFabrics Alliance (OFA)~\cite{ofa}.
Starting as an implementation
of the InfiniBand Trade Association (IBTA) Verbs specification~\cite{ib},
this software evolved
to deal with both the iWARP specifications~\cite{rdmap,ddp,mpa}
and later the IBTA RoCE specifications~\cite{roce}, as well as
with a series of enhancements to InfiniBand and its implementations.
As was inevitable during the rapid growth of these technologies,
new ideas emerged about how users and middleware could best
access the features available in the underlying hardware.
In addition, new applications appeared with the potential to
utilize network interconnects in unanticipated ways.
Finally, whole new paradigms, such as Non-Volatile Memory (NVM)
matured to the stage where closer integration with RDMA
became both desirable and feasible.

At the 2013 SuperComputing Conference a ``Birds-of-a-Feather'' (BoF)
meeting was held to discuss these ideas, and from that
came the impetus to form what eventually came to be know
as the OpenFabrics Interface Working Group (OFIWG).
From the beginning, this group sought to embrace a wide
spectrum of user communities who either were already using
OFS, who were already moving beyond OFS,
or who had become interested in high-performance interconnects.
These communities were contacted about contributing their
ideas, complaints, suggestions, requirements, etc. about
the existing and future state of OFS, as well as about interfacing with
high-performance interconnects in general.

The response was overwhelming.
OFIWG spent months interacting with many enthusiastic representatives from
the various groups, including but not limited to MPI, SHMEM, PGAS,
DBMS, and NVM.
The result was a cumulative requirements document containing 168 specific
requirements.
Some requests were educational -- we need good user-level on-line
documentation from the beginning.
Some were organizational -- we need a well-defined revision and distribution mechanism.
Some were practical -- we need a well-defined suite of examples and tests.
Some were very ``motherhood and apple-pie'' -- the future requires scalability
to millions of communication peers.
Some were very specific to a particular user community -- provide tag-matching
that could be utilized by MPI.
Some were an expansion of existing OFS features -- provide a full
set of atomic operations.
Some were a request to revisit existing OFS features -- redesign memory registration.
Some were aimed at the fundamental structure of the interface --
divide the world into applications and providers, and allow users to
select appropriate providers by
interrogating them to discover the features they are able to provide.
Some were entirely new -- provide remote byte-level addressing.
%%This document both motivated and shaped the design of the new user-space API
%%which is implemented by the libfabric library.

After examining the major requirements,
including a requirement for independence from any given network technology
and a requirement for an API which is more abstract than other network APIs
and hence
more closely aligned with application usage of the API,
the OFIWG concluded that a new API based solely on application requirements
was the appropriate direction.
