Mobile Communication
-
Upload
anand-institute-of-higher-technology-chennai -
Category
Engineering
-
view
1.283 -
download
1
Transcript of Mobile Communication
IT2402 MOBILE COMMUNICATION
UNIT – IV
Dr.A.Kathirvel, Professor and Head, Dept of IT Anand Institute of Higher Technology, Chennai
Unit - IV
MOBILE NETWORK AND TRANSPORT LAYERS
Mobile IP – Dynamic Host Configuration Protocol-Mobile Ad Hoc Routing Protocols– Multicast routing-TCP over Wireless Networks – Indirect TCP – Snooping TCP – Mobile TCP – Fast Retransmit / Fast Recovery – Transmission/Timeout Freezing-Selective Retransmission – Transaction Oriented TCP- TCP over 2.5 / 3G wireless Networks
Why Mobile IP?
What do cellular networks and wireless LANs provide?
Wireless connectivity
Mobility at the data link layer
What is Dynamic Host Configuration Protocol (DHCP)?
It provides local IP addresses for mobile hosts
Is not secure
Does not maintain network connectivity when moving around
What they do not provide:
Transparent connectivity at the network layer
Mobility with local access
The difference between mobility and nomadicity!
What is Mobile IP?
Mobile IP provides network layer mobility
Provides seamless roaming
‘‘Extends’’ the home network over the entire Internet
IP Overview (1/3)
IP Addressing :
Dotted Decimal Notation: 32 bits (4x8) used to represent IPv4 addresses - 192.19.241.18
Network Prefix and Host Portions: p - prefix, h - host, p + h = 32. If p = 24 then h = 32 - 24 = 8. Using above address the network prefix will be 192.19.241 and host will be 18. For those of you familiar with subnet masks, “p” represents the number of 1’s in the subnet mask. If p = 24, subnet mask is 255.255.255.0, if p = 26, subnet mask is 255.255.255.192.
IP Overview (2/3) IP Routing:
Network prefix is used for routing. Routing tables are used to look up next hop and the interface on the router that is to be used.
In the routing tables we use the following notation: target/prefix length, e.g., 192.19.241.0/24, or 192.19.241.192/26.
If two subnet masks/prefixes fit the address, the one with the largest prefix is chosen for routing. E.g., a router with the following 3 entries in its table: 7.7.7.99/32 (p=32 host specific) and 7.7.7.0/24 (0<p<32 network prefix) and 0.0.0.0/0 (p=0 default) will use entry 2 for an IP packet with destination 7.7.7.1 and entry 3 for destination 192.33.14.12.
IP Overview (3/3)
Domain Name System (DNS): used to translate a host name to an IP address. A host sends a query to a server to obtain the IP address of a destination of which it only has the host name.
Link Layer Addresses - Address Resolution Protocol (ARP):
Once a host has the IP address of a destination it then needs to finds its layer 2 address or the layer 2 address of the next hop on the path. A broadcast message is sent and the targeted host responds with its layer 2 address.
A proxy ARP is a response by a node for another node that cannot respond at the time the request is made (e.g. the node is a mobiel node and not on its host net at the time, its home agent will respond in its stead).
A gratuitous ARP, is a reply to no ARP request, used by a node that just joins the network and wants to make its address known. Can be used by a mobile node upon its return to its home net.
Motivation for Mobile IP IP Routing
based on IP destination address, network prefix (e.g. 129.13.42) determines physical subnet
change of physical subnet implies change of IP address to have a topologically correct address (standard IP) or needs special entries in the routing tables
Specific routes to end-systems?
requires changing all routing table entries to forward packets to the right destination
does not scale with the number of mobile hosts and frequent changes in the location, security problems
Changing the IP-address?
adjust the host IP address depending on the current location
almost impossible to find a mobile system, DNS updates take long time
TCP connections break, security problems
What Mobile IP does:
Mobile IP solves the following problems:
if a node moves without changing its IP address it will be unable to receive its packets,
if a node changes its IP address it will have to terminate and restart its ongoing connections everytime it moves to a new network area (new network prefix).
Mobile IP is a routing protocol with a very specific purpose.
Mobile IP is a network layer solution to node mobility in the Internet.
Mobile IP is not a complete solution to mobility, changes to the transport protocols need to be made for a better solution (i.e., the transport layers are unaware of the mobile node’s point of attachment and it might be useful if, e.g., TCP knew that a wireless link was being used!).
Requirements to Mobile IP Transparency
mobile end-systems keep their IP address
continuation of communication after interruption of link possible
point of connection to the fixed network can be changed
Compatibility
support of the same layer 2 protocols as IP
no changes to current end-systems and routers required
mobile end-systems can communicate with fixed systems
Security
authentication of all registration messages
Efficiency and scalability
only little additional messages to the mobile system required (connection typically via a low bandwidth radio link)
world-wide support of a large number of mobile systems in the whole Internet
Mobile IP Terminology Mobile Node (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
registers the location of the MN, tunnels IP datagrams to the COA
Foreign Agent (FA)
system in the current foreign network of the MN, typically a router
forwards the tunneled datagrams to the MN, typically also the default router for the MN
Care-of Address (COA)
address of the current tunnel end-point for the MN (at FA or MN)
actual location of the MN from an IP point of view
can be chosen, e.g., via DHCP
Correspondent Node (CN)
communication partner
Mobile IP Operation: Summary
Consists of 3 steps:
Agent discovery,
Registration, and
Routing/Tunneling
Operation Summary (1/3)
Agent Advertisement/Discovery: consists of broadcast messages used by mobiles to detect that they have moved and are required to register with a new FA.
FAs send agent advertisements
MNs can solicit for agents if they have not heard an agent advertisement in awhile or use some other mechanism to obtain a COA or temp. IP address (e.g. DHCP).
MNs know they are home when they recognize their HA.
Operation Summary (2/3)
Registration: used by a MN to inform the FA that it is visiting.
The new care of address of the MN is sent to the HA.
Registration expires, duration is negotiated during registration
Mobile must re-register before it expires
All registrations are authenticated
The MN sends a regristration request in to the FA which passes it along to the home agent. The HA responds to the FA which then informs the MN that all is in order and registration is complete.
Operation Summary (3/3)
Routing/Encapsulation/Tunneling: consists of the delivery of the packets to the mobile node at its current care of address.
Sender does not need to know that the destination is a MN.
HA intercepts all packets for the MN and passes them along to MN using a tunnel.
MN communicates directly with the CN.
Referred to as Triangle Routing
Example network
mobile end-system Internet
router
router
router
end-system
FA
HA
MN
home network
foreign
network
(physical home network
for the MN)
(current physical network
for the MN) CN
Data transfer to the mobile system
Internet
sender
FA
HA
MN
home network
foreign
network
receiver
1
2
3
1. Sender sends to the IP address of MN,
HA intercepts packet (proxy ARP)
2. HA tunnels packet to COA, here FA,
by encapsulation
3. FA forwards the packet
to the MN
CN
Data transfer from the mobile system
Internet
receiver
FA
HA
MN
home network
foreign
network
sender
1
1. Sender sends to the IP address
of the receiver as usual,
FA works as default router CN
Overview
CN
router
HA
router
FA
Internet
router
1.
2.
3.
home
network MN
foreign
network
4.
CN
router
HA
router
FA
Internet
router
home
network MN
foreign
network
COA
Network integration
Agent Advertisement Discovery
HA and FA periodically send advertisement messages into their physical subnets
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
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
Routing/Encapsulation/Tunneling
HA advertises the IP address of the MN (as for fixed systems), i.e. standard routing information
packets to the MN are sent to the HA,
independent of changes in COA/FA
Agent advertisement
preference level 1 router address 1
#addresses type
addr. size lifetime checksum
COA 1 COA 2
type sequence number length
0 7 8 15 16 31 24 23 code
preference level 2 router address 2
. . .
registration lifetime
. . .
R B H F M G V reserved
Registration
t
MN HA
t
MN FA HA
Mobile IP registration request
home agent home address
type lifetime 0 7 8 15 16 31 24 23
rsv
identification
COA
extensions . . .
S B D M G V
Processing Registration Messages (1/3) A MN, depending on which registration scenario it is in, will figure what addresses to
use in the various fields of the Registration request message.
Link layer addresses are tricky:
A MN may not use ARP if it is using a FA COA. It needs to use the address of the FA as the destination address.
If it is using a collocated COA, then it uses ARP to locate the default router using its COA as source. Note that if the ‘R’ bit is set is uses the FA address as the destination address.
For de-registration is uses ARP to locate the HA link address and it uses its own home address for the ARP message.
For network layer addresses (i.e., IP addresses):
It uses the FA address as destination address when using the FA COA and its own home address as the source address.
If using a collocated COA it uses its COA as source address and the HA address as destination address. Note that if the ‘R’ bit is set then is must use the same addresses as for the FA COA scenario.
For de-registration it uses its own home address as source and the HA address as destination.
Processing Registration Messages (2/3)
For the FA:
A FA may refuse a Registration request for a number of reasons: lifetime too long, authentication failed, requested tunneling not supported, cannot handle another MN (current load too high).
If an FA does not refuse the request it relays it to the HA. Relaying is different from forwarding as the FA is required to process the packet and create new headers.
Some important fields of the request message are recorded for use later on: MN link layer address, MN IP address, UDP source port, HA IP address, identification number and requested lifetime.
Regarding a Registration reply message, the FA can refuse it and send a decline to the MN is it finds the reply from the HA to be invalid. Otherwise it updates its list of visiting MNs and begins acting on behalf of the MN.
Processing Registration Messages (3/3)
For a HA
The HA will determine, as the FA did, whether it will accept the request. If it does not it returns a code in the reply message indicating the cause of the failed request.
If the request is accepted, the reply is sent back by reversing all the IP addresses and UDP port numbers.
The HA updates the binding table corresponding to that MN dependent upon the nature of the request.
Routing/Tunneling (1/5)
Routing a packet to a MN involves the following:
A router on the home link, possibly the HA, advertises reachability to the network prefix of the MN’s home address.
All packets are therefore routed to the MN’s home link.
A HA intercepts the packets for the MN and tunnels a copy to each COA in the binding table.
At the foreign link either the MN extracts the packet (collocated COA) or the FA extracts the packet and forwards it to the MN.
Routing/Tunneling (2/5)
A HA can use one of two methods to intercept a MN’s packets:
The HA is a router with multiple network interfaces. In that case it advertises reachability to the MN’s home network prefix.
The HA is not a router with multiple interfaces. It must use ARP to receive the MN’s packets. It either responds to ARP requests on behalf of the MN (proxy ARP) or uses gratuitous ARPs to inform the home network that it is receiving the MN’s IP packets. This is to update any ARP caches that hosts and other devices might have.
Routing/Tunneling (3/5)
How to ‘fool’ the routing table into handling tunneled packets at the HA?
A virtual interface is used to do the encapsulation.
A packet destined for the MN is handled by the routing routine as all received IP packets are.
The routing table has a host specific entry for the MN. This host specific entry is used to route the packet to a virtual interface that basically consists of a process that does encapsulation.
Once encapsulation has been performed the packet is sent to be processed by the routing routine again. This time the destination address is the COA and it is routed normally.
Routing/Tunneling (4/5)
How to ‘fool’ the routing table into handling tunneled packets at the FA?
The same procedure is used as above.
A packet coming in with a COA that is one of the FA addresses’ is handled by the routing routine.
A host specific address (its own address) in the routing table points to the higher layers and the packet is passed on to a virtual interface.
The virtual interface consists of a process that decapsulates the packet and re-routes it to the routing routine.
The routing routine routes the packet normally based upon a host specific entry that is the MN’s home address (for which it has the link layer address!).
Routing/Tunneling (5/5)
• How does a MN route its packets?
– It needs to find a router to send all its packets to.
– It can select a router in one of a number of ways dependent upon whether it has a FA COA or a collocated COA.
– Having a FA COA does not imply that the MN needs to use it as its default router for sending packets. It can use any router that sends advertisements or that is advertised in the Agent Advertisement message.
– If the MN is using a collocated COA it needs to listen for router advertisements or is it hears none, use DHCP to find the default router.
– Determining the link layer address is another issue. Collocated COA MNs can use ARP. FA COA must note the link layer address when they receive router advertisements or agent advertisements.
Encapsulation Process
original IP header original data
new data new IP header
outer header inner header original data
Types of Encapsulation
Three types of encapsulation protocols are specified for Mobile IP:
IP-in-IP encapsulation: required to be supported. Full IP header added to the original IP packet. The new header contains HA address as source and Care of Address as destination.
Minimal encapsulation: optional. Requires less overhead but requires changes to the original header. Destination address is changed to Care of Address and Source IP address is maintained as is.
Generic Routing Encapsulation (GRE): optional. Allows packets of a different protocol suite to be encapsulated by another protocol suite.
Type of tunneling/encapsulation supported is indicated in registration.
IP in IP Encapsulation
IP in IP encapsulation (mandatory in RFC 2003)
tunnel between HA and COA
Care-of address COA IP address of HA
TTL IP identification
IP-in-IP IP checksum flags fragment offset
length TOS ver. IHL
IP address of MN IP address of CN
TTL IP identification
lay. 4 prot. IP checksum flags fragment offset
length TOS ver. IHL
TCP/UDP/ ... payload
Minimum Encapsulation
Minimal encapsulation (optional)
avoids repetition of identical fields
e.g. TTL, IHL, version, TOS
only applicable for unfragmented packets, no space left for fragment identification
care-of address COA IP address of HA
TTL IP identification
min. encap. IP checksum flags fragment offset
length TOS ver. IHL
IP address of MN original sender IP address (if S=1)
S lay. 4 protoc. IP checksum
TCP/UDP/ ... payload
reserved
Generic Routing Encapsulation
original
header original data
new data new header
outer header GRE
header original data
original
header
Care-of address COA
IP address of HA
TTL
IP identification
GRE IP checksum
flags fragment offset
length TOS ver. IHL
IP address of MN
IP address of CN
TTL
IP identification
lay. 4 prot. IP checksum
flags fragment offset
length TOS ver. IHL
TCP/UDP/ ... payload
routing (optional)
sequence number (optional)
key (optional)
offset (optional) checksum (optional)
protocol rec. rsv. ver. C R K S s
Routing techniques
Triangle Routing: tunneling in its simplest form has all packets go to home network (HA) and then sent to MN via a tunnel.
This involves two IP routes that need to be set-up, one original and the second the tunnel route.
Causes unnecessary network overhead and adds to the latency.
Route optimization: allows the correspondent node to learn the current location of the MN and tunnel its own packets directly. Problems arise with
mobility: correspondent node has to update/maintain its cache.
authentication: HA has to communicate with the correspondent node to do authentication, i.e., security association is with HA not with MN.
Optimization of packet forwarding
Change of FA
packets on-the-fly during the change can be lost
new FA informs old FA to avoid packet loss, old FA now forwards remaining packets to new FA
this information also enables the old FA to release resources for the MN
Change of foreign agent
CN HA FAold FAnew MN
t
request
update
ACK
data data MN changes
location registration
update
ACK data
data data warning
update
ACK
data data
registration
Problems with Triangle Routing
Triangle routing has the MN correspond directly with the CN using its home address as the SA
Firewalls at the foreign network may not allow that
Multicasting: if a MN is to participate in a multicast group, it needs to use a reverse tunnel to maintain its association with the home network.
TTL: a MN might have a TTL that is suitable for communication when it is in its HM. This TTL may not be sufficient when moving around (longer routes possibly). When using a reverse tunnel, it only counts as a single hop. A MN does not want to change the TTL everytime it moves.
Solution: reverse tunneling
Reverse tunneling (RFC 2344)
Internet
receiver
FA
HA
MN
home network
foreign
network
sender
3
2
1
1. MN sends to FA
2. FA tunnels packets to HA
by encapsulation
3. HA forwards the packet to the
receiver (standard case)
CN
Mobile IP with reverse tunneling
Routers accept often only “topologically correct“ addresses (firewall!)
a packet from the MN encapsulated by the FA is now topologically correct
Multicast and TTL problems solved
Reverse tunneling does not solve
all problems with firewalls, the reverse tunnel can be abused to circumvent security mechanisms (tunnel hijacking)
optimization of data paths, i.e. packets will be forwarded through the tunnel via the HA to a sender (longer routes)
The new standard is backwards compatible
the extensions can be implemented easily
Mobile IP and IPv6 Mobile IP was developed for IPv4, but IPv6 simplifies the protocols
security is integrated and not an add-on, authentication of registration is included
COA can be assigned via auto-configuration (DHCPv6 is one candidate), every node has address auto configuration
no need for a separate FA, all routers perform router advertisement which can be used instead of the special agent advertisement
MN can signal a sender directly the COA, sending via HA not needed in this case (automatic path optimization)
soft hand-over, i.e. without packet loss, between two subnets is supported
MN sends the new COA to its old router
the old router encapsulates all incoming packets for the MN and forwards them to the new COA
authentication is always granted
Problems with Mobile IP
Security
authentication with FA problematic, for the FA typically belongs to another organization
no protocol for key management and key distribution has been standardized in the Internet
patent and export restrictions
Firewalls
typically mobile IP cannot be used together with firewalls, special set-ups are needed (such as reverse tunneling)
QoS
many new reservations in case of RSVP
tunneling makes it hard to give a flow of packets a special treatment needed for the QoS
Security, firewalls, QoS etc. are topics of current research and discussions!
Security in Mobile IP Security requirements (Security Architecture for the Internet Protocol, RFC 1825)
Integrity any changes to data between sender and receiver can be detected by the receiver
Authentication sender address is really the address of the sender and all data received is really data sent by this sender
Confidentiality only sender and receiver can read the data
Non-Repudiation sender cannot deny sending of data
Traffic Analysis creation of traffic and user profiles should not be possible
Replay Protection receivers can detect replay of messages
not encrypted encrypted
IP security architecture (1/2)
Two or more partners have to negotiate security mechanisms to setup a security association
typically, all partners choose the same parameters and mechanisms
Two headers have been defined for securing IP packets:
Authentication-Header
guarantees integrity and authenticity of IP packets
if asymmetric encryption schemes are used, non-repudiation can also be guaranteed
Encapsulation Security Payload
protects confidentiality between communication partners
Authentification-Header IP-Header UDP/TCP-Paket authentication header IP header UDP/TCP data
ESP header IP header encrypted data
Mobile Security Association for registrations
parameters for the mobile host (MH), home agent (HA), and foreign agent (FA)
Extensions of the IP security architecture
extended authentication of registration
prevention of replays of registrations
time stamps: 32 bit time stamps + 32 bit random number
responses: 32 bit random number (MH) + 32 bit random number (HA)
registration reply
registration request registration request
IP security architecture (2/2)
MH FA HA registration reply
MH-HA authentication
MH-FA authentication FA-HA authentication
Key distribution
Home agent distributes session keys
foreign agent has a security association with the home agent
mobile host registers a new binding at the home agent
home agent answers with a new session key for foreign agent and mobile node
FA MH
HA
response:
EHA-FA {session key}
EHA-MH {session key}
DHCP: Dynamic Host Configuration Protocol
Application
simplification of installation and maintenance of networked computers
supplies systems with all necessary information, such as IP address, DNS server address, domain name, subnet mask, default router etc.
enables automatic integration of systems into an Intranet or the Internet, can be used to acquire a COA for Mobile IP
Client/Server-Model
the client sends via a MAC broadcast a request to the DHCP server (might be via a DHCP relay)
client relay
client server
DHCPDISCOVER
DHCPDISCOVER
DHCP - protocol mechanisms
server
(not selected)
client server
(selected) initialization
collection of replies
selection of configuration
initialization completed
release
confirmation of
configuration
delete context
determine the
configuration
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
(reject)
DHCPACK
DHCPRELEASE
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
(options)
determine the
configuration
DHCP characteristics
Server
several servers can be configured for DHCP, coordination not yet standardized (i.e., manual configuration)
Renewal of configurations
IP addresses have to be requested periodically, simplified protocol
Options
available for routers, subnet mask, NTP (network time protocol) timeserver, SLP (service location protocol) directory, DNS (domain name system)
Big security problems!
no authentication of DHCP information specified
Ad hoc networks
Standard Mobile IP needs an infrastructure
Home Agent/Foreign Agent in the fixed network
DNS, routing etc. are not designed for mobility
Sometimes there is no infrastructure!
remote areas, ad-hoc meetings, disaster areas
cost can also be an argument against an infrastructure!
Main topic: routing
no default router available
every node should be able to forward
A B C
Routing examples for an ad hoc network
N1
N4
N2
N5
N3
N1
N4
N2
N5
N3
good link
weak link time = t1 time = t2
Traditional routing algorithms
Distance Vector
periodic exchange of messages with all physical neighbors that contain information about who can be reached at what distance
selection of the shortest path if several paths available
Link State
periodic notification of all routers about the current state of all physical links
router get a complete picture of the network
Example
ARPA packet radio network (1973), DV-Routing
every 7.5s exchange of routing tables including link quality
updating of tables also by reception of packets
routing problems solved with limited flooding
Problems of traditional routing algorithms
Dynamics of the topology
frequent changes of connections, connection quality, participants
Limited performance of mobile systems
periodic updates of routing tables need energy without contributing to the transmission of user data, sleep modes difficult to realize
limited bandwidth of the system is reduced even more due to the exchange of routing information
links can be asymmetric, i.e., they can have a direction dependent transmission quality
Problem
protocols have been designed for fixed networks with infrequent changes and typically assume symmetric links
DSDV (Destination Sequenced Distance Vector)
Expansion of distance vector routing
Sequence numbers for all routing updates
assures in-order execution of all updates
avoids loops and inconsistencies
Decrease of update frequency
store time between first and best announcement of a path
inhibit update if it seems to be unstable (based on the stored time values)
Dynamic source routing I
Split routing into discovering a path and maintaining a path
Discover a path
only if a path for sending packets to a certain destination is needed and no path is currently available
Maintaining a path
only while the path is in use one has to make sure that it can be used continuously
No periodic updates needed!
Dynamic source routing II
Path discovery
broadcast a packet with destination address and unique ID
if a station receives a broadcast packet
if the station is the receiver (i.e., has the correct destination address) then return the packet to the sender (path was collected in the packet)
if the packet has already been received earlier (identified via ID) then discard the packet
otherwise, append own address and broadcast packet
sender receives packet with the current path (address list)
Optimizations
limit broadcasting if maximum diameter of the network is known
caching of address lists (i.e. paths) with help of passing packets
stations can use the cached information for path discovery (own paths or paths for other hosts)
Dynamic Source Routing III
Maintaining paths
after sending a packet
wait for a layer 2 acknowledgement (if applicable)
listen into the medium to detect if other stations forward the packet (if possible)
request an explicit acknowledgement
if a station encounters problems it can inform the sender of a packet or look-up a new path locally
Clustering of ad-hoc networks
Internet
super cluster
cluster
Interference-based routing
Routing based on assumptions about interference between signals
S1
N5
N3
N4
N1 N2
R1
R2 N6
N8
S2
N9 N7 neighbors
(i.e. within radio range)
Examples for interference based routing
Least Interference Routing (LIR)
calculate the cost of a path based on the number of stations that can receive a transmission
Max-Min Residual Capacity Routing (MMRCR)
calculate the cost of a path based on a probability function of successful transmissions and interference
Least Resistance Routing (LRR)
calculate the cost of a path based on interference, jamming and other transmissions
LIR is very simple to implement, only information from direct neighbors is necessary
Multicast routing
Unicast: single source sends to a single destination
Multicast: hosts are part of a multicast group
packet sent by any member of a group are received by all
Useful for
multiparty videoconference
distance learning
resource location
Multicast group
Associates a set of senders and receivers with each other
but independent of them
created either when a sender starts sending from a group
or a receiver expresses interest in receiving
even if no one else is there!
Sender does not need to know receivers’ identities
rendezvous point
Addressing
Multicast group in the Internet has its own Class D address
looks like a host address, but isn’t
Senders send to the address
Receivers anywhere in the world request packets from that address
“Magic” is in associating the two: dynamic directory service
Four problems
which groups are currently active
how to express interest in joining a group
discovering the set of receivers in a group
delivering data to members of a group
Expanding ring search
A way to use multicast groups for resource discovery
Routers decrement TTL when forwarding
Sender sets TTL and multicasts
reaches all receivers <= TTL hops away
Discovers local resources first
Since heavily loaded servers can keep quiet, automatically distributes load
Multicast flavors
Unicast: point to point
Multicast:
point to multipoint
multipoint to multipoint
Can simulate point to multipoint by a set of point to point unicasts
Can simulate multipoint to multipoint by a set of point to multipoint multicasts
The difference is efficiency
Example
Suppose A wants to talk to B, G, H, I, B to A, G, H, I
With unicast, 4 messages sent from each source
links AC, BC carry a packet in triplicate
With point to multipoint multicast, 1 message sent from each source
but requires establishment of two separate multicast groups
With multipoint to multipoint multicast, 1 message sent from each source,
single multicast group
Shortest path tree
Ideally, want to send exactly one multicast packet per link
forms a multicast tree rooted at sender
Optimal multicast tree provides shortest path from sender to every receiver
shortest-path tree rooted at sender
Issues in wide-area multicast
Difficult because
sources may join and leave dynamically
need to dynamically update shortest-path tree
leaves of tree are often members of broadcast LAN
would like to exploit LAN broadcast capability
would like a receiver to join or leave without explicitly notifying sender
otherwise it will not scale
Multicast in a broadcast LAN
Wide area multicast can exploit a LAN’s broadcast capability
E.g. Ethernet will multicast all packets with multicast bit set on destination address
Two problems:
what multicast MAC address corresponds to a given Class D IP address?
does the LAN have contain any members for a given group (why do we need to know this?)
Class D to MAC translation
Multiple Class D addresses map to the same MAC address
Well-known translation algorithm => no need for a translation table
01 00 5E
23 bits copied from IP address
IEEE 802 MAC Address
Class D IP
address
Ignore
d
‘1110’ = Class D
indication
Multicast bit Reserved
bit
Internet Group Management Protocol
Detects if a LAN has any members for a particular group
If no members, then we can prune the shortest path tree for that group by telling parent
Router periodically broadcasts a query message
Hosts reply with the list of groups they are interested in
To suppress traffic
reply after random timeout
broadcast reply
if someone else has expressed interest in a group, drop out
To receive multicast packets:
translate from class D to MAC and configure adapter
Wide area multicast
Assume
each endpoint is a router
a router can use IGMP to discover all the members in its LAN that want to subscribe to each multicast group
Goal
distribute packets coming from any sender directed to a given group to all routers on the path to a group member
Simplest solution
Flood packets from a source to entire network
If a router has not seen a packet before, forward it to all interfaces except the incoming one
Pros
simple
always works!
Cons
routers receive duplicate packets
detecting that a packet is a duplicate requires storage, which can be expensive for long multicast sessions
A clever solution
Reverse path forwarding
Rule
forward packet from S to all interfaces if and only if packet arrives on the interface that corresponds to the shortest path to S
no need to remember past packets
C need not forward packet received from D
Cleverer
Don’t send a packet downstream if you are not on the shortest path from the downstream router to the source
C need not forward packet from A to E
Potential confusion if downstream router has a choice of shortest paths to source (see figure on previous slide)
Pruning
RPF does not completely eliminate unnecessary transmissions
B and C get packets even though they do not need it
Pruning => router tells parent in tree to stop forwarding
Can be associated either with a multicast group or with a source and group
trades selectivity for router memory
Rejoining
What if host on C’s LAN wants to receive messages from A after a previous prune by C?
IGMP lets C know of host’s interest
C can send a join(group, A) message to B, which propagates it to A
or, periodically flood a message; C refrains from pruning
A problem
Reverse path forwarding requires a router to know shortest path to a source
known from routing table
Doesn’t work if some routers do not support multicast
virtual links between multicast-capable routers
shortest path to A from E is not C, but F
Two problems
how to build virtual links
how to construct routing table for a network with virtual links
Tunnels
Why do we need them?
Consider packet sent from A to F via multicast-incapable D
If packet’s destination is Class D, D drops it
If destination is F’s address, F doesn’t know multicast address!
So, put packet destination as F, but carry multicast address internally
Encapsulate IP in IP => set protocol type to IP-in-IP
Multicast routing protocol
Interface on “shortest path” to source depends on whether path is real or virtual
Shortest path from E to A is not through C, but F
so packets from F will be flooded, but not from C
Need to discover shortest paths only taking multicast-capable routers into account
DVMRP
DVMRP
Distance-vector Multicast routing protocol
Very similar to RIP
distance vector
hop count metric
Used in conjunction with
flood-and-prune (to determine memberships)
prunes store per-source and per-group information
reverse-path forwarding (to decide where to forward a packet)
explicit join messages to reduce join latency (but no source info, so still need flooding)
MOSPF
Multicast extension to OSPF
Routers flood group membership information with LSPs
Each router independently computes shortest-path tree that only includes multicast-capable routers
no need to flood and prune
Complex
interactions with external and summary records
need storage per group per link
need to compute shortest path tree per source and group
Core-based trees
Problems with DVMRP-oriented approach
need to periodically flood and prune to determine group members
need to source per-source and per-group prune records at each router
Key idea with core-based tree
coordinate multicast with a core router
host sends a join request to core router
routers along path mark incoming interface for forwarding
Example
Pros
routers not part of a group are not involved in pruning
explicit join/leave makes membership changes faster
router needs to store only one record per group
Cons
all multicast traffic traverses core, which is a bottleneck
traffic travels on non-optimal paths
Protocol independent multicast (PIM)
Tries to bring together best aspects of CBT and DVMRP
Choose different strategies depending on whether multicast tree is dense or sparse
flood and prune good for dense groups
only need a few prunes
CBT needs explicit join per source/group
CBT good for sparse groups
Dense mode PIM == DVMRP
Sparse mode PIM is similar to CBT
but receivers can switch from CBT to a shortest-path tree
PIM (contd.)
In CBT, E must send to core
In PIM, B discovers shorter path to E (by looking at unicast routing table)
sends join message directly to E
sends prune message towards core
Core no longer bottleneck
Survives failure of core
More on core
Renamed a rendezvous point
because it no longer carries all the traffic like a CBT core
Rendezvous points periodically send “I am alive” messages downstream
Leaf routers set timer on receipt
If timer goes off, send a join request to alternative rendezvous point
Problems
how to decide whether to use dense or sparse mode?
how to determine “best” rendezvous point?
90
Mobile Transport Layer
91
Transport Layer E.g. HTTP (used by web services) typically uses TCP
Reliable transport between client and server required
TCP
Steam oriented, not transaction oriented
Network friendly: time-out congestion slow down transmission
Well known – TCP guesses quite often wrong in wireless and mobile networks
Packet loss due to transmission errors
Packet loss due to change of network
Result
Severe performance degradation
Client Server
Connection
setup
Data
transmission
Connection
release
TCP SYN
TCP SYN/ACK
TCP ACK
HTTP request
HTTP response
GPRS: 500ms!
>15 s
no data
92
Motivation I Transport protocols typically designed for
Fixed end-systems
Fixed, wired networks
Research activities
Performance
Congestion control
Efficient retransmissions
TCP congestion control
packet loss in fixed networks typically due to (temporary) overload situations
router have to discard packets as soon as the buffers are full
TCP recognizes congestion only indirect via missing acknowledgements, retransmissions unwise, they would only contribute to the congestion and make it even worse
slow-start algorithm as reaction
93
Motivation II TCP slow-start algorithm
sender calculates a congestion window for a receiver
start with a congestion window size equal to one segment
exponential increase of the congestion window up to the congestion threshold, then linear increase
missing acknowledgement causes the reduction of the congestion threshold to one half of the current congestion window
congestion window starts again with one segment
TCP fast retransmit/fast recovery
TCP sends an acknowledgement only after receiving a packet
if a sender receives several acknowledgements for the same packet, this is due to a gap in received packets at the receiver
however, the receiver got all packets up to the gap and is actually receiving packets
therefore, packet loss is not due to congestion, continue with current congestion window (do not use slow-start)
94
Influences of mobility on TCP-mechanisms
TCP assumes congestion if packets are dropped
typically wrong in wireless networks, here we often have packet loss due to transmission errors
furthermore, mobility itself can cause packet loss, if e.g. a mobile node roams from one access point (e.g. foreign agent in Mobile IP) to another while there are still packets in transit to the wrong access point and forwarding is not possible
The performance of an unchanged TCP degrades severely
however, TCP cannot be changed fundamentally due to the large base of installation in the fixed network, TCP for mobility has to remain compatible
the basic TCP mechanisms keep the whole Internet together
95
Early approach: Indirect TCP I
Indirect TCP or I-TCP segments the connection
no changes to the TCP protocol for hosts connected to the wired Internet, millions of computers use (variants of) this protocol
optimized TCP protocol for mobile hosts
splitting of the TCP connection at, e.g., the foreign agent into 2 TCP connections, no real end-to-end connection any longer
hosts in the fixed part of the net do not notice the characteristics of the wireless part
mobile host access point
(foreign agent) „wired“ Internet
„wireless“ TCP standard TCP
96
I-TCP socket and state migration
mobile host
access point2
Internet
access point1
socket migration
and state transfer
97
Indirect TCP II
Advantages
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 fixed network
simple to control, mobile TCP is used only for one hop between, e.g., a foreign agent and mobile host
therefore, a very fast retransmission of packets is possible, the short delay on the mobile hop is known
Disadvantages
loss of end-to-end semantics, an acknowledgement to a sender does now not any longer mean that a receiver really got a packet, foreign agents might crash
higher latency possible due to buffering of data within the foreign agent and forwarding to a new foreign agent
98
Early approach: Snooping TCP I
Transparent extension of TCP within the foreign agent
buffering of packets sent to the mobile host
lost packets on the wireless link (both directions!) will be retransmitted immediately by the mobile host or foreign agent, respectively (so called “local” retransmission)
the foreign agent therefore “snoops” the packet flow and recognizes acknowledgements in both directions, it also filters ACKs
changes of TCP only within the foreign agent
„wired“ Internet
buffering of data
end-to-end TCP connection
local retransmission correspondent
host foreign
agent
mobile
host
snooping of ACKs
99
Snooping TCP II Data transfer to the mobile host
FA buffers data until it receives ACK of the MH, FA detects packet loss via duplicated ACKs or time-out
fast retransmission possible, transparent for the fixed network
Data transfer from the mobile host
FA detects packet loss on the wireless link via sequence numbers, FA answers directly with a NACK to the MH
MH can now retransmit data with only a very short delay
Integration of the MAC layer
MAC layer often has similar mechanisms to those of TCP
thus, the MAC layer can already detect duplicated packets due to retransmissions and discard them
Problems
snooping TCP does not isolate the wireless link as good as I-TCP
snooping might be useless depending on encryption schemes
100
Early approach: Mobile TCP
Special handling of lengthy and/or frequent disconnections
M-TCP splits as I-TCP does
unmodified TCP fixed network to supervisory host (SH)
optimized TCP SH to MH
Supervisory host
no caching, no retransmission
monitors all packets, if disconnection detected
set sender window size to 0
sender automatically goes into persistent mode
old or new SH reopen the window
Advantages: maintains semantics, supports disconnection, no buffer forwarding
Disadvantages: loss on wireless link propagated into fixed network and adapted TCP on wireless link
101
Fast retransmit/fast recovery
Change of foreign agent often results in packet loss
TCP reacts with slow-start although there is no congestion
Forced fast retransmit
as soon as the mobile host has registered with a new foreign agent, the MH sends duplicated acknowledgements on purpose
this forces the fast retransmit mode at the communication partners
additionally, the TCP on the MH is forced to continue sending with the actual window size and not to go into slow-start after registration
Advantage
simple changes result in significant higher performance
Disadvantage
further mix of IP and TCP, no transparent approach
102
Transmission/time-out freezing
Mobile hosts can be disconnected for a longer time
no packet exchange possible, e.g., in a tunnel, disconnection due to overloaded cells or mux. with higher priority traffic
TCP disconnects after time-out completely
TCP freezing
MAC layer is often able to detect interruption in advance
MAC can inform TCP layer of upcoming loss of connection
TCP stops sending, but does now not assume a congested link
MAC layer signals again if reconnected
Advantage
scheme is independent of data
Disadvantage
TCP on mobile host has to be changed, mechanism depends on MAC layer
103
Selective retransmission
TCP acknowledgements are often cumulative
ACK n acknowledges correct and in-sequence receipt of packets up to n
if single packets are missing quite often a whole packet sequence beginning at the gap has to be retransmitted (go-back-n), thus wasting bandwidth
Selective retransmission as one solution
RFC2018 allows for acknowledgements of single packets, not only acknowledgements of in-sequence packet streams without gaps
sender can now retransmit only the missing packets
Advantage : much higher efficiency
Disadvantage: more complex software in a receiver, more buffer needed at the receiver
104
Transaction oriented TCP
TCP phases
connection setup, data transmission, connection release
using 3-way-handshake needs 3 packets for setup and release, respectively
thus, even short messages need a minimum of 7 packets!
Transaction oriented TCP
RFC1644, T-TCP, describes a TCP version to avoid this overhead
connection setup, data transfer and connection release can be combined
thus, only 2 or 3 packets are needed
Advantage: efficiency
Disadvantage: requires changed TCP and mobility not longer transparent
105
Comparison of different approaches for a “mobile” TCP
Approach Mechanism Advantages Disadvantages
Indirect TCP splits TCP connectioninto two connections
isolation of wirelesslink, simple
loss of TCP semantics,higher latency athandover
Snooping TCP “snoops” data andacknowledgements, localretransmission
transparent for end-to-end connection, MACintegration possible
problematic withencryption, bad isolationof wireless link
M-TCP splits TCP connection,chokes sender viawindow size
Maintains end-to-endsemantics, handleslong term and frequentdisconnections
Bad isolation of wirelesslink, processingoverhead due tobandwidth management
Fast retransmit/fast recovery
avoids slow-start afterroaming
simple and efficient mixed layers, nottransparent
Transmission/time-out freezing
freezes TCP state atdisconnect, resumesafter reconnection
independent of contentor encryption, works forlonger interrupts
changes in TCPrequired, MACdependant
Selectiveretransmission
retransmit only lost data very efficient slightly more complexreceiver software, morebuffer needed
Transactionoriented TCP
combine connectionsetup/release and datatransmission
Efficient for certainapplications
changes in TCPrequired, not transparent
106
TCP Improvements I Initial research work
Indirect TCP, Snoop TCP, M-TCP, T/TCP, SACK, Transmission/time-out freezing,
TCP over 2.5/3G wireless networks
Fine tuning today’s TCP
Learn to live with
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
High latency, high jitter, packet loss
Suggestions
Large (initial) sending windows, large maximum transfer unit, selective acknowledgement, explicit congestion notification, time stamp, no header compression
Already in use
i-mode running over FOMA
WAP 2.0 (“TCP with wireless profile”)
pRTT
MSSBW
*
*93.0
• max. TCP BandWidth
• Max. Segment Size
• Round Trip Time
• loss probability
107
TCP Improvements II
Performance enhancing proxies (PEP, RFC 3135)
Transport layer
Local retransmissions and acknowledgements
Additionally on the application layer
Content filtering, compression, picture downscaling
E.g., Internet/WAP gateways
Web service gateways?
Big problem: breaks end-to-end semantics
Disables use of IP security
Choose between PEP and security!
More open issues
RFC 3150 (slow links)
Recommends header compression, no timestamp
RFC 3155 (links with errors)
States that explicit congestion notification cannot be used
In contrast to 2.5G/3G recommendations!
Mobile system
PEP
Comm. partner
wireless
Internet
Questions ?