Chapter6MobileIPandTCP4Slides PDF

Overview
Chapter 6 • Network Protocols / Mobile IP

–
–
Motivation
Data transfer
MOBILE –
–
–
Encapsulation
Problems
DHCP
IP AND TCP • Mobile Transport Layer / TCP

– Motivation
– Various TCP mechanisms
Distributed
Computing
Mobile Computing
Group
Summer 2004
Distributed Computing Group MOBILE COMPUTING R. Wattenhofer 6/2
Motivation for Mobile IP Requirements to Mobile IP (RFC 2002)
• Routing • Compatibility
– based on IP destination address, network prefix (e.g. 129.132.13) – support of the same layer 2 protocols as IP
determines physical subnet – no changes to current end-systems and routers required
– change of physical subnet implies change of IP address to have a – mobile end-systems can communicate with fixed systems
topological correct address (standard IP) or needs special entries in the
• Transparency
routing tables
– mobile end-systems keep their IP address
• Changing the IP-address?
– continuation of communication after interruption of link possible
– adjust the host IP address depending on the current location
– point of connection to the fixed network can be changed
– almost impossible to find a mobile system, DNS updates are too slow
• Efficiency and scalability
– TCP connections break
– only little additional messages to the mobile system required
– security problems
(connection typically via a low bandwidth radio link)
• Change/Add routing table entries for mobile hosts? – world-wide support of a large number of mobile systems
– worldwide!
• Security
– does not scale with the number of mobile hosts and frequent changes in
– authentication of all registration messages
their location
Distributed Computing Group MOBILE COMPUTING R. Wattenhofer 6/3 Distributed Computing Group MOBILE COMPUTING R. Wattenhofer 6/4
Example network Data transfer to the mobile system
HA HA
2
MN MN
router
home network mobile end-system home network 3 receiver

Internet Internet
(physical home network foreign
for the MN)
FA foreign FA
network network
router
1. Sender sends to the IP address of MN,
(current physical network
HA intercepts packet (proxy ARP)
for the MN) 1 2. HA tunnels packet to COA, here FA,
CN CN
by encapsulation
3. FA forwards the packet
end-system router sender to the MN
Data transfer from the mobile system Terminology
HA • Mobile Node (MN)

1 MN – system (node) that can change the point of connection
to the network without changing its IP address
• Home Agent (HA)
– system in the home network of the MN, typically a router
home network sender – registers the location of the MN, tunnels IP datagrams to the COA
Internet • Foreign Agent (FA)
FA foreign – system in the current foreign network of the MN, typically a router
network – typically the default router for the MN
• Care-of Address (COA)
1. Sender sends to the IP address – address of the current tunnel end-point for the MN (at FA or MN)
of the receiver as usual, – actual location of the MN from an IP point of view
CN
FA works as default router – can be chosen, e.g., via DHCP
• Correspondent Node (CN)
receiver
Overview Network integration
COA
• Agent Advertisement
router
home router
FA
MN – HA and FA periodically send advertisement messages into their
network HA
physical subnets
foreign
Internet network
– MN listens to these messages and detects, if it is in the home or a
foreign network (standard case for home network)
– MN reads a COA from the FA advertisement messages
CN router • Registration (always limited lifetime!)
– MN signals COA to the HA via the FA, HA acknowledges via FA to MN
– these actions have to be secured by authentication
3.
router
home router
2. FA
MN • Advertisement
network HA
4.
– HA advertises the IP address of the MN (as for fixed systems), i.e.
foreign
Internet network
standard routing information
– routers adjust their entries, these are stable for a longer time (HA
1. responsible for a MN over a longer period of time)
CN router – packets to the MN are sent to the HA,
– independent of changes in COA/FA
Agent advertisement Registration
• COA @ FA: • COA @ MN:

0 7 8 15 16 23 24 31
type code checksum
#addresses addr. size lifetime MN r
egis FA HA MN r HA
router address 1 egis
preference level 1 req tration
ues re que
tratio
n
t st
router address 2 regi
preference level 2 s
requ tration
est
... n
tratio
regis
ly
n rep
type length sequence number tratio
registration lifetime R B H F MG V reserved regis
ly t
rep
COA 1 n
COA 2 tratio
regis
p ly
... re
Mobile IP registration request & reply Tunneling and Encapsulation
0 7 8 15 16 23 24 31
type = 1 S B DMG V rsv lifetime
home address
home agent original IP header original data
COA
identification
new IP header new data
extensions . . .
outer header inner header original data
0 7 8 15 16 31
type = 3 code lifetime
home address
home agent
identification
extensions . . .
IP-in-IP Encapsulation Minimal Encapsulation
• Mandatory in RFC 2003 • optional

• tunnel between HA and COA • avoids repetition of identical fields such as TTL, IHL, version, TOS
• only applicable for unfragmented packets, no space left for fragment
identification
ver. IHL TOS length

IP identification flags fragment offset ver. IHL TOS length
TTL IP-in-IP IP checksum IP identification flags fragment offset
IP address of HA TTL min. encap. IP checksum
Care-of address COA IP address of HA
ver. IHL TOS length care-of address COA
IP identification flags fragment offset lay. 4 protoc. S reserved IP checksum
TTL lay. 4 prot. IP checksum IP address of MN
IP address of CN IP address of CN (only if S=1)
IP address of MN TCP/UDP/ ... payload
TCP/UDP/ ... payload
Generic Routing Encapsulation Optimization of packet forwarding
original
original data
header
• Triangular Routing
outer header
GRE original
original data – sender sends all packets via HA to MN
header header
– higher latency and network load
new header new data • “Solutions”
ver. IHL TOS length – sender learns the current location of MN
IP identification flags fragment offset
TTL GRE IP checksum
– direct tunneling to this location
IP address of HA – HA informs a sender about the location of MN
Care-of address COA
C R K S s rec. rsv. ver. protocol – big security problems
checksum (optional) offset (optional)
key (optional) • Change of FA
sequence number (optional)
routing (optional) – packets on-the-fly during the change can be lost
ver. IHL TOS length
IP identification flags fragment offset – new FA informs old FA to avoid packet loss, old FA now forwards
TTL lay. 4 prot. IP checksum remaining packets to new FA
IP address of CN
IP address of MN – this information also enables the old FA to release resources for the MN
TCP/UDP/ ... payload
Change of foreign agent Data transfer from the mobile system

CN HA FAold FAnew MN
request HA
update
ACK
1 MN
data data
MN changes
location
registration home network sender
registration
Internet
update
ACK FA foreign
data network
data data
warning
update Problems:
ACK • Firewall at CN
CN
data
data
• TTL
t receiver • Multicast
Reverse tunneling (RFC 2344) Mobile IP with reverse tunneling
HA
• Router accept often only “topologically correct“ addresses (firewall!)
2
MN – a packet from the MN encapsulated by the FA is now topologically
correct
– furthermore multicast and TTL problems solved (TTL in the home
network correct, but MN is too far away from the receiver)
home network sender • Reverse tunneling does not solve
1
Internet – problems with firewalls, the reverse tunnel can be abused to circumvent
security mechanisms (tunnel hijacking)
FA foreign
network – optimization of data paths, i.e. packets will be forwarded through the
tunnel via the HA to a sender (double triangular routing)
1. MN sends to FA • Reverse tunneling is backwards compatible
3 2. FA tunnels packets to HA – the extensions can be implemented easily and cooperate with current
CN by encapsulation implementations without these extensions
3. HA forwards the packet to the
receiver (standard case)
receiver
Mobile IP and IPv6 Problems with mobile IP
• Mobile IP was developed for IPv4, but IPv6 simplifies the protocols • Security
– security is integrated and not an add-on, authentication of registration is – authentication with FA problematic, for the FA typically belongs to
included another organization
– COA can be assigned via auto-configuration (DHCPv6 is one – no protocol for key management and key distribution has been
candidate), every node has address auto-configuration standardized in the Internet
– no need for a separate FA, all routers perform router advertisement – patent and export restrictions
which can be used instead of the special agent advertisement • Firewalls
– MN can signal a sender directly the COA, sending via HA not needed in – typically mobile IP cannot be used together with firewalls, special set-
this case (automatic path optimization) ups are needed (such as reverse tunneling)
– „soft“ hand-over, i.e. without packet loss, between two subnets is • QoS
supported – many new reservations in case of RSVP
• MN sends the new COA to its old router
– tunneling makes it hard to give a flow of packets a special treatment
• the old router encapsulates all incoming packets for the MN and forwards needed for the QoS
them to the new COA
• authentication is always granted • Security, firewalls, QoS etc. are topics of current research and
discussions!
IP Micro-mobility support Cellular IP
• Micro-mobility support: • Operation:

– Efficient local handover inside a foreign domain – „CIP Nodes“ maintain routing Internet
without involving a home agent entries (soft state) for MNs
– Reduces control traffic on backbone – Multiple entries possible Mobile IP
– Especially needed in case of route optimization – Routing entries updated based
CIP Gateway
on packets sent by MN data/control
• CIP Gateway: packets
• Example approaches:
– Mobile IP tunnel endpoint from MN 1
– Cellular IP
– Initial registration processing
– HAWAII
– Hierarchical Mobile IP (HMIP)
• Security provisions:
BS BS BS
– all CIP Nodes share packets from
„network key“ MN2 to MN 1
• Important criteria: – MN key: MD5(net key, IP addr)
Security Efficiency, Scalability, Transparency, Manageability MN1 MN2
– MN gets key upon registration
Cellular IP: Security Cellular IP: Other issues
• Advantages: • Advantages:
– Initial registration involves authentication of MNs
– Simple and elegant architecture
and is processed centrally by CIP Gateway
– All control messages by MNs are authenticated – Mostly self-configuring (little management needed)
– Replay-protection (using timestamps) – Integration with firewalls / private address support possible
• Potential problems: • Potential problems:

– MNs can directly influence routing entries
– Not transparent to MNs (additional control messages)
– Network key known to many entities
(increases risk of compromise) – Public-key encryption of MN keys may be a problem
for resource-constrained MNs
– No re-keying mechanisms for network key
– No choice of algorithm (always MD5, prefix+suffix mode) – Multiple-path forwarding may cause inefficient use of available
bandwidth
– Proprietary mechanisms (not, e.g., IPSec AH)
HAWAII HAWAII: Security
• Operation: • Advantages:
– MN obtains co-located COA 1 Internet – Mutual authentication and C/R extensions mandatory
and registers with HA 2 HA
– Only infrastructure components can influence routing entries
– Handover: MN keeps COA,
Backbone
new BS answers Reg. Request 3
Router • Potential problems:
and updates routers 4
– MN views BS as foreign agent – Co-located COA raises DHCP security issues
Crossover (DHCP has no strong authentication)
Router
– Decentralized security-critical functionality
• Security provisions: 2 (Mobile IP registration processing during handover)
– MN-FA authentication mandatory 4 Mobile IP in base stations
– Challenge/Response Extensions – Authentication of HAWAII protocol messages unspecified
BS BS BS DHCP
mandatory (potential attackers: stationary nodes in foreign network)
Server
Mobile IP – MN authentication requires PKI or AAA infrastructure
3
MN MN DHCP
1
HAWAII: Other issues Hierarchical Mobile IPv6 (HMIPv6)
• Operation:
• Advantages:
– Network contains mobility anchor point Internet
– Mostly transparent to MNs (MAP) HA
(MN sends/receives standard Mobile IP messages) • mapping of regional COA (RCOA) to link
COA (LCOA) RCOA
– Explicit support for dynamically assigned home addresses – Upon handover, MN informs
MAP only MAP
• gets new LCOA, keeps RCOA
• Potential problems: – HA is only contacted if MAP
changes binding AR AR
– Mixture of co-located COA and FA concepts may not be update
supported by some MN implementations LCOAnew LCOAold
• Security provisions:
– No private address support possible – no HMIP-specific
because of co-located COA MN MN
security provisions
– binding updates should be
authenticated
Hierarchical Mobile IP: Security Hierarchical Mobile IP: Other issues
• Advantages: • Advantages:
– Local COAs can be hidden, – Handover requires minimum number
which provides some location privacy of overall changes to routing tables
– Direct routing between CNs sharing the same link is possible (but might – Integration with firewalls / private address support possible
be dangerous)
• Potential problems: • Potential problems:
– Decentralized security-critical functionality – Not transparent to MNs

(handover processing) in mobility anchor points – Handover efficiency in wireless mobile scenarios:
– MNs can (must!) directly influence routing entries via binding updates • Complex MN operations
(authentication necessary)
• All routing reconfiguration messages
sent over wireless link
DHCP: Dynamic Host Configuration Protocol DHCP - protocol mechanisms

server client server
(not selected) initialization (selected)
• Application
– simplification of installation and maintenance of networked computers DHCPDISCOVER DHCPDISCOVER
determine the determine the
– supplies systems with all necessary information, such as IP address, configuration configuration
DNS server address, domain name, subnet mask, default router etc. DHCPOFFER DHCPOFFER
– enables automatic integration of systems into an Intranet or the Internet, collection of replies
can be used to acquire a COA for Mobile IP time
selection of configuration
• Client/Server-Model
– the client sends via a MAC broadcast a request to the DHCP server DHCPREQUEST DHCPREQUEST
(reject) (options) confirmation of
(might be via a DHCP relay) configuration
DHCPDISCOVER DHCPACK
DHCPDISCOVER initialization completed
server client release

DHCPRELEASE delete context
client relay
DHCP characteristics TCP Overview
• Server • Transport control protocols typically designed for

– several servers can be configured for DHCP, coordination not yet – Fixed end-systems in wired networks
standardized (i.e., manual configuration) • Research activities
• Renewal of configurations – Performance
– IP addresses have to be requested periodically, simplified protocol – Congestion control
• Options – Efficient retransmissions
– available for routers, subnet mask, NTP (network time protocol)
timeserver, SLP (service location protocol) directory, • TCP congestion control
DNS (domain name system)
– packet loss in fixed networks typically due to
• Security problems (temporary) overload situations
– no authentication of DHCP information specified – router have to discard packets as soon as the buffers are full
– TCP recognizes congestion only indirectly via missing
acknowledgements, retransmissions unwise, they would
only contribute to the congestion and make it even worse
TCP slow-start TCP fast retransmit/fast recovery
• sender calculates a congestion window for a receiver • TCP sends an acknowledgement only after receiving a packet
• start with a congestion window size equal to one segment • If a sender receives several acknowledgements for the same
• exponential increase* of the congestion window up to the packet, this is due to a gap in received packets at the receiver
congestion threshold, then linear increase • Sender can retransmit missing packets (fast retransmit)
• missing acknowledgement causes the reduction of the congestion
threshold to one half of the current congestion window • Also, the receiver got all packets up to the gap and is actually
• congestion window starts again with one segment receiving packets
• Therefore, packet loss is not due to congestion, continue with
current congestion window (fast recovery)
*slow-start vs. exponential increase: window is increased by one for
each acknowledgement, that is, 1 ! 2 ! 4 ! 8 … In other words, the • In the following simplied analysis, we do consider neither fast
slow-start mechanism is rather a “quick-start”. retransmit nor fast recovery.
TCP on lossy (wireless) link Simple analysis model for lossy TCP
• Without fast retransmit/fast recovery • Segment loss probability q = 1–p

• We are interested in the throughput T
[Lakshman/Madhow]
• If there are no losses (and all ACKs are received in time):
– Number of segments S first doubles up to threshold W
(slow start phase)
– Number of segments S is incremented after S successful ACKs
– At some point we reach the bandwidth of the channel B
• If there is a loss
– We go back to S = 1
Very high loss probability High loss probability
Simple analysis of lossy TCP Lossy TCP: Graphical Interpretation
• For not too high error probability q we are usually in the congestion •
mode (that is: not the slow start mode).
• The expected number of successful transmission E before we get • Plot of T(p), with B = 50
an error is
• Note that 1% faulty
transmissions is enough to
• In the equilibrium, we are in the states 1, 2, 3, …, S-1, S, and then degrade the throughput to
back to 1 because we have a missing ACK, that is, we have about 14% of the bandwidth.
1+2+…+S ¼ S 2/2 successful transmissions. • 10% error rate gives about
4% of possible bandwidth.
• • The higher the bandwidth,
the worse the relative loss.
Mobility and TCP Early Approach: Indirect TCP (I-TCP)
• TCP assumes congestion if packets are dropped • segments the connection

– typically wrong in wireless networks, here we often have packet loss – no changes to the TCP protocol for hosts connected to the wired
due to transmission errors Internet, millions of computers use (variants of) this protocol
– furthermore, mobility itself can cause packet loss, if e.g. a mobile node – optimized TCP protocol for mobile hosts
roams from one access point (e.g. foreign agent in Mobile IP) to another – splitting of the TCP connection at, e.g., the foreign agent into two
while there are still packets in transit to the wrong access point and TCP connections, no real end-to-end connection any longer
forwarding is not possible – hosts in the fixed part of the net do not notice the characteristics of the
wireless part
• The performance of an unchanged TCP degrades severely
mobile host
– however, TCP cannot be changed fundamentally due to the large base access point
of installation in the fixed network, TCP for mobility has to remain (foreign agent) „wired“ Internet
compatible
– the basic TCP mechanisms keep the whole Internet together
„wireless“ TCP standard TCP
I-TCP socket and state migration Indirect TCP Advantages and Disadvantages
+ no changes in the fixed network necessary, no changes for the

hosts (TCP protocol) necessary, all current optimizations to TCP
still work
+ transmission errors on the wireless link do not propagate into the
access point1 fixed network
+ simple to control, mobile TCP is used only for one hop, between a
foreign agent and a mobile host
socket migration
and state transfer + therefore, a very fast retransmission of packets is possible, the
Internet
short delay on the mobile hop is known
– loss of end-to-end semantics, an acknowledgement to a sender
does now not any longer mean that a receiver really got a packet,
access point2 foreign agents might crash
mobile host – higher latency possible due to buffering of data with the foreign
agent and forwarding to a new foreign agent
– high trust at foreign agent; end-to-end encryption impossible
Early Approach: Snooping TCP Snooping TCP
• Transparent extension of TCP within the foreign agent • Data transfer to the mobile host
– buffering of packets sent to the mobile host – FA buffers data until it receives ACK of the MH, FA detects packet loss
– lost packets on the wireless link (both directions!) will be retransmitted via duplicated ACKs or time-out
immediately by the mobile host or foreign agent, respectively (so called – fast retransmission possible, transparent for the fixed network
“local” retransmission) • Data transfer from the mobile host
– the foreign agent therefore “snoops” the packet flow and recognizes – FA detects packet loss on the wireless link via sequence numbers, FA
acknowledgements in both directions, it also filters ACKs answers directly with a NACK to the MH
– changes of TCP only within the foreign agent – MH can now retransmit data with only a very short delay
• Integration of the MAC layer
local retransmission – MAC layer often has similar mechanisms to those of TCP
foreign
agent – thus, the MAC layer can already detect duplicated packets due to
„wired“ Internet retransmissions and discard them
• Problems
snooping of ACKs buffering of data
correspondent
– snooping TCP does not isolate the wireless link as good as I-TCP
mobile
host host – snooping might be useless depending on encryption schemes
end-to-end TCP connection
Early Approach: Mobile TCP Fast retransmit/fast recovery

• Special handling of lengthy and/or frequent disconnections
• M-TCP splits as I-TCP does • Problem: Change of foreign agent often results in packet loss
– unmodified TCP fixed network to supervisory host (SH) – TCP reacts with slow-start although there is no congestion
– optimized TCP SH to MH
• Supervisory host • Solution: Forced fast retransmit
– no caching, no retransmission – as soon as the mobile host has registered with a new foreign agent, the
– monitors all packets, if disconnection detected MH sends (three) duplicated acknowledgements on purpose
• set sender window size to 0 – this forces the fast retransmit mode at the communication partners
• sender automatically goes into persistent mode – additionally, the TCP on the MH is forced to continue sending with the
– old or new SH re-open the window actual window size and not to go into slow-start after registration
+ maintains end-to-end semantics, supports disconnection, no + simple changes result in significant higher performance
buffer forwarding – what a hack…
– does not solve problem of bad wireless link, only disconnections
– adapted TCP on wireless link; new software needed
Transmission/time-out freezing Selective retransmission
• Mobile hosts can be disconnected for a longer time • TCP acknowledgements are often cumulative
– no packet exchange possible, e.g., in a tunnel, disconnection due to – ACK n acknowledges correct and in-sequence receipt of packets up to n
overloaded cells or multiplex with higher priority traffic – if single packets are missing quite often a whole packet sequence
– TCP disconnects after time-out completely beginning at the gap has to be retransmitted (go-back-n), thus wasting
bandwidth, especially if the bandwidth-delay product is high.
• TCP freezing
– MAC layer is often able to detect interruption in advance • Selective retransmission as one solution
– MAC can inform TCP layer of upcoming loss of connection – RFC2018 allows for acknowledgements of single packets, not only
– TCP stops sending, but does now not assume a congested link acknowledgements of in-sequence packet streams without gaps
– MAC layer signals again if reconnected – sender can now retransmit only the missing packets
+ scheme is independent of data + much higher efficiency

– TCP on mobile host has to be changed, mechanism depends on – more complex software in a receiver, more buffer needed at the
MAC layer receiver
Transaction oriented TCP Comparison of different approaches for a “mobile” TCP

Approach Mechanism Advantages Disadvantages
Indirect TCP splits TCP connection isolation of wireless loss of TCP semantics,
• TCP phases into two connections link, simple higher latency at
– connection setup, data transmission, connection release handover
Snooping TCP “snoops” data and transparent for end-to- problematic with
– using 3-way-handshake needs 3 packets for setup and release, acknowledgements, local end connection, MAC encryption, bad isolation
respectively retransmission integration possible of wireless link
– thus, even short messages need a minimum of 7 packets! M-TCP splits TCP connection, Maintains end-to-end Bad isolation of wireless
chokes sender via semantics, handles link, processing
• Transaction oriented TCP window size long term and frequent overhead due to
– RFC1644, T-TCP, describes a TCP version to avoid this overhead disconnections bandwidth management
Fast retransmit/ avoids slow-start after simple and efficient mixed layers, not
– connection setup, data transfer and connection release can be fast recovery roaming transparent
combined Transmission/ freezes TCP state at independent of content changes in TCP
time-out freezing disconnect, resumes or encryption, works for required, MAC
– thus, only 2 or 3 packets are needed after reconnection longer interrupts dependant
Selective retransmit only lost data very efficient slightly more complex
retransmission receiver software, more
+ Efficiency buffer needed
– Requires changed TCP Transaction combine connection Efficient for certain changes in TCP
oriented TCP setup/release and data applications required, not transparent
transmission
[Schiller]
Recent work Recent work
0.93 ⋅ MSS • Performance enhancing proxies (PEP, RFC 3135)

• Initial research work BW ≤ Mobile system
– Indirect TCP, Snoop TCP, M-TCP, T/TCP, RTT ⋅ p – Transport layer
SACK, Transmission/time-out freezing, … • Local retransmissions and acknowledgements
• max. TCP BandWidth wireless
• TCP over 2.5/3G wireless networks • Max. Segment Size – Additionally on the application layer
• Round Trip Time • Content filtering, compression, picture downscaling
– Fine tuning today’s TCP • loss probability PEP
• E.g., Internet/WAP gateways
– Learn to live with
• Web service gateways?
• Data rates: 64 kbit/s up, 115-384 kbit/s down; asymmetry: 3-6, but also up to
1000 (broadcast systems), periodic allocation/release of channels – Big problem: breaks end-to-end semantics
• High latency, high jitter, packet loss • Disables use of IP security
• Choose between PEP and security! Internet
– Suggestions
• Large (initial) sending windows, large maximum transfer unit, selective • More open issues
acknowledgement, explicit congestion notification, time stamp, no header – RFC 3150 (slow links)
compression • Recommends header compression, no timestamp
– Already in use – RFC 3155 (links with errors) Comm. partner
• i-mode running over FOMA • States that explicit congestion notification cannot be used
• WAP 2.0 (“TCP with wireless profile”)
– In contrast to 2.5G/3G recommendations!

Chapter6MobileIPandTCP4Slides PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter6MobileIPandTCP4Slides PDF

Uploaded by

Copyright:

Available Formats

Overview

Chapter 6 • Network Protocols / Mobile IP

IP AND TCP • Mobile Transport Layer / TCP

Distributed Computing Group MOBILE COMPUTING R. Wattenhofer 6/2

Motivation for Mobile IP Requirements to Mobile IP (RFC 2002)

home network mobile end-system home network 3 receiver

Data transfer from the mobile system Terminology

HA • Mobile Node (MN)

Agent advertisement Registration

• COA @ FA: • COA @ MN:

IP-in-IP Encapsulation Minimal Encapsulation

• Mandatory in RFC 2003 • optional

ver. IHL TOS length

Change of foreign agent Data transfer from the mobile system

Mobile IP and IPv6 Problems with mobile IP

• Micro-mobility support: • Operation:

Cellular IP: Security Cellular IP: Other issues

• Potential problems: • Potential problems:

HAWAII: Other issues Hierarchical Mobile IPv6 (HMIPv6)

• Potential problems: • Potential problems:

– Decentralized security-critical functionality – Not transparent to MNs

DHCP: Dynamic Host Configuration Protocol DHCP - protocol mechanisms

DHCPDISCOVER initialization completed

server client release

• Server • Transport control protocols typically designed for

TCP slow-start TCP fast retransmit/fast recovery

• Without fast retransmit/fast recovery • Segment loss probability q = 1–p

Simple analysis of lossy TCP Lossy TCP: Graphical Interpretation

• TCP assumes congestion if packets are dropped • segments the connection

„wireless“ TCP standard TCP

+ no changes in the fixed network necessary, no changes for the

Early Approach: Mobile TCP Fast retransmit/fast recovery

+ scheme is independent of data + much higher efficiency

Transaction oriented TCP Comparison of different approaches for a “mobile” TCP

0.93 ⋅ MSS • Performance enhancing proxies (PEP, RFC 3135)

You might also like