Assignment 1
prepared by
Gerwin Schalk, MS
gschalk@usa.net
http://www.gerv.org
Internet Protocols
Dr. Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
Albany, NY
January 2001
Contents
1 Reading Assignments
1.1 tcpdump, ifconfig, netstat . . . . . . . . . . . . . . . . . . . . .
1.1.1 tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Paper Summaries . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 A Protocol for Packet Network Intercommunication . . .
1.2.2 The Design Philosophy of the DARPA Internet Protocols
1.2.3 End-To-End Arguments in System Design . . . . . . . .
1.3 Assumptions of IP . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 End-To-End Argument: 3 Examples . . . . . . . . . . . . . . . .
1.4.1 Delivery Guarantee . . . . . . . . . . . . . . . . . . . . .
1.4.2 Secure Transmission of Data . . . . . . . . . . . . . . . .
1.4.3 Duplicate Message Suppression . . . . . . . . . . . . . .
1.5 Four Good Reasons for the End-To-End Argument . . . . . . .
1.6 Reordering Goals . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Services/Building Blocks . . . . . . . . . . . . . . . . . . . . . .
2 Addressing
2.1 Analyze Two MAC Addresses . . . . . . . . . . .
2.2 Network Number, Subnet Number, Host Number
2.3 Telephone Network/ARP . . . . . . . . . . . . . .
2.4 Organization and Subnets . . . . . . . . . . . . .
3 Internetworking
3.1 Performance Scaling . . . . . . . . . . . . .
3.2 Address Allocation, Configuration, Mapping
3.2.1 Address Allocation . . . . . . . . . .
3.2.2 Configuration . . . . . . . . . . . . .
3.2.3 Address Mapping . . . . . . . . . . .
3.3 Heterogeneity Problem . . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
2
3
3
3
3
4
4
4
4
4
5
5
5
.
.
.
.
6
6
6
7
7
.
.
.
.
.
.
8
8
8
8
8
9
9
CONTENTS
4 Concepts/Design/Performance
4.1 Packet, Packet Switching, Multiplexing, Statistical Multiplexing
4.1.1 Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Packet Switching . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Statistical Multiplexing . . . . . . . . . . . . . . . . . . .
4.2 Packet Switching/Circuit Switching . . . . . . . . . . . . . . . .
4.3 Program Speedup . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
10
10
11
11
Chapter 1
Reading Assignments
1.1
1.1.1
tcpdump, ifconfig, netstat
tcpdump
tcpdump is a packet filter designed to filter and log activity on a network. It puts
interfaces in promiscous mode, that is, they capture all packets on the network. It
has detailed configuration options to define which packets will be logged. In the
following example, I recorded the traffic that was generated when my machine used
DHCP to determine its settings:
[root@cm-24-29-78-183 /]# tcpdump ip host 24.29.78.183 >test.txt
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on all devices
10:32:58.060585 eth0 > 24.29.78.183.bootpc > 24.92.33.51.bootps: xid:0x72172913
C:24.29.78.183 ether 0:e0:29:13:d3:c [|bootp]
10:32:59.932220 eth0 < 24.92.33.51.bootps > 24.29.78.183.bootpc: xid:0x70172913
Y:24.29.78.183 G:10.29.72.1 ether 0:e0:29:13:d3:c [|bootp] (DF)
10:32:59.962280 eth0 < 24.92.33.51.bootps > 24.29.78.183.bootpc: xid:0x71172913
Y:24.29.78.183 G:10.29.72.1 ether 0:e0:29:13:d3:c [|bootp] (DF)
10:33:00.133071 eth0 < 24.92.33.51.bootps > 24.29.78.183.bootpc: xid:0x71172913
Y:24.29.78.183 G:10.29.72.1 ether 0:e0:29:13:d3:c [|bootp] (DF)
10:33:04.952495 eth0 > 24.29.78.183.1032 > ns1-100bt.nycap.rr.com.domain:
6657+ PTR? 1.72.29.10.in-addr.arpa. (41)
10:33:04.964178 eth0 < ns1-100bt.nycap.rr.com.domain > 24.29.78.183.1032:
6657 NXDomain* 0/1/0 (118) (DF)
10:33:04.965275 eth0 > 24.29.78.183.1032 > ns1-100bt.nycap.rr.com.domain:
6658+ PTR? 23.33.92.24.in-addr.arpa. (42)
1
CHAPTER 1. READING ASSIGNMENTS
2
10:33:04.977554 eth0 < ns1-100bt.nycap.rr.com.domain > 24.29.78.183.1032:
6658* 1/2/2 PTR ns1-100bt.nycap.rr.com. (167) (DF)
1.1.2
ifconfig
ifconfig is a command used to configure network adapters. It can start and stop
individual adapters, or set specific parameters, e.g., MTU, etc.
[root@cm-24-29-78-183 /]# ifconfig
eth0
Link encap:Ethernet HWaddr 00:E0:29:13:D3:0C
inet addr:24.29.78.183 Bcast:24.29.79.255 Mask:255.255.248.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:607 errors:0 dropped:0 overruns:0 frame:0
TX packets:156 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:11 Base address:0x250 Memory:c8000-ca000
lo
1.1.3
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
netstat
netstat is used to print current network connections, routing information, interface
statistics, and other information. In the following example, I used it to print the
routing table of my Linux machine:
[root@cm-24-29-78-183 /]# netstat -route
Kernel IP routing table
Destination
Gateway
Genmask
24.29.72.0
*
255.255.248.0
127.0.0.0
*
255.0.0.0
default
gw-24-29-72.nyc 0.0.0.0
Flags
U
U
UG
Metric
0
0
0
Ref
0
0
0
Use
0
0
0
Iface
eth0
lo
eth0
CHAPTER 1. READING ASSIGNMENTS
1.2
1.2.1
3
Paper Summaries
A Protocol for Packet Network Intercommunication
This classical paper ([1]) describes the necessary considerations for communication in
heterogeneous networks. The authors address problems including different addressing schemes, different packet sizes, transmission failure and differences in transmission performance (e.g., delay, maximum bandwidth). They analyze the superiority
of having a common transmission protocol over the possibility that there are translators that can translate from any protocol used on one network to any protocol
on another network. The authors introduce the concept of a ”gateway” between
two connecting networks and describe its necessary functionality. Finally, they propose this common protocol and describe its addressing scheme, packet format, error
handling, and flow control.
1.2.2
The Design Philosophy of the DARPA Internet Protocols
TCP/IP has been described and discussed in many publications since it has first
been defined. This paper ([2]) sheds light on the reason for many of TCP/IP’s characteristics. It discusses major as well as minor historical goals in the design process
(e.g., communication between heterogeneous rather than homogeneous networks,
high-level transparency of transient failures) and analyzes the expected types of services both of TCP and UDP. The author suggests some possible improvements in
the protocol and discusses some fundamental difficulties the initial designers faced
when they defined the internet protocols’ architectural strategies.
1.2.3
End-To-End Arguments in System Design
Any complex interface may be designed in a somewhat structured way (e.g., layered, hierarchical, etc.). Since software engineering has as of yet not achieved the
same high level of formal description as other engineering sciences (e.g., electrical
engineering), many decisions in the design process of such interfaces or protocols are
somewhat arbitrary. The detailed definition of the types of services in the different
levels of the Internet protocol suite are such an example. This paper ([3]) analyzes
the pros and cons of placing higher level functionality (e.g., error-free transmission)
in low-level protocols. The authors conclude that one should be advised to reduce
his or her temptation to do so.
CHAPTER 1. READING ASSIGNMENTS
1.3
4
Assumptions of IP
IP makes the assumption that
• all networks understand a uniform addressing scheme
• all networks understand how to reasonably reliable transport a packet
• all networks know how to fragment packets, if necessary
1.4
1.4.1
End-To-End Argument: 3 Examples
Delivery Guarantee
Delivery Guarantee is concerned with the reliable delivery of messages. The endto-end argument works in this case, because, even if lower layers would guarantee
delivery, some other problem could cause a message to disappear after it arrived at
the destination, but before it has been processed and acted upon. Therefore, high
level end-to-end acknowledgement is still needed, not matter what lower levels are
doing.
1.4.2
Secure Transmission of Data
Another example is the secure transmission of data: assume, that lower layers encrypt data along the physical path and decrypt it upon arrival. Thus, data would
be unsafe (i.e., decrypted) on its way from arrival to the application. Furthermore,
the application would still have to perform authenticity checks. Once again, a good
balance is probably a good idea: simply functionality (e.g., very simple encryption)
on low layers, high level encryption on higher layers.
1.4.3
Duplicate Message Suppression
Duplicate messages can be generated in many different points in a communication
process. However, suppressing duplicate messages entirely at the lower layers is not
possible and thus, complete resolution of this issue will always have to be dealt with
by higher layers. Consider duplicate message generation by a higher layer (e.g.,
error handling method of an application or a human trying to retype something he
thought had no effect): this will look like a new unique message and could never be
dealt with by low layers in absence of higher-level information.
CHAPTER 1. READING ASSIGNMENTS
1.5
5
Four Good Reasons for the End-To-End Argument
• without it, higher layers would have to pay the price for services they might
not need
• higher layers might still have to implement certain services, even though lower
layers already implement it (e.g., reliable delivery)
• if many services would be packed into low layers, these would have to be
re-engineered for different networks
• designing IP to be a simple and stateless protocol makes it much easier to
recover from system crashes
1.6
Reordering Goals
I assume that ”The Internet architecture must be cost effective” would have been
the primary goal. I further assume that this would have resulted in a (generally)
lower available bandwidth. This might have eliminated the possibility to account
for a variety of networks (since tighter integration to a specific network would lead
to increased performance). This could have led to: more memory effective protocols
(e.g., smaller packet headers). Only one network architecture would have been
possible on the Internet (e.g., Ethernet), a uniform MTU could have eliminated the
need for fragmentation, etc.
1.7
Services/Building Blocks
IP can be looked at as a building block, because it assumes no (or only very basic)
services. TCP/IP, on the other hand, is a service providing reliable and connectionoriented transmission.
I did not exactly understand the second part of this question. I was not sure
whether we should list building blocks and their respective services, or describe their
general characteristics. I will elaborate on IP as a building block used to implement
services a little more:
IP only provides minimal services. It thus nicely conforms with the end-to-end
argument. Because the architecture of all protocols on the Internet is layered (OSI7), all higher-level protocols are ultimately transported via IP. The building block
IP thus supports a variety of services.
Chapter 2
Addressing
2.1
Analyze Two MAC Addresses
The 48 bit MAC addresses consist of a 24 bit OUI and 24 bits assigned by the
vendor. Bit 0 in byte 0 is the G/L bit and bit 1 is the G/I bit.
80:01:47:00:04:00 (hex)
10000000:00000001:01000111:00000000:00000100:00000000 (bin)
This is a global address.
40:01:54:00:00:01 (hex)
01000000:00000001:01010100:00000000:00000000:00000001 (bin)
This is a local address.
There is some inconsistency between the course material (slide 40) and other
sources (e.g., http://as400bks.rochester.ibm.com). I therefore did not further elaborate on this question.
2.2
Network Number, Subnet Number, Host Number
IP 135.104.128.100, mask 255.255.192.0 (dec) is
IP 10000111.01101000.10000000.01100100,
mask 11111111.11111111.11000000.00000000 (bin)
This results in
10 → class B
network ID 135.104
6
CHAPTER 2. ADDRESSING
7
subnet ID 10 (bin) = 2 (dec)
host ID 01100100 (bin) = 100 (dec)
2.3
Telephone Network/ARP
The telephone network is a simple circuit switched network in which the phone numbers are hierarchically organized. It does not have names or name resolution protocols, because those would be very difficult to implement without packet switched
networks.
2.4
Organization and Subnets
140.25.0.0 (dec) is
10001100.00011001.00000000.00000000 (bin)
This is a class B address. To accomodate for 25 hosts on each subnet, the organization has to reserve at least 5 bits for the host ID (up to 30 hosts). Therefore, the subnet mask would be 11111111.11111111.11111111.11100000 (bin) or
255.255.255.224 (dec). The subnet ID has 11 bits and thus allows for 2046 subnets. If 25 hosts are on each subnet that could hold up to 30, 5 addresses per subnet
are being wasted.
Chapter 3
Internetworking
3.1
Performance Scaling
IP allows for performance scaling, because it does not make (or at least only very
loose) assumptions on the performance of the underlying data link layer. In addition,
the addressing scheme is hierarchical. Thus, problems (e.g., routing, address resolution, etc.) can be reduced to a subset of the internetworking domain. Bridges fail to
solve the scaling problem, because they simply forward packets without analyzing
and filtering them.
3.2
3.2.1
Address Allocation, Configuration, Mapping
Address Allocation
The address allocation issue with IP is that, since addresses are not flat addresses,
but rather split in a host and a network ID, almost always a network will waste
addresses that it does not need. In addition, since IPv4 addresses have only 32 bits,
we’ll be running out of these addresses sooner or later. Furthermore, if an ISP has a
class B address and at one point there are more than 60000 user online, the address
space is exhausted and new users can’t be served.
3.2.2
Configuration
Configuration issues arise, because a machine’s IP address depends on which network
it is connected to. If the machine is moved, the IP address changes and software
might have to be re-configured. In addition, routing information between networks
has to be configured.
8
CHAPTER 3. INTERNETWORKING
3.2.3
9
Address Mapping
There are mapping issues on IP and X25, since Internet and X25 addresses are
incompatible. Mapping of IP to ATM is difficult, too.
3.3
Heterogeneity Problem
The heterogeneity issue is addressed in IP by defining a common packet format and
a common address space. In addition, IP assumes very little about the performance
of individual networks. IP only assumes best effort packet delivery and that hosts
understand how to fragment packets, if necessary.
Chapter 4
Concepts/Design/Performance
4.1
4.1.1
Packet, Packet Switching, Multiplexing, Statistical Multiplexing
Packet
A packet is data transmitted over a packet-switching network. A packet consists of
a header that lists, among other details, source and destination address, and actual
data.
4.1.2
Packet Switching
Packet switching is a technique in which messages are divided into packets before
they are sent. Each packet is then transmitted individually. Once the destination received all packets comprising a message, the packets are recompiled into the
message.
4.1.3
Multiplexing
Multiplexing is a technique that allows signals from multiple sources to be transmitted over a single line. There are many implementations, both analog and digital
to do this. They all have in common that the different signals are being assigned
specific fractions of a transmission domain (i.e., time, frequency, etc.) such that
they can be transferred virtually (or actually) simultaneously.
4.1.4
Statistical Multiplexing
Multiplexing is performed based on statistical assumptions on peak transfer rate
and average transfer rate, to better utilize bandwidth, or optimize some other com10
CHAPTER 4. CONCEPTS/DESIGN/PERFORMANCE
11
munication property.
4.2
Packet Switching/Circuit Switching
Packet switching is fundamentally more efficient than circuit switching, because in
circuit switching bandwidth is used whether or not it is needed. In packet switching,
bandwidth is only used, if data is actually transmitted.
4.3
Program Speedup
The program runs in 100 s and multiplication instructions comprise 60% of the
program (while not specified whether 60% of time or of memory, I assumed time).
Thus, they use 60 s of the total 100 s and the rest (that can’t be sped up by Designer
M) 40 s. Since 40 s is still more than the targeted goal (25 s = 100s
), speeding the
4
program up four times by speeding up multiply operations is not possible.
Bibliography
[1] V. Cerf and R. Kahn. A protocol for packet network intercommunication. IEEE
Transactions on communications, 22(5):637–648, 1974.
[2] D. Clark. The design philosophy of the DARPA internet protocols. Proc. SIGCOMM ’88 4, Massachusetts Institute of Technology, 1988.
[3] J. Saltzer, D. Reed, and D. Clark. End-to-end arguments in system design. ACM
Transactions on Computer Systems, 2(4):277–288, 1984.
12