CarGeo6 Project

Transcription

CarGeo6 Project

CarGeo6 Project
« Developement results
and User guide »
DATE
EDITOR
SECURITY
:
:
:
June 2011
Thouraya TOUKABRI, INRIA
Public
DOCUMENT HISTORY
Release
Date
Reason of change
0.1
21/04/11
Thouraya TOUKABRI: First draft
Draft
0.2
07/06/11
Reviewed by Anouar CHEMEK
Draft
0.3
16/06/11
Final corrections by Thouraya TOUKABRI and
Thierry ERNST
Copyright © 2010 ESPRIT-INRIA
Status
Final
version
Developement Results and User guide
Table of Contents
Introduction.......................................................................................................................................... 3
Partner contributions....................................................................................................................... 3
Development environment.............................................................................................................. 6
Hardware platform......................................................................................................................6
Software platform....................................................................................................................... 7
Software Liscence........................................................................................................................... 8
Software architecture and modules...................................................................................................... 8
C2CNet layer implementation.........................................................................................................9
ITSNET software architecture.................................................................................................... 9
Main components and functionalities....................................................................................... 11
C2CNet Packet header format.................................................................................................. 11
Packet processing......................................................................................................................12
Position sensor...............................................................................................................................13
IPv6 over C2CNet implementation............................................................................................... 13
Implementation design..............................................................................................................13
IPv6 Packet forwarding............................................................................................................ 16
IPv6 movement detection......................................................................................................... 16
Mobile Network Prefix Provisioning (MNPP)..............................................................................17
Interface implementation..................................................................................................... 22
CarGeo6 sending interface (Dll-SAP)...........................................................................................22
The C2C-IP interface.....................................................................................................................23
Design....................................................................................................................................... 23
Interface implementation:......................................................................................................... 23
User Guide......................................................................................................................................... 25
Software installation......................................................................................................................26
Building dependencies..............................................................................................................26
Compilation.............................................................................................................................. 26
Configuration.................................................................................................................................26
Ad-hoc Network configuration.................................................................................................27
ITSNET parameters configuration :......................................................................................... 28
Starting script configuration .................................................................................................... 29
MNPP configuration................................................................................................................. 31
Running CarGeo6..........................................................................................................................32
Example of V2V single hop Unicast scenario.......................................................................... 32
Acknowledgment............................................................................................................................... 34
2
1.
Introduction
CarGeo6 is the product of a partnership between the French research institute INRIA and
the Tunisian school ESPRIT. The main purpose of this project is to provide an open source
implementation of IPv6 GeoNetworking as originally specified in the GeoNet deliverables
[GeoNetD2.2], [GeoNetD1.2] (see http://www.geonet-project.eu/) and now taken over by
ETSI TC ITS. At this point in time, the necessary adaptation of the implementation to
comply with ETSI specifications of IPv6 GeoNetworking is a work under progress.
ESPRIT was in charge of providing a stable implementation of the C2CNet layer
conforming with [GeoNetD2.2] while INRIA brought its contribution by extending this
implementation with the integration of IPv6 features over the C2CNet layer.
Functional modules of the architecture are shown Figure 1 but the reader is advised to
report to [GeoNetD1.2] for a detailed description of the architecture and to [GeoNetD2.2]
for a detailed description of modules composing this architecture..
The current software is open source and is released under version 0.9.8.1 which is the last
stable one. It has already been published under the name “CarGeo6” (see
http://www.cargeo6.org) in:
•
http://sourceforge.net/
•
https://gforge.inria.fr/
The present document is the first official and public documentation of CarGeo6 and is
intended for users and open source developer communities to help them understanding
the implementation design of the software and its modules and how to test it in a basic
vehicle-based communication scenario.
The present document is structured as follows:
•
Overview of CarGeo6 and a description of partner contributions
•
The software architecture and the implementation design
•
CarGeo6 Interface implementation
•
The use guide with demonstration scenario
1.1
Partner contributions
The list of contributors from ESPRIT and INRIA is described in the following table. The list
involves people who participated to the design,the implementation documentation and
3
tests of the software and people who were in charge of coordination between the two
teams :
ESPRIT
INRIA
Farouk KAMMOUN
Thierry ERNST
Lamjed BETTAIEB
Manabu TSUKADA
Hichem BARGAOUI
Thouraya TOUKABRI
Anouar CHEMEK
Ines BEN JEMAA
Lamiss AMAMOU
Jong-Hyouk LEE
Based on the GeoNet specifications, the CarGeo6 implementation was validated in
collaboration with INRIA on the same testing platform used in GeoNet experimentations.
As such, the implementation relies on the same architecture specified in GeoNet D2.2.
Contributions to the implementation by each part are summarized in Figure 1 as follows:
Figure 1: CarGeo6 general architecture and contributions
4
•
ESPRIT : ESPRIT was in charge of the implementation of all C2CNet Layer
modules as described in GeoNet D2.2 and the C2C-LL SAP. In addition, they
implemented the position sensor module that communicates mainly with a GPS
device and the C2C-GPS SAP which is part of the MNG-CC SAP.
•
INRIA : INRIA was in charge of the development of an adaptation module (IPv6
over C2CNet) that integrates IPv6 features on the top of the C2CNet software
provided by ESPRIT. In addition, they contributed to the elaboration and edition of
the final documentation and User Guide manual with the help of ESPRIT
developers.
Besides, INRIA is currently leading a work to integrate the CarGeo6 implementation
in the ITS station architecture. The work is then focused on the design, specification
and implementation of all the SAPs of the Network & Transport layer in the ITS
station architecture (see Figure 2). According to CarGeo6 architecture in Figure 1,
the current focus of INRIA is the specification and implementation of the MNG-CC
SAP and the MNG-IP SAP that could be considered, from an ITS station point of
view, part of the MN-SAP.
FN SAP
SN SAP
MN SAP
IN SAP
Figure 2: CarGeo6 in the ITS station architecture
5
1.2
Development environment
In this part, we describe hardware and software platforms used in CarGeo6 during the
development phase and the experimentation phase.
1.2.1
Hardware platform
At a first time, normal desktops and laptops with processor based mainly on X86
architecture were used for software development and testing of first versions of the
C2CNet software. Once we had a complete version of the software that includes basic
C2CNet and IPv6 features, we started working directly on Mobile Routers.
Mobile Routers were provided by INRIA and were used for indoor and outdoor
experiments until the end of the project. The developed software is hardware-platform
independent at the current time as it does not contain any features or configurations
related to a specific hardware or specific software running on the hardware.
The table below summarizes hardware characteristics of Mobile Routers:
Features
Description
Model
Alix3d3
Operating system
Ubuntu 9.0.4, kernel version 2.6.29.6
Processor
Geode(TM) Integrated Processor by AMD PCSi586 CPU 498.128 MHz
Wireless card
mini-pci wireless card (Atheros AR5413 802.11abg NIC)
Ethernet card
VT6105M [Rhine-III]
Disk & Memory
4110MB SanDisk SDCFX3- 004G247MiB System memory
IPv6 hosts used in experimentation tests are Sony VAIO U50/70 PCs on which a Linux
based operating system was installed for testing purposes.With Debian operating system
and a 2.6.15 kernel version, VAIOs run normal IPv6 stack only and are not designed to run
the complete IPv6 GeoNetworking stack (I.e: not GeoNetworking modules)..
During tests, VAIOs were connected to Mobile Routers using an Ethernet hub. Figure 2
shows how IPv6 hosts are connected to the Mobile Router.
6
Figure 3: ITS station hardware platform
1.2.2
•
Software platform
Operating system:
The operating system chosen for software development is Linux. Considering the fact that
the kernel version will evolve during the development process, no requirement is made on
the kernel version as long as it's a variety of 2.6 kernel and does not include any specific
features of a certain version of kernel. Besides, CarGeo6 was tested mainly on 2.6.29,
2.6.31, 2.6.32 and 2.6.37 kernel versions.
•
Programming language:
The programming language C/C++ was chosen for all software modules. No specific and
only standard C/C++ libraries were identified for the implementation. All software modules
are user-space programs, and are not kernel modules. This eases the whole
implementation process and does not limit the deployment of modules.
•
Tools:
The management of source code and releases was carried-out using SVN on a dedicated
server at INRIA.
In addition, the DoxyGen tool was used to provide source code documentation. This tool
was a support for developers in both teams to quickly find their way in the source code
and provided means to visualize relations between the various elements and modules of
the developed software (i.e: dependency graphs, inheritance diagrams, and collaboration
diagrams...).
7
1.3
Software Liscence
CarGeo6 is released under the LGPLv2 license (Lesser GNU Public License). The GNU
Lesser General Public License counts as the successor of the GNU Library General Public
licence.
The first reason for choosing LGPL licence for CarGeo6 is that it is almostly compatible
with GPL licences. Then, in a matter of evolutivity of CarGeo6 and in the case we want to
link CarGeo6 with other softwares not necessary free ones, LGPL allows us to use not
only free softwares but also propriatery ones. In other words, LGPL implies less
restrictions on the use of CarGeo6 than GPL and is GPL compliant at the same time.
2.
Software architecture and modules
Figure 3 is a simplified description of the CarGeo6 software architecture with its main
modules and interfaces.
The C2CNet module developed by ESPRIT was named ITSNET: It's in charge of the
geographical addressing and implements all routing functionalities specified in GeoNet
D2.2. The ITSNET software communicates with the lower layer using the C2C-LL interface
and with the Position sensor module using the GPS-C2C interface (MNG-C2C SAP) to get
position information from the GPS equipment.
Figure 4: Software architecture, modules and interfaces
8
At the IPv6 layer, four modules have been integrated: NEMO, IPv6 over C2CNet, MNPP
and MLDv2. The module IPv6 over C2CNet implements the interface C2C-IP between
IPv6 and the C2CNet layer that allows sending IPv6 packets through the ITSNET
software.
The NEMO module provides mobility management mechanisms and communicates also
with the C2CNet layer over the C2C-IP interface. Besides, MCoA is another IPv6 feature
that will be integrated in CarGeo6 in the future in order to enhance mobility management.
As an advanced IPv6 feature, MNPP implements a mechanism that enables two Mobile
Routers communicate directly.
The software module Position sensor sends local position information read from a GPS
receiver to the C2CNet layer. As indicated in the GeoNet deliverables, this module shall be
part of the ITS station management plane as positionning information must be accessed
by various layers composing the ITS station reference architecture. However, this is not
yet acknowledged in ETSI specification and is not formally specified in GeoNet
deliverables.
2.1
C2CNet layer implementation
This section describes the implementation of the C2CNet layer by ESPRIT. The developed
software is a user space program named ITSNET that implements all Geo-Routing
functionalities and modules described in the GeoNet specification D2.2.
2.1.1
ITSNET software architecture
Complying to GeoNet D2.2, the ITSNET daemon is a C/C++ user space program which
runs under the Linux operating system. It has already been tested with the Linux kernel
versions 2.6.29, 2.6.31, 2.6.32 and 2.6.37 and should work with any newer kernel version
since it does not include any kernel specific feature or library.The ITSNET daemon
architecture is described in Figure 4.
•
The Message dispatcher manages communication between the four different
interfaces (Management SAP, IP SAP, Transport SAP and Security SAP) and the
other modules’ daemons of the architecture. When a packet is received on one
interface, the message dispatcher forwards it to the right module according to its
packet type. For a given packet type, the message dispatcher calls the appropriate
9
handler that will process it.
•
The packet dispatcher represents the bridge between Networking modules such
as Beaconing and GeoRouting, and the DLL SAP which is the C2C-LL SAP. In other
words, all packets coming from the ITSNET daemon and going to the wireless
interface (egress interface) are dispatched by the packet dispatcher. Then,
according to the type of the outgoing packet (Beacon or Geo-Routing packet), the
packet dispatcher calls the appropriate encapsulation function to add the
appropriate C2CNet header.
•
The Timer sub-module is in charge of temporizing two tasks : The sending interval
between two successive beacons and the refreshing time of the Location table.
Figure 5: Implementation design of ITSNET software
•
GeoNetworking modules mainly Beaconing, Location Service and Geo-Routing
sub-modules have access to the Location table using read/write operations to get
information about neighbor nodes and their position. Particularly, Location service
and Geo-Routing have both access to a buffer which is used to temporarily keep a
given packet for a certain duration time when needed.
10
2.1.2
Main components and functionalities
The ITSNET daemon supports the 3 Geo-Routing schemes described in GeoNet
specification D2.2 : GeoBroadcast, GeoUnicast and GeoAnycast. The TopoBroadcast
scheme is still under development. The ITSNET daemon provides a set of GeoNetworking
functionalities which are implemented by the following sub-modules :
–
Beaconing : Allows periodic sending of C2CNet packets from a Mobile Router
(OBU or RSU) to inform its neighbor Mobile Routers about its presence . This type
of packet is called Network Beacon, and contains only the common header (as
defined by C2C-CC) which contains a position vector to inform about own position
information.
–
Location table : Represents a table that is maintained in each MR in order to
record the list of C2CNet neighbors with their geographical position information.
–
Location manager :This sub-module is used when the MR wants to send a
GeoUnicast packet to a non-neighbor MR (position information of the destination
node is unknown). Meaning a Re- quest/Reply packet exchange mechanism, the
location service sub-module could provide this information.
–
Geo-Routing : This sub-module implements Geo-Routing algorithms for each
GeoNetworking schemes mainly GeoUnicast scheme, GeoBroadcast scheme,
GeoAnycast scheme and TopoBroadcast scheme.
–
Store and Forward : This sub-module is in charge of storing packets when no
destination or next forwarder is available. In such case, the packet is stored in a
local buffer until its validity expires. When a next forwarder or destination is
available, the packet is sent from this buffer to the targeted destination.
2.1.3
C2CNet Packet header format
•
MAC frame format:
Figure 6: General CarGeo6 frame format
11
MAC Frame format
Field
Description
Length
MAC dest
Destination address
6 bytes
MAC source
Source address
6 bytes
Type
Packet type (ethertype 0x0707)
2 bytes
Ethernet payload
C2CNet packet
•
1500 bytes
C2CNET common header fields:
C2CNET common header
Fields
INFO
Forwarder
position vector
2.1.4
Length
itsnet_version
4 Bits
itsnet_next_header
4 Bits
itsnet_header_type
4 Bits
itsnet_header_subtype
4 Bits
txpower
8 Bits
flags
8 Bits
payload_length
16 Bits
traffic_class
8 Bits
hop_limit
8 Bits
node_id
64 Bits
time_stamp
32 Bits
latitude
32 Bits
longitude
32 Bits
speed
16 Bits
heading
16 Bits
altitude
16 Bits
accuracy
16 Bits
Packet processing
All the incoming packets from the wireless interface (egress interface) are processed by
the appropriate handler.Then, for each packet handler, the packet processing is mainly
based on the packet header structure.Two main processing phases are done for each
incoming packet :
12
•
MAC header processing : All arriving packets on the egress interface are first
processed by the MAC layer. Each field of the MAC header is then processed and
checked (e.g. header type, destination MAC address and source MAC address).
Once the MAC layer related information is retrieved from the MAC header, the
header is removed and the rest of the packet is transferred to the next module.
•
C2CNet header processing : This module implements the position-based routing
protocols with forwarding functionalities (e.g. GeoUnicast, GeoBroadcast, etc.)
needed to route packets to a destination. In general, the processing is divided into
two sides : receiver side and sender side. For the receiver side, all the packets
coming from the MAC layer to the C2CNet layer are forwarded to the application
layer. Irrelevant packets will be discarded. if the packet is not intended for the
receiving node, then it will be forwarded to the egress interface (wireless interface).
2.2
Position sensor
The position sensor module is a very simple module that provides the geographic position
of the mobile router to the C2CNet layer or the other layers. The geographic information is
provided by the GPS in the form of a 3-uplet <latitude, longitude timestamp>.
In the current implementation, the position sensor module is an adaptation for gpsd ,which
is an open source tool for getting formatted positioning data from a connected NMEA
device. Every time new position data is known, a message is sent to C2CNet modules via
a UDP socket. This module communicates with ITSNET through C2C-GPS interface.
2.3
IPv6 over C2CNet implementation
This module allows the transmission of IPv6 packets between C2CNet and the IPv6 layers
stack. In the GeoNet architecture design, it links the IPv6 over C2CNet sub-module to the
C2CNet modules through the C2C-IP SAP, a SAP internal to the network layer.
2.3.1
Implementation design
IP over C2CNet sub-module is in charge of acquiring necessary IP parameters such as
IPv6 address, performing IP Next Hop determination and IP address resolution over the
C2CNet link in order to communicate with nearby Mobile Routers.
As the IPv6 stack is implemented in the kernel space, this sub-module implemented in the
13
user space should get routing information for IP Next Hop determination from kernel
routing tables. This is done using existent Linux libraries and tools mainly :
•
The LibNetlink library for the look up in kernel routing tables.
•
The tunctl tool for TUN/TAP virtual interface creation between Kernel space and
User space.
Using the tunctl package, the IP over C2C software creates and mounts a network virtual
interface named tun0 on which are written all packets coming from the IPv6 stack. In this
way, packets on tun0 interface could be easily manipulated and processed by any program
in the user space in particular the ITSNET software.
Figure 6 illustrates the implementation of the IP over C2C software and its main
functionalities. The software consists mainly of two components : the main program and
the configuration script. The configuration script is in charge of IPv6 address configuration
for the Mobile Router ingress and egress interfaces , creation and configuration of the
virtual interface tun0 as well as the static IP routes setting.
Figure 7: IP over C2CNet implementation design
14
Besides, according to the packet destination range (GeoUnicast, GeoBroadcast,
TopoBroadcast or GeoAnycast), the destination C2C-ID and the payload, the IP over C2C
program implements the following functions:
•
Reads the packet from tun0 interface
•
Parses the source and destination address of the packet from tun0
•
Looks up routing table by destination to find the IP next hop using the Netlink library
•
Extracts C2C-ID from the IP Next Hop address
IP Next Hop determination is the operation that consists on finding the IP Next Hop’s IPv6
address from a given destination IPv6 address. This operation is performed by the IP over
C2C sub-module in all Mobile Routers running an IPv6 GeoNetworking stack. The
operation is closely related to on-link determination, which means determining whether a
destination is directly reachable through C2CNet forwarding mechanisms or not.
For the receiving, IP over C2C does not perform any operation with incoming packets from
the ITSNET software as all packets are directly handled by the C2C-IP SAP. Thus, IPv6
forwarding mechanisms detects automatically packets on the interface and performs the
appropriate IPv6 Forwarding routine. After executing these operations, the C2C-IP SAP
handles the packet until the C2CNet layer and performs the necessary IPv6 to C2C
mapping operations.
Figure 8: IP Next Hop determination
15
2.3.2
IPv6 Packet forwarding
As C2CNet is implemented in the user space, a virtual interface is used to deliver packets
from the IP layer implemented in kernel space to the C2CNet module. In the Linux system,
IPv6 packet forwarding is processed in the kernel space so the packet has to be brought to
the user land from kernel. Then the packet is encapsulated with a C2CNET header and
then sent back to the kernel again. The tun virtual interface is used to bring the packet to
the user land. This is illustrated in figure 8.
Figure 9: IPv6 forwarding mechanism over C2CNET
2.3.3
IPv6 movement detection
Figure 9 shows a mobility scenario where MR changes its point of attachment, and informs
its Home Agent about its new address. When the Access Router sends a Router
Advertisement, it uses the multicast address ff02::1 (all-node link local address). The RA
packets are then GeoBroadcasted in a given radius area around the AR. MRs receive the
RA and update their routing tables setting the link local address of the AR as a default
gateway address. They also auto-configure their CoA using the prefix advertised in the RA
packet. The traffic bound to a CN is encapsulated first into the NEMO tunnel and then into
the C2CNet tunnel.
16
Figure 10: IPv6 movement detection
2.4
Mobile Network Prefix Provisioning (MNPP)
This function part of the IPv6 over C2CNet module provides a solution to advertise the
IPv6 prefix (known as the Mobile Network Prefix or MNP in the case of a MR) of a router
(MRs and ARs) to other nearby routers in order to avoid the transmission of packets via
the HA when routers are directly reachable over the IPv6 C2CNet link or any conventional
wireless link.
MNPP has been implemented as an extension (patch) of radvd, the well known IPv6
router advertisement daemon. The current implementation of MNPP, which is v0.3, has
been developed on top of radvd v1.5 as an extension (patch) so that it provides also the
original radvd functionalities. It only requires the same level of requirements with radvd so
that any specific kernel version or library is not required for the compilation or operation of
MNPP.
The current implementation of MNPP only implements the reactive mode in which each
MR sends periodically an MNPP advertisement message to its neighboring nodes so that
the neighboring nodes can obtain the IPv6 prefix from the MNPP advertisement message
17
and update their routing information for any IPv6 node having the IPv6 prefix as the
network prefix. In other words, functionalities for sending and responding MNPP
solicitation are not considered in the current implementation.
Figure 10 shows the ICMPv6 message format for MNPP. For the type field of ICMPv6, 200
and 201 are used for the MNPP solicitation and advertisement messages, respectively.
The valid options are as follows:
•
Source Link-Layer Address (SLLA) Option: The link-layer address of the sender
(MR) of the MNPP message should be included.
•
Station-internal In-vehicle Maximum Transmission Unit (MTU) Option: The
MTU size of the ITS station-internal network should be sent.
•
Mobile Network Prefix (MNP) Option: The IPv6 station-internal prefix (MNP1)
must be included to indicate which IPv6 prefix is being used in the ITS station
internal network of the sender (MR or AR). This option is a mandatory option for the
MNPP advertisement message. Note that multiple MNPs can be carried in one
MNPP advertisement message.
Figure 11: ICMPv6 message format for MNPP
The implementation of MNPP can be viewed by two different angles: the sender and
receiver. First, from the viewpoint of the sender, the operation of MNPP is illustrated in
Figure 11.
For sending periodically MNPP advertisement messages, the sending router (MR or AR)
uses its ICMPv6 socket interface since the MNPP advertisement message has been
defined as an ICMPv6 message similar to the RA message. Then, some configuration
parameters are dispatched from the configuration file that will be described later.
1
The term MNP comes from NEMO RFC 3963 which is used to maintain Internet reachabilitiy of the in-vehicle network at a permanent address.
In IPv6 GeoNetworking, MNP is used in broader sense meaning « Ipv6 station-internal prefix » wether NEMO is used (ITS station internal
network on the MR side) or not (ITS station internal network on the AR side).
18
As shown in figure 11, send_ra() in send.c is the function for generating MNPP
advertisement messages. The timer for the next MNPP advertisement message is set
after its first sending by set_timer() in timer.c.
Figure 12: MNPP Sending Function
Figure 12 illustrates the operation of MNPP from the viewpoint of the receiver. As shown,
only RS, RA, and MNPP messages are dispatched from the ICMPv6 socket.
Since those messages have different ICMPv6 message types, process() in process.c
classifies them and calls appropriate functions such as process_rs(), process_ra(), and
process_mnpp_advert(). Here, process_mnpp_advert() is a newly added function for
processing
MNPPadvertisement.
The most important procedure of
process_mnpp_advert()
is
to
call
two
routes
manipulation functions for updating the route path: route_del() and route_add() that are
coming from rtnl.c and rtnl.h of UMIP. route_del() is called as follows:
result_route = route_del(iface->if_index, RT_TABLE_MNPP_NUM,
RT_TABLE_MNPP_PRE, NULL, 0, &pinfo->nd_opt_pi_prefix, pinfo>nd_opt_pi_prefix_len, NULL);
19
Figure 13: MNPP Receiving Function
Similarly, route_add() is called as follows:
result_route = route_add(iface->if_index, RT_TABLE_MNPP_NUM,
RTPROT_STATIC,0,RT_TABLE_MNPP_PRE,NULL,0, &pinfo>nd_opt_pi_prefix, pinfo->nd_opt_pi_prefix_len, &addr->sin6_addr);
As shown in figure 12, by calling two route manipulation functions, we can update the
route path with the following parameters:
•
iface->if_index indicates the interface for MNPP.
•
RT_TABLE_MNPP_NUM indicates the routing table number for MNPP. It is defined
as 201 in radvd.h. This number can be changed as needed.
•
RT_TABLE_MNPP_PRE indicates the routing preference for MNPP. It is defined as
99 in radvd.h. This number can be changed as needed.
•
RTPROT_STATIC indicates that this route is installed by a means of administrator.
More detailed at /usr/include/linux/rtnetlink.h
•
&pinfo->nd_opt_pi_prefix
indicates
the
MNP
obtained
from
the
MNPP
advertisement message.
•
pinfo->nd_opt_pi_prefix_len indicates the length of MNP. • &addr->sin6_addr
indicates that the gateway for the routing, i.e., the egress address of the MR.
20
The filtering tool, ip6tables, is used for marking packets. The followings are an example
that all ICMPv6 and UDP packets are marked with 63:
ip6tables -t mangle -F
ip6tables -A PREROUTING -t mangle -p icmpv6 -j MARK --set-mark 63
ip6tables -A PREROUTING -t mangle -p udp -j MARK --set-mark 63
Then, by the following ip command, the packet selection rule for the marked packets is
defined:
ip -6 from xxx rule add fwmark 0x3F lookup 201 prio 300
This rule is applied to packets coming from the network prefix, i.e., xxx. The marking
number in this example is (0x3F) that must be the same number with the marked number
used by ip6tables. Note that the marking number of ip command must be the hexadecimal
number. The lookup table number, i.e., lookup 201, must be the same value with
RT_TABLE_MNPP_NUM defined in radvd.h. Then, the priority to this rule is 300. Note that
it is important to put a higher priority to this rule than that of UMIP/NEPL routing table. For
instance, the following example shows a lower priority of UMIP/NEPL routing table:
ip -6 rule from xxx add fwmark 0x3F lookup 252 prio 400
Since the priority to UMIP/NEPL routing table (table number 252) is lower than that of
MNPP, the packets from xxx are checked by the rule for MNPP first. This feature provides
a possibility of selective routing for different flows.
Figure 14: Multiple Routing Tables Lookup
21
This is worth noting that MNPP enabled routers (MR and AR) should look up their routing
tables in proper priorities, e.g., for the MNPP enabled MR, MNPP routing table (table
number 201) → UMIP/NEPL routing table (table number 252) → Main routing table (table
number 254) and for the MNPP enabled AR, MNPP routing table (table number 201) →
Main routing table (table number 254). Figure 13 shows an example of routing lookup over
multiple routing tables. In the presented illustrate, for given packets (marked packets with
63), the MNPP routing table has higher priority than the UMIP/NEPL routing table.
3.
3.1
Interface implementation
CarGeo6 sending interface (Dll-SAP)
Designated by DLL-SAP, this SAP is used to communicate with the egress interface of the
MR. For now, the ITSNET implementation works only with 802.11a,b,g media. A future
integration with the 802.11p protocol is planned meaning an adaptation module.
Scripts
Figure 15: CarGeo6 sending interface implementation
The sending interface in ITSNET is statically pre-configured. The DLL_SAP.c file which is
responsible for packets sending uses the Device_parser () function in the itsnet_parser.c
file to know which interface must be used. The itsnet_parser.c file, check the variable
"Device" in the configuration file itsnet.conf to get the name of the pre-configured sending
interface. This scenario is described in Figure 14.
22
3.2
The C2C-IP interface
3.2.1
Design
The C2C-IP interface is the piece of software that links the ITSNET software with the IPv6
stack. In other words, all incoming packets from the IP layer and going to the wireless
interface should be mapped according to their packet type into C2CNet packets with given
destination range.
According to the GeoNet specification for the IP Forwarding module in D2.2, the C2C-IP
interface provides the following functionalities :
•
Sending function : This function transmits an IPv6 packet with all the parameters
needed by Geo-Routing module over the IP over C2C sub-module in order to
forward this packet until its destination. In case of an IPv6 Unicast scenario, the
function should transmit the C2CNet ID of the IP next hop. For IPv6 multicast
packets, the IP layer must provide the C2CNet layer with the necessary
GeoDestination information to GeoBroadcast the packet in a specific geographical
area.
•
Receiving function : This function handles the incoming packet from the C2CNet
layer and delivers its payload (the IPv6 packet) to the IP over C2C sub-module in
order to process it and give it to the upper layers.
The mapping performed by the C2C-IP interface at the sending function is explained here
in the table below:
Destination range
IPv6 layer
C2CNet layer
A node in a specific vehicle
Unicast
GeoUnicast
Nodes located in vehicles in a specific
geographical area
Multicast
GeoBroadcast
A node located in a vehicule in a
specific geographical area
Anycast
GeoAnycast
A node in vehicles at x hops away
Multicast
TopoBroadcast
3.2.2
Interface implementation:
From an implementation point of view, the C2C-IP SAP is composed mainly of two
primitive functions : The sending function ip-listener() and the receiving function ipreceive().
23
▪ Ip-listener ():
This primitive function is in charge of finding a given node’s C2CNet ID from its IPv6
address and sending the IPv6 packet to the appropriate C2CNet handler according to the
mapping rules described in the previous table. The current implementation of C2C-IP
considers only two cases for sending : IPv6 Unicast packets and IPv6 multicast packets.
The mapping for the Anycast sending case is implemented in the source code but not yet
tested as it requires the implementation of the GeoDestination module in the Management
layer.
Figure 16: C2C-IP SAP sending function
▪ ip-receive ():
When the ITSNET software receives a packet at the C2CNet layer of the IP Next Hop, the
following operations are executed :
•
At the C2CNet layer : It checks the C2CNet header to see if the destination C2C-
ID is identical to IP Next Hop C2C-ID or not.If yes, the C2CNet header is retrieved and the
IPv6 packet is given to the C2C-IP SAP.
•
At the C2C-IP SAP : Gets the packet from the C2CNet receiving routine and writes
it on the virtual interface tun0.
•
At the IP layer : The IPv6 forwarding mechanism checks if the IPv6 destination
address is correct and forwards it to IPv6 destination node.
24
Figure 17: C2C-IP SAP receiving function
4.
User Guide
In this section, we describe to users how to prepare software and hardware environments
for CarGeo6 indoor or outdoor testing. Samples configuration files are provided in the
ReadMe directory of the CarGeo6-v0.9.8.1 package and are described in this user guide.
Then, we describe compilation and installation steps before running the software.
The CarGeo6-v0.9.8.1 released package is structured as follows :
•
/cargeo6-src-v0.9.8.1: Contains the source code of all CarGeo6 modules. Most
important sub-directories here are:
◦ /src : Contains the source code of the ITSNET software and the IP over C2C
adaptation module.
◦ /position-sensor : Contains position-sensor module implementation and is
used only for outdoor tests.
◦ /static-position-sender: Contains an implementation that simulates a positionsensor and is used for indoor tests purpose.
◦ /ReadMe: contains a HOWTO and samples of basic configuration files
25
4.1
Software installation
The CarGeo6 package contains mainly user space modules related to the C2CNet layer
and the IPoverC2C module. The source code is based mainly on basic GNU libraries.
Besides, some additional libraries or tools that may not exist by default in the linux kernel
should be installed.
4.1.1
Building dependencies
Here is the list of need tools and libraries to install before compiling the source code:
◦ Tools:
•
The tunctlv1.5 package should be installed. This package allows creation and
mounting of TUN/TAP network virtual interfaces used by the IPoverC2C module.
•
The gpsd software should be installed to ensure position-sensor module
functioning.
◦ Libraries:
•
libpthread, libconfuse0, libgps18 or libgps19, libconfuse0 and libconfuse-dev should
be installed. Notice that these library names could change for recent versions of the
Linux kernel.
4.1.2
Compilation
You should have root permissions to execute the following commands under the main
directory of the package CarGeo6-v0.9.8.1/ :
# make distclean
# ./configure
# make
The compilation will generate binaries for source files in /src only. Other modules should
be compiled separately (position-sensor and fake-position-sensor).
if your compilation fails, check that you have installed all the required dependencies.
5.
Configuration
In order to run properly the CarGeo6 daemon, basic configuration files and scripts has
been provided with the source code. To test basic Ipv6 V2V scenarios, some parameters
should be configured in configuration files. In this section, we describe basic configurations
26
to set up before running the implementation.
Samples of configuration files are provided in /cargeo6-src-0.9.8.1/ReadMe/samplesconfig/.
Mainly, 5 configuration files and scripts are provided with CarGeo6 source code:
create_wifi.sh , startOBU.sh and itsnet.conf. These configuration files are necessary to
create the ad-hoc network, configure GeoNetworking parameters at the C2CNet layer of
each GeoNetworking node, enable IPv6 routing and addressing and stop the itsnet
daemon.
5.1.1
Ad-hoc Network configuration:
This configuration is done by running the create_wifi.sh script. The configuration of this
file is described as follows:
#mounting the wireless interface driver
modprobe -r ath5k
sleep 1
modprobe ath5k
sleep 1
#setting up the channel to use
iwconfig wlan1 channel 3
sleep 1
#setting up the ad-hoc mode and the Rate for the interface
iwconfig wlan1 mode Ad-hoc
sleep 1
iwconfig wlan1 rate 6M
sleep 1
#setting up the SSID for the ad-hoc network
iwconfig wlan1 essid itsnet
sleep 1
#activating the interface
ifconfig wlan1 up
iwconfig |grep itsnet
Notice : if you are using an ath_pci interface, here is an exemple of configuration for an
ath_pci interface :
#Mounting the interface and setting the ad-hoc mode
modprobe -r ath_pci
sleep 1
modprobe ath_pci autocreate=adhoc
sleep 1
#Setting up the ESSID, the channel and the Rate
iwconfig ath1 essid itsnet channel 3 mode Ad-hoc rate 6M
sleep 1
#Setting up the interface
ifconfig ath1 up
27
5.1.2
ITSNET parameters configuration :
The itsnet.conf file is used to configure basic parameters of the ITSNET software at the
C2CNet layer. This file is parsed by the itsnet daemon to allow receiving and sending
C2CNet packets at the wireless interface.
The following configuration example shows the utility of each parameter in the itsnet.conf
configuration file:
# Whether Itsnet is a daemon or not.
# default = false
DetachFromTTY = false
#Specifies the debug level (0 to 5) but only 0, 3 and 5 levels are defined
# 0 : no debugging messages, better for real field tests
# 3 : shows differed debugging
# 5 : shows real time debugging messages, better for debugging tests
#default = 0
DebugLevel = 5
# Specifies the wireless interface
# default = eth1
Device = wlan1
# Specifies itsnet max data size
#default 1500
ItsnetDataSize = 1500
# Specifies the broadcast mac address
#default = ff:ff:ff:ff:ff:ff
BroadcastMac = "ff:ff:ff:ff:ff:ff"
#Specifies the max number of neighbor vehicles
#default = 10
MaxNeighbor = 10
#Specifies the lifetime entry in the Location Table
#default = 5
LocationTableEntry = 5
#Specifies the ethertype of the itsnet packet
#default = 0x707
EthPItsnet = 0x707
#Specifies sending beacon or not
#default = true
SendBeacon = true
#Specifies the C2CNet NodeId of the vehicle
#default = aa:aa:bb:bb:cc:cc:00:22
NodeId = "00:00:00:00:00:00:CA:03"
#Specifies the log file for debugging messages
ItsnetLog="/var/log/itsnet.log"
#Specifies the radius when destination address is ff02::1
AllNodeMcast_Radius = 1500
28
#Specifies the radius when destination address is ff0e::2
MLD_GroupAddress = ff02:0:0:0:0:0:0:2
MLD_GroupAddress_Radius = 1000
#Initial geographic position of the vehicle
InitialLatitude = 48.4
InitialLongitude = 10.003
InitialAltitude = 48
InitialSpeed = 24
InitialHeading = 36
5.1.3
Starting script configuration :
The main script that is in charge of setting up IPv6 configuration and running the cargeo6
daemon is startOBU.sh2.
The first section is dedicated to specify paths for configuration files and for external
modules :
#!/bin/bash
OBU_ID=OBU4
BASE_DIR=/GIVE/THE/PATH/TO/CarGeo6-v0.9.8.1/cargeo6-src-v0.9.8.1/
Egress_IF=wlan1
# === Software ===
Tunctl=GIVE/THE/PATH/TO/tunctl
ITSNET=$BASE_DIR/src/itsnet
GPS_SENDER=$BASE_DIR/static-position-sender/gps_position_sender
PositionSensor=$BASE_DIR/position-sensor/position_sensor
GPSD=/usr/sbin/gpsd
MNPPD=mnppd
RADVD=/usr/sbin/radvd
# === Config ===
RADVD_CONF=./radvd.conf
MNPP_CONF=./mnppd.conf
ITSNET_CONF=./itsnet.conf
GPS_SENDER_CONF=./gps_data3
The second section is for interface configuration:
#===== Interfaces =====
Ingress_IF=eth0
TUNNEL=tun0
#===== Addresses =====
IngressAddress=2001:660:3013:CA04::1/64
TunnelLinkLocal=fe80::ca04/64
InVehicleNetwork=2001:660:3013:CA04::/64
TunnelAddress=2001:660:3013:F005::CA04/64
The third section is for GPS daemon configuration:
2
The OBU term is used in the GeoNet specification to designate the On Board Unit, which is the MR entity in CarGeo6.
29
#==== GPS =========
PositionSensorDevice=/dev/ttyS0
# Serial port used to connect GPS serial cable
StaticRSUDestPrefix=default
StaticRSUIPNextHop=2001:660:3013:F005::CA05
# static routing
IP over C2C interface and IPv6 routing rules are configured in the following section:
#====== IPC2C Configuration ======
sh kill.sh
# tap0
echo "tap0 config"
modprobe -r tun; sleep 1; modprobe tun;
$Tunctl -t $TUNNEL -n # point-to point
#ip link set $TUNNEL arp off
ip link set $TUNNEL arp on
echo "Tunneling interface mounted"
sysctl -w net.ipv6.conf.all.forwarding=1
ifconfig $TUNNEL inet6 add $TunnelLinkLocal up
ifconfig $Egress_IF up
ifconfig $Ingress_IF inet6 add $IngressAddress up
ifconfig $TUNNEL inet6 add $TunnelAddress up
ifconfig $TUNNEL mtu 1350 up
echo "Tunnel address configured"
ip -6 route add $StaticRSUDestPrefix via $StaticRSUIPNextHop dev $TUNNEL
ip -6 route change $StaticRSUDestPrefix via $StaticRSUIPNextHop dev $TUNNEL
$RADVD -C $RADVD_CONF
sysctl -w net.ipv6.neigh.$TUNNEL.mcast_solicit=1
echo "route set for V2V communication "
Then, the last part of the script executes the binaries of the different modules to run
cargeo6 main daemon:
$GPSD -N $PositionSensorDevice &
$PositionSensor &
# in the case of test without GPS
#$GPS_SENDER -c $GPS_SENDER_CONF &
$ITSNET -c $ITSNET_CONF
Notice: In case you use radvd.conf to announce the in-vehicle prefix, here is an example
of the configuration:
interface eth0
{
AdvSendAdvert on;
# IgnoreIfMissing on;
MaxRtrAdvInterval 3;
MinRtrAdvInterval 1;
30
};
AdvIntervalOpt on;
prefix 2001:660:3013:ca04::/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
AdvPreferredLifetime 60;
AdvValidLifetime 120;
};
5.1.4
MNPP configuration :
As mentioned before, MNPP is presented as a patch to radvd 1.5 in order to advertise the
IPv6 prefix (MNP) of a router (MRs and ARs) to other nearby routers in order to avoid the
transmission of packets via the HA when routers are directly reachable over the IPv6
C2CNet link.
MNPP software is provided in the CarGeo6-v0.9.8.1 package under cargeo6-srcv0.9.8.1/mnpp/radvd-v1.5-mnpp-v0.3/.
To enable MNPP mechanism, the patched radvd software should be run in each MR or
AR at its egress interface. Configuration is done at the radvd.conf file provided in the
MNPP directory mentioned below:
# radvd configuration file (t400s)
interface tun0
{
/* enable ou disable MNPP */
MNPP on;
AdvSendAdvert on;
AdvIntervalOpt on;
};
/* the prefix to advertise */
prefix 2003:1:2:3::1/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
#normal radvd configuration
interface eth0
{
AdvSendAdvert on;
31
AdvIntervalOpt on;
prefix 2003:1:2:3::1/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
# EOF
5.2
Running CarGeo6
First, you should create a directory for scripts and configuration files for CarGeo6 based on
the models provided in ReadMe/sample-config/. Make sure to mention the path of the
directory and the path for each configuration file in startOBU.sh.
You can name the directory as cargeo6-scripts/ and it should contain at least 3
configuration files: create_wifi.sh, startOBU.sh and itsnet.conf
Once you have configured all the parameters in each file, follow these instructions to run
the software: *****replace OBU/RSU by MR/AR ********
•
./create_wifi.sh
•
Check if the wireless interface is set in the ad-hoc mode and that the ssid is "itsnet"
•
Run ./startOBU.sh –> This will start the main CarGeo6 daemon.
•
Check if IPv6 addresses for tun0 and ingress interface are correctly configured.
•
If you are using the debugging level value 5, you can see debugging messages in
real time in /var/log/itsnet.log
5.2.1
Example of V2V single hop Unicast scenario
Like shown in Figure 17, this is a possible configuration to test direct communication
between two IPv6 nodes MN1 and MN2 attached respectively to MR1 and MR2. Each
Mobile Router has static route configuration to reach nodes in the other ITS station internal
network. Radvd is used to advertise the Ipv6 ITS station internal network prefix at each
ingress interface.
32
Figure 18: Address configuration for V2V Single hop Unicast scenario
Figure 19: INRIA Mobile Routers used in the indoor
testbed
33
6.
Acknowledgment
Special thanks goes to the following people who contributed to the development, design
and experimentation of the presented software CarGeo6 (by alphabetic order):
Mr. Anouar CHEMEK
Mr. Hichem BARGAOUI
Mr. Jong-Hyouk LEE
Ms. Lamiss AMAMMOU
Mr. Lamjed BETTAIEB
Mr. Manabu TSUKADA
Mr. Thierry ERNST
Ms. Thouraya TOUKABRI
34

CarGeo6 Project

Transcription

Similar documents

Summer Work for Students Entering AP Calculus AB

COVER SHEET FOR THE CEMALA FOUNDATION GRANT PACKET

VitalQIP 8.0 PR1 slides - Alcatel

Analysis of Internet Traffic in Educational Network

IPv6.br

IPv6 in Daily Use