Re: [gaia] Fixes to "Alternative Network Deployments" Internet Draft

[Arjuna Sathiaseelan <[e-mail]>]

Thanks Ermanno,

Should we also write more on TVWS - about geolocation databases and why
using proprietary databases may not be the right way forward to connect
rural areas in developing regions - and whether cognitive sensing could be
used because there is enough spectrum along with the spectrum masking
details etc?.

Or do you think it will be too much for this document..

Regards
Arjuna
On 7 Nov 2014 17:11, "Ermanno Pietrosemoli" <[e-mail]> wrote:

> Hi,
> I made a few changes in the document, highlighted in red in the attached
> pdf, and a short mention of the 802.22 standard, since, to the best of my
> knowledge, it has not been implemented in any of the White Spaces products
> currently available.
>
> Best regards,
> Ermanno
> ---------
>
>
>
>
> [Docs <http://tools.ietf.org/html/>] [txt
> <https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt>
> |pdf
> <http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt>
> |xml
> <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.xml>|
> html
> <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.html>]
> [Tracker
> <https://datatracker.ietf.org/doc/draft-manyfolks-gaia-community-networks>]
> [Email
> <[e-mail]?subject=draft-manyfolks-gaia-community-networks%20>]
> [Diff1
> <http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-manyfolks-gaia-community-networks-01.txt>]
> [Diff2
> <http://tools.ietf.org/rfcdiff?url2=draft-manyfolks-gaia-community-networks-01.txt>]
> [Nits
> <http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt>]
>
>
>
>
> Versions: 00
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-00> 01
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01>
>
>
>
>
> Global Access to the Internet for All                    J. Saldana, Ed.
>
> Internet-Draft                                    University of Zaragoza
>
> Intended status: Informational                            A. Arcia-Moret
>
> Expires: April 9, 2015                          Universidad de Los Andes
>
>                                                                 B. Braem
>
>                                                                   iMinds
>
>                                                               L. Navarro
>
>                                                 U. Politecnica Catalunya
>
>                                                          E. Pietrosemoli
>
>                                         Escuela Latinoamericana de Redes
>
>                                                            C. Rey-Moreno
>
>                                           University of the Western Cape
>
>                                                          A. Sathiaseelan
>
>                                                  University of Cambridge
>
>                                                               M. Zennaro
>
>                                                         Abdus Salam ICTP
>
>                                                          October 6, 2014
>
>
>
>     *Alternative Network Deployments.  Taxonomy and characterization*
>
>                *draft-manyfolks-gaia-community-networks-01*
>
>
> Abstract
>
>
>    This document presents a taxonomy of "alternative network
>
>    deployments", and a set of definitions and shared characteristics.
>
>    This term includes a set of network models emerged in the last
>
>    decades with the aim of bringing Internet connectivity to people,
>
>    following topological, architectural and business models different
>
>    from the so-called "traditional" ones, where a company deploys the
>
>    infrastructure connecting the households of the users, who pay for
>
>    it.
>
>
>    Several initiatives throughout the World have built large scale
>
>    networks that use wireless technologies (including long distance) due
>
>    to the reduced cost of using the unlicensed spectrum.  Others rely on
>
>    wired technologies.  Some of these networks are self-organized and
>
>    decentralized, other ones are based on sharing wireless resources of
>
>    the users.  The emergence of these networks can be motivated by
>
>    different causes: Sometimes the reluctance, or the impossibility, of
>
>    network operators to provide wired and cellular infrastructures to
>
>    rural/remote areas.  In these cases, the networks have self
>
>    sustainable business models that provide more localised communication
>
>    services as well as providing Internet backhaul support through
>
>    peering agreements with traditional network operators.  Some other
>
>    times, they are built as a complement and an alternative to
>
>    commercial Internet access provided by "traditional" network
>
>    operators.
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 1]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-2>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    The classification considers different existing network models as
>
>    e.g., community networks, open wireless services, user-extensible
>
>    services, traditional local ISPs, new global ISPs, etc.  Different
>
>    criteria are used in order to build a classification as e.g., the
>
>    ownership of the equipment, the way the network is organized, the
>
>    participatory model, the extensibility, if they are driven by a
>
>    community, a company or a local (public or private) stakeholder, etc.
>
>
>    According to the developed taxonomy, a characterization of each kind
>
>    of network is presented, in terms of network characteristics related
>
>    to architecture, organization, etc.
>
>
> Status of This Memo
>
>
>    This Internet-Draft is submitted in full conformance with the
>
>    provisions of BCP 78 <http://tools.ietf.org/html/bcp78> and BCP 79
> <http://tools.ietf.org/html/bcp79>.
>
>
>    Internet-Drafts are working documents of the Internet Engineering
>
>    Task Force (IETF).  Note that other groups may also distribute
>
>    working documents as Internet-Drafts.  The list of current Internet-
>
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>
>    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."
>
>
>    This Internet-Draft will expire on April 9, 2015.
>
>
> Copyright Notice
>
>
>    Copyright (c) 2014 IETF Trust and the persons identified as the
>
>    document authors.  All rights reserved.
>
>
>    This document is subject to BCP 78 <http://tools.ietf.org/html/bcp78>
> and the IETF Trust's Legal
>
>    Provisions Relating to IETF Documents
>
>    (http://trustee.ietf.org/license-info) in effect on the date of
>
>    publication of this document.  Please review these documents
>
>    carefully, as they describe your rights and restrictions with respect
>
>    to this document.  Code Components extracted from this document must
>
>    include Simplified BSD License text as described in Section 4
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4>.e
> of
>
>    the Trust Legal Provisions and are provided without warranty as
>
>    described in the Simplified BSD License.
>
>
>
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 2]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
> Table of Contents
>
>
>    1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1>.
> Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3>
>
>      1.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1>.
> Requirements Language . . . . . . . . . . . . . . . . . .   4
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4>
>
>    2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2>.
> Classification  . . . . . . . . . . . . . . . . . . . . . . .   4
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4>
>
>      2.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1>.
> Community Networks  . . . . . . . . . . . . . . . . . . .   5
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5>
>
>      2.2.  Crowdshared approaches, led by the people and third party
>
>            stakeholders  . . . . . . . . . . . . . . . . . . . . . .   6
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-6>
>
>      2.3
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3>.
> User-centric Networks . . . . . . . . . . . . . . . . . .   7
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7>
>
>      2.4
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4>.
> Testbed . . . . . . . . . . . . . . . . . . . . . . . . .   8
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>
>
>    3
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3>.
> Scenarios where Alternative Networks are deployed . . . . . .   8
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>
>
>      3.1.  Alternative Networks depending on the income level of
>
>            each country  . . . . . . . . . . . . . . . . . . . . . .   8
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>
>
>      3.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2>.
> Urban vs. rural areas . . . . . . . . . . . . . . . . . .  10
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10>
>
>    4
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4>.
> Technologies employed . . . . . . . . . . . . . . . . . . . .  11
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>
>
>      4.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1>.
> Wired . . . . . . . . . . . . . . . . . . . . . . . . . .  11
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>
>
>        4.1.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1>.
> Optical Fiber . . . . . . . . . . . . . . . . . . . .  11
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>
>
>      4.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2>.
> Wireless  . . . . . . . . . . . . . . . . . . . . . . . .  11
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>
>
>        4.2.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1>.
> Antennas  . . . . . . . . . . . . . . . . . . . . . .  11
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>
>
>        4.2.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2>.
> Link length . . . . . . . . . . . . . . . . . . . . .  13
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13>
>
>        4.2.3
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3>.
> Layer 2 . . . . . . . . . . . . . . . . . . . . . . .  15
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15>
>
>          4.2.3.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1>.
> 802.11 (Wi-Fi)  . . . . . . . . . . . . . . . . .  15
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15>
>
>          4.2.3.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2>.
> GSM . . . . . . . . . . . . . . . . . . . . . . .  17
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>
>
>    5
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5>.
> Network and architecture issues . . . . . . . . . . . . . . .  17
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>
>
>      5.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1>.
> Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . .  17
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>
>
>        5.1.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1>.
> IP addressing . . . . . . . . . . . . . . . . . . . .  17
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>
>
>        5.1.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2>.
> Routing protocols . . . . . . . . . . . . . . . . . .  18
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>
>
>          5.1.2.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1>.
> Traditional routing protocols . . . . . . . . . .  18
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>
>
>          5.1.2.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2>.
> Mesh routing protocols  . . . . . . . . . . . . .  18
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>
>
>      5.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2>.
> Upper layers  . . . . . . . . . . . . . . . . . . . . . .  18
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>
>
>        5.2.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1>.
> Services provided by these networks . . . . . . . . .  19
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19>
>
>          5.2.1.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1>.
> Intranet services . . . . . . . . . . . . . . . .  20
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20>
>
>          5.2.1.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2>.
> Access to the Internet  . . . . . . . . . . . . .  20
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20>
>
>      5.3
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3>.
> Topology  . . . . . . . . . . . . . . . . . . . . . . . .  21
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>
>
>    6
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6>.
> Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>
>
>    7
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7>.
> Contributing Authors  . . . . . . . . . . . . . . . . . . . .  21
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>
>
>    8
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8>.
> IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>
>
>    9
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9>.
> Security Considerations . . . . . . . . . . . . . . . . . . .  22
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>
>
>    10
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10>.
> References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>
>
>      10.1
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1>.
> Normative References . . . . . . . . . . . . . . . . . .  22
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>
>
>      10.2
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.2>.
> Informative References . . . . . . . . . . . . . . . . .  23
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23>
>
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-25>
>
>
> *1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1>*.
> Introduction*
>
>
>    Several initiatives throughout the World have built large scale
>
>    networks that use wireless technologies (including long distance) due
>
>    to the reduced cost of using the unlicensed spectrum.  Others rely on
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 3]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    wired technologies.  Some of them are self-organized and
>
>    decentralized, other ones are based on sharing wireless resources of
>
>    the users.  The emergence of these networks can be motivated by
>
>    different causes: Sometimes the reluctance, or the impossibility, of
>
>    network operators to provide wired and cellular infrastructures to
>
>    rural/remote areas [Pietrosemoli
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Pietrosemoli>].
> In these cases, the networks have
>
>    self sustainable business models that provide more localised
>
>    communication services as well as providing Internet backhaul support
>
>    through peering agreements with traditional network operators.  Some
>
>    other times, they are built as a complement and an alternative to
>
>    commercial Internet access provided by "traditional" network
>
>    operators.
>
>
>    One of the aims of the Global Access to the Internet for All (GAIA)
>
>    IRTF initiative is "to document and share deployment experiences and
>
>    research results to the wider community through scholarly
>
>    publications, white papers, Informational and Experimental RFCs,
>
>    etc."  In line with this objective this document is intended to
>
>    propose a classification of these "alternative network deployments".
>
>    This term includes a set of network models emerged in the last
>
>    decades with the aim of bringing Internet connectivity to people,
>
>    following topological, architectural and business models different
>
>    from the so-called "traditional" ones, where a company deploys the
>
>    infrastructure connecting the households of the users, who pay for
>
>    it.  The document is intended to be largely descriptive providing a
>
>    broad overview of initiatives, technologies and approaches employed
>
>    in these networks.  Research references describing each kind of
>
>    network are also provided.
>
>
> *1.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1>*.
> Requirements Language*
>
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>
>    document are to be interpreted as described in RFC 2119
> <http://tools.ietf.org/html/rfc2119> [RFC2119
> <http://tools.ietf.org/html/rfc2119>].
>
>
> *2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2>*.
> Classification*
>
>
>    This section classifies Alternative Networks according to their
>
>    intended usage.  Each of them have different incentive structures,
>
>    maybe common technological challenges, but most importantly
>
>    interesting usage challenges which feeds into the incentives as well
>
>    as technological challenges.
>
>
>    This classification is agnostic from the technical point of view.
>
>    Technology in this case must be taken as implementation.  Moreover,
>
>    many of these networks are implemented in a way that several
>
>    technologies (Ad-Hoc WiFi, Infrastructure WiFi, Optical Fibre, IPv4,
>
>    IPv6, RFC1918 <http://tools.ietf.org/html/rfc1918>, OLSR, BMX6, etc.)
> coexist.
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 4]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
> *2.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1>*.
> Community Networks*
>
>
>    Community Networks are large-scale, distributed, self-managed
>
>    networks sharing these characteristics:
>
>
>    - They are built and organized in a decentralized and open manner.
>
>
>    - They start and grow organically, they are open to participation
>
>    from everyone, sometimes agreeing to an open peering agreement.
>
>    Community members are directly contributing active network
>
>    infrastructure (not just passive infrastructure).
>
>
>    - Knowledge about building and maintaining the network and ownership
>
>    of the network itself is decentralized and open.  Community members
>
>    have an obvious and direct form of organizational control over the
>
>    overall operation of the network in their community (not just their
>
>    own participation in the network).
>
>
>    - The network CAN serve as a backhaul for providing a whole range of
>
>    services and applications, from completely free to even commercial
>
>    services.
>
>
>    Hardware and software used in community networks CAN be very diverse,
>
>    even inside one network.  A Community Network CAN have both wired and
>
>    wireless links.  The network CAN be managed by multiple routing
>
>    protocols or network topology management systems.
>
>
>    A definition of Free Network (which MAY be the same as Community
>
>    Network) is proposed by the Free Network Foundation (see
>
>    http://thefnf.org) as:
>
>
>    A free network equitably grants the following freedoms to all:
>
>
>    Freedom 0 - Freedom to communicate for any purpose, without
>
>    discrimination, interference, or interception.
>
>
>    Freedom 1 - The freedom to grow, improve, communicate across, and
>
>    connect to the whole network.
>
>
>    Freedom 2- The freedom to study, use, remix, and share any network
>
>    communication mechanisms, in their most reusable forms."
>
>
>    The principles of these networks have also been summarized (see
>
>    http://guifi.net/ca/CXOLN) this way:
>
>
>    - You have the freedom to use the network for any purpose as long as
>
>    you don't harm the operation of the network itself , the rights of
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 5]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-6>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    other users, or the principles of neutrality that allow contents and
>
>    services to flow without deliberate interference.
>
>
>    - You have the right to understand the network, to know its
>
>    components, and to spread knowledge of its mechanisms and principles.
>
>
>    - You have the right to offer services and content to the network on
>
>    your own terms.
>
>
>    - You have the right to join the network, and the responsibility to
>
>    extend this set of rights to anyone according to these same terms.
>
>
>    These networks grow organically, since they are formed by the
>
>    aggregation of nodes belonging to different users.  A minimum
>
>    governance infrastructure is required in order to coordinate IP
>
>    addressing, routing, etc.  A clear example of this kind of Community
>
>    Network is described in [Braem
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Braem>].
> These networks are effective in
>
>    enhancing and extending digital Internet rights following a
>
>    participatory model.
>
>
>    The fact of the users adding new infrastructure can be used to build
>
>    another definition: A network in which any participant in the system
>
>    may add link segments to the network in such a way that the new
>
>    network segments can support multiple nodes and adopt the same
>
>    overall characteristics as those of the joined network, including the
>
>    capacity to further extend the network.  Once these link segments are
>
>    joined to the network, there is no longer a meaningful distinction
>
>    between the previous extent of the network and the new extent of the
>
>    network.  In that sense, Community Networks can be called "user-
>
>    extensible networks".
>
>
>    These networks are also called sometimes "Free Networks" or even
>
>    "Network Commons".  However, the most accepted name is Community
>
>    Networks.
>
>
>    In Community Networks, the profit can only be made by services and
>
>    not by the infrastructure itself, because the infrastructure is
>
>    neutral, free, and open (traditional ISPs base their business on the
>
>    control of the infrastructure).  In Community Networks, everybody
>
>    keeps the ownership of what he/she has contributed.
>
>
> *2.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.2>*.
> Crowdshared approaches, led by the people and third party*
>
> *      stakeholders*
>
>
>    These networks follow the following approach: the home router creates
> two
>
>    wireless networks, one of them to be normally used by the owner, and
>
>    the other one is public.  A small fraction of the bandwidth is
>
>    allocated to the public network (as e.g.  Less-than-best-effort or
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 6]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    scavenger traffic), to be employed by any user of the service in the
>
>    immediate area.  An example is described in [PAWS
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-PAWS>
> ].
>
>
>    A Virtual Private Network (VPN) is created for public traffic, so it
>
>    is completely secure and separated from the owner's connection.  The
>
>    network capacity shared may employ a less-than-best-effort approach,
>
>    so as not to harm the traffic of the owner of the connection
>
>    [Sathiaseelan_a
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a>
> ].
>
>
>    There are three actors in the scenario:
>
>
>    - End users who sign up for the service and share their network
>
>    capacity.  As a counterpart, they can access anyone's home broadband
>
>    for free.
>
>
>    - Virtual Network Operators (VNOs) are stakeholders with socio-
>
>    environmental objectives.  They can be a local government, grass root
>
>    user communities, charities, or even content operators, smart grid
>
>    operators, etc.  They are the ones who actually run the service.
>
>
>    - Network operators, who have a financial incentive to lease out the
>
>    unused capacity [Sathiaseelan_b
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_b>]
> at lower cost to the VNOs.
>
>
>    VNOs pay the sharers and the network operators, thus creating an
>
>    incentive structure for all the actors: the end users get money for
>
>    sharing their network, the network operators are paid by the VNOs,
>
>    who in turn accomplish their socio-environmental role.
>
>
> *2.3*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3>*.
> User-centric Networks*
>
>
>    A first example is constituted by the networks created and managed by
> City Councils
>
>    (e.g., [Heer
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Heer>]).
> Some companies [FON reference missing] develop and
>
>    sell Wi-Fi routers with a dual access: a Wi-Fi network for the user,
>
>    and a shared one.  A user community is created, an people can join it
>
>    different ways: they can buy a dual router, so they share their
>
>    connection and in turn they get access to all the routers associated
>
>    to the community.  Some users can even get some revenues every time
>
>    another user connects to their Wi-Fi spot.  Other users can just buy
>
>    some passes in order to use the network.  Some telecommunications
>
>    operators can collaborate with the community, including in their
>
>    routers the possibility of creating these two networks.
>
>
>    These networks can be defined as a set of nodes whose owners share
>
>    common interests (e.g. sharing connectivity; resources; peripherals)
>
>    regardless of their physical location.  The node location exhibits a
>
>    space and time correlation which is the basis to establish a robust
>
>    connectivity model over time.
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 7]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    - "Interest": a parameter capable of providing a measure (cost) of
>
>    the attractiveness of a node towards a specific location, in a
>
>    specific instant in time.
>
>
>    - The owner: an entity (e.g. end-user; operator; virtual operator;
>
>    municipality) that is to be made responsible for any actions
>
>    concerning his/her device.
>
>
>    - The user: a legal entity or an individual using or requesting a
>
>    publicly available electronic communications' service for private or
>
>    business purposes, without necessarily having subscribed to such
>
>    service.
>
>
>    - Resources: A physical or virtual element of a global system.  For
>
>    instance, bandwdith; energy; data; devices.
>
>
>    - The Virtual Operator: entity that acts in some aspects as a network
>
>    coordinator.  It may provide services such as initial authentication
>
>    or registering, and eventually, trust relationship storage.  A VO is
>
>    not an ISP given that it does not provide Internet access (e.g.
>
>    infrastructure; naming).  A VO is neither an ASP since it does not
>
>    provide user services.
>
>
> *2.4*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4>*.
> Testbed*
>
>
>    In some cases, the initiative to start the network is not from the
>
>    community, but from a research entity (e.g. a university), with the
>
>    aim of using it for research purposes [Samanta
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Samanta>
> ].
>
>
> *3*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3>*.
> Scenarios where Alternative Networks are deployed*
>
>
>    Alternative Network Deployments are present in every part of the
>
>    World.  Even in some high-income countries, these networks have been
>
>    built as an alternative to commercial ones managed by traditional
>
>    network operators.  This section discusses the scenarios where
>
>    alternative networks are interesting or have been deployed.
>
>
> *3.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.1>*.
> Alternative Networks depending on the income level of each country*
>
>
>    There is no definition for what a developing country represents that
>
>    has been recognized internationally, but the term is generally used
>
>    to describe a nation with a low level of material well-being.  In
>
>    this sense, one of the most commonly used classification is the one
>
>    by the World Bank, who ranks countries according to their Gross
>
>    National Income (GNI) per Capita: low income, middle income, and high
>
>    income, being those falling within the low and middle income groups
>
>    considered developing economies.  Developing countries have been also
>
>    defined as those which are in transition from traditional lifestyles
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 8]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-9>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    towards the modern lifestyle which began in the Industrial
>
>    Revolution.  Additionally, the Human Development Index, which
>
>    considers not only the GNI but also life expectancy and education,
>
>    has been proposed by the United Nations to rank countries according
>
>    to the well-being of a country and not solely based on economic
>
>    terms.  These classifications are used to give strong signals to the
>
>    international community to the need of special concessions in support
>
>    of these countries, implying a correlation between development and
>
>    increased well-being.
>
>
>    However, at the beginning of the 90's the debates about how to
>
>    quantify development in a country were shaken by the appearance of
>
>    Internet and mobile phones, which many authors consider the beginning
>
>    of the Information Society.  With the beginning of this Digital
>
>    Revolution, defining development based on Industrial Society concepts
>
>    started to be challenged, and links between digital development and
>
>    its impact on human development started to flourish.  The following
>
>    dimensions are considered to be meaningful when measuring the digital
>
>    development state of a country: infrastructures (availability and
>
>    affordability); ICT sector (human capital and technological
>
>    industry); digital literacy; legal and regulatory framework; and
>
>    content and services.  The lack or less extent of digital development
>
>    in one or more of these dimensions is what has been referred as
>
>    Digital Divide.  This divide is a new vector of inequality which - as
>
>    it happened during the Industrial Revolution - generates a lot of
>
>    progress at the expense of creating a lot economic poverty and
>
>    exclusion.  The Digital Divide is considered to be a consequence of
>
>    other socio-economic divides, while, at the same time, a reason for
>
>    their rise.
>
>
>    In this context, the so-called "developing countries", worried of
>
>    being left behind of this incipient digital revolution, motivated the
>
>    World Summit of the Information Society which aimed at achieving "a
>
>    people-centred, inclusive and development-oriented Information
>
>    Society, where everyone can create, access, utilize and share
>
>    information and knowledge, enabling individuals, communities and
>
>    peoples to achieve their full potential in promoting their
>
>    sustainable development and improving their quality of life" [WSIS
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS>
> ],
>
>    and called upon "governments, private sector, civil society and
>
>    international organisations" to actively engage to accomplish it
>
>    [WSIS
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS>
> ].
>
>
>    Most efforts from governments and international organizations focused
>
>    initially on improving and extending the existing infrastructure in
> order to not  leave their population behind.  Universal Access and Service
>
>    plans have taken different forms in different countries over the
>
>    years, with very uneven success rates, but in most cases inadequate
>
>    to the scale of the problem.  Given its incapacity to solve the
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                 [Page 9]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    problem, some governments included Universal Service and Access
>
>    obligations to mobile network operators when liberalizing the
>
>    telecommunications market.  In combination with the overwhelming and
>
>    unexpected uptake of mobile phones by poor people, this has mitigated
>
>    the low access indicators existing in many developing countries at
>
>    the beginning of the 90s [Rendon
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Rendon>
> ].
>
>
>    Although it is undeniable the contribution made by mobile network
>
>    operators in decreasing the access gap, their model presents some
>
>    constraints that limits the development outcomes that increased
>
>    connectivity promises to bring.  Prices, tailored for the more
>
>    affluent part of the population, remain unaffordable to many, who
>
>    invest large percentages of their disposable income in
>
>    communications.  Additionally, the cost of prepaid packages, the only
>
>    option available for the informal economies existing throughout
>
>    developing countries, is high compared with the rate longer-term
>
>    subscribers pay.
>
>
>    The consolidation of many Alternative Networks (e.g.  Community
>
>    Networks) in high income countries sets a precedent for civil society
>
>    members from the so-called developing countries to become more active
>
>    in the search for alternatives to provide themselves with affordable
>
>    access.  Furthermore, Alternative Networks could contribute to other
>
>    dimensions of the digital development like increased human capital
>
>    and the creation of contents and services targeting the locality of
>
>    each network.
>
>
> *3.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2>*.
> Urban vs. rural areas*
>
>
>    The Digital Divide presented in the previous section is not only
>
>    present between countries, but within them too.  This is specially
>
>    the case for rural inhabitants, which represents approximately 55% of
>
>    the World's population, from which 78% inhabit in developing
>
>    countries.  Although it is impossible to generalize among them, there
>
>    exist some common features that have determined the availability of
>
>    ICT infrastructure in these regions.  The disposable income of their
>
>    dwellers is lower than those inhabiting urban areas, with many
>
>    surviving on a subsistence economy.  Many of them are located in
>
>    geographies difficult to access and exposed to extreme weather
>
>    conditions.  This has resulted in the almost complete lack of
>
>    electrical infrastructure.  This context, together with their low
>
>    population density, discourages telecommunications operators to
>
>    provide similar services to those provided to urban dwellers, since
>
>    they do not deem them profitable
>
>
>    The cost of the wireless infrastructure required to set up a network,
>
>    including powering them via solar energy, is within the range of
>
>    availability if not of individuals at least of entire communities.
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 10]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    The social capital existing in these areas can allow for Alternative
>
>    Network set-ups where a reduced number of nodes may cover communities
>
>    whose dwellers share the cost of the infrastructure and the gateway
>
>    and access it via inexpensive wireless devices.  In this case, the
>
>    lack of awareness and confidence of rural communities to embark
>
>    themselves in such tasks can become major barriers to their
>
>    deployment.  Scarce technical skills in these regions have been also
>
>    pointed as a challenge for their success, but the proliferation of
>
>    urban Community Networks, where scarcity of spectrum, scale, and
>
>    heterogeneity of devices pose tremendous challenges to their
>
>    stability and to that of the services they aim to provide, has
>
>    fuelled the creation of robust low-cost low-consumption low-
>
>    complexity off-the-self wireless devices which make much easier the
>
>    deployment and maintenance of these alternative infrastructures in
>
>    rural areas.
>
>
> *4*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4>*.
> Technologies employed*
>
>
> *4.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1>*.
> Wired*
>
>
>    Some of the wired technologies employed in ANs are:
>
>
> *4.1.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1>*.
> Optical Fiber*
>
>
>    In many (developed or developing) countries it may happen that
>
>    national service providers may decline to provide connectivity to
>
>    tiny and isolated villages.  So in some cases the villagers have
>
>    created their own optical fiber networks
>
>    http://www.fiberopticmania.com/blogs/details/948/lowenstedt-
> <http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf>
>
>    villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf
> <http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf>
>
>    http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/
> <http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/German-villagers-set-up-their-own-broadband-network.html>
>
>    German-villagers-set-up-their-own-broadband-network.html
> <http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/German-villagers-set-up-their-own-broadband-network.html>
>
>
> *4.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2>*.
> Wireless*
>
>
>    Different wireless technologies [WNDW
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WNDW>]
> can be employed in Alternative
>
>    Network Deployments.
>
>
> *4.2.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1>*.
> Antennas*
>
>
>    Three kinds of antennas are suitable to be used in these networks:
>
>    omnidirectional, directional and high gain antennas.
>
>
>    For local access, omnidirectional antennas are the most useful, since
>
>    they provide the same coverage in all directions of the plane in
>
>    which they are located.  Above and below this plane, the received
>
>    signal will diminish, so the maximum benefits are obtained when the
>
>    client is at approximately the same height as the Access Point.
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 11]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-12>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    When using an omnidirectional antenna outdoors to provide
>
>    connectivity to a large area, people often select high gain antennas
>
>    located at the highest structure available to extend the coverage.
>
>    In many cases this is counterproductive, since a high gain
>
>    omnidirectional antenna will have a very narrow beamwidth in the
>
>    vertical plane, meaning that clients that are below the plane of the
>
>    antenna will receive a very weak signal (and by the reciprocity
>
>    property of all antennas, the omni will also receive a feeble signal
>
>    from the client).  So a moderate gain omnidirectional of about 8 to
>
>    10 dBi is normally preferable.  Higher gain omnis antennas are only
>
>    advisable when the farthest way client are roughly in the same plane.
>
>
>    For indoor clients, omnis are generally fine, because the numerous
>
>    reflections normally found in indoor environments negate the
>
>    advantage of using directive antennas.
>
>
>    For outdoor clients, directive antennas can be quite useful to extend
>
>    coverage to an Access Point fitted with an omni.
>
>
>    When building point to point links, the highest gain antennas are the
>
>    best choice, since their narrow beamwidth mitigates interference from
>
>    other users and can provide the longest links [Flickenger
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Flickenger>]
> [Zennaro
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Zennaro>
> ].
>
>
>    24 to 34 dBi antennas are commercially available at both the
>
>    unlicensed 2.4 GHz and 5 GHz bands, and even higher gain antennas can
>
>    be found in the newer unlicensed bands at 17 GHz and 24 GHz.
>
>
>    Despite the fact that the free space loss is directly proportional to
>
>    the square of the frequency, it is normally advisable to use higher
>
>    frequencies for point to point links when there is a clear line of
>
>    sight, because it is normally easier to get higher gain antennas at
>
>    5 GHz.  Deploying high gain antennas at both ends will more than
>
>    compensate for the additional free space loss.  Furthermore, higher
>
>    frequencies can make do with lower altitude antenna placement since
>
>    the Fresnel zone is inversely proportional to the square root of the
>
>    frequency.
>
>
>    On the contrary, lower frequencies offer advantages when the line of
>
>    sight is blocked because they can leverage diffraction to reach the
>
>    intended receiver.
>
>
>    It is common to find dual radio Access Points, at two different
>
>    frequency bands.  One way of benefiting from this arrangement is to
>
>    attach a directional antenna to the high frequency radio for
>
>    connection to the backbone and an omni to the lower frequency to
>
>    provide local access.
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 12]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    Of course, in the case of mesh networking, where the antenna should
>
>    connect to several other nodes, it is better to use omnidirectional
>
>    antennas.
>
>
>    Keep also in mind that the same type of polarisation must be used at
>
>    both ends of any radio link.  For point to point links, some vendor
>
>    use two radios operating at the same frequency but with orthogonal
>
>    polarisations, thus doubling the achievable throughput, and also
>
>    offering added protection to multipath and other transmission
>
>    impairments.
>
>
> *4.2.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2>*.
> Link length*
>
>
>    For short distance transmission, there is no strict requirement of
>
>    line of sight between the transmitter and the receiver, and multipath
>
>    can guarantee communication despite the existence of obstacles in the
>
>    direct path.
>
>
>    For longer distances, the first requirement is the existence of an
>
>    unobstructed line of sight between the transmitter and the receiver.
>
>    For very long path the earth curvature is an obstacle that must be
>
>    cleared, but the trajectory of the radio beam is not strictly a
>
>    straight line due to the bending of the rays as a consequence of non-
>
>    uniformities of the atmosphere.  Most of the time this bending will
>
>    mean that the radio horizon extends further than the optical horizon.
>
>
>    Another factor to be considered is that radio waves occupy a volume
>
>    around the optical line, which must be unencumbered from obstacles
>
>    for the maximum signal to be captured at the receiver.  This volume
>
>    is known as the Fresnel ellipsoid and its size grows with the
>
>    distance between the end points and with the wavelength of the
>
>    signal, which in turn is inversely proportional to the frequency.
>
>
>    So, for optimum signal reception the end points must be high enough
>
>    to clear any obstacle in the path and leave extra "elbow room" for
>
>    the Fresnel zone.  This can be achieved by using suitable masts at
>
>    either end, or by taking advantage of existing structures or hills.
>
>
>    Once a clear radio-electric line of sight (including the Fresnel zone
>
>    clearance) is obtained, one must ascertain that the received power is
>
>    well above the sensitivity of the receiver, by what is known as the
>
>    link margin.  The greater the link margin, the more reliable the
>
>    link.  For mission critical applications 20 dB margin is suggested,
>
>    but for non critical ones 10 dB might suffice.
>
>
>    Bear in mind that the sensitivity of the receiver decreases with the
>
>    transmission speed, so more power is needed at greater transmission
>
>    speeds.
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 13]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-14>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    The received power is determined by the transmitted power, the gain
>
>    of the transmitting and receiving antennas and the propagation loss.
>
>
>    The propagation loss is the sum of the free space loss (proportional
>
>    to the square of the the frequency and the square of the distance),
>
>    plus additional factors like attenuation in the atmosphere by gases
>
>    or meteorological effects (which are strongly frequency dependent),
>
>    multipath and diffraction losses.
>
>
>    Multipath is more pronounced in trajectories over water, if they
>
>    cannot be avoided special countermeasures should be taken.
>
>
>    So to achieve a given link margin (also called fade margin), one can:
>
>
>    a) increase the output power. The maximum transmitted power is
>
>    specified by the country's regulation, and for unlicensed frequencies
>
>    is much lower than for licensed frequencies.
>
>
>    b) Increase the antenna gain.  There is no limit in the gain of the
>
>    receiving antenna, but high gain antennas are bulkier, present more
>
>    wind resistance and require sturdy mounts to comply with tighter
>
>    alignment requirements.  The transmitter antenna gain is also
>
>    regulated and can be different for point to point as for point to
>
>    multipoint links.  Many countries impose a limit in the combination
>
>    of transmitted power and antenna gain, the EIRP (Equivalent
>
>    Isotropically Irradiated Power) which can be different for point to
>
>    point or point to multipoint links.
>
>
>    c) Reduce the propagation loss, by using a more favourable frequency
>
>    or a shorter path.
>
>
>    d) Use a more sensitive receiver.  Receiver sensitivity can be
>
>    improved by using better circuits, but it is ultimately limited by
>
>    the thermal noise, which is proportional to temperature and
>
>    bandwidth.  So one can increase the sensitivity by using a smaller
>
>    receiving bandwidth, or by settling to lower throughput even in the
>
>    same receiver bandwidth.  This step is often done automatically in
>
>    many protocols, in which the transmission speed can be reduced say
>
>    from 150 Mbit/s to 6 Mbit/s if the receiver power is not enough to
>
>    sustain the maximum throughput.
>
>
>    A completely different limiting factor is related with the medium
>
>    access protocol.  WiFi was designed for short distance, and the
>
>    transmitter expects the reception of an acknowledgment for each
>
>    transmitted packet in a certain amount of time, if the waiting time
>
>    is exceeded, the packet is retransmitted.  This will reduce
>
>    significantly the throughput at long distance, so for long distance
>
>    application it is better to use a different medium access technique,
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 14]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    in which the receiver does not wait for an acknowledgement of the
>
>    transited packet.  This strategy of TDMA (Time Domain Multiple
>
>    Access) has been adopted by many equipment vendors who offer
>
>    proprietary protocols alongside the standard WiFi in order to
>
>    increase the throughput at longer distances.  Low cost equipment
>
>    using TDMA can offer high throughput at distances over 100
>
>    kilometres.
>
>
> *4.2.3*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3>*.
> Layer 2*
>
>
> *4.2.3.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1>*.
> 802.11 (Wi-Fi)*
>
>
>    Wireless standards ensure interoperability and usability to those who
>
>    design, deploy and manage wireless networks.  The Standards used in
>
>    the vast majority of Community Networks come from the IEEE Standard
>
>    Association's IEEE 802 Working Group.
>
>
>    The standard we are most interested in is 802.11 a/b/g/n, as it
>
>    defines the protocol for Wireless LAN.  Different 802.11 amendments
>
>    have been released, as shown in the table below, also including their
>
>    frequencies and approximate ranges.
>
>
>
>    |802.11| Release | Freq |BWdth | Data Rate per  |  Approx range (m) |
>
>    |prot  |  date   | (GHz)|(MHz) |stream (Mbit/s) | indoor |  outdoor |
>
>    +------+---------+------+------+----------------+--------+----------+
>
>    |  a   |Sep 1999 | 5    |  20  | 6,9,12, 18, 24,|    35  |    120   |
>
>    |      |         |      |      | 36, 48, 54     |        |          |
>
>    |  b   |Sep 1999 | 2.4  |  20  | 1, 2, 5.5, 11  |    35  |    140   |
>
>    |  g   |Jun 2003 | 2.4  |  20  | 6,9,12, 18, 24,|    38  |    140   |
>
>    |      |         |      |      | 36, 48, 54     |        |          |
>
>    |  n   |Oct 2009 | 2.4/5|  20  | 7.2, 14.4, 21.7|    70  |    250   |
>
>    |      |         |      |      | 28.9, 43.3,    |        |          |
>
>    |      |         |      |      | 57.8, 65, 72.2 |        |          |
>
>    |  n   |Oct 2009 | 2.4/5|  40  | 15, 30, 45, 60,|    70  |    250   |
>
>    |      |         |      |      | 90, 120,       |        |          |
>
>    |      |         |      |      | 135, 150       |        |          |
>
>    |  ac  |Nov 2011 | 5    |  20  | Up to 87.6     |        |          |
>
>    |  ac  |Nov 2011 | 5    |  40  | Up to 200      |        |          |
>
>    |  ac  |Nov 2011 | 5    |  80  | Up to 433.3    |        |          |
>
>    |  ac  |Nov 2011 | 5    |  160 | Up to 866.7    |        |          |
>
>
>    In 2012 IEEE issued the 802.11-2012 Standard that consolidates all
>
>    the previous amendments.  The document is freely downloadable from
>
>    IEEE standards [IEEE
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-IEEE>
> ].
>
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 15]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-16>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
> *4.2.3.1.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1.1>*.
> Deployment planning for 802.11 wireless networks*
>
>
>    Before packets can be forwarded and routed to the Internet, layers
>
>    one (the physical) and two (the data link) need to be connected.
>
>    Without link local connectivity, network nodes cannot talk to each
>
>    other and route packets.
>
>
>    To provide physical connectivity, wireless network devices must
>
>    operate in the same part of the radio spectrum.  This means that
>
>    802.11a radios will talk to 802.11a radios at around 5 GHz, and
>
>    802.11b/g radios will talk to other 802.11b/g radios at around 2.4
>
>    GHz.  But an 802.11a device cannot interoperate with an 802.11b/g
>
>    device, since they use completely different parts of the
>
>    electromagnetic spectrum.  More specifically, wireless interfaces
>
>    must agree on a common channel.  If one 802.11b radio card is set to
>
>    channel 2 while another is set to channel 11, then the radios cannot
>
>    communicate with each other.
>
>
>    When two wireless interfaces are configured to use the same protocol
>
>    on the same radio channel, then they are ready to negotiate data link
>
>    layer connectivity.  Each 802.11a/b/g device can operate in one of
>
>    four possible modes:
>
>
>    1.Master mode (also called AP or infrastructure mode) is used to
>
>    create a service that looks like a traditional access point.  The
>
>    wireless interface creates a network with a specified name (called
>
>    the SSID) and channel, and offers network services on it.  While in
>
>    master mode, wireless interfaces manage all communications related to
>
>    the network (authenticating wireless clients, handling channel
>
>    contention, repeating packets, etc.)  Wireless interfaces in master
>
>    mode can only communicate with interfaces that are associated with
>
>    them in managed mode.
>
>
>    2.Managed mode is sometimes also referred to as client mode.
>
>    Wireless interfaces in managed mode will join a network created by a
>
>    master, and will automatically change their channel to match it.
>
>    They then present any necessary credentials to the master, and if
>
>    those credentials are accepted, they are said to be associated with
>
>    the master.  Managed mode interfaces do not communicate with each
>
>    other directly, and will only communicate with an associated master.
>
>
>    3.Ad-hoc mode creates a multipoint-to-multipoint network where there
>
>    is no single master node or AP.  In ad-hoc mode, each wireless
>
>    interface communicates directly with its neighbours.  Nodes must be
>
>    in range of each other to communicate, and must agree on a network
>
>    name and channel.  Ad-hoc mode is often also called Mesh Networking.
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 16]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    4.Monitor mode is used by some tools (such as Kismet) to passively
>
>    listen to all radio traffic on a given channel.  When in monitor mode,
>
>    wireless interfaces transmit no data.  This is useful for analysing
>
>    problems on a wireless link or observing spectrum usage in the local
>
>    area.  Monitor mode is not used for normal communications.
>
>
>    When implementing a point-to-point or point-to-multipoint link, one
>
>    radio will typically operate in master mode, while the other(s)
>
>    operate in managed mode.  In a multipoint-to-multipoint mesh, the
>
>    radios all operate in ad-hoc mode so that they can communicate with
>
>    each other directly.  Remember that managed mode clients cannot
>
>    communicate with each other directly, so it is likely that you will
>
>    want to run a high repeater site in master or ad-hoc mode.  Ad-hoc is
>
>    more flexible but has a number of performance issues as compared to
>
>    using the master / managed modes.
>
>
> *4.2.3.1.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1.2>*.
> 802.11af (TVWS)*
>
>
>    Some Alternative Networks make use of TV White Spaces, using 802.11af
>
>    standard. Nevertheless for rural applications the IEEE 802.22 standard
>
>    is better suited since it is specifically designed for greater range.
>
>    Although current deployments of TV White Spaces have not implemented
>
>    the full specifications of 802.22, they are closer to it than to
> 802.11af.
>
>
>
>
> *4.2.3.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2>*.
> GSM*
>
>
>    802.11 is not the only layer 2 option to be used in Alternative
>
>    Networks.  Some of them use mobile technologies as e.g.  GSM.
>
>    http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-
> <http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/>
>
>    big-companies-Mexican-village-creates-its-own-mobile-service/
> <http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/>
>
>    articleshow/22094736.cms?referral=PM
>
>
> *5*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5>*.
> Network and architecture issues*
>
>
> *5.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1>*.
> Layer 3*
>
>
> *5.1.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1>*.
> IP addressing*
>
>
>    Most known Alternative Networks started in or around the year 2000.
>
>    IPv6 was fully specified by then, but almost all Alternative
>
>    Networks still use IPv4.  A community networks survey [Avonts
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Avonts>
> ]
>
>    indicated that IPv6 rollout presents a challenge to Community Networks.
>
>
>    Most Community Networks use private IPv4 address ranges, as defined
>
>    by RFC 1918 <http://tools.ietf.org/html/rfc1918> [RFC1918
> <http://tools.ietf.org/html/rfc1918>].  The motivation for this was the
> lower cost
>
>    and the simplified IP allocation because of the large available
>
>    address ranges.
>
>
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 17]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
> *5.1.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2>*.
> Routing protocols*
>
>
>    These networks are composed of possibly different layer 2 devices,
>
>    resulting in a mesh of nodes.  Connection between different nodes is
>
>    not guaranteed, the link stability can vary strongly over time.  To
>
>    tackle this, some Community Networks use mesh network routing
>
>    protocols while other networks use more traditional routing
>
>    protocols.  Some networks operate multiple routing protocols in
>
>    parallel.  E.g., they use a mesh protocol inside different islands
>
>    and use traditional routing protocols to connect islands.
>
>
> *5.1.2.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1>*.
> Traditional routing protocols*
>
>
>    The BGP protocol, as defined by RFC 4271
> <http://tools.ietf.org/html/rfc4271> [RFC4271
> <http://tools.ietf.org/html/rfc4271>] is used by a
>
>    number of Community Networks, because of its well-studied behavior
>
>    and scalability.
>
>
>    For similar reasons, smaller Community Networks opt to run the OSPF
>
>    protocol, as defined by RFC 2328 <http://tools.ietf.org/html/rfc2328> [
> RFC2328 <http://tools.ietf.org/html/rfc2328>].
>
>
> *5.1.2.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2>*.
> Mesh routing protocols*
>
>
>    A large number of Community Networks use the OLSR routing protocol as
>
>    defined in RFC 3626 <http://tools.ietf.org/html/rfc3626> [RFC3626
> <http://tools.ietf.org/html/rfc3626>].  The pro-active link state routing
>
>    protocol is a good match with Community Networks because it has good
>
>    performance in mesh networks where nodes have multiple interfaces.
>
>
>    The Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.)
>
>    [Abolhasan
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Abolhasan>]protocol
> was developed by members of the Freifunk
>
>    community.  The protocol handles all routing at layer 2, creating one
>
>    bridged network.
>
>
>    Parallel to BGP, some networks also run the BMX6 protocol [Neumann
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Neumann>
> ].
>
>    This is an advanced version of the BATMAN protocol which is based on
>
>    IPv6 and tries to exploit the social structure of Community Networks.
>
>
> *5.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2>*.
> Upper layers*
>
>
>    From crowd shared perspective, and considering just regular TCP
>
>    connections during the critical sharing time, the Access Point
>
>    offering the service is likely to be the bottleneck of the
>
>    connection.  This is the main concern of sharers, having several
>
>    implications.  There should be an adequate Active Queue Management
>
>    (AQM) mechanism that implements a Less than Best Effort policy for the
>
>    user and protect the sharer.  Achieving LBE behaviour requires the
>
>    appropriate tuning of the well known mechanisms such as ECN, or RED,
>
>    or others more recent AQM mechanisms such as CoDel and PIE that aid
>
>    on keeping low latency RFC 6297 <http://tools.ietf.org/html/rfc6297> [
> RFC6297 <http://tools.ietf.org/html/rfc6297>].
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 18]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    The user traffic should not interfere with the sharers traffic.
>
>    However, other bottlenecks besides client's access bottleneck may not
>
>    be controlled by the previously mentioned protocols.  Therefore,
> recently
>
>    proposed transport protocols like LETBAT [reference required] with
>
>    the purpose of transporting scavenger traffic may be a solution.
>
>    LEDBAT requires the cooperation of both the client and the server to
>
>    achieve certain target delay, therefore controlling the impact of the
>
>    user along all the path.
>
>
>    There are applications that manage aspects of the network from the
>
>    sharer side and from the client side.  From sharer's side, there are
>
>    applications to centralise the management of the APs conforming the
>
>    network that have been recently proposed by means of SDN
>
>    [Sathiaseelan_a
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a>]
> [Suresh
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Suresh>].
> There are also other proposals such as
>
>    Wi2Me [Lampropulos
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Lampropulos>]
> that manage the connection to several Community
>
>    Networks from the client's side.  This application have shown to
>
>    improve the client performance compared to a single-Community Network
>
>    client.
>
>
>    On the other hand, transport protocols inside a multiple hop wireless
>
>    mesh network are likely to suffer performance degradation for
>
>    multiple reasons, e.g., hidden terminal problem, unnecessary delays
>
>    on the TCP ACK clocking that decrease the throughout or route
>
>    changing [Hanbali
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Hanbali>].
> So, there are some options for network
>
>    configuration.  The implementation of an easy-to-adopt solution for
>
>    TCP over mesh networks may be implemented from two different
>
>    perspectives.  One way is to use a TCP-proxy to transparently deal
>
>    with the different impairments RFC 3135
> <http://tools.ietf.org/html/rfc3135> [RFC3135
> <http://tools.ietf.org/html/rfc3135>].  Another way is to
>
>    adopt end-to-end solutions for monitoring the connection delay so
>
>    that the receiver adapts the TCP reception window (rwnd)
>
>    [Castignani_c
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c>].
> Similarly, the ACK Congestion Control (ACKCC)
>
>    mechanism RFC 5690 <http://tools.ietf.org/html/rfc5690> [RFC5690
> <http://tools.ietf.org/html/rfc5690>] could deal with TCP-ACK clocking
>
>    impairments due to inappropriate delay on ACK packets.  ACKCC
>
>    compensates in an end-to-end fashion the throughput degradation due
>
>    to the effect of media contention as well as the unfairness
>
>    experienced by multiple uplink TCP flows in a congested WiFi access.
>
>
> *5.2.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1>*.
> Services provided by these networks*
>
>
>    This section provides an explaining of the services between hosts
>
>    inside the network.  They can be divided into Intranet services,
>
>    connecting hosts between them, and Internet services, connecting to
>
>    nodes outside the network.
>
>
>
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 19]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
> *5.2.1.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1>*.
> Intranet services*
>
>
>    - VoIP (e.g. with SIP)
>
>
>    - remote desktop (e.g. using my computer and my Internet connection
>
>    when I am on holidays in a village).
>
>
>    - FTP file sharing (e.g. distribution of Linux software).
>
>
>    - P2P file sharing.
>
>
>    - public video cameras.
>
>
>    - DNS.
>
>
>    - online games servers.
>
>
>    - jabber instant messaging.
>
>
>    - IRC chat.
>
>
>    - weather stations.
>
>
>    - NTP.
>
>
>    - Network monitoring.
>
>
>    - videoconferencing / streaming.
>
>
>    - Radio streaming.
>
>
> *5.2.1.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2>*.
> Access to the Internet*
>
>
> *5.2.1.2.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2.1>*.
> Web browsing proxies*
>
>
>    A number of federated proxies provide web browsing service for the
>
>    users.  Other services (file sharing, skype, etc.) are not usually
>
>    allowed.
>
>
> *5.2.1.2.2*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2.2>*.
> Use of VPNs*
>
>
>    Some "micro-ISPs" may use the network as a backhaul for providing
>
>    Internet access, setting up VPNs from the client to a machine with
>
>    Internet access.
>
>
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 20]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
> *5.3*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3>*.
> Topology*
>
>
>    These networks follow different topology patterns, as studied in
>
>    [Vega
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Vega>
> ].
>
>
>    Regularly rural areas in these networks are connected through long-
>
>    distance links (the so-called community mesh approach) which in turn
>
>    convey the Internet connection to relevant organisations or
>
>    institutions.  In contrast, in urban areas, users tend to share and
>
>    require mobile access.  Since these areas are also likely to be
>
>    covered by commercial ISPs, the provision of wireless access by
>
>    Virtual Operators like FON is the way to extend the user capacity (or
>
>    gain connection) to the network.  Other proposals like Virtual Public
>
>    Networks [Sathiaseelan_a
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a>]
> can also extend the service.
>
>
>    As in the case of main Internet Service Providers in France,
>
>    Community Networks for urban areas are conceived as a set of APs
>
>    sharing a common SSID among the clients favouring the nomadic access.
>
>    For users in France, ISPs promise to cause a little impact on their
>
>    service agreement when the shared network service is activated on
>
>    clients' APs.  Nowadays, millions of APs are deployed around the
>
>    country performing services of nomadism and 3G offloading, however as
>
>    some studies demonstrate, at walking speed, there is a fair chance
>
>    of performing file transfers [Castignani_a
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_a>]
> [Castignani_b
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_b>
> ].
>
>    Scenarios studied in France and Luxembourg show that the density of
> APs in
>
>    urban areas (mainly in downtown and residential areas) is quite big and
>
>    from different ISPs.  Moreover, performed studies reveal that
> aggregating
>
>    available networks can be
>
>    beneficial to the client by using an application that manage the best
>
>    connection among the different networks.  For improving the scanning
>
>    process (or topology recognition), which consumes the 90% of the
>
>    connection/reconnection process to the Community Network, the client
>
>    may implement several techniques for selecting the best AP
>
>    [Castignani_c
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c>
> ].
>
>
> *6*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6>*.
> Acknowledgements*
>
>
>    This work has been partially funded by the CONFINE European
>
>    Commission Project (FP7 - 288535).
>
>
> *7*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7>*.
> Contributing Authors*
>
>
>
>
>
>
>
>
>
>
>
> Saldana, et al.           Expires April 9, 2015                [Page 21]
>
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>
>
> Internet-Draft       Alternative Network Deployments        October 2014
>
>
>
>    L. Aaron Kaplan
>
>    Funkfeur
>
>    Street
>
>    1234 city
>
>    Austria
>
>
>    Phone: [phone]
>
>    Email: [e-mail]
>
>
> *8*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8>*.
> IANA Considerations*
>
>
>    This memo includes no request to IANA.
>
>
> *9*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9>*.
> Security Considerations*
>
>
>    No security issues have been identified for this document.
>
>
> *10*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10>*.
> References*
>
>
> *10.1*
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1>*.
> Normative References*
>
>
>    [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
>
>               E. Lear, "Address Allocation for Private Internets", BCP
> <http://tools.ietf.org/html/bcp5>
>
>               5 <http://tools.ietf.org/html/bcp5>, RFC 1918
> <http://tools.ietf.org/html/rfc1918>, February 1996.
>
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>
>               Requirement Levels", BCP 14
> <http://tools.ietf.org/html/bcp14>, RFC 2119
> <http://tools.ietf.org/html/rfc2119>, March 1997.
>
>
>    [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328
> <http://tools.ietf.org/html/rfc2328>, April 1998.
>
>
>    [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
>
>               Shelby, "Performance Enhancing Proxies Intended to
>
>               Mitigate Link-Related Degradations", RFC 3135
> <http://tools.ietf.org/html/rfc3135>, June 2001.
>
>
>    [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
>
>               Protocol (OLSR)", RFC 3626
> <http://tools.ietf.org/html/rfc3626>, October 2003.
>
>
>    [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
>
>               Protocol 4 (BGP-4)", RFC 4271
> <http://tools.ietf.org/html/rfc4271>, January 2006.
>
>
>    [RFC5690]  Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
>
>               Acknowledgement Congestion Cont
> ...