Roadmap

This is the LISPmob Open Roadmap for 2014, please feel free to express your opinion, suggestions at criticism at the mailing list (users@lispmob.org).

Keeping up-to-date with recent IETF drafts/standards

Item	Description	Priority
Instance ID support	From RFC6830: “When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI-based address unique. See IANA Considerations (Section 14.2) for details on possible address encodings.”	Release 0.6
LCAF support	LISP creates two separate namespaces, EIDs and RLOCs. To provide flexibility for several use-cases such namespaces can be expressed using a general syntax. There are already types defined for geo-coordinates, names, etc. More details can be found at draft-ietf-lisp-lcaf	Expected in next release (0.5)
ITR+PITR persistent list	This list will be updated automatically and stored in a file. When LISPmob starts, SMR to all locators of this list. With this we can also remove the static proxy-ITR list of the configuration file	Release 0.6
Advanced reachability algorithms	Implement the (more advanced) reachability algorithms discussed in RFC6830	Low
Explicit Locator Paths (ELP) support	From draft-farinacci-lisp-te: “The ELP is an explicit list of RLOCs for each RTR a packet must travel to along its path toward a final destination ETR (or PETR). The list is a strict ordering where each RLOC in the list is visited.”. ELPs can be used to define paths for congestion avoidance, failure recovery or in general Traffic Engineering. ELPs require LCAF Type 10:	Expected in next release (0.5)

Infrastructure components

This items aims to enable innovation in the LISP infrastructure components by implementing features in LISPmob that enable quick prototyping.

Item	Description	Priority
LISPmob API	Allow third-party software to control LISPmob (Map-Cache, multihoming, reachability, etc…) by means of an API	Release 0.6
LISPmob in other platforms	Integrate LISPmob with other systems such as OpenVSwitch, OpenDayLight, etc..	Medium
RTR mode	Support Re-encapsulating Tunnel Router (RTR) mode as defined in draft-ermagan-lisp-nat-traversal	Expected in next release (0.5)
Map Server/Map Resolver mode	Support Map-Server and Map-Resolver (MS/MR) mode as defined in RFC6833	TBD
PITR/PETR mode	RFC6832	Expected in next release (0.5)

Edge components

This items aims to implement features that enable new edge-based use-cases.

Item	Description	Priority
Implement multihoming and multipath support	LISPmob already supports multihoming (i.e., multiple simultaneous interfaces) in Linux and load-balances flows among the different active interfaces. Although this is also supported in OpenWRT, there are very few devices that have multiple WAN ports. This increases dramatically the deployment cost of multihoming. With respect to vanilla Android, the OS does not support having multiples interfaces actives at the same time. This prevents the use of this feature in mobile devices. The LISPmob community can look into both issues and identify possible solutions/workarounds.	High
Implement NAT to non-NAT handover	Currently LISPmob does not support a vertical/horizontal handover from NAT to non-NATed networks. Implementing this would allow LISPmob to fully support vertical and horizontal handovers	High
Optimize handover latency	Currently the handover latency for LISP is too large, in the order of seconds. The LISPmob community can try to find optimizations and reduce it to the order of hundreds of ms.	Low
liblispmob	LISPmob has a robust implementation of LISP, we can leverage this to create a library that can be used by any third party software that wants to use part of the LISP functionality.	Expected in next release (0.5)
Manual configuration for NAT-traversal	Support for manual configuration of the src RLOC in the NAT-box to correctly advertise it in the Map-Register.	Low