[OOR-Devel] OOR Design diagram
Albert López
alopez at ac.upc.edu
Thu Apr 27 13:17:22 CEST 2017
I also want to point to this article. May be could be interesting to
understand the oor architecture.
Albert
El 27/04/17 a les 12:17, Albert López ha escrit:
> <-- devel in copy -->
>
> Dear Marian,
>
> I am sorry but we don't have any diagram, only the code itself. I
> suppose than in two or three weeks we will release a new version of
> the code which have a few architecture changes.
> I can provide you some details about the folder structure (of the new
> architecture).
>
> * config : All the files related to configure the device
> o Process the configuration file -> confuse in linux and
> android, uci in OpenWRt
> o oor_api* to configure the router online with netconf . In the
> netconf folder ( top directory) there is the files to compile
> the module used in the netconf server
> * control:
> o We have the main controller (oor_ctrl) that controls one
> device ( we would like that in a future it could control
> more than one device ) . Currently a device could be a MS or
> a tunnel router (xTR/MN/RTR). Each device implements the
> structure ctrl_dev_class_t which contain the abstract
> functions that should be implemented for any device. lisp_xtr
> and lisp_ms implements this functions and all the logic behind
> LISP (what should be done when an event is received, for
> instance a lisp control message, expiration of an entry, ...).
> o In this directory we also have the local_db (our EIDs) and the
> map_cache database
> o control-data-plane: data plane of the control messages. For
> each data plane we implement control_dplane_struct_t. We have
> tun data plane based on raw sockets, vpnapi for android (no
> root) and VPP <https://fd.io/> (a software router with very
> fast packet forwarding).
> * data-plane: Here you find everything related with the encap/decap
> and forwarding of the packets. All the three data planes we
> support implements data_plane_struct_t
> * elibs: External libraries like patricia tree
> * fwd_policies: Here you find the policies to be used to select the
> source and destination RLOCs to reach a destination. We have two
> policies defined, the flow balancing to do multihoming and
> vpp_balancing to adapt to the requirements of VPP
> * lib: General functionalities. Here we have the timers, the socket
> master where we register the sockets we create with the function
> to be called when something is received in the socket, glits,
> hashtables, ...
> * liblisp: Here we have the structures that define the lisp messages
> and how to serialize our own structures (for instance a mapping)
> to packets or deserialize the packet to convert it to our structures.
> * net_mgr: This abstraction level is new. We define net_mgr_class_t
> with all the functions that should be implemented for each
> dataplane to obtain the list of interfaces, addresses, routes,.. .
> It also process the changes of the network and notifies to the OOR
> control and data plane.
>
> This is the basic information you may need. If you need more details
> regarding one specific point, let me know and I will try to help you.
>
> Best regards
>
> Albert
>
>
> El 26/04/17 a les 15:11, Marian Aretu ha escrit:
>>
>> Hello Albert,
>>
>> I don’t know if you remember, but I wrote to you back in January
>> regarding OOR implementation.
>>
>> I was wondering if you have some design diagram for oor-1.1.1. It
>> will help me to understand faster your implementation.
>>
>> Can you help me with this?
>>
>> Thank you,
>>
>> Marian Aretu
>>
>>
>> PPlease consider the environment before printing this e-mail.
>>
>> ------------------------------------------------------------------------
>> This message including any attachments may contain confidential
>> information, according to our Information Security Management System,
>> and intended solely for a specific individual to whom they are
>> addressed. Any unauthorised copy, disclosure or distribution of this
>> message is strictly forbidden. If you have received this transmission
>> in error, please notify the sender immediately and delete it. Thank you.
>> ------------------------------------------------------------------------
>> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
>> contener información clasificada por su emisor como confidencial en
>> el marco de su Sistema de Gestión de Seguridad de la Información
>> siendo para uso exclusivo del destinatario, quedando prohibida su
>> divulgación copia o distribución a terceros sin la autorización
>> expresa del remitente. Si Vd. ha recibido este mensaje erróneamente,
>> se ruega lo notifique al remitente y proceda a su borrado. Gracias
>> por su colaboración.
>> ------------------------------------------------------------------------
>> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter
>> informação confidencial, de acordo com nosso Sistema de Gestão de
>> Segurança da Informação, sendo para uso exclusivo do destinatário e
>> estando proibida a sua divulgação, cópia ou distribuição a terceiros
>> sem autorização expressa do remetente da mesma. Se recebeu esta
>> mensagem por engano, por favor avise de imediato o remetente e
>> apague-a. Obrigado pela sua colaboração.
>> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> devel mailing list
> devel at openoverlayrouter.org
> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170427/f34dd660/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oor-commag-r1.pdf
Type: application/unknown
Size: 539738 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170427/f34dd660/attachment-0001.bin>
More information about the devel
mailing list