|
|
|
Introduction and History |
|
Data in Wireless Cellular Systems |
|
Data in Wireless Local Area Networks |
|
Internet Protocols |
|
Routing and Ad-Hoc Networks |
|
TCP over Wireless Link |
|
Services and Service Discovery |
|
System Support for Mobile Applications |
|
|
|
|
TCP/IP is a collection of protocols that
facilitates communications among servers and terminals that are hooked to
different networks |
|
|
|
|
The TCP and IP are only two of several
protocols, but the name stuck !! |
|
They are the most important ones |
|
|
|
|
|
|
|
|
Who develops protocols such as TCP/IP, Mobile
IP, ...? |
|
“standardized” by action of IETF |
|
IETF has over 70 working groups considering a
broad range of protocol proposals for the Internet, tries to identify
protocol needs in advance (?) |
|
IETF works with Internet Assigned Number
Authority (IANA) to keep track of protocol number assignments and address
allocations as required by various Internet protocols |
|
each protocol specified by a “Request for
Comments” |
|
working groups develop new RFCs by publishing
Internet Drafts, building prototypes, and encouraging public debate |
|
operational model: rough consensus and running
code |
|
|
|
|
Layers are logical steps with well-defined
purposes: OSI reference model |
|
We are mainly interested in lower 4 layers: (1)
Physical, (2) Link, (3) Network, (4) Transport |
|
|
|
|
The network layer is the domain of the Internet
Protocol (IP) |
|
The IP guides user's datagrams across several
networks |
|
The IP is "connectionless". The data is guided by addresses rather
than fixed pre-determine connections |
|
|
|
|
|
|
The lines in the figure represent separate
networks. |
|
The circles represent IP routing points. |
|
The Hosts are connected to their own LAN's or
Internet Service Providers (ISP) |
|
|
|
|
|
|
|
|
|
The address field of IPv4 is 32-bit long |
|
It consists of three parts: |
|
<class> <network ID> <host ID> |
|
|
|
|
|
|
|
Map IP addresses into physical addresses |
|
destination host |
|
next hop router |
|
Techniques |
|
encode physical address in host part of IP
address |
|
table-based |
|
ARP |
|
table of IP to physical address bindings |
|
broadcast request if IP address not in table |
|
target machine responds with its physical
address |
|
table entries are discarded if not refreshed |
|
|
|
|
|
Notes on ARP table management: |
|
table entries time out in about 10 minutes |
|
update table with source when you are the target
(reverse learning) |
|
update table entry timeout if table already has
an entry |
|
do not refresh table entries upon reference |
|
|
|
|
There are number of tasks that IP does not
perform. These tasks are done by a
helper protocol called: Internet Control Message Protocol (ICMP) |
|
The primary task of ICMP is to report routing
errors and anomalies back to the source |
|
ICMP also tests the reachability of a node
across the internet |
|
It also provide ways to increase routing
efficiency |
|
It also informs the source that a given datagram
has exceeded its allocated time |
|
|
|
|
Extended addressing capabilities: 128-bit
address field and other improvements. |
|
Simplified header format: Some fields of IPv4
are dropped or turned into options |
|
Improved support for extensions and options:
flexibility and ability to introduce new options |
|
Flow labeling |
|
Authentication and privacy |
|
|
|
|
|
|
|
mobile computing is on the rise |
|
wireless communications technologies widely
available |
|
IEEE 802.11 finally standardized |
|
MAC layer protocol with lots of features: power
saving, ad-hoc networking support, maybe even isochronous communication |
|
cellular telephony everywhere |
|
AMPS and CDPD |
|
GSM |
|
wireless indoor equipment (IR and RF) such as
Lucent (formerly AT & T) WaveLAN or Proxim |
|
people expect the same from both desktop and
laptop |
|
high-resolution color display |
|
200 MHz processor |
|
multi-gigabyte disk |
|
with a docking station, the laptop is the
desktop |
|
|
|
|
|
wireless communication and powerful portable
devices lead to new computing paradigms: |
|
mobile computing |
|
ubiquitous computing |
|
nomadic computing |
|
at the same time, the Internet and in particular
the Web, are growing exponentially |
|
timely news (and lots of it), user-friendly(?),
lots of pretty pictures (70%-80% of Internet traffic is WWW traffic) |
|
the “Information Superhighway” is where people
want to be |
|
certainly strong support by national governments
to build and maintain this infrastructure |
|
mobile computing seen as “on-ramp” to this
infrastructure |
|
|
|
|
|
What model of mobility |
|
“nomadic clients”: DHCP or similar solutions
enough |
|
Truly mobile: need to keep connections alive
WHILE moving |
|
Where in the protocol stack |
|
IP is common glue, solve it once and for all at
IP layer |
|
BUT: may be in contradiction to end-to-end
argument |
|
Other solutions/proposals exits, such as TCP
connection migration |
|
|
|
|
|
automated allocation, configuration and
management of IP addresses and TCP/IP protocol stack parameters: |
|
automated allocation and recovery of IP
addresses |
|
automated configuration of all TCP/IP stack
parameters, as described in the Host Requirements documents |
|
automated configuration of other host parameters
such as application layer services |
|
inter-server communication for coordination of
multiple servers |
|
mechanisms for the authentication of clients and
servers |
|
A specification for IPv4 has been entered into
the IETF standards track (RFC 2131) |
|
currently developing a specification for DHCP
for IPv6 (DHCPv6), which is available as an Internet Draft. |
|
|
|
|
|
|
|
|
|
|
|
|
|
If an address is available, the new address
SHOULD be chosen as follows: |
|
The client's current address as recorded in the
client's current binding, ELSE |
|
The client's previous address as recorded in the
client's (now expired or released) binding, if that address is in the
server's pool of available addresses and not already allocated, ELSE |
|
The address requested in the 'Requested IP
Address' option, if that address is valid and not already allocated, ELSE |
|
A new address allocated from the server's pool
of available addresses; the address is selected based on the subnet from
which the message was received (if 'giaddr' is 0) or on the address of the
relay agent that forwarded the message ('giaddr' when not 0). |
|
|
|
|
|
The server must choose an expiration time for
the lease, as follows: |
|
IF the client has not requested a specific lease
in the DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously assigned
to that address (note that the client must explicitly request a specific
lease to extend the expiration time on a previously assigned address), ELSE |
|
IF the client has not requested a specific lease
in the DHCPDISCOVER message and the client does not have an assigned
network address, the server assigns a locally configured default lease
time, ELSE |
|
IF the client has requested a specific lease in
the DHCPDISCOVER message (regardless of whether the client has an assigned
network address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select another lease. |
|
|
|
|
|
leases expire, so have to renew configuration
from time to time |
|
renewing similar to initialization, but no
discovery step needed |
|
renewal with either server that issued
configuration in the first place, or all servers |
|
in latter case, pick configuration that is
ack-ed first, ignore later DHCPACKs |
|
when done, release configuration |
|
|
|
|
|
|
|
|
|
Initiate connectivity to Internet by DHCP
request |
|
Once initial IP address has been obtained, start
all servers/demons, etc. |
|
Suppose host detects movement: re-issue new DHCP
request to validate current IP address |
|
if okay, proceed |
|
if new address needed, we have a problem |
|
new IP address will not work with existing
connections |
|
shut down and reboot machine |
|
since no other node knows new IP address, MH has
to initiate all requests |
|
alternative: allow DNS updates, which takes time
and introduces new security problem |
|
|
|
|
|
|
Mobile IP: support true mobility, transparent to
higher protocol layers |
|
addressing mobility at network layer has
following advantages: |
|
wireless network access |
|
location-independent access to computing
resources |
|
continuous connectivity (even when physical
media changes) |
|
software reusability, application transparency |
|
economy and ease of operation |
|
Mobile IP can make it seem that a (possibly
virtual) home network extends over the entire Internet, allowing for
seamless roaming. |
|
|
|
|
|
datagrams in Internet flow from on link to
another via routers |
|
computers send and receive datagrams based on
their IP (Internet Protocol) address |
|
Domain Name Service (DNS) translates machine
names into IP address |
|
Internet routing is dynamic, unpredictable,
subject to congestion, and performed on a best-effort basis. IP does not
guarantee that datagrams will be delivered (current loss rate 2%-5%,
expected to grow due to congestion) |
|
|
|
|
|
|
TCP connections are defined by source and
destination IP addresses and port numbers: |
|
Connection := <129.97.40.25, port#,
130.83.27.4, port#> |
|
mobile computers violate the assumption that IP
addresses define the topological relationship |
|
change host address: connection breaks |
|
do not change host address: routing fails |
|
|
|
|
|
|
|
|
|
|
Mobile IP basically transforms the mobility
problem to a routing problem, using two IP addresses |
|
static IP address: connection establishment,
packet delivery |
|
care-of IP address: changes with host mobility |
|
home agent is the router for the home network |
|
foreign agent, located within the range of a
mobile computer, delivers packets to it after receiving them from the home
agent |
|
no special routing is needed to send packets
from a mobile computer to a non-mobile computer |
|
routing from stationary computer to mobile
computer is not necessarily optimal (triangular routing), proposals exist
for route optimization |
|
|
|
|
|
|
|
standardized by RFC 2002: “IP Mobility Support” |
|
service advertisements: let mobiles know of
existence of mobility agent (home agent or foreign agent) |
|
registration: mobile computer “camps on” an IP
subnet and informs its home agent about its current location |
|
tunneling: process of forwarding IP packets from
home agent to foreign agent, for delivery to the mobile |
|
motion detection: mobile detects that it moved
on to a new cell/IP subnet |
|
route optimization: avoid problem of triangle
routing, not part of standard but under discussion |
|
|
|
|
|
|
agent advertisements transmitted every second by
mobility agents (extension of ICMP router advertisement), serves as a
“beacon” for cell selection |
|
alternatively, mobile can issue agent
solicitation (extension of ICMP router solicitation) when no advertisements
received |
|
foreign agents can: |
|
be too busy for more clients (but still send out
advertisements) |
|
describe what encapsulation they offer |
|
require registration via an advertised care-of
address (even if mobile has co-located care-of address) |
|
service advertisements not authenticated |
|
|
|
|
|
|
|
|
|
|
|
detect when MH moved to new IP subnet, triggers
new registration |
|
two primary mechanisms, others MAY be used: |
|
algorithm 1 based on lifetime in agent
advertisement: |
|
MH records lifetime, updates it with every
advertisement |
|
upon expiration, assume that contact with agent
is lost |
|
register with an agent for which advertisement
was received and whose lifetime is not yet expired |
|
algorithm 2 uses network prefixes |
|
compare newly received agent advertisements with
network prefix of currently used care-of address |
|
if prefixes differ, assume that MH moved |
|
upon expiration of current registration, MH MAY
choose to register with new FA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
triangle routing is best you can do with no
modifications to fixed hosts |
|
route optimization under discussion, not part of
mobile IP standard |
|
current solution allows correspondent host to
know care-of address of the mobile node (get binding update) |
|
bindings kept in location cache, part of routing
table |
|
again, authentication is necessary to prevent
traffic hijacking |
|
newer version of proposal also supports “soft
handover” between two FAs |
|
|
|
|
|
|
four UDP message types: |
|
binding warning |
|
binding request |
|
binding update |
|
binding acknowledge |
|
when mobility agent sees that a correspondent
host has a stale location cache, it issues a binding warning |
|
message rate is limited, preferably with
exponential backoff |
|
correspondent makes binding request to elicit binding
update (for example, as result of binding warning) |
|
binding update may be acknowledged with a binding
acknowledge |
|
|
|
|
|
|
support for smooth handoffs |
|
support for multiple home agents |
|
nonces vs. timestamps in authentication |
|
timestamps require clock synchronization, open
to attack |
|
TCP congestion control vs. error-prone media |
|
discovering home agent addresses |
|
simultaneous registrations |
|
replicate each IP packet, send over different
wireless links for improved reliability |
|
specify broadcast and multicast preferences |
|
organize foreign agents hierarchically to limit
reporting requirements back to HA |
|
use ideas from location management in cellular
systems? |
|
|
|
|
|
|
|
|
Use dynamic IP address as co-located
care-of-address |
|
no need to reboot machine or to restart demons |
|
MH known under home IP address |
|
others can initiate connections to it |
|
no need to allow updates to DNS servers |
|
obtain IP address from DHCP server prior to
registration request |
|
should set D bit in registration request,
especially if MH needs to get broadcasts or multicasts sent by home agent |
|
required to register care-of-address by way of a
foreign agent if agent advertisements with R bit set are being received
from local foreign agents |
|
|
|
|
|
Two address expirations |
|
DHCP lease (IP addresses are leased for a
limited time, need to be renewed periodically) |
|
Home Agent binding will expire |
|
Ideally: make DHCP lease and binding lifetime
same (usually means that DHCP lease will be shortened, since leases are
usually rather long-lived for desktops and other stationary devices) |
|
Dual-mode operation: FA or DHCP? |
|
Less address maintenance is required when using
FA care-of-address (no DHCP lease renewal) |
|
FA may be equipped to handle decapsulation
efficiently |
|
FAs may cooperate to provide smooth handoffs |
|
packets for MH decapsulated before wireless
link, reducing bandwidth |
|
|
|
|
Problem: completely auto-configure a MH, even
with information about home address/home agents |
|
existing DHCP options do not allow MH to specify
that they request an appropriate home address |
|
new option (68): DHCP server returns home
address plus zero or more home agent addresses |
|
as part of DISCOVER and REQUEST message, MH
requests return of option 68, use information in reply to register its
care-of-address (obtained by whatever means) for its (new) home address
with one home agent (maybe returned as part of reply) |
|
|
|
|
|
Is location transparency really wanted/needed? |
|
Is seamless connectivity really wanted/needed? |
|
As cells shrink and bandwidth increases: |
|
reconfigurations have to be automatic |
|
reduce minimal time between registrations,
minimal time between successive solicitations for FA service |
|
make better decisions about cell changes to
avoid unnecessary packet losses |
|
How does MobileIP interact with QoS reservation
protocols such as RSVP |
|
home IP address will not always be
important/necessary (POP, anonymous FTP) |
|
if home address is NOT important, use
care-of-address to avoid problems associated with use of home address |
|
co-existence MobileIP and AdHoc Networks? |
|
Notes