1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
\documentclass[a4paper,9pt]{article}
\author{Camil Staps\\\small{s4498062}}
\title{Networking\\\large{Assignment 5}}
\date{April 27, 2016}
\usepackage{polyglossia}
\setmainlanguage{english}
\usepackage{geometry}
\usepackage{enumitem}
\setenumerate{label=\alph*)}
\usepackage{amsmath}
\usepackage{minted}
\begin{document}
\maketitle
\section{Packet forwarding}
\begin{enumerate}
\item
\begin{tabular}{l | l}
Dest. addr. & Interface \\\hline
H1 & 1 \\
H2 & 2 \\
H3 & 3 \\
\end{tabular}
\item No: in a datagram network, the forwarding table entries are tuples of
destination address prefixes and link interfaces. There is no way to
distinguish packets coming from host H1 from packets coming from host H2.
\item
\begin{tabular}{l | l | l | l}
\multicolumn{2}{c|}{Incoming} & \multicolumn{2}{c}{Outgoing} \\\hline
Interface & VC\# & Interface & VC\# \\\hline
1 & 13 & 3 & 23 \\
2 & 37 & 4 & 47 \\
\end{tabular}
\item
\begin{enumerate}[label=\Alph*.]
\setcounter{enumii}{1}
\item
\begin{tabular}{l | l | l | l}
\multicolumn{2}{c|}{Incoming} & \multicolumn{2}{c}{Outgoing} \\\hline
Interface & VC\# & Interface & VC\# \\\hline
1 & 23 & 2 & 33 \\
\end{tabular}
\item
\begin{tabular}{l | l | l | l}
\multicolumn{2}{c|}{Incoming} & \multicolumn{2}{c}{Outgoing} \\\hline
Interface & VC\# & Interface & VC\# \\\hline
1 & 47 & 2 & 57 \\
\end{tabular}
\item
\begin{tabular}{l | l | l | l}
\multicolumn{2}{c|}{Incoming} & \multicolumn{2}{c}{Outgoing} \\\hline
Interface & VC\# & Interface & VC\# \\\hline
1 & 33 & 3 & 43 \\
2 & 57 & 3 & 67 \\
\end{tabular}
\end{enumerate}
\end{enumerate}
\section{Switching}
\begin{enumerate}[label=\arabic*.]
\item Only one packet can be handled at the same time, so we may have to wait
for $n-1$ packets. That gives a delay of $(n-1)\cdot D$.
\item Every packet goes to a different output port, so we will never go over
the bus bandwidth (which is at least 1). Therefore, there is no queuing
delay in this case.
\item Every packet goes to a different output port and therefore uses a
different vertical bar in the interconnection network. Queuing can only
occur when two packets need the same vertical line, but as explained this
cannot happen. Therefore, there is no queuing delay in this case either.
\end{enumerate}
\section{Subnets}
223.1.17.128/26 can support up to 64 addresses (so also 60).\\
223.1.17.0/25 can support up to 128 addresses (so also 90).\\
223.1.17.192/26 can support up to 64 addresses (so also 12).
The subnets do not conflict; their binary prefixes in the last byte are
\texttt{10}, \texttt{0} and \texttt{11} respectively.
\section{ICMP Traceroute}
\texttt{do\_one\_ping} and the underlying functions have been adapted to return
a tuple \texttt{(address, icmp\_type)} (or \texttt{(None, None)} in case of a
timeout).
The function \texttt{ping} has been replaced by \texttt{traceroute}. This uses
a counter \texttt{i} to increase the TTL of the echo requests we send. For each
TTL we call \texttt{do\_one\_ping} which gives us either \texttt{(None, None)}
if no server responded, or \texttt{(address, icmp\_type)}, where
\texttt{icmp\_type} is either \texttt{ICMP\_ECHO\_REPLY} or
\texttt{ICMP\_TIME\_EXCEEDED}. We can use this to stop (in case of a reply) or
continue (in case of a TTL excess).
The logic may be found in \texttt{traceroute}:
\inputminted[linenos,xleftmargin=1cm,firstline=102,lastline=118]{python}%
{assignment5/traceroute.py}
\end{document}
|
