\documentclass[11pt,ngerman]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{schulinf}

\usepackage[headsepline]{scrpage2}
\pagestyle{scrheadings}

% Dieses Dokument ist in der Zusammenarbeit von Informatikreferendaren und
% ehemaligen Informatikreferendaren der Studienseminare (heute ZfsL) Arnsberg,
% Hamm und Solingen entstanden.
%
% Das Dokument steht unter der Lizenz: Creative Commons by-nc-sa Version 4.0
% http://creativecommons.org/licenses/by-nc-sa/4.0/deed.de
%
% Nach dieser Lizenz darf das Dokument beliebig kopiert und bearbeitet werden,
% sofern das Folgeprodukt wiederum unter gleichen Lizenzbedingungen vertrieben
% und auf die ursprünglichen Urheber verwiesen wird.
% Eine kommerzielle Nutzung ist ausdrücklich ausgeschlossen.
%
% Die Namensnennung durch einen Verweis und die Lizenzangabe der ursprünglichen
% Urheber auf den Materialien für Schülerinnen und Schüler ist erforderlich.
%
% Die Sammlung der Dokumente steht unter
% http://ddi.uni-wuppertal.de/material/materialsammlung/
% zur Verfügung.
%
% Das LaTeX-Paket zum Setzen der Dokumente der Sammlung steht
% unter  http://www.ctan.org/pkg/schule
% zur Verfügung.

\usepackage[pdfauthor={Referendare der Informatikfachseminare Arnsberg, Hamm und Solingen}]{hyperref}
\includexmp{lizenz}
\cclizenz{byncsaeu}
\footerQRLink{materialsammlung_qr_url.pdf}

\svnid{$Id: Planspiel-Routing.tex 1447 2016-03-21 22:16:55Z pieper $}

\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
\usepackage[ngerman=ngerman-x-latest]{hyphsubst}
% \usepackage[usenames,dvipsnames,pdftex]{xcolor}

\usepackage{comment}
\usepackage[a4paper]{geometry} % to change the page dimensions
\usepackage{graphicx}

\parindent 0pt
\clubpenalty = 10000 % Keine "Schusterjungen"
\widowpenalty = 10000 \displaywidowpenalty = 10000 % Keine "Hurenkinder"


\usepackage{tikz}
\usetikzlibrary{arrows,shapes,backgrounds,calc,trees}
\usepackage{keyval}
\usepackage{ifthen}
\usepackage{pdflscape}
\usepackage{rotating}
\usepackage{caption}
\usepackage{subcaption}

\usepackage{prettyref}
\usepackage{hyperref}
\definecolor{LinkColor}{rgb}{0,0,0}
\hypersetup{
        pdftitle = {Routing},
        pdfsubject = {},
        pdfauthor = {Adrian Salamon, André Hilbig},
        bookmarksnumbered = true,
        bookmarksopen = false,
        colorlinks = false,
        hypertexnames = true,
        a4paper = true,
        colorlinks=true,%
        linkcolor=LinkColor,%
        filecolor=LinkColor,%
        citecolor=LinkColor,
        menucolor=LinkColor,%
        urlcolor=LinkColor,
        breaklinks=true 
}
\usepackage{nameref}

%%% Für Abschnitte %%%
\newrefformat{sec}{Abschnitt~\ref{#1} \textit{\nameref{#1}}, S.~\pageref{#1}}
\newrefformat{anh}{S.~\pageref{#1}}
%%% Für Abbildungen %%%
\newrefformat{fig}{Abb.~\ref{#1}}
%%% Für Tabellen %%%
\newrefformat{tab}{Tab.~\ref{#1}}

\usepackage{todonotes}
\newcommand{\adrian}[1]{\todo[inline, color=green!40, author=Adrian]{#1}}
\newcommand{\andre}[1]{\todo[inline, color=blue!20, author=André]{#1}}


\usepackage[german=guillemets]{csquotes}

\usepackage{multicol}
\usepackage{placeins}

\usepackage{qtree}
%\usepackage{xspace}
%\newcommand{\SuS}{Sch\"ulerinnen und Sch\"uler\xspace}
%\newcommand{\SuSn}{Sch\"ulerinnen und Sch\"ulern\xspace}

\newcommand{\email}{E\mbox{-}Mail\xspace}
\newcommand{\emails}{E\mbox{-}Mails\xspace}

\usepackage[natbib=true, bibstyle=verbose, 
	citestyle=authoryear-ibid, ibidtracker=context,
	backend=biber]{biblatex} 

\renewcommand{\cite}{\parencite}
\renewcommand*{\bibleftparen}{[} 
\renewcommand*{\bibrightparen}{]\midsentence}
\renewcommand*{\mkbibnamelast}{\textsc}

\defbibheading{weiter}{\FloatBarrier\addsec{Weiterführende Literatur}}
\addbibresource{lit-routing.bib}

\usepackage{schule}

%fuer das Einbinden der anderen Dokumente
\usepackage{pdfpages}
\usepackage{standalone}
\usepackage{enumerate}
\usepackage{forloop}
%Vordeklaration, damit im Hauptdokument immer per \renewcommand{cmd}{def} gesetzt werden kann
\newcommand{\names}{}
\newcommand{\anbieter}{}
\newcommand{\zusatzaufgabe}{}


%Zeilenumbrüche
\usepackage{hyphenat}
\hyphenation{Quit-tier-ungs-bo-gen}


\title{Modulbeschreibung: Planspiel Routing}
\author{Adrian Salamon, André Hilbig}
\date{\today} 


\makeatletter
\newcommand*\addsubsec{\secdef\@addsubsec\@saddsubsec}
\newcommand*{\@addsubsec}{}
\def\@addsubsec[#1]#2{\subsection*{#2}\addcontentsline{toc}{subsection}{#1}
  \if@twoside\ifx\@mkboth\markboth\markright{#1}\fi\fi
}
\newcommand*{\@saddsubsec}[1]{\subsection*{#1}\@mkboth{}{}}
\makeatother


\usepackage{array}
\newcolumntype{L}[1]{>{\raggedright\let\newline\\\arraybackslash\hspace{0pt}}m{#1}}
\newcolumntype{C}[1]{>{\centering\let\newline\\\arraybackslash\hspace{0pt}}m{#1}}
\newcolumntype{R}[1]{>{\raggedleft\let\newline\\\arraybackslash\hspace{0pt}}m{#1}}


\begin{document}
\maketitle

\begin{abstract}
Im \enquote{Planspiel Routing} wird die Wegfindung bei der Übertragung von Nachrichten in hierarchischen Netzwerken simuliert.
\end{abstract}

\tableofcontents

\listoffigures


\section{Einleitung}

Das hier vorliegende Dokument stellt die Beschreibung eines Planspiels zum Thema \enquote{Routing}
im Informatikunterricht dar. Ziel ist es, \SuSn die Topologie in Netzwerken und dem dadurch
entstehenden Problem, Wege finden zu müssen, um Daten zu übertragen, näher zu bringen. 

Dafür werden  komplexe Referenzmodelle und entsprechende Schichten vernachlässigt. Es werden 
keine \textit{IP-}~oder \textit{MAC-Adressen} verwendet.
%. Auch die Ebenen der technischen Informatik werden ausgeblendet
Ziel ist es ein simples Transport-Protokoll zu schaffen, das sich in die Alltagswelt der Schüler
integriert und einfach handhabbar ist. Daher werden zur Adressierung normale \email-Adressen
verwendet. Eine Nachricht wird als \email auf Papier festgehalten. Die \SuS leiten die
\enquote{E\mbox{-}Mails} per Hand weiter. Dabei soll nicht der \email-Transport selbst verdeutlicht
werden, sondern es ist lediglich ein Werkzeug, um die Komplexität des Routing zu reduzieren. Hierfür
wird eine Vermischung und Vereinheitlichung der Dienste Domain Name System (\textit{DNS})
und \email vorgenommen. Somit ist es für \SuS einfacher die auszuarbeitenden hierarchischen
Strukturen auch auf andere Dienste im Internet, wie etwa das World Wide Web (\textit{WWW}), zu 
übertragen, ohne auf eine abstrakte, technische Ebene (\textit{IP}, \textit{MAC}, etc.) gehen zu müssen.

Zusätzlich wird im Planspiel Routing Wert auf die Dokumentation des Weges vom Sender zum 
Empfänger gelegt. Sämtliche Zwischenstationen \enquote{quittieren} dafür Erhalt und Weiterleitung
der Nachrichten. 

Für eine genauere Beschreibung von \textit{DNS} und eine gelungene Analogie zum Postsystem empfiehlt
sich \cite[S.\,631ff]{Tanenbaum2003}.
Für einen mögliche Rahmen zur Einbindung des Planspiel Routings in eine Unterrichtsreihe zum Thema \enquote{Kommunikation und Schutz der Privatsphäre} siehe \cite[S\,255ff]{Freischlad2010}. % Hier wird weiterhin eine Vertiefung zum Client-Server Prinzip und zum Verhalten von Mailservern vorgestellt.


\subsection{Problemstellung Routing}
\enquote{Wie kommt meine \email zum Empfänger?} Diese Frage soll durch das Planspiel Routing
beantwortet werden. Um ein Netzwerk erfolgreich betreiben zu können, müssen alle Teilnehmer 
und Knotenpunkte in einer Struktur nach gewissen Regeln handeln. Dafür soll eine einheitliche 
und offene Infrastruktur vorgegeben werden. Hierbei wird auf dynamischen Routing"~Tabellen, die 
etwa mit Hilfe des Dijkstra-Algorithmus den optimalen Weg finden (vgl. \cite[227]{Comer2002}), verzichtet.
Stattdessen wird ein statisches System mit eindeutigen Routingwegen vorgegeben. Somit liegt der didaktische Fokus nicht auf der Algorithmisierung des Routings, sondern auf der Hierarchisierung der Client-Server-Struktur.

\subsection{Kompetenzen}

Im Folgenden werden die in diesem Modul zu erwerbenden Kompetenzen beschrieben.
\citeauthor{Koubek2005} bringt weiterhin an, dass \SuS der Klassen~5-7 in der Lage sein sollten, die
Eigenschaften von \emails zu analysieren und Auffälligkeiten einer E-Mail zu entdecken (vgl.
\cite[S\,62f]{Koubek2005}).

\subsubsection[Inhaltsbereiche]{Inhaltsbereiche\footcite[Vgl. zu Inhaltsbereichen][S.\,12f]{Bildungsstandards}}
	\begin{itemize}
		\item Die \SuS verstehen Operationen auf Daten und interpretieren diese in Bezug auf die dargestellte Information.
		
		\item Die \SuS führen Operationen auf Daten sachgerecht durch.
		
		\item Die \SuS führen die Anweisungen und Regeln des Verfahrens \textit{Routing} aus und arbeiten dabei in Netzen (vgl. \cite[S.\,17]{Bildungsstandards}).
		
		\item Die \SuS nutzen die grundlegenden Konzepte der Datenübertragung (Schreiben/\-Lesen/\-Senden/\-Kopieren).

		%\item Die \SuS finden eine Problemlösung bzw. ein Verfahren indem sie informatisch modellieren. 
	\end{itemize}


\subsubsection[Prozessbereiche]{Prozessbereiche\footcite[Vgl. zu Prozessbereichen][S.\,13]{Bildungsstandards}}

\begin{itemize}
\item Die \SuS kennen und beachten Spielregeln. Sie bleiben in der zugeteilten Rolle.

\item Die \SuS erkennen, dass anhand der \email-Adressen der Routing-Weg vorgegeben und nachvollziehbar ist.

\item Die \SuS erklären die möglichen Übertragungswege innerhalb der hierarchischen Baumstruktur
und differenzieren	 nach den folgenden drei Sonderfällen: Übertragung innerhalb eines Anbieters,
innerhalb des selben Nameserver, außerhalb des Nameservers (vgl. \prettyref{sec:sonderfaelle}).
	
\item Die \SuS reflektieren mögliche Vor- und Nachteile einer Netzwerktopologie bezüglich der Durchführbarkeit des Routings als auch Aspekte der Datensicherheit.

\item Die \SuS reflektieren Aspekte des Datenschutzes bei privaten Nachrichten und entwickeln Ideen	für einen sinnvollen Umgang mit Malware\footnote{Malware sind \emails, die schädliche und ungewollte Inhalte, wie etwa Werbung, schadhafte Software, Spionage etc., enthalten.}.

%\item Die \SuS entwickeln eigene Verhaltensmuster für undefinierte Situationen (Spam).

\item Die \SuS nutzen geeignete Werkzeuge zur Kommunikation und Kooperation.

\item Die \SuS erarbeiten Prinzipien der informationstechnischen Sicherheit: Authentizität, Vertraulichkeit und Integrität.

\end{itemize}

\subsection{Voraussetzungen der \SuS}

%Anhand der kognitiven Entwicklung der \SuS kann das Planspiel Routing ab der 6.~Klasse eingesetzt werden. 
%Das Planspiel Routing kann ab der 6.~Klasse eingesetzt werden.
Besonders bei jungen Lerngruppen sollte stark darauf geachtet werden, dass die jeweiligen Rollen
eingehalten werden und nur die vorgegebenen Kommunikationswege benutzt werden. Ältere Lerngruppen
könnten schneller arbeiten und damit auch zu breiteren und differenzierteren 
Ergebnissen kommen (Datenschutz, Serverüberlastung, \ldots).

Das Planspiel Routing ist auf die Größe der Lerngruppe anpassbar. Eine Mindestanzahl von 12 \SuSn
wird empfohlen.\footnote{Wählbar wären z.\,B. 6~\texttt{Nutzer}, 3~\texttt{Anbieter},
2~\texttt{Nameserver}, 1~\texttt{Wurzelserver} als Teilbäume von S.~\pageref{fig:Baum},
\prettyref{fig:Baum}.} Im Folgenden wird von einer Lerngruppe mit 28 \SuSn ausgegangen.
Es ist zu empfehlen einen Raum mit beweglichen Tischen zu wählen, um mit der Sitzstruktur die
Baumstruktur aufzugreifen und damit die Kommunikationswege auch visuell greifbar und zugleich durch
kurze Wege praktisch umsetzbar zu gestalten.

Inhaltliche Voraussetzung ist, dass die \SuS das Prinzip von Adressaten und Nachrichteninhalt aus
Kontexten wie z.\,B. Postkarten kennen. Sie wissen, dass die Post eingeworfene Postkarten anhand der
Adresse zum Zielort bringt.  Da in dem Planspiel Routing der Kontext \email verwendet wird, sollte
der syntaktische Aufbau einer \email-Adresse bekannt sein (siehe:
\prettyref{sec:Erklaerung-E-Mail-Adressen}).
	%Vielleicht haben die \SuS bereits auch eine eigene private \email-Adresse oder benutzen die
	%\email-Adresse der Eltern. 
Ein Großteil der \SuS wird bereits mit der Übermittlung von Nachrichten in Netzwerken bzw. dem
Internet in Berührung gekommen sein. 

%\subsection{Informatische Gedanke}


\section{Spielrahmen}

\subsection{Grundlegender Aufbau}

%\andre{NICHT vorher die ganze Struktur erklären.}

%\emails sind digitale Briefe, die über das Internet zwischen den Nutzern verschickt werden. 
Im Planspiel Routing wird \email gedanklich auf einen Datenträger reduziert, der zwischen
einem Sender und einem Empfänger ausgetauscht werden kann. Meta-Daten des Header-Bereichs der technischen \email werden durch einen Quittierungsbogen und die Angabe eines Betreffs umgesetzt (vgl. \cite[S.\,457f]{Comer2002}). Der Body-Bereich wird durch einen Nachrichtentext repräsentiert.

Sender und Empfänger sind
\texttt{Nutzer} des zu simulierenden \email-Dienstes. Im Planspiel wird für die Übertragung der \email eine hierarchische
Netzwerkstruktur modelliert, die der Namensauflösung (\textit{DNS}) im Internet ähnelt. Dabei soll
der Transportweg, den die Nachrichten dabei nehmen, mit diesem kleinen Planspiel verdeutlicht
werden.

Die Spieler werden aufgeteilt: Die \email-Nutzer haben im Wesentlichen die Aufgabe, 
Nachrichten zu verfassen, abzuschicken und zu lesen. Daneben müssen die Dienste 
\texttt{Anbieter}, \texttt{Nameserver} und \texttt{Wurzelserver} übernommen werden. Sie stellen
Knotenpunkte von straßenähnlichen Verbindungen zwischen den \email-Nutzern dar. Damit sind sie die
Infrastruktur der \email-Übertragung. Sie müssen die Nachrichten weiterleiten und entscheiden,
welchen Weg die Nachricht weiter nehmen muss. %Wie an einer Kreuzung wird bei ihnen entschieden, welchen Weg die \email nehmen muss, um zu ihrem Ziel zu gelangen.


\subsection{Spezifikationen von \email-Adressen}\label{sec:Erklaerung-E-Mail-Adressen}

Um \email-Nutzer\footnote{Im weiteren Verlauf nur \texttt{Nutzer} genannt.} zu erkennen und
zuordnen zu können, muss ihnen eine eindeutige Adresse zugeordnet werden. \email ist die
Kurzfassung für \enquote{electronic Mail} und bedeutet \enquote{elektronische Post}. Beim
Papierbrief erfolgt die Zuordnung der Adressen mit einem Datensatz der Form Vorname, Nachname, Straße,
Hausnummer, Postleitzahl und Stadt. Die \email-Adresse stellt für jeden Nutzer eine 
\textit{eindeutige} Adresse dar. Sie besteht aus 3 Teilen: 

\begin{multicols}{2}
\begin{enumerate}
  \item Dem (Spitz-)Namen des \texttt{Nutzers}, 
  \item gefolgt von einem @-Symbol und dem Bezeichner des \texttt{Anbieters}, 
  \item gefolgt von einem Punkt und dem Bezeichner des \texttt{Nameservers}.
\end{enumerate}
\columnbreak
\textbf{Beispiel:}\\
$\underbrace{\text{Fritzgerald}}_{\text{Nutzer}}@\underbrace{\text{supersurf}}_{\text{Anbieter}}.\underbrace{\text{de}}_{\text{Nameserver}}$
\end{multicols}
	
Das dreigliedrige Syntax identifiziert also von hinten nach vorne den \texttt{Nameserver}, den \texttt{Anbieter} und schließlich den \texttt{Nutzer} des \texttt{Anbieters} hinter dem @-Symbol (vgl. \cite[456]{Comer2002}).
Bei \email-Adressen sind Groß- und Kleinschreibung nicht relevant. 
%Eine Nachricht an
%\enquote{Fritzgerald@supersurf.de} kommt genau so zum Ziel wie eine an
%\\\enquote{FritzGerald@supersurf.de}. 
Während die \texttt{Nutzer} sich ihren (Spitz-)Namen in der
\email Adresse selbst aussuchen können, sind die Adressen der \texttt{Anbieter},
\texttt{Nameserver} und des \texttt{Wurzelservers} fest vorgegeben. Es ist jedoch zu empfehlen, dass
die \texttt{Nutzer} sich einfache Adressen, wie VORNAME@supersurf.de, wählen. Allerdings müssen alle
Adressen eindeutig sein.

%Doppelt vorkommende
%Vornamen innerhalb der Lerngruppe müssten dann zwecks Eindeutigkeit zu anderen Anbietern wechseln,
%oder noch Buchstaben des Nachnamens hinzufügen.



\section{Rollenbeschreibungen}
 
Für die Rollen der \texttt{Nutzer}, der \texttt{Anbieter}, der \texttt{Nameserver} und des
\texttt{Wurzelservers} gibt es gesonderte Dokumente, auf denen die einzelnen Aufgaben explizit
aufgelistet werden. Diese sollen an die teilnehmenden \SuS entsprechend verteilt werden. Hinweise
für eine Aufteilung zu den Rollen kann \prettyref{fig:Baum} auf S.\,\pageref{fig:Baum} entnommen
werden. Hier folgt nun eine grobe Beschreibung der Rollen.


  \subsection{\email-Nutzer}\label{sec:Nutzer}
	\email-\texttt{Nutzer} sind aktive Teilnehmer am Internet. Sie benutzen die \email als digitalen
	Brief, um Nachrichten an Freunde, Bekannte und Kollegen zu versenden. Dabei müssen sie ihre eigene
	\email-Adresse und die Adressen der Kommunikationspartner kennen, nicht aber den Weg zum Partner.

	Jeder Nutzer kennt nur den Weg zu seinem eigenen \texttt{Anbieter}, der für ihn \emails
	übermittelt. Alle ein- und ausgehenden Nachrichten gehen erst zu dem jeweiligen Anbieter.

  \vspace*{0.2 cm}
  \textbf{Kennt:} Weg zum eigenen \texttt{Anbieter}, \texttt{Adressen} von Bekannten.\\
  \textbf{Aufgabe:} \emails schreiben und lesen.



  \subsection{\email-Anbieter}\label{sec:Anbieter}
  Ein \email-\texttt{Anbieter} übermittelt \email-Nachrichten für seine eigenen \texttt{Nutzer}. Er kennt nur den Weg zu seinen \texttt{Nutzern} und zu seinem übergeordneten \texttt{Nameserver}. Er darf keine Nachrichten direkt an andere \texttt{Anbieter} weiterreichen.

  Sobald einer seiner \texttt{Nutzer} eine Nachricht verschicken möchte, prüft der \texttt{Anbieter}, ob er den Empfänger selbst kennt. In diesem Fall kennt er den direkten Weg zum Ziel und kann die Nachricht übermitteln. Kennt der \texttt{Anbieter} den Weg zum Empfänger nicht, leitet er die Nachricht an seinen \texttt{Nameserver} weiter und fragt diesen, ob er den weiteren Weg kennt. Vor jedem Weiterleiten quittiert der \texttt{Anbieter}, dass er die \email erhalten hat. 

  \vspace*{0.2 cm}
  \textbf{Kennt:} Weg zu den eigenen \texttt{Nutzern}, Weg zum eigenen \texttt{Nameserver}.\\
  \textbf{Aufgabe:} \emails weiterleiten, \emails zustellen, \emails quittieren.



  \subsection{Nameserver}\label{sec:Namesever}
  Ein \texttt{Nameserver} ist für das Übermitteln von \emails zuständig. Er kennt nur den Weg zu
	\textit{seinen} \texttt{Anbietern}. Er darf keine Nachrichten direkt an andere \textit{Nameserver} weiterreichen.

	Wenn der Namesever von seinen \texttt{Anbietern} eine \email erhält, dann prüft er, ob der \texttt{Anbieter} des 
	Empfängers zu ihm gehört, und leitet die \email an diesen \texttt{Anbieter} weiter. Kennt er den
	\texttt{Anbieter} des Empfängers nicht, dann leitet er die \email an den \texttt{Wurzelserver} weiter. Vor jedem Weiterleiten quittiert der \texttt{Nameserver}, dass er die \email erhalten hat.

  \vspace*{0.2 cm}
  \textbf{Kennt:} Eigene \texttt{Anbieter}, \texttt{Wurzelserver}.\\
  \textbf{Aufgabe:} Weganfragen verarbeiten, \emails weiterleiten, \emails quittieren.


  \subsection{Wurzelserver}\label{sec:Wurzelsever}
  Der Wurzelserver ist die höchste Instanz. Es gibt nur einen einzigen Wurzelserver. Wenn er von
	einem Nameserver eine \email erhält, leitet er diese immer an den für den Empfänger zuständigen 
	Nameserver weiter. Vor jedem Weiterleiten quittiert der Wurzelserver, dass er die \email 
	erhalten hat. 
	
	Der Name des Wurzelservers ist \enquote{/}. Der Bezeichner kommt in der \email-Adresse nicht
	vor.

\vspace*{0.2 cm}
\textbf{Kennt:} \textit{alle} \texttt{Nameserver}\\
\textbf{Aufgabe:} Weganfragen verarbeiten, \emails weiterleiten, \emails quittieren.


\section{Die Durchführung}
\subsection{Der Leitfaden}
Die Aufgabe der \texttt{Nutzer} ist es, sich untereinander zu einer Freizeitaktivität zu verabreden.
Dabei sollten sich mindestens drei \texttt{Nutzer} gemeinsam für eine der ausgeschriebenen
Freizeitaktivitäten entscheiden und einen Termin mit Uhrzeit ausmachen. Ein möglichst langer
Routing-Weg kann gewährleistet werden, wenn die Kommunikationspartner ihre Adresse nicht beim selben Anbieter haben. Die gesamte Kommunikation zwischen den Nutzern findet nur schriftlich statt. Sie schreiben \emails mit Betreff, Absender und Adressaten, welche dann über ihre \texttt{Anbieter} und eventuell weitere \texttt{Nameserver} und \texttt{Wurzelserver} bis zum Empfänger weitergeleitet werden. Daran angeheftet werden Quittierungsbögen, die von Anbietern und Servern bei dem Weiterleiten und Verarbeiten der Nachricht quittiert werden. 

Bei Bedarf sollte das Kommunikationsszenario an die Lerngruppe angepasst werden.

\subsection{Quittierung}

Als eine der wichtigsten Aufgaben im Planspiel Routing muss die Quittierung von allen Teilnehmern
konsequent durchgeführt werden.  Jeder Nachricht soll ein Quittierungsbogen mit einer Büroklammer
angeheftet werden. Ausgehend vom Nutzer, der auf dem Quittierungsbogen Absender und Empfänger
notiert, wird an jeder weiteren Station angegeben wo Nachricht und Quittierungsbogen gerade sind,
woher sie kamen und wohin sie weitergeleitet werden. Zusätzlich gibt es auf dem Quittierungsbogen
ein Feld für Fehler, wenn z.\,B. eine Nachricht falsch weitergeleitet wurde oder wegen einer
falschen Adresse unzustellbar ist.

\subsection{Zusatzaufgaben}

Der Leitfaden gilt als Grundlage des Spiels und muss von allen Teilnehmern verfolgt werden. Weitere
Zusatzaufgaben ermöglichen neue Schwerpunkte und können auch punktuell eingesetzt werden, um
unterforderte \SuS mehr zu beschäftigen oder überforderte \SuS zu entlasten.

\subsubsection{Spam}\label{sec:Spam}
Um die Kommunikation etwas zu behindern sind einige Spamnachrichten vorbereitet. Sie werden von der Lehrkraft eingestreut, um einerseits den Spam als ungewollte Werbe- und Müllnachricht einzuführen und andererseits können dadurch gezielt \SuS, die während des Spiels wenig oder keine Post bekommen, stärker ins Spiel integriert werden. Die Spamnachrichten sorgen beim Empfänger für Irritation, weil kein ansprechbarer Kommunikationspartner verfügbar ist und die Nachricht zusammenhangslos erscheint. Der Umgang mit Spam ist bewusst nicht vorgegeben, sondern soll von jedem Nutzer selbst im Spiel entwickelt werden. Die Möglichkeiten der Spambekämpfung können in der Auswertung diskutiert werden.

\subsubsection{Werbung der Anbieter}\label{sec:Werbung}

Die Anbieter taube.de, einfach.net und netz.org haben die Zusatzaufgabe unter jede Nachricht einen Werbesatz zu schreiben. Damit soll simuliert werden, dass der Inhalt einer Nachricht auf dem Weg zum Ziel von Dritten modifiziert werden kann.

Die anderen Anbieter haben die Aufgabe sich nur die Metadaten der Kommunikation zu notieren (Absender, Empfänger, Betreff).

\subsubsection{Überlastungen}\label{sec:Ueberlastung}
Bei der Durchführung des Planspiels kann es zur Überlastung einiger Knotenpunkte kommen. Die Server, insbesondere der Wurzelserver, können wegen der Nachrichtenflut der Nutzer schnell mit der Quittierung und Weiterleitung überfordert sein. Dies ist ein realistischer, aber für den Spielfluss kontraproduktiver Nebeneffekt. Deswegen ist es sinnvoll diese stark frequentierten Knotenpunkte der Kommunikation doppelt zu besetzen. Alternativ kann auch die Lehrkraft bei Engpässen einspringen.

Die Rollen der Knoten können bei großen Lerngruppen mehrfach besetzt werden. Der Arbeitsaufwand
steigt mit geringerer Entfernung zur Wurzel.

    
\subsubsection{Organisation: Adressbuch}\label{sec:Adressbuch}

Da alle \SuS miteinander schriftlich kommunizieren sollen, kann es sinnvoll sein, ein gemeinsames
Adressbuch anzulegen, so dass alle Adressen bekannt sind. Eine einfache Umsetzung wäre eine tabellarische Zuordnung von Adressen und Namen auf einer Folie auf dem OHP, die für alle Teilnehmer sichtbar sein sollte. Alternativ kann auch mit der Tafel oder einem Beamer gearbeitet werden.\footnote{Mit diesem öffentlichen Adressbuch können LDAP-Adressbücher simuliert werden.}




\section{Reflexion}

Jede einzelne Station nimmt während der Durchführung nur einen Teil des gesamten Prozesses wahr.
Eine Reflexion sollte den Teilnehmenden auch die Aufgaben der anderen Rollen verdeutlichen. Dabei
sollten die folgenden Punkte angesprochen werden:
\begin{itemize}
	\item Wie erreichen die Nachrichten ihr Ziel?
	\item Welchen Weg nehmen die Nachrichten?
	\item Wie wird über den Weg der Nachrichten entschieden?
	\item Welche Aufgaben haben die einzelnen Rollen?
\end{itemize}

Ausführlich sollte dabei auf die in \prettyref{sec:sonderfaelle} und \prettyref{sec:sicherheit}
näher beschriebenen Aspekte eingegangen werden.

  \subsection{Abstraktion der Kommunikationsstruktur/Baumstruktur}\label{sec:sonderfaelle}
    Die Lehrkraft sollte während des Spiels beobachten, wie die Kommunikationswege entsprechend der Vorgaben genutzt werden. Es gibt mehrere Fälle die eintreten können:
    \begin{itemize}
     \item Die Nachricht bleibt beim selben Anbieter. Dafür werden übergeordnete Strukturen nicht benötigt. Der Anbieter leitet sie selbst direkt weiter.
     
		 \item Die Nachricht bleibt im selben Namespace\footnote{In diesem Zusammenhang gehören
		 Nachrichten, bei denen Sender und Empfänger den selben Nameserver haben, zum selben
		 \textit{Namespace}.}. Hier muss der Anbieter die Nachricht an seinen Nameserver weitergeben, da
		 er die Adresse von sich aus nicht erreichen kann. Der Nameserver aber kennt die anderen
		 Anbieter und kann die Nachricht weiterleiten.
     
     \item Die Nachricht bleibt nicht im selben Namespace. Nun wird sie bis zum Wurzelserver
						 weitergereicht. Von dort wird sie dann zum entsprechenden Nameserver und Anbieter
						 weitergegeben.
    \end{itemize}

	\begin{figure}[hbt!]
	\centering
	%  \hspace*{-4.0cm} \Tree [.Wurzel  [.\ .de taube  surf ] [.\ .net einfach schnell  ]  [.\ .org inter netz ] ]\adrian{Mit richtigem tikZ-Tree ersetzen}
		\begin{tikzpicture}
		[level distance=1.2cm,
		  level 1/.style={sibling distance=3.5cm},
		  level 2/.style={sibling distance=1.7cm},
		  level 3/.style={level distance=0.8cm},
		  level 4/.style={sibling distance=0.5cm}]
		  
		  \node {Wurzel}
		    child {node {.de}
		      child {node {taube}
		      		    	child {node{@}
		      		    			child{node {1}}
		      		    			child{node {2}}
		      		    			child{node {3}}}}
		      child {node {surf}
		      		    	child {node{@}
		      		    			child{node {4}}
		      		    			child{node {5}}
		      		    			child{node {6}}}}
		    }
		    child {node {.net}
		    	child {node {einfach}
		    			    	child {node{@}
		    			    		child{node {7}}
		    			    		child{node {8}}
		    			    		child{node {9}}
		    			    		}}
		    	child {node {schnell}
		    			    	child {node{@}
		    			    		child{node {10}}
		    			    		child{node {11}}
		    			    		child{node {12}}}}
		    	}
		    child {node {.org}
		    child {node {inter}
		    	child {node{@}
		    			    		child{node {13}}
		    			    		child{node {14}}
		    			    		child{node {15}}}}
		      child {node {netz}
		      	child {node{@}
		      			    		child{node {16}}
		      			    		child{node {17}}
		      			    		child{node {18}}}}
		    };
		\end{tikzpicture}
	  \caption{Baumstruktur der Serververbindungen für 28~\SuS}\label{fig:Baum}
	\end{figure}

    Diese drei Fälle sollten zu einer Struktur abstrahiert werden (siehe~\prettyref{fig:Baum}). Dabei kann direkt die Erfahrung der \SuS aus dem Spiel angesprochen werden. Es ist wichtig, dass jeder Einzelne seine Aufgabe reflektieren kann und seinen Platz im Ganzen wieder findet.

	%	\FloatBarrier
		
	Um die Begriffe des Nameservers oder des Wurzelservers besser einordnen zu können, kann in der Nachbereitung auf Client-Server-Strukturen eingegangen werden. Dies ist für das Planspiel Routing nicht im Vorfeld nötig, kann jedoch zu einem differenzierterem Verständnis führen. Siehe hierfür die fachliche Beschreibung bei \cite[42,441]{Comer2002}.

  \subsection{Probleme in einem Netzwerk}\label{sec:sicherheit}
    Die \SuS können mit Hilfe dieses Spieles bestimmte Problematiken beim Versand von Daten
		über Netzwerke direkt erkennen. Diese sollten in der Reflexionsphase thematisiert werden. Je
		nachdem wie intensiv bestimmte Zusatzaufgaben eingestreut wurden, können einzelne \SuS
		die Probleme vielleicht direkt durch ihre Erfahrungen im Spiel ansprechen:

    \begin{description}
     \item[Authentizität:] \enquote{Spam} kann ungehindert eingeschleust werden. Es wird nicht überprüft, wer diese Nachricht sendet und was sie enthält. Sehr viele solcher Mails könnten sogar den gesamten Datenverkehr lahm legen.(\prettyref{sec:Spam})
     \item[Vertraulichkeit:] Alle Knotenpunkte können die Nachrichten lesen und theoretisch sogar verändern. (\prettyref{sec:Werbung})
     \item[Integrität:] Teilweise sind die Server stark überlastet und Nachrichten kommen verzögert oder sogar beim falschen Empfänger an. (\prettyref{sec:Ueberlastung})
    \end{description}
    

    Damit werden einige wichtige Problematiken beim Versand von Daten über das Internet deutlich. % Vor allem die Datenschutzproblematik sollte den \SuS bekannt werden.
    Allgemein sollen damit die drei Hauptziele der informationstechnischen Sicherheit, die einem
		Netzwerk zu Grunde liegen sollten, erarbeitet und erkannt werden: Authentizität, Vertraulichkeit
		und Integrität. Alle drei Punkte wurden im Spiel nicht realisiert. Den \SuSn soll die
		Wichtigkeit der Sicherheitsziele bewusst werden. Eventuell können auch noch Ideen erarbeitet werden, 
		mit denen das Planspiel entsprechend verbessert wird.

	\section{Mögliche Erweiterungen}

	Je nach Schwerpunkt des Kontextes der Unterrichtsreihe können auf dem Planspiel Routing verschiedene Modifikationen aufbauen, um die aufkommenden Probleme zu lösen oder stärker zu fokussieren.


	\subsection{Authentizität, Vertraulichkeit und Integrität}\label{sec:AVI}
	
	Diese drei ausgearbeiteten Prinzipien lassen sich auch ansatzweise mit dem Planspiel Routing umsetzen.
		
	\begin{description}
	\item[Authentizität] kann mit einer glaubhaften Unterschrift, z.\,B. ein Stempel, die allen zur Überprüfung zur
					Verfügung gestellt wird, erreicht werden. Jeder Nutzer signiert seine \emails mit dieser
					Unterschrift und unterschreibt auch in einer öffentlich sichtbaren
					Datenbank\footnote{Diese öffentliche Datenbank lässt sich mit einer OHP-Folie
					realisieren.}. Bei Letzterem muss geprüft werden, dass die Unterschrift auch wirklich zum
					repräsentierten Urheber passt. Dies kann z.\,B. mit Zeugen beim Unterschreiben umgesetzt werden.  
					Weitere Hinweise können	\cite[56]{Mueller2006} entnommen werden.
	
	\item[Vertraulichkeit] kann mit einer (einfachen) Verschlüsselung umgesetzt werden, die
					verhindert, dass Dritte Einblick in den Inhalt der Nachricht bekommen. Dafür kann z.\,B.
					die Caesar-Verschlüsselung genutzt werden (vgl. \cite{Spioncamp}).
	
	\item[Integrität] kann z.\,B. mit Prüfsummen realisiert werden. Im analogen Kontext könnte die
					Anzahl der Worte/Buchstaben/Vokale/\ldots jeder Nachricht mitgesendet werden. So könnte
					der Empfänger rudimentär prüfen, ob die Nachricht verändert wurde.
	\end{description}

	\subsection{Spambekämpfung}
	Bei der Spambekämpfung gibt es zwei Ansatzpunkte: Entweder, es wird verhindert, dass Spamnachrichten
	in das Netzwerk gelangen, z.\,B. indem nur Nachrichten von authentifizierten Sendern zugelassen
	werden,	oder ungewollte Nachrichten werden anhand von Schlüsselwörtern (Spamfilter) verworfen. Die
	letztere Methode kann auch mit der Automatentheorie verbunden werden. Fachdidkatische Hinweise zu 
	Spamfiltern und Phishing können \cite[S.\,60f]{Koubek2005} entnommen werden.
	
	\subsection{Protokolle}
	Sollte der Fokus stärker auf realistischere \email Kommunikation gelegt werden, dann könnten auch 
	die Postein- und Ausgangsprotokolle durch Kisten bei den \texttt{Anbietern} simuliert werden.
	
	\textit{SMTP} könnte durch eine Art Briefkasten beim \texttt{Anbieter}, in den die \texttt{Nutzer} 
	ihre \emails einwerfen, simuliert werden. Jeder Nutzer erhält außerdem beim Anbieter eine Art
	Postfach, aus dem sie ihre \emails abholen können (\textit{POP3}). Einen umfangreicher Zugang
	hierzu wird	in \cite{Jonietz2005c} beschrieben.
	
	\subsection{Metadatenanalyse}
	Da einige \texttt{Anbieter} die Metadaten der Nachrichten mitschreiben, und dies auch nicht durch die in \prettyref{sec:AVI} beschriebenen Maßnahmen unterbunden werden kann, kann der Nutzen für \texttt{Anbieter} oder weitere fiktive Firmen aus solchen Metadaten abgeschätzt und analysiert werden.

%\nocite{*}
%\clearpage
\nocite{Bell2005, Jonietz2005a, Jonietz2005b}
	\sloppy\printbibliography[heading=weiter]

%\clearpage
\appendix
\addsec{Anhang}
	
\addsubsec{Materialliste für ein Beispielsetup mit 28 \SuS}
\begin{itemize}[$\Box$]
	\item 1\,x OHP Folie für öffentliches Adressbuch (siehe \prettyref{sec:Adressbuch})
	\item 28\,x Papier für Namensschilder für alle Teilnehmer
	\item[] 18\,x Rollenbeschreibung \texttt{Nutzer}:
		\begin{itemize}\itemsep -0.5em
		\item[$\Box$] 3\,x Nutzer@taube.de
		\item[$\Box$] 3\,x Nutzer@surf.de
		\item[$\Box$] 3\,x Nutzer@einfach.net
		\item[$\Box$] 3\,x Nutzer@schnell.net
		\item[$\Box$] 3\,x Nutzer@inter.org
		\item[$\Box$] 3\,x Nutzer@netz.org
		\end{itemize}
	\item 6\,x Rollenbeschreibung \texttt{Anbieter}
	\item 3\,x Rollenbeschreibung \texttt{Nameserver}
	\item 1\,x Rollenbeschreibung \texttt{Wurzelserver}
	\item 6\,x Übersicht Freizeitangebote (für Nutzer, alternativ: Projektion per Beamer oder OHP.)
	\item 50\,x Quittierungsbogen
	\item 50\,x Büroklammern
	\item 50\,x leeres A5-Papier für \emails. 
	\item 3\,x leeres A4-Papier für Metadatenprotokolle der Anbieter (siehe \prettyref{sec:Werbung})
\end{itemize}

\addsubsec{Material und Kopiervorlagen}\clearpage
\pagestyle{empty}

%\begin{comment}
{\addcontentsline{toc}{subsubsection}{Freizeitangebote}
	\input{freizeitangebote.tex}}\clearpage
	
{\addcontentsline{toc}{subsubsection}{Quittierung}
\newgeometry{margin=1cm,tmargin=1cm}
\input{quittierung.tex}
\restoregeometry
}\clearpage
	
{\addcontentsline{toc}{subsubsection}{Spam}
\input{spam.tex}}\clearpage
	

{\addcontentsline{toc}{subsubsection}{Rollenbeschreibung Nutzer}
\input{nutzer-rolle.tex}}

{\addcontentsline{toc}{subsubsection}{Rollenbeschreibung Anbieter}
\input{anbieter-rolle.tex}}

{\addcontentsline{toc}{subsubsection}{Rollenbeschreibung Nameserver}
\input{nameserver.tex}}

{\addcontentsline{toc}{subsubsection}{Rollenbeschreibung Rootserver}
\input{rootserver.tex}}
%\end{comment}


\end{document}
