190 likes | 439 Views
Elmic Systems Your Partner in Internet Connectivity, Security and Mobility. Mobile IPv6 Scenarios. Network “push”: accept incoming VoIP packet-switched phone calls on your global scope IPv6 (unchanging) home address, regardless of where you are physically attached to the network
E N D
Elmic Systems Your Partner in Internet Connectivity, Security and Mobility
Mobile IPv6 Scenarios • Network “push”: accept incoming VoIP packet-switched phone calls on your global scope IPv6 (unchanging) home address, regardless of where you are physically attached to the network • Roaming between different L2 technologies: seamlessly switch between different network interfaces (I.e. move from 3G wireless or GPRS to 802.11b) while preserving your application connectivity
Roaming without Mobile IP • Without Mobile IP, devices must tear down and set up connections as they move from location to location IP address A Internet IP address B
Roaming with Mobile IP • Mobile IPv6 allows an IPv6 host to leave its home subnet, while transparently maintaining all its connections and remaining reachable to the rest of the Internet IP address A Internet IP address A & IP address B
How it works • Mobile IPv6 identifies each node by its unchanging global home address, regardless of its current point of attachment to the Internet • While a mobile node is away from home it sends information about its current location (I.e. primary care-of address) to a home agent on its home link • The home agent intercepts packets addressed to the mobile node’s home address and tunnels them to the mobile node’s current location (I.e. primary care-of address)
Home Network Mobile IPv6Triangular Routing Home Agent The mobile node’s home address is associated with the home agent HA IPv6 Network Correspondent NodeThat is communicating with the mobile node Visited Network Mobile Node With a care-of address
Home Network Mobile IPv6Route Optimization Home Agent The mobile node’s home address is associated with the home agent HA IPv6 Network Correspondent NodeThat is communicating with the mobile node Visited Network Mobile Node With a care-of address
Elmic Mobile IPv6 • Mobile Node & Correspondent Node compliant with latest IETF drafts: • draft-ietf-mobileip-ipv6-22.txt • draft-ietf-mobileip-mipv6-ha-ipsec-05.txt • At least an order of magnitude smaller than embedded Linux • Route optimization can be excluded at compile-time, further reducing code size; can also disable per application socket • MN Binding Update List and CN Binding Cache are fully integrated with existing Voyager TCP/IP performance optimizations • Includes Wi-Fi example device driver (Intersil PRISM 2.5)
Elmic Correspondent Node • Fully compliant with TAHI test suite • Supports sending Binding Refresh Request message • Compile-time macro limits size of Binding Cache • Optimized nonce and Kcn management • Optimized Binding Cache maintenance • Binding Update replay attack prevention
Elmic Mobile Node • Fully integrated with Elmic’s IPsec/IKE • Which is not a BITS implementation, rather it is tightly integrated with Voyager TCP/IP for optimal performance • Home addresses are configured by user application on special virtual home interface • Keeps them separate from care-of addresses, with regard to source address selection & packet routing • Supports Mobile Prefix Solicitation/Advertisement messages • Supports Dynamic Home Agent Address Discovery • Implements MIPv6 Generic Movement Detection with support for L2 triggers • Optional support for Eager Cell Switching • Supports Key Management Mobility Capability (K) bit in Binding Update and Binding Acknowledgement messages
Mobile Node Public APIs Powerful APIs give applications direct control over mobility: • tf6MnGetHomeAgentAddress performs Dynamic Home Agent Address Discovery for a home agent on home network • tf6MnStartMobileIp is called to specify the home agent address and start Mobile IPv6 movement detection. • tf6MnRegisterBinding creates mobility binding between a specified care-of address and a specified home address, and then initiates registration of that binding with home agent • tf6MnMoveNotify is called to notify the MN of L2 triggers (L2 and L3 handovers), as well as of a change of network interface (I.e. switch from GPRS to 802.11b) • The application can be notified of various MN events, such as status of home registration, movement detection events, etc.
Mobile Node State Machine • The mobile node state machine is very complex: • 16 events, 9 states to manage CN registration (BUL entry) • Some of the state machine design was in an earlier MIPv6 draft, but removed in draft 18. This state machine can be found in open source implementations of MIPv6 (such as KAME). However, it combines MN home registration (with HA) and CN registration (for route optimization) in the same state machine. • We have two separate state machines for mobility bindings: • One for managing home registration • The other for managing CN registration (BUL entry) • Result: an easier to understand and more robust implementation • Don’t use separate state machine to manage Return Routability • Instead this is part of our CN registration (BUL entry) state machine
'Disabled' State • Special state ‘disabled’, we transition a CN registration (BUL entry) to when we determine a specific CN does not support route optimization. To avoid DoS attacks, once we’ve successfully registered binding with specific CN, we can never enter ‘disabled’ state, so the transition to ‘disabled’ can only occur on initial registration.
Libero State Machine Design • We used free state machine design tool Libero to do our MN state machine design. It is available at: • http://www.imatix.com/html/libero/index.htm • Libero, an excellent design tool, supports customizable code generation • Implemented code generation “schema” to output state machine design in HTML format, suitable for inclusion in our design documentation. • Comes with schemas for C and AT&T “dot” formats to generate state machine transition diagrams and other programming languages.
Integration withWireless TCP • RFC-2018 + FACK (Forward Acknowledgement), RFC-2414, RFC-2481, RFC-2581, RFC-3042 • When a mobile node comes back on-link it notifies TCP of L2 handover. TCP then performs the recovery: • TCP was sending data, and was trying to retransmit: if TCP had gone into retransmission timeout during off-link condition, then upon coming back on-link TCP immediately retransmits one segment of unacknowledged data. This enables TCP to not be penalized (as much) by exponential backoff on retransmissions. Note, when TCP (re)transmits packets while MN is off-link, these packets are not queued but instead are discarded – this avoids MN queuing up duplicates of retransmitted packets to send once it is back on-link. • TCP receiver (peer TCP was sending data): the peer might have tried to send data while we were off-link, and we did not receive that data. So, TCP upon coming back on-link sends 3 duplicate ACKs to activate remote Fast Retransmit algorithm.
Elmic Emerging Products • Wireless TCP • TTCP • SSL • Turbo-Treck WebServer • Turbo-Treck SMTP and POP3 Web Servers Convergence Devices SMTP and POP3 Servers
Elmic Product Portfolio • Elmic System’s Turbo-Treck Protocol Suites include: • TCP/IP v4 and IPv4/v6 Dual Stack • IPSec/IKE • Mobile IPv6 • 802.11b Device Driver • H.323 and SIP • DHCP Client, BootP • FTP, TFTP • Telnet Server • DNS Resolver • IGMP, NAT, Auto IP • SNMPv1/v2/v3 with MIB II • MIB Compiler based on industry-standard libsmi Wireless Medical communication Device Printers Set-top-Box Transportation Tracking Device PCI Network Storage