Computer Networks (Graduate level) - PowerPoint PPT Presentation

Loading...

PPT – Computer Networks (Graduate level) PowerPoint presentation | free to download - id: 7552ed-YzI5Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Computer Networks (Graduate level)

Description:

Computer Networks (Graduate level) Lecture 5: Internetworking University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani – PowerPoint PPT presentation

Number of Views:92
Avg rating:3.0/5.0
Slides: 59
Provided by: Larry406
Learn more at: http://ece.ut.ac.ir
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Computer Networks (Graduate level)


1
Computer Networks(Graduate level)
Lecture 5 Internetworking
  • University of Tehran
  • Dept. of EE and Computer Engineering
  • By
  • Dr. Nasser Yazdani

2
Internetworking
  • How to connect existing networks
  • TCP/IP protocol
  • Assigned Reading
  • CK74 A Protocol for Packet Network
    Intercommunication.
  • Hin96 IP Next Generation Overview

3
The Problem
  • Before Internet
  • different packet-switching networks (e.g.,
    ARPANET, ARPA packet radio)
  • only nodes on the same physical/link layer
    network could communicate
  • want to share room-size computers, storage to
    reduce expense

4
The Challenge
  • Interconnect existing networks
  • but, packet switching networks differ widely
  • different services
  • e.g., degree of reliability
  • different interfaces
  • e.g., length of the packet that can be
    transmitted, address format
  • different protocols
  • e.g., routing protocols

5
Key problem Heterogeneity
  • Not described as such in paper
  • Heterogeneous addressing conventions gt common
    addressing scheme
  • Heterogeneous MTU gt fragmentation
  • Heterogeneous queuing/transit delays gtadaptive
    timing procedures
  • Heterogeneous reliability gt end-to-end recovery
    mechanisms
  • Heterogeneous control/status info gt common
    error/coordination mechanism

6
Possible solutions
  • Reengineer and develop one global packet
    switching network standard
  • not economically feasible
  • not deployable
  • Have every host implement the protocols of any
    network it wants to communicate with
  • Complexity/node O(n)
  • O(n2) global complexity

7
Solution
  • Add an extra layer internetworking layer
  • hosts
  • understand one network protocol
  • understand one physical/link protocol
  • gateways
  • understand one network protocol
  • understand the physical/link protocols of the
    networks they gateway
  • Complexity to add a node/network O(1) with
    respect to number of existing nodes

8
Solution
Gateways
9
Challenge 1 Different Address Formats
  • Options
  • Map one address format to another. Why not?
  • Provide one common format
  • map lower level addresses to common format
  • Format
  • Initially 8b network 16b host 24b total
  • Before Classless InterDomain Routing (CIDR)
  • 7b/24b, 14b/16b, or 21b/8b 32b total
  • After CIDR Arbitrary division 32b total
  • NAT 32b 16b simultaneously active
  • IPv6 128b total

10
Address Formats
  • 256 networks? What were they thinking?
  • Why CIDR?
  • What happens if they run out before IPv6?
  • Why IPv6?
  • Why 128b for IPv6? 248281 trillion.
  • Why not variable length addresses?

11
Challenge 2 Different Packet Sizes
  • Need to define maximum packet size
  • Options
  • Take the minimum of the maximum packets sizes
    over all networks
  • Implement fragmentation/reassembly
  • Flexibility to adjust packet sizes as new
    technologies arrive
  • IP fragment at routers, reassemble at host
  • Why not reassemble at routers?
  • Still stuck with 1500B as de facto maximum

12
Other Challenges
  • Errors ? require end-to-end reliability
  • Thought to be rarely invoked, but necessary
  • Different (routing) protocols ? coordinate these
    protocols
  • Accounting
  • Did not envision script kiddies
  • Quality of Service
  • Not addressed

13
Transmission Control Program
  • Original TCP/IP (Cerf Kahn)
  • no separation between transport (TCP) and network
    (IP) layers
  • one common header flow control, but not
    congestion control (why not?)
  • fragmentation handled by TCP
  • Todays TCP/IP
  • separate transport (TCP) and network (IP) layer
    (why?)
  • split the common header in TCP and UDP headers
  • fragmentation reassembly done by IP
  • congestion control

14
Devils Advocate
  • Who cares about resource sharing?
  • 1974 cycles, storage, bandwidth expensive,
    people cheap
  • 2002 resources cheap, people expensive
  • 1974 Share computer resources
  • 2002 Communicate with people, access documents,
    buy, sell
  • Does it still make sense to make processes the
    endpoint?
  • Where do people and organizations fit into the
    ISO layering model?

15
Back to the big picture
16
Goals (Clark88)
  • Connect existing networks
  • initially ARPANET and ARPA packet radio network
  • Survivability
  • ensure communication service even in the presence
    of network and router failures
  • Support multiple types of services
  • Must accommodate a variety of networks
  • Allow distributed management
  • Allow host attachment with a low level of effort
  • Be cost effective
  • Allow resource accountability

17
1. Survivability
  • continue to operate even in the presence of
    network failures (e.g., link and router failures)
  • failures (excepting network partition) should be
    transparent to endpoints
  • maintain state only at end-points (fate-sharing)
  • no need to replicate and restore router state
  • disadvantages?
  • Internet stateless network architecture
  • no per-flow state, still have state in address
    allocation, DNS

18
2. Types of Services
  • Add UDP to TCP to better support other types of
    applications
  • e.g., real-time applications
  • Probably main reason for separating TCP and IP
  • Provide datagram abstraction lower common
    denominator on which other services can be built
  • service differentiation considered (ToS header
    bits)
  • was not widely deployed (why?)

19
Application Assumptions
  • Who made them
  • Telephone network voice (web, video?)
  • Cable broadcast (2-way?)
  • X.25 remote terminal access (file transfer?)
  • BBS centralized meeting place (web, p2p?)
  • NAT client/server model (p2p, IM, IP Telephony?)
  • Who didn't Internet
  • Caveat best-effort, unicast, fixed location
    (real-time, multicast, mobility?)
  • Allows development of unforseen applications
  • Web, distributed gaming
  • Sometimes too general
  • Interdomain, multi-source multicast scales poorly
  • Single source multicast scales better Holbrook99

20
3. Variety of Networks
  • Very successful
  • because the minimalist service it requires from
    underlying network only to deliver a packet with
    a reasonable probability of success
  • does not require
  • reliability, in-order delivery, single delivery,
    QoS guarantees
  • IP over everything
  • Then ARPANET, X.25, DARPA satellite network..
  • Now ATM, SONET, WDM, PPP, USB, 802.11b, GSM,
    GPRS, DSL, cable modems, power lines

21
Internet Architecture
  • Packet-switched datagram network
  • IP is the glue
  • Hourglass architecture
  • all hosts and routers run IP
  • Common Intermediate Representation

TCP
UDP
IP
Satellite
ATM
Ethernet
22
Other Goals
  • Allow distributed management
  • each network can be managed by a different
    organization
  • different organizations need to interact only at
    the boundaries
  • doesnt work so well for routing, accounting
  • Cost effective
  • sources of inefficiency
  • header overhead
  • retransmissions
  • routing
  • but routers relatively simple to implement
    (especially software side)

23
Other Goals (Cont)
  • Low cost of attaching a new host
  • not a strong point ? higher than other
    architecture because the intelligence is in hosts
    (e.g., telephone vs. computer)
  • Moores law made this moot point, both lt100
  • bad implementations or malicious users can
    produce considerably harm (remember
    fate-sharing?)
  • DDoS possibly biggest threat to Internet
  • Accountability
  • very little so far

24
What About the Future?
  • Datagram not the best abstraction for
  • resource management,accountability, QoS
  • A new abstraction flow?
  • Routers require to maintain per-flow state (what
    is the main problem with this raised by Clark?)
  • state management
  • Solution
  • soft-state end-hosts responsible to maintain the
    state

25
Summary Minimalist Approach
  • Dumb network
  • IP provide minimal functionalities to support
    connectivity
  • addressing, forwarding, routing
  • Smart end system
  • transport layer or app does more sophisticated
    functionalities
  • flow control, error control, congestion control
  • Advantages
  • accommodate heterogeneous technologies
  • support diverse applications (telnet, ftp, Web, X
    windows)
  • decentralized network administration
  • Disadvantages
  • poor realtime performance
  • poor accountability

26
How is IP Design Standardized?
  • IETF
  • Voluntary organization
  • Meeting every 4 months
  • Working groups and email discussions
  • We reject kings, presidents, and voting we
    believe in rough consensus and running code
    (Dave Clark 1992)
  • Need 2 independent, interoperable implementations
    for standard

27
IP Internet
  • Concatenation of Networks or networks of
    Networks.
  • R is routers and H is hosts.

28
Service Model
  • Connectionless (datagram-based)
  • Best-effort delivery (unreliable service)
  • packets are lost. No recover from lost.
  • packets are delivered out of order
  • duplicate copies of a packet are delivered
  • packets can be delayed for a long time
  • Datagram format

Contains all information for routing!
29
Packet Headers
  • The current Version is 4 or IPv4.
  • HLen- the Header Length from 5-15 in 32-bit
    words.
  • Length- the total length of the packet including
    headers. Max length is 64K.
  • TTL Time To Live is expressed in second. It is
    to prevent packet from permanently circulating in
    a loop.
  • Protocol specify the packet application ex. 1
    for ICMP. It is for demultiplexing to higher
    layer protocols.
  • Checksum is a 1-complement error checksum for
    the header only.

30
Packet Headers (Cont)
  • TOS type of Service
  • Precedence
  • Specify the priority
  • Type of Services Specify routing, for instance
    cheapest, fastest and more reliable
  • D for Delay
  • T for Throughput
  • R for Reliability
  • C for low cost.
  • Note Precedence is only for inside channel
    queuing.
  • Replaced by DiffServ.

0 2 3 7 0 2 3 7 0 2 3 7 0 2 3 7 0 2 3 7
Precedence Type of service Type of service Type of service Type of service
Precedence D T R C
31
Packet Headers (Cont)
  • Options
  • If C set, the option will copied to all
    fragments. Otherwise, only to the first one.
  • Class 0 for control
  • Class 2 for debugging and measurement.
  • Options are rarely used in today except for
    loose and strict source routing parameters.
  • loose and strict source option sometimes, is
    used for IP encapsulation in another IP or
    Tunneling

C Class Number
32
Fragmentation and Reassembly
0 70 70 4 70 7 0 70 70 4 70 7 0 70 70 4 70 7
Identification Flags Fragment Offset
  • Flags
  • DF Dont Fragment
  • MF More Fragment coming
  • In fragmentation, IP copy the original header and
    only modify
  • The length, which is the new length, and offset.
  • Offset is used for reassembly.
  • Note Fragmentation may degrade the network
    performance.
  • That is why the IP packet should be the same of
    TCP packets
  • Modern TCP implement Path MTU discovery.
  • It start with large packet and with DF set flag,
    if it passed
  • TCP keeps the same packet size, otherwise, it
    reduces it.

0 1 2
0 DF MF
33
Fragmentation and Reassembly (cont)
  • Each network has a Maximum Transfer Unit size,
    MTU
  • Strategy
  • fragment when necessary (MTU lt Datagram)
  • fragments are self-contained datagrams
  • do not recover from lost fragments
  • Where to do reassembly?
  • End nodes avoids unnecessary work
  • Dangerous to do at intermediate nodes
  • Buffer space
  • Multiple paths through network

34
Fragmentation is Harmful
  • Uses resources poorly
  • Forwarding costs per packet
  • Best if we can send large chunks of data
  • Worst case packet just bigger than MTU
  • Poor end-to-end performance
  • Loss of a fragment
  • Reassembly is hard
  • Buffering constraints

35
Path MTU Discovery
  • Hosts dynamically discover minimum MTU of path
  • Algorithm
  • Initialize MTU to MTU for first hop
  • Send datagrams with Dont Fragment bit set
  • If ICMP pkt too big msg, decrease MTU
  • What happens if path changes?
  • Periodically (gt5mins, or gt1min after previous
    increase), increase MTU
  • Some routers will return proper MTU
  • MTU values cached in routing table

36
Addressing in IP
  • IP addresses are names of interfaces
  • Domain Name System (DNS) names are names of hosts
  • DNS binds host names to interfaces
  • Routing binds interface names to paths

37
Addressing Considerations
  • Fixed length or variable length?
  • Issues
  • Flexibility
  • Processing costs
  • Header size
  • Engineering choice IP uses fixed length addresses

38
Addressing Considerations
  • Structured vs flat
  • Issues
  • What information would routers need to route to
    Ethernet addresses?
  • Need structure for designing scalable binding
    from interface name to route!
  • How many levels? Fixed? Variable?

39
IP Addresses
  • Fixed length 32 bits
  • Initial classful structure (1981)
  • Total IP address size 4 billion
  • Class A 128 networks, 16M hosts
  • Class B 16K networks, 64K hosts
  • Class C 2M networks, 256 hosts

High Order Bits 0 10 110
Format 7 bits of net, 24 bits of host 14 bits of
net, 16 bits of host 21 bits of net, 8 bits of
host
Class A B C
40
IP Address Classes (Some are Obsolete)
Network ID
Host ID
8
16
32
24
Class A
Network ID
Host ID
0
Class B
10
Class C
110
Class D
Multicast Addresses
1110
Class E
Reserved for experiments
1111
41
Some Special IP Addresses
  • 127.0.0.1 local host (a.k.a. the loopback
    address
  • Host bits all set to 0 network address
  • Host bits all set to 1 broadcast address

42
Subnet Addressing RFC917 (1984)
  • For class B C networks
  • Very few LANs have close to 64K hosts
  • For electrical/LAN limitations, performance or
    administrative reasons
  • Need simple way to get multiple networks
  • Use bridging, multiple IP networks or split up
    single network address ranges (subnet)
  • Must reduce the total number of network addresses
    that are assigned

43
Subnetting
  • Variable length subnet masks
  • Could subnet a class B into several chunks

Network
Host
Network
Host
Subnet
1111..
00000000
..1111
Mask
44
Subnetting Example
  • Assume an organization was assigned address
    150.100
  • Assume lt 100 hosts per subnet
  • How many host bits do we need?
  • Seven
  • What is the network mask?
  • 11111111 11111111 11111111 10000000
  • 255.255.255.128

45
Subnet Addressing Example
  • Assume a packet arrives with address
    150.100.12.176
  • Step 1 AND address with subnet mask

150.100.12.154
150.100.12.176
H1
H2
150.100.12.128
150.100.12.129
150.100.12.55
150.100.12.24
150.100.0.1
H3
H4
R1
To Internet
150.100.12.4
150.100.12.0
46
IP Address Problem (1991)
  • Address space depletion
  • In danger of running out of classes A and B
  • Why?
  • Class C too small for most domains
  • Very few class A IANA (Internet Assigned
    Numbers Authority) very careful about giving
  • Class B greatest problem

47
IP Address Utilization (98)
http//www.caida.org/outreach/resources/learn/ipv4
space/
48
Some Problems
  • Class B sparsely populated
  • But people refuse to give it back
  • Solution
  • Assign multiple class C addresses
  • Assign consecutive blocks
  • RFC1338 Classless Inter-Domain Routing (CIDR)

49
Classless Inter-Domain Routing
  • Do not use classes to determine network ID
  • Assign any range of addresses to network
  • Use common part of address as network number
  • e.g., addresses 192.4.16 - 196.4.31 have the
    first 20 bits in common. Thus, we use this as the
    network number
  • netmask is /20, /xx is valid for almost any xx
  • Enables more efficient usage of address space
    (and router tables)

50
Network Address Translation (NAT)
  • Sits between your network and the Internet
  • Translates local network layer addresses to
    global IP addresses
  • Has a pool of global IP addresses (less than
    number of hosts on your network)

51
NAT Illustration
Pool of global IP addresses
Destination
Source
P
G
Global Internet
Private Network
NAT
Dg
Sp
Data
Dg
Sg
Data
  • Operation Source (S) wants to talk to
    Destination (D)
  • Create Sg-Sp mapping
  • Replace Sp with Sg for outgoing packets
  • Replace Sg with Sp for incoming packets

52
Problems with NAT
  • What if we only have few (or just one) IP
    address?
  • Use NAPT (Network Address Port Translator)
  • NAPT translates
  • Translates Paddr flow info to Gaddr new flow
    info
  • Uses TCP/UDP port numbers
  • Potentially thousands of simultaneous connections
    with one global IP address

53
Problems with NAT
  • Hides the internal network structure
  • Some consider this an advantage
  • Multiple NAT hops must ensure consistent mappings
  • Some protocols carry addresses
  • e.g., FTP carries addresses in text
  • What is the problem?
  • Encryption
  • No inbound connections

54
IPv6 Changes
  • Scale addresses are 128bit
  • Header size?
  • Simplification
  • Removes infrequently used parts of header
  • 40byte fixed size vs. 20 byte variable
  • IPv6 removes checksum
  • Relies on upper layer protocols to provide
    integrity
  • IPv6 eliminates fragmentation
  • Requires path MTU discovery
  • Requires 1280 byte MTU

55
IPv6 Header
0
4
16
24
32
12
19
Version
Class
Flow Label
Payload Length
Next Header
Hop Limit
Source Address
Destination Address
56
IPv6 Changes
  • TOS replaced with traffic class octet
  • Flow
  • Help soft state systems
  • Maps well onto TCP connection or stream of UDP
    packets on host-port pair
  • Easy configuration
  • Provides auto-configuration using hardware MAC
    address to provide unique base
  • Additional requirements
  • Support for security
  • Support for mobility

57
IPv6 Changes
  • Protocol field replaced by next header field
  • Support for protocol demultiplexing as well as
    option processing
  • Option processing
  • Options are added using next header field
  • Options header does not need to be processed by
    every router
  • Large performance improvement
  • Makes options practical/useful

58
Next-lecture Intra-Domain Routing
  • Routing algorithms- two main approaches
  • Distance vector protocols
  • Link state protocols
  • How to make routing adapt to load
  • How to make routing scale
  • Assigned reading
  • KZ89 The revised ARPANET routing metric
  • Tsu88 The Landmark Hierarchy A New Hierarchy
    for Routing in Very Large Networks
About PowerShow.com