OMNeT++ Community Summit, 2015 Beyond INET 3.0 IBM Research - - PowerPoint PPT Presentation

OMNeT++ Community Summit, 2015 Beyond INET 3.0 IBM Research - Zurich, Switzerland – September 3 - 4, 2015 Levente Mészáros

Overview Network node architecture refactoring Cross-layer communication and optimization Mobility refactoring

Real World Network Node Architecture ● Real world Application applications often Kernel Socket API use different kind of Transport Layer sockets and protocols TCP UDP simultaneously Network Layer IPv4 IPv6 Link Layer Ethernet 802.11 PPP VLAN

Current Network Node Architecture 1 ● Nodes currently have tcpApp[] udpApp[] pingApp[] tunApp[] separate submodule vectors for different kinds of applications tcp udp ● What if an application wants to use TCP and UDP simultaneously? ipv4 eth[] ppp[] wlan[] tun[]

Current Network Node Architecture 2 ● TUN application are tcpApp[] udpApp[] pingApp[] tunApp[] currently connected to ? TUN interfaces only ● TUN applications are tcp udp useless without being connected to other protocols ipv4 ● Should we connect them to TCP, UDP, eth[] ppp[] IPv4, or all of them? wlan[] tun[]

Current Network Node Architecture 3 ● Dual network stack tcpApp[] udpApp[] pingApp[] tunApp[] needs extra dispatch mechanism towards network protocols tcp udp ● Where should the dispatch mechanism ? be? ipv4 ipv6 ● In general, protocols of adjacent OSI layers eth[] ppp[] should be in many-to- wlan[] tun[] many relationship

TCP Applications ● Limitation: TCP tcpApp[] udpApp[] pingApp[] tunApp[] applications exclusively and directly connect to TCP tcp udp ● Dispatch from TCP towards applications is ipv4 built into TCP ● Dispatch from IPv4 eth[] ppp[] towards TCP is built wlan[] tun[] into IPv4

UDP Application ● Limitations: UDP tcpApp[] udpApp[] pingApp[] tunApp[] applications exclusively and directly connect to UDP tcp udp ● Dispatch from UDP towards applications is ipv4 built into UDP ● Dispatch from IPv4 eth[] ppp[] towards UDP is built wlan[] tun[] into IPv4

Ping Application ● Network layers tcpApp[] udpApp[] pingApp[] tunApp[] currently have separate gates for ping applications (pingIn, pingOut) tcp udp ● IPv4 needs to do special ICMP packet ipv4 handling to reach ping applications eth[] ppp[] wlan[] tun[]

New Network Node Architecture app[] ● Added separate dispatcher packet dispatchers between OSI layers tcp udp ● Eliminated dispatch mechanisms from dispatcher individual protocols ipv4 ipv6 dispatcher eth[] ppp[] wlan[] tun[]

Protocol Registration Mechanism app[] ● Protocols have to dispatcher register themselves in the dispatcher (protocolId, gate) tcp udp registers dispatcher ipv4 ipv6 dispatcher eth[] ppp[] wlan[] tun[]

Interface Registration Mechanism app[] ● Interfaces also have to dispatcher register themselves in the dispatcher (interfaceId, gate) tcp udp dispatcher ipv4 ipv6 dispatcher eth[] ppp[] registers wlan[] tun[]

Simpler Network Node Architectures ● Dispatchers are app[] app[] app optional dispatcher dispatcher ● Modules can still udp be organized in udp udp other ways ipv4 ipv4 ipv4 eth dispatcher eth eth[]

IPv4 Network Layer Architecture ● IPv4 network layer also uses a dispatcher internally icmp igmp ● ARP and IP don't exchange dispatcher packets, thus no connection between them ip arp

TCP Application app[] ● TCP application still dispatcher uses a TCPSocket to send and receive packets tcp udp ● Dispatcher learns dispatcher where sockets are, based on socket open ipv4 ipv6 and close commands dispatcher eth[] ppp[] wlan[] tun[]

UDP Application app[] ● UDP application still dispatcher uses a UDPSocket to send and receive packets tcp udp ● Dispatcher routes dispatcher packets based on the destination protocol ipv4 ipv6 ● Destination protocol is dispatcher determined from control info and packet eth[] ppp[] class wlan[] tun[]

Ping Application app[] ● Ping application uses dispatcher a raw IPv4Socket to send and receive ICMP echo packets tcp udp ● There's no special dispatcher network layer gate for ping applications ipv4 ipv6 dispatcher eth[] ppp[] wlan[] tun[]

Ethernet Application app[] ● Ethernet applications dispatcher can directly communicate using ethernet sockets tcp udp dispatcher ipv4 ipv6 dispatcher eth[] ppp[] wlan[] tun[]

MANET Routing Application app[] routing[] ● MANET routers now dispatcher share the same network node architecture tcp udp ● Routing application dispatcher can be replaced from INI file ipv4 ipv6 ● Routing applications dispatcher can still use all kinds of sockets eth[] ppp[] wlan[] tun[]

Tunnel Application app[] ● Tunnel application dispatcher simultaneously opens a TUN device and a raw IPv4Socket tcp udp dispatcher ipv4 ipv6 eth[] ppp[] wlan[] tun[]

Tunnel Application 1 app[] ● Node receives packet dispatcher from network tcp udp dispatcher ipv4 ipv6 eth[] ppp[] wlan[] tun[]

Tunnel Application 2 app[] ● Node receives packet dispatcher from network ● IPv4 forwards packet tcp udp to TUN interface dispatcher ipv4 ipv6 eth[] ppp[] wlan[] tun[]

Tunnel Application 3 app[] ● Node receives packet dispatcher from network ● IPv4 forwards packet tcp udp to TUN interface dispatcher ● Application receives packet from TUN ipv4 ipv6 interface eth[] ppp[] wlan[] tun[]

Tunnel Application 4 app[] ● Node receives packet dispatcher from network ● IPv4 forwards packet tcp udp to TUN interface dispatcher ● Application receives packet from TUN ipv4 ipv6 interface ● Application sends packet inside another eth[] eth[] ppp[] ppp[] IPv4 packet wlan[] tun[] tun[]

Standard Host 1

Standard Host 2

Overview Network node architecture refactoring Cross-layer communication and optimization Mobility refactoring

Cross-layer design Application Layer ● Quality of ● Link service quality Transport Layer parameters indication Network Layer ● Resource ● Physical optimization channel Link Layer parameters conditions Physical Layer

Current Cross-Layer Communication Applications send UDP packets on a specific interface by ● setting the interfaceId in UDPControlInfo Currently applications cannot even specify type of service ● parameter to control the quality of service functionality

New Cross-Layer Communication ● As packets go through the layers Application Layer ● Packets ● Packets Transport Layer collect collect various various Network Layer request indication tags tags Link Layer Physical Layer

Tag Examples QualityOfServiceRequest ● tos InterfaceIndication ● id InterfaceRequest ● id MACAddressIndication ● source Packet MACAddressRequest ● destination ● source ● destination ReceptionIndication ● power TransmissionRequest ● channel ● power ● channel

Overview Network node architecture refactoring Cross-layer communication and optimization Mobility refactoring

Current Mobility Models 1 There are mobility models ● that do static positioning There are mobility models ● that move nodes around How to combine these ● models?

Current Mobility Models 2 There are group mobility ● models with built-in differences for individual nodes How to reuse existing models ● for group mobility? How to model a docking ship ● with passengers moving around?

Current Mobility Models 3 Sometimes positioning and ● orientation are best expressed in separate mobility models (e.g. satellites) Sometimes elevation may be ● derived from the position on the surface of the Earth (e.g. a moving vehicle)

Mobility Superposition Support combining different positioning and ● orientation models using superposition Support start/end time (limits) for mobility models ● superposition positioning & orientation group initial perturbation time individual

Coordinate Systems ● Abstract Cartesian ● Geographic coordinate system coordinate system such as WGS-84 ● How to express coordinates inside buildings around a city? ● How to express antenna orientation of a vehicle separately?

Questions and Answers Thank you for your kind attention! IBM Research - Zurich, Switzerland – September 3 - 4, 2015 Levente Mészáros