[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

MANET Autoconfiguration (AUTOCONF)                          C. Bernardos
Internet-Draft                                               M. Calderon
Intended status: Informational                                   I. Soto
Expires: May 6, 2009                                                UC3M
                                                        November 2, 2008


 Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless
                         Mesh Network scenarios
             draft-bernardos-autoconf-backbone-mesh-reqs-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 6, 2009.

Abstract

   This Internet Draft presents the multi-hop Backbone Wireless Mesh
   Network scenario, summarising its basic characteristics and
   describing the requirements and desired properties of an IP
   Autoconfiguration mechanism aimed at being used in this kind of
   networks.

   Once that the AUTOCONF WG has almost finalised the documents that
   describe the general architecture of MANETs and the IP
   autoconfiguration problem statement in MANETs, the WG is expected to
   start working on solutions.  This document describes an ad-hoc



Bernardos, et al.          Expires May 6, 2009                  [Page 1]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   scenario that is getting a lot of attention from both
   telecommunication operators and end-users: Backbone/infrastructure
   Wireless Mesh Networking.  This document identifies and explains the
   requirements posed by this particular scenario to an IP
   autoconfiguration mechanism.  The goal is to help the AUTOCONF WG
   identify the requirements that need to be taken into account when
   designing IP autoconfiguration solution(s) suitable for this Wireless
   Mesh environment.


Table of Contents

   1.  Introduction and motivation  . . . . . . . . . . . . . . . . .  3
   2.  The Wireless Mesh networking scenario  . . . . . . . . . . . .  3
   3.  IP autoconf requirements posed by the Backbone WMN scenario  .  6
     3.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Mobility type  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Address uniqueness . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Merging support  . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Partitioning support . . . . . . . . . . . . . . . . . . .  8
     3.6.  Prefix delegation support  . . . . . . . . . . . . . . . .  8
     3.7.  Protocol overhead  . . . . . . . . . . . . . . . . . . . .  9
     3.8.  Robustness . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.9.  Convergence time . . . . . . . . . . . . . . . . . . . . .  9
     3.10. Scalability  . . . . . . . . . . . . . . . . . . . . . . . 10
     3.11. Address space utilisation  . . . . . . . . . . . . . . . . 10
     3.12. Distributed/Centralised approach . . . . . . . . . . . . . 10
     3.13. Trust and security . . . . . . . . . . . . . . . . . . . . 10
     3.14. Integration with standard IPv6 nodes . . . . . . . . . . . 11
     3.15. Gateway involvement  . . . . . . . . . . . . . . . . . . . 11
     3.16. Routing protocol dependency  . . . . . . . . . . . . . . . 11
     3.17. Multiple interfaces support  . . . . . . . . . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15










Bernardos, et al.          Expires May 6, 2009                  [Page 2]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


1.  Introduction and motivation

   The multi-hop nature of ad-hoc networks and its lack of a single
   multicast-capable link for signalling prevents current IP address
   autoconfiguration related protocol specifications (such as RFCs 2461,
   2462, etc.) to be used as-is in ad-hoc networks.  Some limitations of
   these existing solutions are stated in [1] and they mainly concern:
   the lack of multi-hop support, the lack of dynamic topology support,
   the lack of network merging support and the lack of network
   partitioning support.

   The main purpose of the AUTOCONF WG is to standardise mechanisms to
   be used by ad-hoc nodes for configuring unique local and/or globally
   routable IPv6 addresses.  The ad-hoc nodes under consideration are,
   once configured, expected to be able to support multi-hop
   communication by running MANET routing protocols as developed by the
   IETF MANET WG.

   Once that the AUTOCONF WG has almost finalised the documents that
   describe the general architecture of MANETs [2] and the IP
   autoconfiguration problem statement in MANETS [1], the WG is
   chartered to start working on the standardisation of IP
   autoconfiguration solutions.  In this context, this document reviews
   and describes a particular ad-hoc scenario that is getting a lot of
   attention from both telecommunication operators and end-users:
   Backbone/Infrastructure Wireless Mesh Networking.  This document
   identifies and explains the requirements posed by this particular
   scenario to an IP autoconfiguration mechanism.  The goal is to help
   the AUTOCONF WG identify the requirements that need to be taken into
   account when designing IP autoconfiguration solution(s) suitable for
   the Wireless Mesh environment.


2.  The Wireless Mesh networking scenario

   Wireless networks are evolving to provide better services with lower
   deployment costs.  Ad-hoc networking as shown itself as one promising
   technology in many applicability scenarios.  The ad-hoc term is
   highly overloaded nowadays and it usually comprises many different
   network architectures, with disparate characteristics and
   requirements.  As an example, today we can find several instances of
   ad-hoc networks: Mobile Ad-hoc Networks (MANETs), sensor networks,
   Vehicular Ad-hoc Networks (VANETs), Wireless Mesh Networks (WMNs),
   etc.  All of them share their multi-hop, unmanaged and decentralised
   nature, but also present very important differences.  In this
   document, we pay attention to Wireless Mesh Networks, as one
   particular type of ad-hoc network that today is gaining momentum,
   mainly due to the interest from both end-users and telcos.



Bernardos, et al.          Expires May 6, 2009                  [Page 3]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   In a Wireless Mesh Network [3], nodes are comprised of mesh routers
   and mesh clients.  Each node operates not only as a host, but also as
   a router, forwarding packets on behalf of other nodes that are not
   within direct wireless reachability of their destinations.  WMNs are
   dynamically self-organised and self-configured, with their nodes
   automatically setting-up and maintaining mesh connectivity among
   themselves.  WMNs are considered to be a very promising technology
   for a broad number of applications, such as community and
   neighbourhood networks, building automation, emergency networks,
   broadband home networking, carrier backhaul solutions, etc.

   A number of variants of WMNs exist today, basically differing from
   the intended end-use and the mobility of their nodes.  As an example,
   a well known classification of WMNs distinguishes among the following
   types:
   o  Infrastructure/Backbone WMNs.  Basically, this type of WMN is
      composed of wireless mesh routers providing an infrastructure for
      clients to connect to them.  One of the possible applications of
      this type of WMNs is to serve as a carrier backhaul for a
      telecommunications operator, providing backbone for conventional
      clients.  While mesh-based solutions can be used both in temporary
      and permanent scenarios, their usage is particularly advantageous
      in situations where the network infrastructure is only needed for
      short time periods.  In these situations, the deployment of a
      backhaul infrastructure based on current solutions requires a very
      high investment which is usually uneconomical for such a short
      duration; a mesh-based solution provides a much more cost
      effective way of satisfying this short-term demand.  A good
      example of such a temporary scenario that can greatly benefit from
      a mesh-based solution is the London 2012 Olympic Games.  Besides
      this kind of "planned wireless mesh deployment", we may consider
      also an additional and very interesting example of application of
      backbone WMN: the Neighbourhood/Community Networks, which can be
      considered as an example of "unplanned wireless mesh deployment".
   o  Client WMNs.  This type of WMNs provides peer-to-peer networks
      among client devices.  Therefore, in this architecture, the client
      nodes are the ones constituting the actual network to perform
      routing, configuration and service provisioning to customers.
      This type of networks does not require mesh routers.  Compared to
      the previous type of WMNs, this imposes more requirements on the
      end-users, since they must perform additional functions such as
      routing and self-configuration.  Examples of client WMNs include:
      meeting networks, file sharing networks, entertainment networks
      for gaming, etc.
   o  Hybrid WMNs.  This architecture is actually the combination of the
      previous two ones (Infrastructure and Client WMNs), in which mesh
      clients can access the network both through mesh routers and
      directly through other clients.



Bernardos, et al.          Expires May 6, 2009                  [Page 4]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


                -------------------------
              -(                         )-
            -(                             )-
           (                                 )
          (             Internet              )
           (                                 )
            -(                             )-
              -(                         )-
                -+----------+----------+-
                /           |           \
               /            |            \
              /             |             \
         ----+----      ----+----      ----+----
         | WMN R +.-.-.-+ WMN R +.-.-.-+ WMN R |
         ----+----      ---+-+---      ----+----
              .           .   .           .
               \         /     \         /
                .       .       .       .
                 \     /         \     /
                --+---+--       --+---+--
                | WMN R +.-.-.-.+ WMN R |
                -+----+--       ----+----
                *     *              *
               *       *              *
              *         *              *
             *           *          ----+-----
            *             *         | Client |
       ----+-----     -----+----    ----------
       ! Client |     | Client |
       ----------     ----------
                               -----------------------------
                               | WMN R:  Mesh Router       |
                               | Client: IPv6 Client       |
                               -----------------------------

                      Figure 1: Backbone WMN scenario

   Since Infrastructure/Backbone WMNs are a very relevant and common
   type of WMN -- which is receiving a lot of attention today --, that
   differs from general MANET scenarios, this document will focus on
   this type of WMN (Figure 1).

   While a Backbone WMN share many common characteristics with classical
   ad-hoc networks, we may highlight the following key differences:
   o  Low/null node mobility.  Mesh routers will usually present minimal
      (if any) mobility.  Changes in the network topology will be mainly
      caused by variations in the wireless radio link characteristics
      and by WMN routers being switched on/off (that is, joining/leaving



Bernardos, et al.          Expires May 6, 2009                  [Page 5]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


      the network).
   o  Infrastructure-connected.  While we can differentiate between
      standalone and connected when considering generic ad-hoc networks,
      WMNs are expected to be always connected to the Internet.
      Backbone WMNs (or parts of them) could be temporarily
      disconnected, but only because some kind of trouble, and therefore
      the standalone mode of operation does not need to be necessarily
      considered.
   o  Multiple gateway nature.  Since Backbone WMNs are characterised
      for its Internet connectivity, they will likely require to benefit
      from deploying multiple Border Routers/Internet gateways to
      provide attached nodes with Internet connectivity.
   o  Compatibility with existing wireless networks, Internet protocols
      and legacy nodes.  Backbone WMNs are expected to provide
      connectivity to non ad-hoc/legacy clients.  Therefore, existing
      IPv6 nodes should be able to attach to a Backbone WMN (using an
      unmodified wireless/wired access protocol) and gain Internet
      connectivity through it.
   o  Scalability.  Although it is difficult to predict and it will be
      mostly dependant on the particular deployment, Backbone WMNs may
      be composed of up to hundreds (even thousands) of devices and,
      therefore, special attention should be paid to the scalability of
      the protocols designed to work in Backbone WMNs.
   o  Low power-consumption constraints.  Mesh routers usually will not
      have any strong constraint on power consumption.
   o  Multiple types of access.  While generally speaking ad-hoc
      networking technologies do not impose any restriction on the
      technologies deployed within the network, backbone WMNs will
      likely benefit from disparate heterogeneous wireless and wired
      access technologies to efficiently provide services to end-users.


3.  IP autoconf requirements posed by the Backbone WMN scenario

   This section describes in more detail the requirements that the
   Backbone WMN scenario poses on the design of an IP autoconfiguration
   solution aimed at working in this kind of environment.  This analysis
   is based on the main characteristics that define Backbone WMNs
   (described in Section 2).  To perform this analysis, we make use of
   the evaluation considerations defined in [4], by assessing each
   evaluation consideration from the point of view of a solution
   targeting Backbone Wireless Mesh Network scenarios.

3.1.  Scenarios

   This characteristic concerns the multi-hop network environment.  In
   this context, two possible scenarios of ad-hoc networks are
   identified in [1]: Standalone MANETs and Connected MANETs.  WMNs are



Bernardos, et al.          Expires May 6, 2009                  [Page 6]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   expected to be connected to the Internet.  This means that the IP
   autoconfiguration solution will have to deal with the issue of
   getting global IPv6 addresses that allow nodes to get Internet
   connectivity.

   Since Backbone WMNs are expected to be always connected to the
   infrastructure (i.e. the Internet), an IP autoconfiguration solution
   aimed at working in Backbone WMNs must provide support for Connected
   MANETs, whereas support for standalone operation is not required.
   This is a critical difference from the general ad-hoc/MANET scenario
   -- in which supporting Standalone MANETs is usually required -- and
   might have a noticeable impact on the solution space for this kind of
   environments, since solutions may assume that the infrastructure is
   always reachable and benefit from that fact (e.g., availability of
   servers).

3.2.  Mobility type

   This characteristic concerns the nodes behaviour in multi-hop
   network.  In fact, nodes' mobility type depends on the application
   type.

   Backbone WMNs are composed of wireless mesh routers, characterised by
   presenting very low (if any) mobility.  Typically, in a Backbone WMN
   scenario, mesh routers are located at fixed positions (being these
   locations also very stable over the time), and therefore a low
   topology dynamism is expected.  Most topological changes would be
   originated by the degradation of radio link conditions and by the
   switching on/off of wireless mesh routers.

3.3.  Address uniqueness

   The Address Uniqueness characteristic concerns two points: i)
   Duplicate Address Avoidance, and ii) Non-unique Address Detection.
   Duplicate Address Avoidance is a mandatory characteristic in any
   autoconfiguration mechanism.  It consists in making all
   autoconfiguration mechanisms' functionalities configure addresses
   only after their uniqueness have been verified.  On the other hand,
   Non-unique Address Detection is the process used to detect address
   collisions -- that may appear during the normal life-time of the
   network -- and resolve them.

   A solution designed aimed at working in these scenarios must ensure
   that the IP addresses configured in the mesh routers are unique
   (therefore, support for Duplicated Address Avoidance is mandatory).
   Although it is not very likely that several nodes would turn using
   duplicated addresses during the normal operation of a Backbone WMN,
   it is interesting to provide also Non-unique Address Detection, in



Bernardos, et al.          Expires May 6, 2009                  [Page 7]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   order to avoid potential disruptions in the IP connectivity due to
   address conflicts.

3.4.  Merging support

   This characteristic basically deals with the ability of an
   autoconfiguration mechanism to detect network merging and the
   functionalities that are required in order to avoid IP address
   conflicts and connectivity problems in case several networks merge.
   To illustrate an example of merging in Backbone WMNs, we might think
   of a community network formed by several neighbours of a 10-stories
   building.  In this scenario, depending on the availability of the
   neighbours' routers, it is possible that several isolated WMNs
   networks are formed (e.g. a WMN cloud formed by routers on 1st to 5th
   floor and another one formed by routers on 7th to 10th floor).  These
   isolated networks may merge if a router on the 6th floor is switched
   on.  However, given the connected nature of Backbone WMNs (every mesh
   router needs to be provided with a globally unique IPv6 address), it
   is very unlikely that after such a merging, an IPv6 address collision
   happens.

   Therefore, an IP autoconfiguration solution aimed at working in
   Backbone WMNs does not require to provide support for handling
   network merging.

3.5.  Partitioning support

   An IP autoconfiguration mechanism may present the ability to detect
   network partitioning and provide functionalities to avoid
   connectivity problems in such a case.  The same reasoning used in the
   previous section also applies here.  Only temporal, sporadic
   disconnections -- caused by some kind of trouble -- are expected in
   backbone networks.

   Therefore, an IP autoconfiguration solution aimed at working in
   Backbone WMNs is not expected to provide support for handling network
   partitioning.

3.6.  Prefix delegation support

   An IP autoconfiguration mechanism may support the delegation of IPv6
   prefixes to the connected nodes, so they can use these prefixes for
   further delegation to "traditional" or legacy attached nodes.

   Since Backbone WMNs are expected to provide legacy clients with IP
   and Internet connectivity, supporting the delegation of IPv6 prefixes
   to the mesh routers is a very interesting feature (although it is not
   the only possibility to assist legacy clients gaining IP



Bernardos, et al.          Expires May 6, 2009                  [Page 8]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   connectivity).  Therefore, an IP autoconfiguration solution aimed at
   working in Backbone WMNs should support IPv6 prefix delegation.

3.7.  Protocol overhead

   This characteristic concerns the additional signalling required by
   the IP autoconfiguration mechanism.  Such signalling is considered as
   protocol overhead that might have a significant performance impact.
   This characteristic might have an impact on the convergence time, on
   the scalability of the autoconfiguration mechanism and on the power
   consumption.

   Backbone WMNs are expected not to be power nor resource constrained
   and they will not typically suffer from very low and poor radio link
   interconnections.  Therefore, although the protocol overhead should
   always be minimised as much as possible, this is not a very critical
   issue in this kind of environments.

3.8.  Robustness

   One important characteristic/property of an autoconf mechanism is its
   robustness.  Given the particular multi-hop characteristics of ad-hoc
   scenarios, it might be important to analyse the underlying
   assumptions that an IP autoconfiguration mechanism might make.

   IP autoconfiguration mechanism aimed at working in Backbone WMNs
   should be robust in terms of resiliency to sporadic transmission
   problems (wireless links are unreliable).  However, typical radio and
   stability conditions in Backbone WMNs will be not much worse than in
   a single-hop networking scenario, and therefore the use of additional
   dedicated mechanisms is not expected.

3.9.  Convergence time

   Another important characteristic, that can be related to the
   robustness as well, is the convergence time of an autoconf solution.
   Depending on the scenario and/or the application, we may define the
   convergence time as the time required by a single node to get a
   usable (and unique) IPv6 address or as the time required by the whole
   network to have all its nodes configured with correct addresses.

   Given the level of stability of Backbone WMNs (topological changes
   are mainly caused by radio link degradation and wireless mesh
   switching on/off), convergence time is not a critical issue.  It is
   expected that only during bootstrapping many nodes will be
   configuring an IP address simultaneously, and the time that this
   "power-up" takes is not considered a concern.




Bernardos, et al.          Expires May 6, 2009                  [Page 9]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


3.10.  Scalability

   An important issue to deal with during autoconfiguration mechanisms
   design is the scalability of mechanisms to different networks sizes.
   An autoconfiguration mechanism is not scalable, if its performance
   degrades significantly when the network size increases.  The MANET
   Architecture I-D [2] defines as Small a MANET composed of 2-30 peer
   MANET routers, Moderate a MANET composed of 30-100 peer MANET
   routers, Large a MANET composed of 100-1000 peer MANET routers, and
   Very Large those MANETs larger than 1000 peer MANET routers.

   Given the application scenarios that usually involve Backbone WMNs,
   an IP autoconfiguration solution aimed at working in these kind of
   environments should scale in such a way that it works in Large
   (hundreds to thousands nodes) Backbone WMNs deployments.

3.11.  Address space utilisation

   This characteristic basically analyses how an autoconf solution makes
   use of the available address space.

   An IP autoconfiguration solution aimed at working in WMNs should make
   an efficient use of the IP address space available, given its
   connected nature and its potentially large size.

3.12.  Distributed/Centralised approach

   There are different possible approaches that an IP autoconfiguration
   mechanism might follow to provide IP addresses to all the nodes of an
   ad-hoc network, from the deployment a centralised server that is in
   charge of the IP address configuration (e.g., DHCPv6) to sharing the
   IP address configuration task among all the participant nodes.

   The Backbone WMN scenario does not impose itself any constraint/
   requirement on the particular type of solution to be used
   (centralised or distributed).  However, given the connected nature
   and reasonable topological stability of Backbone WMNs, the use of
   centralised solutions is not as discouraged as in a general MANET
   environments.  Therefore, approaches that make use of centralised
   servers located at the infrastructure can be considered.

3.13.  Trust and security

   Security is a critical issue in any communication protocol.  In the
   design of autoconfiguration mechanisms, attacks in ad hoc multi-hop
   environments should be considered.  Given the typical application
   scenarios of WMNs, it might be even possible to assume the existence
   of trust relationships between each communicating pair of nodes that



Bernardos, et al.          Expires May 6, 2009                 [Page 10]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   are involved in the autoconfiguration process.

   An IP autoconfiguration solution aimed at working in Backbone WMNs
   should be provided with a level of security similar to today's fixed
   Internet.  Because of the connected nature and taking into account
   the potential application scenarios that are being considered today
   for Backbone WMNs, it could be assumed the existence of trust
   relationships (or mechanisms enabling its establishment on-demand)
   between the participant nodes.

3.14.  Integration with standard IPv6 nodes

   Certain autoconf mechanisms may allow/be compatible to support IPv6
   nodes to get addresses using standard mechanisms defined in IPv6,
   while others may be totally incompatible with today's IPv6 nodes,
   therefore preventing these nodes to inter-operate with these autoconf
   solutions, unless the IPv6 nodes are properly modified to support
   them.

   Enabling the connectivity of legacy clients is a key characteristic
   of a Backbone WMN, Therefore an IP autoconfiguration solution aimed
   at working in this kind of environments must be compatible with
   standard IPv6 nodes, allowing them to attach and get IP connectivity
   through the WMN.

3.15.  Gateway involvement

   Internet gateways (also known as MANET Border Routers) are
   responsible of providing nodes with the connectivity to the fixed
   infrastructure.  Additionally, these gateways might also have a role/
   involvement in the IP address configuration procedure (e.g., in some
   solutions, the gateway might only be responsible of forwarding
   packets to the infrastructure, while in other solutions it may also
   be involved in the task of providing nodes with addresses/prefixes).

   An IP autoconfiguration solution aimed at working in Backbone WMNs
   does not impose any particular role to the Internet Gateways in the
   IP address configuration process.  Again, given the always-connected
   nature of this kind of WMNs, a particular solution may become simpler
   when collocating the gateway and IP address functionalities on the
   same entities.

3.16.  Routing protocol dependency

   An IP autoconfiguration mechanism may depend on a particular routing
   protocol in order to work properly or may need some specific
   information from the routing protocol stack, whereas another
   autoconfiguration mechanism may be completely independent of the



Bernardos, et al.          Expires May 6, 2009                 [Page 11]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   routing protocol used in the network.

   Potentially, it is preferred to keep the IP autoconfiguration
   solution as much independent as possible from the MANET routing
   protocol used in the network.  However, since Backbone WMN scenarios
   usually involve relatively closed user groups (e.g., community
   networks) or domains administered by a single entity (e.g., backhaul
   operator networks), the MANET routing protocol dependency is not an
   issue as critical as in generic ad-hoc scenarios.

3.17.  Multiple interfaces support

   One characteristic that might have an impact on the IP
   autoconfiguration mechanism is the number of interfaces that should
   be provided with IP addresses.  Although from a conceptual point of
   view solutions should not be affected by this, if we look at the
   solution space, this could have an impact on the IP autoconfiguration
   mechanism.

   Wireless mesh routers will typically have more than one single
   physical interface.  Therefore, an IP autoconfiguration solution
   aimed at working in a backbone WMN should support the operation on
   multiple-interfaced mesh routers, being able to provide IP addresses
   to more than one single interface.


4.  Security Considerations

   None.


5.  IANA Considerations

   This document has no actions for IANA.


6.  Acknowledgements

   Patrick Stupar provided text for an earlier version of this draft.

   This work has been partially supported by the Spanish Government
   under the POSEIDON (TSI2006-12507-C03-01) project.

   This work has also been partially supported by the EU through the ICT
   FP7 European Project CARMEN (INFSO-ICT-214994).  Apart from this, the
   European Commission has no responsibility for the content of this
   Internet-Draft.  The information in this document is provided as is
   and no guarantee or warranty is given that the information is fit for



Bernardos, et al.          Expires May 6, 2009                 [Page 12]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   any particular purpose.  The user thereof uses the information at its
   sole risk and liability.


7.  References

7.1.  Normative References

   [1]  Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address
        Autoconfiguration for MANET: Terminology and Problem Statement",
        draft-ietf-autoconf-statement-04 (work in progress),
        February 2008.

   [2]  Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network
        Architecture", draft-ietf-autoconf-manetarch-07 (work in
        progress), November 2007.

7.2.  Informative References

   [3]  Akyildiz, I., Wang, X., and W. Wang, "Wireless mesh networks: a
        survey", Computer Networks, vol. 47, no. 4, March 2005, pp. 445-
        487 , 2005.

   [4]  Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation
        Considerations for IP Autoconfiguration Mechanisms in MANETs",
        draft-bernardos-autoconf-evaluation-considerations-03 (work in
        progress), November 2008.


Appendix A.  Change Log

   Changes from -00 to -01:
   o  New release to keep the document alive.
   o  Update of some references.


Authors' Addresses

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es





Bernardos, et al.          Expires May 6, 2009                 [Page 13]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


   Maria Calderon
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 8780
   Email: maria@it.uc3m.es


   Ignacio Soto
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 5974
   Email: isoto@it.uc3m.es

































Bernardos, et al.          Expires May 6, 2009                 [Page 14]


Internet-Draft         AUTOCONF Mesh Requirements          November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Bernardos, et al.          Expires May 6, 2009                 [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/