Schließt sich ein neues nomadisches System an den Switch an, so versucht es zuerst durch das Senden eines DHCPDISCOVER einen zuständigen DHCP-Server zu erreichen. Der Switch empfängt das Frame und gibt über seinen Agenten (SwitchAgent) eine Ereignismeldung an den Event Channel ab. Das Ereignis enthält die MAC-Adresse und den Port, an den sich das neue System angeschlossen hat. Der Manager, der auf neue Ereignismeldungen vom Event Channel wartet, empfängt die Information und versucht anhand bestimmter Regeln, den sogenannten Policies ([Rad98]), das System
Kann der Manager das System einem oder mehreren VLAN's zuordnen, so wird der Switch durch einen Methodenaufruf des Managers auf dem Agenten dahingehend konfiguriert. Im nächsten Schritt geht der normale Client/Server-Dialog unter DHCP weiter (siehe [Rie96,Dro93,Dro97]). Die Konfiguration des DHCP-Servers wird dabei von seinem Agenten, dem DHCP-Agent, bewerkstelligt. Dieser wiederum bekommt Vorgaben in Form von Methodenaufrufen vom Manager. Die Interaktion zwischen Manager, DHCP-Agent und DHCP-Server wird in [Rad98] und [Dem98] näher beschrieben.
Verfügt der DHCP-Server über die Möglichkeit, Systeme anhand starker Authentifizierung mittels DHCP zu identifizieren [Dro96], können diese durch Interaktion mit dem Manager weiteren VLAN's zugeordnet werden. Beim Anschluß von stationären Rechnern oder DTE's, die nicht das DHCP-Protokoll verstehen, fällt der Fall der Authentifizierung mittels DHCP im Managementszenario weg. Stattdessen muß das Managementsystem in der Lage sein, nur mit Hilfe der übermittelten MAC-Adresse das System zu identifizieren und einem VLAN zuzuordnen (Kapitel 3.2.3).
Abbildung 3.5 soll den Anschluß eines neuen Systems an ein geswitchtes LAN in Anlehnung an [Hei97] darstellen. Dabei wird der zeitliche Verlauf der Anmeldung skizziert.
Zu Beginn muß der Switch eine Verbindung von einem Port zum DHCP-Server gewährleisten. Dies kann durch einen Defaulteintrag für bestimmte Ports geschehen. Im Gegensatz zu [Hei97] meldet in diesem Szenario der Switch, der den DHCPDISCOVER des nomadischen Systems an den DHCP-Server weiterleitet, dem Managementsystem das ,,Erscheinen`` des neuen Systems. Das Managementsystem entscheidet aufgrund seiner Policies über die ,,Zulassung`` des Endsystems unter anderem nach obigen Beispielkriterien (siehe Kapitel 3.2.3). Darüberhinaus teilt es dem DHCP-Server die zu verwendende Konfigurationsinformation für dieses System mit. Erst dann kann der DHCP-Server die Konfiguration mit dem Client aushandeln.
Der DHCP-Server muß aus diesem Grund bis zu diesem Zeitpunkt warten. In der Zwischenzeit könnte der DHCP-Server zum Beispiel nichts tun und nur auf die Beendigung seiner Konfiguration warten, um anschließend einen DHCPOFFER an den Client zu schicken. Eine andere Möglichkeit besteht darin, einen DHCPOFFER mit einer ungültigen Konfiguration an den Client zu schicken, um Zeit zu gewinnen, und den anschließenden DHCPREQUEST des Clients mit einem DHCPNAK zu verweigern. Daraufhin muß der Client eine neue Abfrage initialisieren (DHCPDISCOVER).
Der DHCP-Client wartet eine gewisse Zeit auf das Eintreffen eines DHCPOFFER. Trifft dieses nicht in dieser Zeitspanne ein, so versucht er erneut eine Abfrage (DHCPDISCOVER) an den DHCP-Server zu senden. Gleiches gilt für das Warten auf eine Antwort auf einen DHCPREQUEST.
Handeln DHCP-Server und Client schließlich eine gültige Konfiguration aus, die das Endsystem akzeptiert, so teilt das Managementsystem das nomadische Endsystem einem VLAN zu. Der Switch schaltet die entsprechenden Ports frei.
Zur Verwirklichung dieses und ähnlicher Szenarien bedarf es eines Managementsystems, das die Steuerung der einzelnen Komponenten übernimmt (siehe dazu [Rad98]). Die technische Realisierung dieser Managementlösung wird auf CORBA aufbauen, das für die Interaktion verteilter Objekte besonders geeignet ist, wie in Kapitel 2.3 herausgestellt wurde.